How much process is enough?
Ask that question of ten corporate managers and you’ll get ten different answers. That’s one of the reasons why converting from waterfall software development to any agile approach is so difficult.
Waterfall development is a command-and-control process filled with checks, balances, phases and gates. It feels right to many managers despite it’s lack of speed and responsiveness.
Agile approaches like Scrum, XP and Kanban offer speed and responsiveness but sacrifice some command-and-control elements. You can’t have it all, right?
When managers think of adopting an agile approach, they tend to err on the side of too much process based on the theory that having too much control is better than not having enough. Getting into an argument about the issue is unlikely to convince anyone of the merits of agile development.
So what’s the answer?
Give a little. You’ll likely be forced into implementing your agile approach with more command-and-control elements than you want or need. That’s okay. Have a plan for removing some of those command-and-control pieces as the team improves. Here are some things to consider.
- Do not merely wrap your waterfall process in an agile wrapper. That is, don’t practice waterfall adding daily meetings, stories and burndown charts to it. You’ll just add more overhead and make matters worse.
- Instead, do the opposite — wrap your agile approach with some waterfall elements. Managers want to see metrics that measure progress. You may have to comply.
- Pick an end date for the project. End dates are good. They establish a time box. An agile project cannot operate on the principle that the software will take whatever time it takes. There needs to be an end.
- Managers want to know how big the project is. Stories are great for that. You don’t need to fully refine every story to it’s sprint-ready state. High-level stories are okay as long as you can estimate their duration — roughly.
- Managers want to see progress. Burndown charts are great for that. They clearly show how many stories are complete and how many are left. Of course, this needs to be based on the initial estimates in item 4 so it’s not a true Scrum burndown chart but it’s good enough for reporting purposes.
- Managers like to see defect reports. You’ll need to maintain a defect backlog and report on it.
- Some managers really like earned value charts (I think they are totally fictitious but more on that another time). A simple metric showing stories completed and cost incurred should do it.
What’s the downside?
Once you start tracking size and cost, any change that impacts size and cost has to be tracked. Change control? Unfortunately, yes, though this is a project management issue not a development one. The key is to only track and report on changes that impact size and cost. The majority of the day-to-day team decisions will not impact either.
If you can get this far, you’re in great shape. Over time, you can work toward eliminating the waterfall wrapper — one element at a time. What do you think?