One of my all-time favorite sales books is entitled Hope Is Not a Strategy. It’s a book about how to properly manage sales teams and opportunities. But I often use this slogan when talking to senior executives about their unrealistic software project expectations. When teams push back on unrealistic project release schedules, story estimates, or sprint capacity, they often get these types of responses from management:
“Make it happen!”
“Just do it!”
“Failure is not an option.”
In summary, hope is the strategy. While everyone loves a good motivational speech, these types of statements don’t add any value to the conversation. In fact, they cast management as being out of touch with reality. No wonder managers get so little respect from technical staff! Here are some things management does that can only be attributed to hope as a strategy.
1. Doubling the teams workload and expecting more productivity.
2. Adding more stories to a sprint and expecting them to get done with the same amount of people.
3. Planning no time to build needed customer documentation, provide maintenance on the current software release, or fix critical bugs that will inevitably be found.
4. Adding staff to a late project and expecting it to go faster.
5. Constantly swapping staff in and out and wondering why team velocity never improves.
Recognizing such unrealistic expectations is the easy part. Getting management to change their behavior is much more difficult. Try these ideas and see if they make a difference in your organization:
1. Hold the line on changes made within a sprint. Once a sprint starts and work has been agreed upon, do not allow management to change the stories in the sprint backlog. This will encourage the product owner / stakeholders to more carefully set priorities and understand customer needs. In my experience, many “new priorities” that arise during a sprint often magically disappear by the end. If they don’t, they can be addressed in the next sprint.
2. Consistently measure sprint productivity and estimation variance. Doing #1 above will not only stabilize your sprints but assures you can consistently measure productivity and estimation variance sprint over sprint. This is extremely important as it provides data to management on the impact that changes to staff have on the project. We all expect that adding a new team member will decrease productivity in the short-term as that person is brought up to speed. Collecting productivity data in the face of staff changes helps ground management in reality.
3. Put everything that needs to be done by the team for release on a story card. Period. End of story. No more elephants in the room that aren’t on the schedule. This should include: documentation, critical defects to fix, integration/system testing (and rework time!), non-functional testing, training of maintenance teams, etc. If it’s not documented in the product backlog, it doesn’t exist.
Don’t let hope continue to be your strategy!
