An interesting phenomenon I have noticed is how an enterprise gathers itself once a ‘project’ gets under way. As soon as a team is brought together and build is in the air vultures start circling as reports are asked for, milestones and commitments become the order of the day and a heightened expectation of knowledge and certainty is apparent.
In large enterprises, whose expectations are ingrained from years of traditional waterfall projects, this becomes a big problem for Agile teams. The issue lies in the tale of two starts, in other words when a project officially ‘starts’ in waterfall vs Agile and what this means for managing expectations.
The key sticking point seems to be that traditional PM’s, Managers and Executives operated in a world where once ‘build’ teams come together and start building stuff they already have loads of requirement documents, requirement definition documents and design documents. With these documents it would be expected that simple questions like “when will I get?”, “how much?” and “how many?” would be met specific replies backed up by project plans and documentation.
With Agile projects ‘build’ teams are brought together early and are participants in the definitions and designs as they evolve. So the misconception is that because the teams are together and building they have all the knowledge and as the managers etc are burning money they expect to get specific answers to their questions.
There are several responses required here that will develop as the enterprise matures with its use of Agile. For a mature enterprise the answer lies with stable teams, common backlogs and smaller chunks instead of projects, i.e. the expectation would not exist as the traditional model has been expelled.
For the mid-range enterprise being expert in leaning on the tools Agile gives us for transparency and common understanding such as big visible charts, showcases, Kanban walls etc helps to alleviate the anxiety. Being responsible by taking the time to prepare information in a way that traditionalists can better understand and take comfort from for business decision making and reporting, in other words finding the right balance as the enterprise develops in its use of Agile practices.
For enterprises starting out on their journey education is the key as the enterprise moves toward the above states. I found the use of a timeline to be effective in upward communication as to where we are at in the project life-cycle so as to re-set expectation and understanding. The diagram below is an example to illustrate.
The important thing to highlight is the comparison of the time of design and definition.
The diagram shows that in traditional methods this time is conservatively 6 months and conducted by a few team members. In Agile, during this same time, teams are also learning the same designs and definition, but as a whole team and delivering incremental value at the same time. In fact the Agile team, by doing, may be learning valuable information that would be missed in traditional methods and may in fact end up with different but more suitable designs and definitions. This also takes advantage of ‘just enough’ designs and adaptation that can result in projects finishing early or being stopped all together if value is not being received as expected.
So lets view the first 6 months of an Agile project similarly to that of the traditional methods, one of definition and design, and teams should be treated accordingly not with the requests for certainty and milestones. Of course you get the additional benefit of value delivered along the way and, using the concept of the cone of certainty, building knowledge and validating learning so that release plans and progress can be transparent and well understood…..with certainty.
In summary, set proper understanding of how knowledge is built and what can be expected. Use the communication tools available in our Agile world to relieve anxiety, and as the enterprise matures, move to features, stable teams and common backlogs.