Agile lessons learned

Introduction

Running an Agile workshop for those new to Agile this week, and two lessons learned really jumped out at me:

• I don’t think we talk enough about the business case for adopting an Agile mindset.
• I don’t think we talk enough about Agile as a culture, not a set of processes and techniques.

Business case

I spent a lot of time in the workshop helping the group to create the economic case for working in an Agile way, as they need to be clear on these arguments if they are to persuade their senior managers to support them.

Firstly I explained the funding cycle for any project starts as soon as resources are committed, and only ends when all expenditure has been completed. In a traditional waterfall or PRINCE2? project the funding cycle runs from the requirements gathering to go-live.

Requirements gathering and planning involve a lot of resources. I might establish focus groups, run workshops, commission surveys or interview key stakeholders to discover their needs for features and functions. Some of the project team might be involved in this, but as I use this information to develop detailed plans, more of the project team will come on board.

As we start work on the first activities, the project team is fully resourced. Additional costs are accrued during the project as suppliers are commissioned and change management activities begin in the business units impacted by the project.

As a former CEO, I know the pressure of commissioning these types of projects. I have to invest up front but might be waiting a long time for any return on investment. Things get really difficult for me if the initial investment is in one financial year and the expected realisation of benefits will not start until the next financial year.

The financial benefits of Agile working is that the set up costs are less. The initial requirements gathering concentrates on establishing the overall goals of the project and then finding something that can be done relatively quickly to prove the concept and see if further investment is a good idea. Further increments will seek out parts of the solution that can be created within short timescales and transitioned into new ways of working so benefits can be realised.

This early and frequent stream of benefits gives senior leaders comfort that their investment is the right decision. The added bonus is that some of the early benefits can be used to cross-fund the later work in the project, potentially enabling the project to become cost neutral early in the lifecycle, and delivering return on investment soon after that.

Agile is a new culture

To establish Agile working practices is relatively simple. There are a number of techniques that are often adopted first when starting to work in an Agile way. Dividing work into Sprints or Timeboxes, often lasting a couple of weeks at a time is very popular. Daily meetings to discuss progress, the use of Kanban Boards to visually record work in progress are also very common. Establishing the roles and responsibilities and the planning, risk management and quality management processes are also easy to do.

However, these structural changes are not enough. Underpinning all aspects of Agile working is trust.

• Enabling the team to decide for themselves the detail of the solution and when it will be created requires empowerment, which comes from trust.
• Not planning in detail up front, and agreeing to be fluid on which aspects of the solution are delivered and which are left out requires trust.
• Having a nominated business representative decide what is workable and what the new business as usual will look like on behalf of their colleagues requires trust in their judgement and their experience.
• Accepting new ideas throughout the project lifecycle and fluidly altering the priorities of the remaining work to accommodate them creates uncertainty for those commissioning the work. This evolving solution requires trust in the experts creating the project deliverables.

Establishing this culture of trust only happens if everyone impacted is happy to debate and design new priorities, new reporting lines, new levels of responsibilities and new values and behaviours. Any adoption of Agile will fail if only the processes and techniques are implemented.

I think before teams state that they are going to move to Agile working, the challenges of creating a new culture and a new set of organisational norms needs to be considered. This cultural change programme needs to be established at least at the same time if not before teams adopt other aspects of Agile.

Conclusion

My workshop once again proved that adopting Agile is not as easy as it looks on the surface. There is a depth of change needed for it to be successful and inevitably this takes longer than is initially thought. For more information, read this paper on Agile as a cultural change and involving relevant departments in creating your Agile ways of working.