Subscribe
Posted on November 12th, 2009
This week, I had the distinct pleasure of co-presenting with the ever lovable Mitch Lacey at the Agile Development Practices conference in Orlando. I also got the chance to have a great conversation with Alan Shalloway about the state of Scrum and the Scrum Alliance, and to run into Alistair Cockburn.
This got me thinking about the whole ecosphere that makes up agility in software today. There are so many angles one has to consider – from development practice changes, to team and project management changes, scaling up to organizational issues such as portfolio management, risk management, and avoiding local optima by focusing on the flow of value through the organization. And it we look at the practices and methodologies out there today, one could say that the cure to what blocks value in an organization is X-LACKS:
- X – Extreme Programming – This focuses primarily on the software development team, though with an important nod of the importance of customer involvement at all times
- L – Lean Software Development – Lean has been around for a very long time in the manufacturing world, and had a strong applicability to software organizations.
- A – The Agile Manifesto, the founding document outlining the values and principles behind the agile movements.
- C – The Crystal Methodologies are a family of methodologies which provide a sense of what tradeoffs and restrictions have to come into play as the size, scope and criticality of the agile project increases.
- K – Kanban is part of the Lean principles, and has twisted to have a split meaning. The Kanban board is a specific artifact, similar to the Information Radiator from XP or the Sprint Backlog from Scrum, but with an important twist – statuses are limited to the number of items in a column at a time. This is called limited WIP (Work-in-progress). This concept of limited WIP is applied at the broader sense to the team under the same term of Kanban.
- S – Scrum. Ah yes. Scrum. Three Artifacts, Three Rituals, Three Roles. One of the great love/hate stories in the agile world.
Just like ex-lax is made up of multiple ingredients, each with a specific purpose, so goes the above list. People like to make blanket statements like “Kanban is better than Scrum” or “You still need XP in Lean”. But pay attention. The people you want to listen to will provide the context like “…when you are adopting a large-scale organizational transformation” or “…when you are working with a company whose primary function is software” – and that context is what is necessary to know if the medicine you are using is appropriate.
The agile practices aren’t snake oil. They really do work. And the information they expose can make it seem like you’d rather stay sick. But if you address it with the right combination, and with the right leadership, vision and values, you’ll end up with an organization magnitudes better than what you could have ever achieved before.
Posted on September 10th, 2009
Ah, the Sprint Backlog. While not quite as visible as the Daily Scrum, the Sprint Backlog makes up the core trifecta of Scrum. And what developer wouldn’t love it? Every two weeks (or four weeks, or whatever iteration length you have) we’ll get together with the product owner. They’ll tell us what is most important, we’ll tell them what we can get done, and we’ll add that to a list. During the iteration that list is all we know as a development team, so no more of this, “I have to have you work on this other thing now!” business.
To a team working in utter chaos, it sounds like the perfect club to wield against a management unit that can’t make up their mind. “Sorry, we’re doing Scrum, and it says you have to leave us alone over the next two weeks.” What they don’t realize is that something that is a weapon can be used by both sides – and when the team doesn’t finish all of the stories they signed up for, management will use that same club against them. But if we look closer at why we have the Sprint Backlog, and why we have to have the Planning Meetings, we can understand better when we can tweak them to fit our needs.
In traditional software project management, the question is, “Can you all get this stuff done in this amount of time?” Because developers are a) optimistic and b) really bad at guessing, the standard answer will be “Absolutely!”. And because management and/or the customers don’t know what they want there will inevitably be a point when everyone realizes they aren’t going to make it, leading to what is known as a Death March.
But the goal with Scrum is instead to say, “Here is how much work we can get done in a timeboxed period. Let’s deliver the most value we can in that time.” So the sprint planning games become the place where the stories are reestimated, reprioritized, and signed up for to create the Sprint Backlog. And because we know the approximate velocity of the team, the release planning becomes a matter of looking at the story estimates, looking at the velocity, and then adding up stories until the time we want to release.
(In theory, of course. One of the better practices I saw with this was to have all of the stories estimated for the release, then add two cards that were each 10% of the total value – one for changes, and one for refactoring or other technical debt. That team generally hit within a week of their estimated date on 6-month projects)
Consistency is the secret sauce
Inherent in developing the Sprint Backlog is that the team can consistently deliver the same velocity iteration after iteration. Using a technique known as Yesterday’s Weather, teams can do a pretty good job of signing up and delivering the stories during the planning meeting.
The interesting thing is that the onus of this process is the consistency of the development teams. While that may make good fodder for mathematical calculations and modeling of release planning, it isn’t always the best for the developers. If we’ve signed up for two stories – one a “4″ and one a “2″, then all of a sudden we find ourselves having to do some planning to make sure that we break these down enough to get them finished. In other words, the stories don’t naturally flow through the team.
But what if they did? What if the consistency wasn’t in the teams, but in the stories themselves?
“Look honey, a real, live Business Analyst!”
If we begin to look at the flow of items through the system known as our development process, we see something interesting. In this chart, we see that even though the story sizes don’t appear to have too much variability, the number of actual hours to complete each one varies wildly. What we really want to do is setup the backlog in a way that smoothes these bumps to reduce the variability in the tasks.
To do that, you begin by throwing away estimates. Instead, your card is your estimate. So if it is written on an index card, it should be the same approximate size as the other index cards. Let’s say a story on an index card only goes on there if the team knows they can finish it in two days. If the product backlog has items that are bigger, then you have a whole group known as business analysts who can evaluate, research and find out just how to break that into smaller items.
When this variability is reduced, then the question is no longer, “Here’s how much we can do in two weeks. Fill us up”. It simply becomes a matter of, “Ok, we’re done! What’s the next prioritized story?” As that begins to happen, the need for a “sprint backlog” begins to go away – the sprint backlog is simply, “What’s next?”
Sounds great, Bob! What else do our contestants get?
There’s an important point here. To get to this, you have to be at a maturity level to allow for several things:
- Recognition of flow through the system – You’ve taken the time to do value stream maps to figure out where the bottlenecks are.
- Invested customers – You have customers and business folk who are willing to work with you to get that level of detail
- Strong definition of done, done – because the consistency comes out of small stories, there is no room for “mini-waterfall” iterations. The team has to be very good at delivering running, tested features
Without these things, then the Sprint Planning Meetings and Sprint Backlog serve a very important goal – to stabilize and checkpoint the development process. So as you begin modifying the planning game and the backlog ask yourself – are we modifying this because we’ve analyzed the flow of our system and found that we need a different optimization stream? Or is it simply because your team can’t even meet two or four week commitments?