Finding the Theme
I enjoy helping people with Scrum and Agile. The more I do it, the more I learn and enjoy it. Many of my recent in person and online encounters have had a similar flavor to them. I didn’t put my finger on it until this morning.
In an online exchange people have been discussing the Sprint Burndown Chart. Opinions on it’s usefulness, how it should be used and what it contains vary widely. That’s OK, because every team and situation is different. The point that struck me was one particular comment. This person described how their chart showed burn down of estimated hours for tasks. They adjusted the burndown each day if a task’s estimated hours to done changed, essentially including actual hours into the burndown.
For example, take a task that was originally estimated at two hours. The next day the developer working on the task reports slow progress. The task is not done with four hours already spent. The developer now estimates the task will take ten hours. So the burndown chart data point would be adjusted up by six hours to include the new estimate.
This example shows the desire of this particular team to track actual hours. I suppose they wished to compare them to the original estimates to measure accuracy, though that did not come up. (There are several reasons that I don’t like such a way of doing things, but that is another discussion.)
Other examples along the theme have been
- eight hour planning meetings
- estimating an entire five month long Product Backlog all at once
- two days of wireframing before writing the story
- sprint tracking spreadsheets with more detail than a Gantt chart
So when I was thinking about the burndown of actual hours example and other practices of potential waste, the theme hit me:
Big Design Up Front (BDUF) of Scrum
It seems many people are trying to eliminate BDUF of products, with Scrum implementations that are designed big up front.
- They need to define every possible field that might be needed on a story card before they start using story cards.
- They want to track hours and sub-hour increments on tasks, allocated by a percent of the developers time against other tasks.
- They need backlog spreadsheets with date coded story ID’s, date last edited, comments by department in separate columns and priority votes from each of five stakeholders.
- They make up two page forms for recording the definition of done and how each maps to the appropriate use case record(s).
And they do all this before the first team starts the first sprint. Because, well, they’ll need the data, right?
Maybe they will need such tracking of information someday. Any one of the above might be the right thing to do at some point for a particular team or company or product. Does it make sense to design all this infrustructure up front, not knowing if it’s really needed?
BDUF Practices in Scrum
Finally, after weeks of discussion, meetings, documents and planning, they start the first sprint. And here they are with all these BDUF practices now part of their Scrum processes. Product Owners who have more clerk-work than product innovation-work. Scrum Masters who have to keep asking for actual hours worked. Burndown charts that require an instruction sheet to interpret. A project bogged down by the same stuff that was supposed to be left behind by “going Agile.”
Simple Code, Simple Scrum
The best code is simple, direct and no more complex than it has to be. The best products have a clear function and benefit to their customers. The best information is direct, focused and simply presented. The best Scrum is simple as possible. Just as it is not possible to know all the answers to creating an innovative product before starting development, it is not possible to know all the things needed for an awesome and highly productive Scrum process. Start simple, way simple, with just the basic pieces. Then, retrospective after retrospective, the team and company learns what they need, solves it in a simple way and gets back to the real business of creating a killer product.