sales, marketing or someone from the executive team starts asking for the availability date of a specific feature, the accurate answer is a shrug. Too bad that's not going to be an acceptable answer.
What's to be done?
PHB should engage organizational leadership up-front to set expectations that there will not be a master project plan. He's got to let them know they are going to change the way they make plans, engage customers and deal with analysts. If you can afford it, have PHB bring in an agile consultant and have them run a ‘get prepared for agile' workshop for the executive team. If you can't afford a consultant, have everyone read the Gartner "fact or fiction" report on agile software development. [i] It does a reasonable job of explaining that agile software development changes the entire business, not just IT.
Unfortunately, these your PHB's arguments might fail and you could end up being asked to do up-front planning. [ii] Yes, this is wasteful, but the political reality may require you to start out with some waste, and lean out as your organization gets more agile experience. Have your PHB negotiate again next project, and the project after that, until you come to a workable compromise. As Brent Barton from Solutions IQ says, "Agile is a journey."
Let's assume PHB gets the sales and marketing teams on board. What other problems could you face? If you are in an agile-only environment, the next issue probably won't be troublesome, but if you are in a mixed methodology environment, look out. You have to face The PMO project status meeting . Here's problem: On a Waterfall team, because your tasks are pushed to you, you report on how closely you adhere to a published plan. On an Agile team, because you pull tasks, you report how much is left to do, and how much you can do. About halfway through the project, when waterfall projects start to get derailed, these differences will become political.
When you are on a waterfall team and you fall behind, you generally go through a re-scoping effort with lots of gates and visibility across the business. If you have to re-scope several times, this on-going negative visibility will do your team no good. Your PHB may start getting defensive and sniping at the PHB of the agile team. "His team is cavalier about requirements. When they get behind they just throw stuff into the backlog. There is no discipline! There is no accountability!"
He's right, of course. When you are on an agile team and you have too much work, you de-scope as part of the agile process. You don't need to execute a change document. You don't need to get permission. The rest of the business may not even realize that your project scope has changed. At project status time your agile team looks forward to what can be done rather than backwards to whether or not you have adhered to plan. This causes a lot of friction and backbiting between the project teams. We don't like getting negative feedback. We especially don't like it if we think others are held to a different standard.
To restore good order and discipline, both waterfall and agile teams must report on an apples-to-apples basis. We already know that agile teams can't report against a project plan. Can a waterfall team report work remaining and velocity similar to the agile team?
I believe so. In an agile environment we calculate velocity based on the project's history to predict how much work we can expect to get done over
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
