Kicking off the 'Projects and Agile Community of Practice'

Earlier this year I delivered two well received presentations on the topic of Agile leadership roles - where do Project Managers and Scrum Masters fit? Following the presentations we had strong interest from the audience for Equinox IT to host a Community of Practice around the topics of Projects and Agile.

On Tuesday last week I facilitated the first 'Projects and Agile Community of Practice' event, hosted at our Equinox IT offices in Wellington.

We had a great turn out of client staff and Equinox IT team members representing roles such as CIO, Project / Programme Manager, Project Management Office Manager, Application Development Manager, Consultant and Agile Coach.

I initiated the session with a round of introductions and asked people to share their expectations on the way the Community of Practice should run. Given people want to be comfortable sharing experiences, ideas and learning during the sessions, participants placed emphasis on the need for confidentiality, trust and Chatham house rules amongst the group.

Using a Lean Coffee format

I facilitated the session using a Lean Coffee format. You can find more details about the format on the Lean Coffee website, but in a nutshell I asked participants to write the topics they wanted to discuss or faced challenges with on post-it notes. The participants then dot voted topics and the ones with the most votes were discussed and the remainder were added to a Kanban style backlog of future discussion topics. We spoke about each topic for 5-minute intervals at which point the group again voted whether to continue the discussion on the current topic or move onto the next highest voted topic.

Topics discussed

During this inaugural Community of Practice we discussed three topics:

Budgeting for Agile projects

The topic of 'Budgeting for Agile projects' received the most votes during the Lean Coffee dot voting exercise. The topic relates to organisations that have traditional expectations around budgeting and how to meet these expectations with Agile projects which by nature are not fully planned upfront.

There was a lot of discussion around the topic with suggestions for using story mapping to breakdown projects to come up with a ballpark figure based on a known or estimated team velocity. Others spoke about getting 12 months of funding and delivering the highest priority features within that period with regular feedback to the project board on progress. Another example given related to a project where just enough budget to complete a minimum viable product was asked for, with the view to ask for more thereafter based on the learning and next steps from that MVP.

One participant raised a valuable point that with project budgets we think of cost, and the importance of those governing projects to shift towards value and the required investment (cost) to achieve that value.

I spoke about the fact that budgeting issues are not unique to Agile projects. Even on traditional and waterfall projects stakeholders want all of the scope, for a known cost, delivered at a set time. This iron triangle doesn't work for any project type and it needs stakeholders to be more realistic about what is most important, which Agile practices can help them realise.

With help from members of the Community of Practice I plan to pull together some of the current industry thinking on budgeting for Agile projects to share with the group in a future session.

DevOps teams, what do they look like?

One of the participants spoke about a change in their organisation to move applications onto Amazon Web Services (AWS) infrastructure and adopt a DevOps culture. The teams involved are waiting to be told what they are going to be doing, but no one really knows what to tell them.

During the discussion on this topic one suggestion was to set up a Kanban board and start by moving one application onto the AWS infrastructure and learn and get better.

Another person spoke about how they had the opportunity to start from new in the cloud, rather than move applications into cloud infrastructure, and this had made it much easier to establish a new DevOps way of working using Continuous Delivery.

Some risks of the early stages of DevOps were also raised where in one example initially DevOps meant that both the development team and the operations team had access to each other's environments, which had caused problems.

My view was that DevOps is the high-end of Agile team performance. It will take a while to achieve, but a pragmatic first step would be to co-locate the development and operations teams together to build trust.

The co-location suggestion spawned a side-discussion about the realities of today's work environments where many organisations have moved to hot desking and international outsourced development teams. While co-location undoubtedly has benefits for Agile and DevOps teams, it may not be realistic for some organisations given the other decisions made. Those people in organisations that had moved to hot desking noted it was difficult to find people and as a result they collaborated less and didn't talk to people as often, using instant messenger more often instead.

Governance of Agile projects

The person who raised this topic spoke about it being hard to know where you are in an Agile project and it is difficult for a steering committee to govern when they are used to waterfall projects with considerable upfront planning and traditional monthly reporting. At times, governance was slowing Agile teams down rather than enabling the team.

An example was given of one Agile project where they got to the end, delivered the priority features, but hadn't achieved a full minimum viable product.

There was discussion around using story mapping and feature level development and presenting these at governance level to show what is planned and progress. There was also discussion about how pragmatically project managers interpreted Agile projects and reported on these using traditional waterfall reports to satisfy governance. Kanban boards and visual boards to radiate project information and status was also discussed, but relied on stakeholders making the effort to visit the project area to see the status. Finally, there were thoughts on how we should be setting different expectations with governance groups when new Agile projects are kicked off - a process of education and co-creation is required.

My view was again that this is not necessarily a problem of Agile. I refer to it as "governance by remote control", where governance groups want to see each project with a simplistic traffic light colour, rather than get full transparency into the project.

On Agile projects our Product Owners should be deeply involved in the projects and should be able to make financial decisions on behalf of the organisation. In other words, Product Owners involved in Agile projects should represent the governance level of the organisation, not a lower level proxy. When the business person funding the project is involved as the Product Owner and directing the project investment decisions, then the problems of governance become less.

As a group we are agreeing the regularity of Projects and Agile Community of Practice, and I look forward to working with the group to discuss and share more ideas and learning at the next event.

Carl Weller is a Principal Consultant specialising in Project Management and Agile Leadership, based in our Wellington office.

If your organisation has any challenges with Agile, our team at Equinox IT is always happy to catch-up and discuss how we can help. Please contact us.