One of the most important steps when embarking on a transition to Agile is to set expectations for what it actually means, how it will change what the team does and how this will impact the business.
Stakeholders will have had a variety of experiences of Agile, ranging from those that have never heard of it to those that have experienced ‘bad’ agile, all the way through to those who have seen it work well (although in my experience this last group are still rare). Ensuring everyone knows what to expect can help reduce a lot of friction as you transition and will increase the chance of success.
Below are a few areas/techniques I have focused on when setting expectations, I cover them briefly here and will go into more detail in future posts:
Compare and Contrast to get a common understanding
Unless everyone buys into what Agile is and how it works there are many areas which can cause confusion, misunderstanding and issues, where one group of stakeholders expects things to happen in one way and another has a different expectation. As a result everyone gets frustrated and progress is significantly impacted.
For example, the development team needs use stories prioritised for the next sprint so they can get on with development, while the business wants a detailed Business requirements document covering all the functionality that would eventually be delivered.
A good way to expose these expectations and get a common understanding is to draw up a table to help everyone understand the key difference between Agile and Waterfall delivery and highlight how key items will change (such as the approach to requirements). This also allows you to highlight where there are expectations which conflict or where some areas are still thinking in waterfall terms and not agile.
It doesn’t mean ‘quicker’
Often senior management will expect that agile means they will get the finished product quicker and hence reduce the overall cost of the project. This usually comes from the frustration with waterfall projects which have taken a long time to deliver anything and then finding out that requirements were missed or that the benefit case has changed and will no longer be fully realised.
Making it clear that the project won’t necessarily cost any less or complete any quicker overall is important, the reason to transition to Agile should never be based on completing the project quicker. When this area is discussed, it is important to focus on the iterative and incremental aspects of agile, articulating how this will ensure the delivered software more closely aligns to business expectations and allows the business to realise some of the benefits sooner:
It doesn’t happen overnight
Unless you are very lucky, the transition to Agile will be a long process and require a lot of effort from the whole team. Without good sponsorship from above and strong buy in from the team it will be a very difficult process. Many people suggest that the transition process will take at least 9-12 months, and in my experience this is definitely the case.
It is also likely to require a lot of changes in the way the team works. Don’t under-estimate the effort required, and don’t oversell what you can achieve!
Managing the transition process is critical and using retrospectives to constantly look for ways of being more agile is critical. Get everyone engaged and reward people for demonstrating the expected behaviours.
Level of engagement
In the enterprise, the business unit which will receive the software being built is often providing the budget and will therefore be the sponsor and customer (and possibly the product owner).
In waterfall their engagement will probably have been through signing off project deliverables such as the weighty specification document at the end of a requirements phase and then taking part in a period of user testing close to implementation. Outside these phases there is usual a time where business engagement drops off while the IT guys go and build something:
With the transition to Agile, if the business needs or wants to have the same level of involvement then there will be a very different engagement profile, with ongoing involvement through the various ceremonies, regular feature reviews, generation and prioritisation of use stories etc:
Discussing these changes with the impacted stakeholders up front and revisiting when issues arise will greatly help the adoption process and help reduce friction between teams throughout the transition.
I’d love to hear your comment below on other areas you feel are important to set upfront expectations.