We have been using Scrum since I joined the team at the end of January. Over the course of the last 8 months, we have started using several XP practices. It took a long time, but we've finally gotten to the point of using a story card wall. Well, at this point it's actually a task card wall, but it's a start :). (For those not familiar with Extreme Programming, or XP, a story card wall is a big wall used to visibly track progress of user stories throughout an iteration. User stories are written on index cards, which are placed on the wall. The location of each card on the wall provides information about its status). It's caused an almost unbelievable improvement in our communication, productivity, and visibility into problems.
Why was there such a big difference? I'll get to that in a minute, but first, a little intro to Scrum:
For those not familiar with Scrum, the daily scrum is stand-up meeting where each participant answers three questions:
1) What did you do yesterday?
2) What will you do today?
3) What is blocking progress?
It is intended to allow the team to work together to remove obstacles blocking progress and keep momentum during the iteration.
The burndown is a graph of the amount of estimated work remaining over the course of an iteration. The days of the iteration are written on the x axis, and the amount of remaining work is measured on the y axis. Each day, a new data point is added to the graph. The amount of work remaining is calculated from an accompanying list of tasks and time estimates. The time estimate for each task is updated daily.
We were getting very little value from these two tools. But why?
As I suspect is the case in many large organizations adopting Scrum for the first time, our Scrum had degenerated into a status report rather than a tool to resolve problems and increase productivity. We often forgot to mention what we would be working on in the upcoming day, and hardly anyone ever admitted to being blocked. Most of the time, we just reported what we had been working on.
As for the burndown, we had developed a habit of ending every iteration with only slight slippage from the 'ideal burndown'. Here's an example of what our burndown graphs almost always looked like:
The blue line is an ideal burndown. Notice it reaches zero at the end of the iteration. The red line is our typical burndown. Doesn't look too bad, right? The problem was, even though there weren't many hours left on the burndown at the end of each iteration, there would be lots of incomplete tasks. We would always have a lot of tasks "almost done" and very few actually done.
There were three main deficiencies in our current process that caused this problem:
1) The burndown was deceiving. It didn't show us how many tasks were currently completed and incomplete. To find that out you had to squint at the task list. As a result we were often suprised at the end of the iteration.
2) We had no way to prioritize tasks on the task list. Developers simply claimed a new task at random when they were available. As a result, often we would finish an iteration with important tasks incomplete but less important tasks completed.
3) In the daily scrum, any given developer would usually only mention that he was blocked if he couldn't make any progress at all. He would not mention if a task he was responsible for was blocked, as long as there were other tasks we could work on. Because of this, blockages would often go unresolved.
Here's how we solved these problems: We divided our task wall into three columns: Available, Started, and Completed, so we could tell at a glance how many tasks remained incomplete. We divided the Available column into three sections based on priority: High, Medium, and Low, to keep us from starting low priority tasks when higher priority tasks were available. Finally, we put bright yellow sticky notes on task cards that were blocked. At a glance, we can now tell how many tasks are currently blocked, and can take action if we spot dangerous trends (like most of the available high priority tasks being blocked). The visibility the task wall gives us makes it very easy to realize when we're heading for trouble while we still have plenty of time to do something about it, rather than at the end of the iteration.
This experience reveals a dangerous pitfall that Scrum projects can fall into when not supported by XP practices. The daily scrum iterates focuses on each individual in the team. The burndown shows one view of overall progress. Both make it easy to neglect the actual tasks that need to be completed to make an iteration a success.
I'm eager to hear the opinions and perspectives of others who have used Scrum. Do you support Scrum with XP practices (or vice versa)? Have you encountered this same pitfall? Are there other pitfalls I should keep an eye out for (I've got a few others in mind)?
Why was there such a big difference? I'll get to that in a minute, but first, a little intro to Scrum:
For those not familiar with Scrum, the daily scrum is stand-up meeting where each participant answers three questions:
1) What did you do yesterday?
2) What will you do today?
3) What is blocking progress?
It is intended to allow the team to work together to remove obstacles blocking progress and keep momentum during the iteration.
The burndown is a graph of the amount of estimated work remaining over the course of an iteration. The days of the iteration are written on the x axis, and the amount of remaining work is measured on the y axis. Each day, a new data point is added to the graph. The amount of work remaining is calculated from an accompanying list of tasks and time estimates. The time estimate for each task is updated daily.
We were getting very little value from these two tools. But why?
As I suspect is the case in many large organizations adopting Scrum for the first time, our Scrum had degenerated into a status report rather than a tool to resolve problems and increase productivity. We often forgot to mention what we would be working on in the upcoming day, and hardly anyone ever admitted to being blocked. Most of the time, we just reported what we had been working on.
As for the burndown, we had developed a habit of ending every iteration with only slight slippage from the 'ideal burndown'. Here's an example of what our burndown graphs almost always looked like:
The blue line is an ideal burndown. Notice it reaches zero at the end of the iteration. The red line is our typical burndown. Doesn't look too bad, right? The problem was, even though there weren't many hours left on the burndown at the end of each iteration, there would be lots of incomplete tasks. We would always have a lot of tasks "almost done" and very few actually done.There were three main deficiencies in our current process that caused this problem:
1) The burndown was deceiving. It didn't show us how many tasks were currently completed and incomplete. To find that out you had to squint at the task list. As a result we were often suprised at the end of the iteration.
2) We had no way to prioritize tasks on the task list. Developers simply claimed a new task at random when they were available. As a result, often we would finish an iteration with important tasks incomplete but less important tasks completed.
3) In the daily scrum, any given developer would usually only mention that he was blocked if he couldn't make any progress at all. He would not mention if a task he was responsible for was blocked, as long as there were other tasks we could work on. Because of this, blockages would often go unresolved.
Here's how we solved these problems: We divided our task wall into three columns: Available, Started, and Completed, so we could tell at a glance how many tasks remained incomplete. We divided the Available column into three sections based on priority: High, Medium, and Low, to keep us from starting low priority tasks when higher priority tasks were available. Finally, we put bright yellow sticky notes on task cards that were blocked. At a glance, we can now tell how many tasks are currently blocked, and can take action if we spot dangerous trends (like most of the available high priority tasks being blocked). The visibility the task wall gives us makes it very easy to realize when we're heading for trouble while we still have plenty of time to do something about it, rather than at the end of the iteration.
This experience reveals a dangerous pitfall that Scrum projects can fall into when not supported by XP practices. The daily scrum iterates focuses on each individual in the team. The burndown shows one view of overall progress. Both make it easy to neglect the actual tasks that need to be completed to make an iteration a success.
I'm eager to hear the opinions and perspectives of others who have used Scrum. Do you support Scrum with XP practices (or vice versa)? Have you encountered this same pitfall? Are there other pitfalls I should keep an eye out for (I've got a few others in mind)?
7 comments:
Some in the XP community call Scrum "Extreme Programming without the Programming." This may be a bit harsh, but there is no doubt in my mind that real agility requires agile teams, agile projects, AND agile code. And Scrum, as forthrightly concerned as it is with the former two, leaves us in the lurch where the third item is concerned.
Our poorly-tested legacy Balls of Mud are like so many 30-pound ankle-weights once we embrace Scrum's "sprinting" commitment to regular, frequent incremental delivery of Running Tested Features (RTF). A couple of sprints around that track are brutally painful.
Without agile code, we are not agile. Without agile programming practices like TDD, refactoring, incremental design, pairing, and continuous integration, we cannot produce agile greenfield code, much less rescue our legacy code. And we therefore cannot achieve a regular, sustainable rhythm of RTF. Not with all of the best Scrum Masters, stand-up meetings, and burn-down charts in the world.
Subjective measures of agility like ambient levels of trust and respect, morale, and sustainable pace are the measures we can see easily -- once we are already expert at agility. Once we are virtuosos in agile music, the beauty of the music is self-evident.
In the meantime, we are practicing on our instruments, and all agile methods, agile teams, and agile projects should measure themselves by the harsh yardstick of RTF per unit time. This measure should apply equally to Scrum teams, XP teams, Crystal Clear teams, FDD teams, you name it.
Once we are measuring RTF, the failings of our programming practices and our code are as plain and painful as a stringless guitar in our hands, as we stand on stage.
At that point, we should have the courage to say it out loud: "I can't give you what you want with this codebase."
--Patrick Wilson-Welsh
Interesting observation Patrick.
Scrum does not pretend to talk about programming or the "how" of how things are done. That is left to the Scrum Team to decide as a self-managed team. Naturally the knowledge of the team and the Scrum Master are what constrains the way we work within the framework. The more XP knowledge amongst the team the more XP practises that can potentially be implemented.
I think real agile projects require a change in culture from the "usual" way of working.
A storyboard would have no value without an engaged Product Owner that has taken the time to own the - in our case - stories on the Product Backlog and worked closely with the Scrum Team to better define these requirements.
I would argue that XP can be implemented within a development group on it's own without ever changing the business side of things ... however I think we are losing out on a whole world of improvement that XP does not speak to.
To sum it up ... Scrum and XP are accomplishing different goals - however - XP can play a vital role in helping a Scrum Team become more effective and efficient.
But please let's keep the bigger picture in mind ... without a business community we don't have a project to apply XP to and without business support, we could be the best programmers in the world, and still have the project fail!
So let's look at Scrum and XP as tools that can help us and build upon each other rather than a can't have one with out the other situation.
Interesting observations, all.
IMO Andrew hits the nail on the head. What we're really interested in is delivering business value in an effective and sustainable way. No doubt there's more than one way to achieve that. If we choose the agile way, then the various practices do mesh with one another, for good or for ill. Looking at individual practices in isolation isn't very instructive.
I'll just reiterate Andrew's comment to Patrick, too. Scrum and XP aren't welded together. Scrum is a management process designed to support iterative work with empirical process control (as opposed to linear work with predictive or statistical process control). It predates the agile software movement by a number of years, and has been used on all sorts of projects besides software development. It "wraps" a methodology, but doesn't try to define the kind of details that a methodology defines, like whether you have "agile code" or not. That's why it can work with XP, AUP, Crystal Clear, or any number of other methodologies. Scrum works very well with agile software development projects, but it isn't the "definition" of agile software development. In fact, scrum can also work well with any iterative methodology, including non-agile ones like RUP or CMMI.
A few comments on the problems you noted, based on your description of the situation:
1. The burndown was deceiving. It didn't show us how many tasks were currently completed and incomplete. To find that out you had to squint at the task list. As a result we were often suprised at the end of the iteration.
A burndown usually tracks either (a) story points completed, or (b) features completed, or (c) customer-defined financial value delivered. It is a different way of tracking progress than traditional Gantt-chart style tracking. You are interested in the task list, which sounds like you prefer to track progress by task - more like a traditional Gantt-style method. This isn't a flaw in the burndown as such. You're looking for a type of output the burndown chart isn't intended to provide. If you want to track tasks, you should create a Gantt chart and track time (maybe in addition to the burndown chart). Personally, I don't find it useful to track tasks and time; I think that's one of the flaws in traditional methods. But if you want to track it, use the right tool for the job.
2. We had no way to prioritize tasks on the task list. Developers simply claimed a new task at random when they were available. As a result, often we would finish an iteration with important tasks incomplete but less important tasks completed.
This is an example of doing agile practices wrong. Your customer or Product Owner defines the priorities of the stories (not "tasks") during the IPM (or SPM if you use that terminology). If they aren't doing so, then they aren't fulfilling their responsibilities as Product Owner for the project. After the IPM there is no question about what the priority is. The backlog is prioritized. Developers are supposed to take the next story card in priority order off the board when they're ready to pick up a new story. They don't have the option to cherry-pick stories that look interesting. They do have the freedom to add tasks - technical things they discover are necessary in order to play the story (build the feature) and to adjust estimates accordingly - but not to re-prioritize stories or cherry-pick stories. This is not a flaw in the methodology, it's just people doing it wrong. The lead developer or PM may be able to help with this problem by keeping an eye on which cards are taken. After all, if someone grabs a card from the middle of the list, it will leave an obvious gap on the wall.
3. In the daily scrum, any given developer would usually only mention that he was blocked if he couldn't make any progress at all. He would not mention if a task he was responsible for was blocked, as long as there were other tasks we could work on. Because of this, blockages would often go unresolved. Having a process facilitator or ScrumMaster on the team could help with this problem. His/her job is to remind people of how to follow the process correctly.
Sorry, but this, too, looks like a case of people doing things wrong. Why does the developer mention any "tasks" he's not working on? He should be working on exactly one story at a time. If he's blocked on that story, he's blocked. I'm having difficulty visualizing how he avoids mentioning his own story; how he could possibly use the fact that other stories are playable to conceal the fact he's blocked. Something's funny about the way he's answering the three questions. Pair programming might help alleviate this problem. The pairing partners tend to monitor each other on things like this (although it doesn't always work out that way). Another suggestion is to have a team member designated as "tracker" for each story. His/her responsibility isn't necessarily to play the story, but to keep an eye on its progress. We usually have people volunteer as trackers during the second half of the IPM, as each story is estimated.
I hope this helps, and good luck on your journey towards agility!
Software degrades pretty easily and quickly without constant attention to design/code quality. Developing in an IID fashion will dramatically and inevitably compound this problem.
Scrum is kind of like a ski instructor telling someone that skiing is all about reaching the bottom of the hill, with a few stops along the way to reflect and replan the route. Never mind the technical details of how to actually stop and steer--you can just figure that out on your own. In the real world, the ski instructor would fortunately be open to a lawsuit upon death of a skiier.
I think a lot of shops trying Scrum are in for a huge wakeup call, when they realize they've been able to deliver on a year's worth of features, but are now stuck. Stuck, because no attention has been paid to design quality and because no one has been ensuring that the code gets reviewed, all because of the compulsion to sprint every month. At some point, you can't sprint any longer.
Yes, the Control Chaos page says Scrum is intended to wrapper other engineering processes. "Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products." They don't mention the impending death if it's not combined with engineering processes. Unfortunately, the technical solutions to continual delivery of quality product are not easy or obvious.
It's a truly bad idea to promote IID without also explaining the implications.
First to Ryan and Drew - how long have you been practicing SCRUM and on how many projects?
It seems to me your background is textbook and not reality. SCRUM is a process - that is similar to PM. But you must first have a PM basics background in order to know how to manage SCRUM, and implement successfully. Are you developers, Project Managers, System Architects?
From previous experience SCRUM is a technique, but if you really want to implement successfully - first read the PMBOK - implement a few projects as a full PM, have the scars and experience and then you will know how to handle situations and change the culture. If you don't fully understand it there is no way in which you can implement it.
Hi Anonymous. Thanks for your comments! :)
This project is the first in which I've used Scrum (previously I had used other Agile methods, mainly XP). My experience is as a developer, not a project manager. You are absolutely right; my knowledge of Scrum comes from books and limited experience thus far.
However, the strong impression I got during my CSM training was that the scrum master role is that of a facilitator, not a manager, and that previous management experience can actually be harmful to a new Scrum Master. Of course, this presumes a difference in the semantic meaning of 'facilitation' and 'management'. I would argue good management IS facilitation.
I certainly think facilitation experience would be very helpful in bringing about cultural change and dealing with many of the problems we have faced (whereas bad management, a.k.a Command and Control, a.k.a. Hamburger Management might be harmful instead). I am not personally familiar with the PMBOK, although I've heard negative rumblings about it in the Agile community. However, you've piqued my interest, so I intend of having a look for myself. Thanks!
P.S. I was not as clear as I should have been in describing my intent in writing this article. It seems some people were left with them impression that I was trying to point out 'problems' with Scrum. This is not the case. Rather, I was trying to point out common pitfalls that are easy for an inexperienced Scrum team to fall into, based on my experience as a member of an inexperienced Scrum team. :)
Post a Comment