Introduction
I am helping an organisation transition from waterfall to Agile project management. This has led to lots of discussions on the benefits of Agile. Aside from the obvious benefits of faster response to changing circumstances, continuous representation of the customer/business viewpoint and earlier return on investment, I want to add honesty.
Honesty refers to means honesty about how much we can get done in the time allowed. I know those who are against Agile complain that there is no planning or reporting but that isn’t true and the planning that is done in Agile gives us much greater visibility of what is being created, often at a very granular level. This spreads honesty into what the business can expect as a result of the project and therefore honesty about the likely benefits achieved.
Planning honesty
Planning is output or achievement focused, not based on activities. This leads to an inherent honest about what is being created, moving from epic level requirements to individual user stories and then more specific sub requirements into even more specific sub sub requirements and then the specific activities needed to deliver these requirements.
Teams use techniques to decompose each piece of work into these specific activities, which enables them to cross check with each other that they have the resources, skills and information easily to hand to enable them to do the work. Again, there is honesty in whether or not everything required is in place to get the work done.
Development honesty
This granular level of detail leads to a much clearer understanding of the time required to develop. For small, specific outputs the time needed to move through initial draft to review, amend and finish the product can be calculated.
This is driven by the need to fit work into sprints often a couple of weeks in duration. The happy by product of these “product breakdowns” is clarity of exactly what is created before it is created.
Teams can more easily see from the early sprints how much work they can get done so there is greater honesty in what they promise to deliver in later sprints
Business involvement honesty
Product owners (also known as Business Ambassadors) can clearly see what the team expect to deliver. This makes is easier for them to share their own ideas about what needs to be included, and to plan ahead for how they can become involved in the design, development and testing of each component.
This honesty also extends to the deployment or change management work that the business will need to do to get ready to work in the new way. Specific pieces of work are easier to understand than larger bundles of requirements, so there is greater understanding about what changes need to be made to “business as usual” to adopt the outputs the team are developing.
Conclusion
As you can see I am a fan of using Agile to run a wide variety of initiatives, and I help a lot of organisations to develop their Agile transformation. If you want to understand more about Agile watch this webinar and register here for the sequel. Book here for a place on my next Agile Change course.
