Imagine you’re doing your taxes. You’ve been collecting receipts, filling out forms, and doing some light math. Then you discover that the deadline is tomorrow morning, suddenly you jolt yourself out of the monotony and move that pen a little faster. You get everything done and breathe a sigh of relief. A few questions about this process:
- Why were you drudging your way through it before?
- Why were you suddenly able to sprint your way to the end to get it done?
- Did the quality of your work change before and after you learned about that deadline?
This is a situation that many Americans can understand. There are plenty of activities in our world where we can turn up our intensity and suddenly turn into apparent “super heroes” in a burst. Many of our colleagues and managers in the software development world, believe that we can do the same when building a software product. What makes this a bad thing to do in complex software, but at least debatably a good thing doing our taxes? Quality. Assessing the quality of light math or collecting forms, filling in paperwork is vastly easier than assessing the quality of software – of which the user experience is but one way to interact with it. Corners can be cut, and often not deliberately at all levels of a software development project, and often they are when the right checks and balances are not in place.
I’m working with a product owner that really struggles with the agile concepts as part of an agile software development project that is literally one sprint away from releasing their software to the world for the first time (with the minimally viable product). This product owner still thinks he can ask the team to “get additional items done” plus all the existing commitments. He’s playing with fire and risking his business in ways he doesn’t yet understand. This is a launch in the making with many hours of input and the team has up until now built quality software at an astonishing velocity.
Waterfall projects often play out that the team has been building software, and a project manager/product owner gets involved and asks for more intensity. Somehow teams often “get it done” but they made choices that the business may not like. They often have to cut quality to get a set scope done by a specific date. Often that quality is harder to assess; and the team moves on and the business celebrates and moves on. Somehow later, the maintenance problems show up, and we all forgot the cause for those issues.
Rather than comparing an agile software development project to tasks like filling in tax forms or other tangible work in the world, it’s a better thing to compare it to a factory shop floor with a conveyor belt smoothly pushing product through the factory until completion. Imagine the engineer has rated the conveyor belt at 5MPH before he believes the wheels fall off. This product owner wouldn’t feel comfortable interjecting and claiming to run it at 10MPH. I imagine that product owner would defer to the engineers that have given him facts on which to make decisions.
Agile projects, with a few characteristics share more in common with that belt than tax forms:
- Retrospectives done regularly
- Team builds software with a limited work in progress limit
- Team has a clear definition of done (requirements, development, testing, and releasing)
If a team has been continually doing retrospectives over the course of the year; it’s already been continually improving. It’s already with a limited WIP, delivering software at a level of quality in a smooth/flow fashion. And if that team has been successful, it’s velocity is predictable.
By definition, the team has left nothing on the table, already. A product owner asking for more is asking for another 10MPH and if the team does that, quality will suffer – just like the conveyor belt and possibly break.