Over the past year or so, I’ve collected some burndown charts that illustrate some team problems. I don’t want to tell tales on past clients, so no names will be revealed by me. And for that matter, people always mean to do their best, but sometimes it’s an emotional challenge to fix things (see the second to last paragraph below).
For each image, I’ll list a few ideas I have about why the team’s progress looks as bad as it does.
- mis-use of an agile tool (stories weren’t “in” the sprint when the start button was pushed)
- stories not broken down into small enough pieces
- probably not really using daily meetings to report progress.
- mis-estimated some of the work, or actually had done work before the sprint started
- …and then somehow managed to get stuck on the remaining work
- meanwhile, a points worth of work failed at the end of the extended sprint–why wasn’t some qa-like work done earlier?
- Oh please. Admit that you didn’t meet the commitment, and move unfinished stories into a new sprint. Figure out why you struggled, and fix that problem.
I think there are two themes that pop out here. The first is using and relying on a tool before fully understanding the underlying principles. That first image, where all the scope of the sprint is added after the sprint has begun, illustrates a simple “record-keeping level” problem. But there are larger problems with tools. They’re built for some specific requirements, requested over time by people using the tool. But those people are not you or your team. You and your team will look at all the fields and dropdowns and buttons on the tool’s interface and decide you have to use them, even if you don’t know what they are for. Before figuring out what is important for you to track, you are puzzling over how to use someone else’s idea of tracking. This just leads to confusion and losing your focus to things that are actually meaningless to you.
When coaching, I really do prefer to start teams using paper and pens. Using simple manual tools forces simplicity. Simplicity gives you the chance to understand the process you are creating before it grows.
The second is a more emotional issue: teams are uncomfortable to admit failure. Look at that last image. It is the map of a massive failure of some sort. “Extending” the sprint is much less confrontational than saying “something is broken.” But as hard as it is to admit failure, admitting failure is the first step in fixing the causes of that failure.
I don’t know if I heard this phrase somewhere else, but I’ll use it now: “Fess up when you mess up.” Then use your retrospective to make some improvement, somewhere in your process, or your team organization or your client/product owner relationship. Don’t let your burndown charts look like these.
Wednesday, March 20, I will be moderating a panel discussion on how UX fits into agile environments.
This is IxDAChicago’s monthly meeting. I’m really looking forward to this event. It’s something I have wanted to do for a long time.
Agile principles really suggest that people are more important than fixed processes and tools. So I hope in this conversation to bring out the different ways (processes) that user experience design (and research, etc.) has been integrated into different agile environments. And by implication those environments have been created by (different) people with unique needs.
I hope that members of the audience will come away with some ideas for their own agile journeys, as well as an appreciation that there is no single “best” practice for UX in an agile space.
If you attend, please say “hello” after the discussion! Oh, and bring your questions, too!
I really like the ideas expressed by Tobias Mayer in his post “How to Hire an Agile Consultant.” I recommend you go read his post.
I found Tobias via the comments on this anonymous “editorial”. That happens to be a post with some good ideas and concerns as well, but I have to fall in with the commenters who take it to task for its anonymity, in spite of using the personal pronouns “I” and “me” consistently throughout. Good ideas, but no-one to whom one can give credit.
I haven’t yet directly experienced the coach = scrummaster situation yet, but I can easily see how it will happen as more and more companies look for help in “doing agile.” And more and more companies spring up to offer these services.
There is some great stuff on Jiles van Gurp’s blog. Here are a few of my favorite thoughts from “Scrum: Agile Madness”
- “…you can’t substitute experience with process and that is exactly what agile followers end up doing. Take away the experienced people and you have a lot of people executing the rituals of scrum, kanban, or whatever without really understanding what they are doing.”
- “…often scrum is introduced to fix what is already a dysfunctional organization.”
- “Actually, if all of the above is true [referring to four assumptions about happy and productive teams], you will have little need for process. If that isn’t the case, no amount of process is going to fix things magically.”
- “[ironically:] A two day pep talk about scrum is apparently all the training you need to become a product manager or scrum master.”
- “[T]here are a lot of inexperienced people who get promoted to be a product owner or worse start their first or second job being one. Likewise, the scrum master role is not considered a job very high on the corporate ladder either.”
- “Choosing and tuning the way in which you work is more important than having everybody mindlessly follow the same process.”
These quotations of course are all presented here without the context van Gurp provides. I strongly recommend you read the whole post: http://www.jillesvangurp.com/2011/12/03/scrum-agile-madness/ . Thank you, Jilles, for your blog!