When starting any new significant change in your life, its easy (and natural) to have high expectations. Whether it's starting a workout program, a new job or even a marriage, human beings tend to get caught up in the euphoria of the newness and all that the change can seemingly promise. Unrealistic expectations of (somewhat) effortless success can pervade and sometimes sabotage the effort. Transitioning from traditional Waterfall-based methodologies to Agile is no different. The promise of the "silver bullet" of Agile and common misconceptions about what Agile even is (or isn't), if allowed to persist, will make the move far more difficult than it needs to be. Let's look at some of the challenges related to stakeholder expectations in Agile and how to address them.
Battling Misconceptions
There are some common misconceptions out there about what Agile is or is not, and you need to address these before they manifest on your adoption. Here are a few of the biggest ones:
- "Agile=Rapid Development" – I'm not exactly sure where this notion started, but it is even perpetuated by some Agilists in the community. This, in my opinion, is potentially the most dangerous misconception that stakeholders could have. It's the notion that because you're "doing Agile," you'll just get done faster. I argue that while this will likely end up happening in the long run, I wouldn't characterize it as "rapid development." "More efficient development" is the term I would use. Agile should end up giving the development team more value-added time by stripping away unnecessary processes and lost time from miscommunication that comes from relying on the written word. It should also give the business quicker ROI by delivering release-ready product sooner in the business cycle. But stakeholders shouldn't expect that all else can stay the same, the development team starts "doing Agile," and code will just be cranked out sooner.
"Agile=No more Documentation" – Looking at the Agile Manifesto, and the valuing of "Working Software over comprehensive documentation," stakeholders will often expect this will mean they will get NO documentation. This should not be the case. As I tell my teams, "I want you to do as much documentation as is absolutely necessary." And how/when/if you should create the document depends on the type of document it is. To look at this a little more closely, I'll divide documentation into three subgroups:- Compliance – Documents required by governing bodies external to the team, be they industry regulatory governance or even internal project management office requirements. Either way, those types of documents are necessary to release the product, even if they are not part of building the product. Creating these documents should be tasked out on the Sprint backlog, even if those tasks are all taken by a B.A. or technical writer. These tasks will likely be ongoing during a sprint so as to avoid a mad rush to document at the end.
- Users – User guides, help documentation, etc. These types of documents also are not directly related to building the product, but necessary for release. The key to developing these documents is to generate them as late as possible in the process, so as to capture the end state of the product, rather than expending effort throughout the development cycle to continually try to capture the change. Since they aren't published until release time, all that time spent changing them is waste.
Team – These documents are used by the team to document the development of the product and the technical aspects of the design. These will likely include logical and physical database models, class diagrams, design guidelines…anything you can picture would be used by designers and coders to understand how the product was/is designed and functioning under the surface. There are two keys to these documents:- Have the conversation first, then document – We shouldn't assume we need all the documents we're used to generating. Teams should first talk about an issue, or approach. If they arrive at an agreement and no documentation is needed, then don't produce it. If they decide they need documentation at that point, then they've proven its validity and should task it out.
- Generate the documents, don't author them – Especially when we're talking system and database documentation, there are plenty of tools out there that can reverse engineer code or databases and document the end state. Spend your time collaborating and designing, then use one of these tools one the design is stable and let it do the work for you to optimize your time.
- Have the conversation first, then document – We shouldn't assume we need all the documents we're used to generating. Teams should first talk about an issue, or approach. If they arrive at an agreement and no documentation is needed, then don't produce it. If they decide they need documentation at that point, then they've proven its validity and should task it out.
- Compliance – Documents required by governing bodies external to the team, be they industry regulatory governance or even internal project management office requirements. Either way, those types of documents are necessary to release the product, even if they are not part of building the product. Creating these documents should be tasked out on the Sprint backlog, even if those tasks are all taken by a B.A. or technical writer. These tasks will likely be ongoing during a sprint so as to avoid a mad rush to document at the end.
Another key way to manage expectations is to give stakeholders the transparency that Agile promises. Use "information radiators" to do this. Beyond the typical burndown chart used primarily by the team to track progress towards sprint completion, consider using a burnup chart, showing the additional metric of scope change. In this way, stakeholders can clearly see the effect that adding or removing scope will have on the team's progress towards reaching their goal.
Burnup Chart
Consider also adding the information radiators of a release burndown and velocity charts. A release burndown will simply show the amount of work remaining from the product backlog after each sprint. Used in conjunction with a velocity measurement chart of the amount of work the team completes in each sprint, simple math will give you and stakeholders the best case, worst case, and probable average for how long it will take the team to complete the work for the release.
Velocity Chart
