Month: May 2010

(I originally posted this on my MSDN blog.)

In another conversation on an internal email thread, someone asked some newbie questions about Scrum daily standup meetings, like do they have to be every day or could they be done every three days or so?  There were some good replies that encouraged the standard practice of daily meetings, then someone else mentioned that since his team sits together in one common team room, they communicate all day long and they’ve found the daily standup meeting to be not really necessary at all.

I thought that was a interesting point and replied:

That’s a good example of why it’s important to understand the goals that any given methodology is trying to achieve, not just the ceremonies that it uses to achieve them.  The goal in this case is a short feedback cycle, shared understanding of what all team members are doing, and identification of the most important things to be working on right at this moment.  The mechanism you use to achieve that is really beside the point if you’re able to effectively drive the goal.  Scrum’s mechanism of the daily standup meeting is very effective for the vast majority of Microsoft teams who have individual offices.  If you’re fortunately enough to have extremely high communication going on all day long, then sure, I can see how a daily standup would not be as important.

Anyone who tries to implement Scrum (or any other new methodology) without understanding the end goals and how the individual practices are intended to express those goals is pretty much doomed to failure.  I suppose you can start out that way (I guess I did, come to think of it) but you can’t continue for very long that way.  You have to understand the “why”, not just the “how”.

Time and time again when I see a person or a team who is fumbling along with agile practices (whether that’s Scrum, XP, TDD, design patterns, or anything else) and it’s not really working for them, it’s usually because people are just going through the motions they’ve read about without any real understanding of the principles, the philosophy, and the goals involved.  There’s usually some cargo cult engineering going on.  This causes at least two types of serious problems:

1. Either they slavishly follow every detail of the methodology without considering the unique circumstances of their project and adapting certain aspects of the process to best fit what they need,
2. Or they start slicing and dicing the methodology, throwing out whatever they don’t immediately like or whatever seems difficult to implement without having any sort of plan to accomplish the same goals by other means.

The Agile Manifesto calls for favoring individuals and interactions over processes and tools.  No methodology should be followed to the letter without thought, but most methodologies have important, specific reasons for every practice they prescribe.  The only way we can favor people over processes and still deliver working software is if we understand the “why” of our processes so we can intelligently mold them to fit our people.

(I originally posted this on my MSDN blog.)

My current work environment is pretty typical of a lot of tools teams, IT shops, and similar groups; we have lots of relatively small projects to build and maintain.  In fact, we have far more projects than we have people in each discipline (Dev, Test, PM).  This obviously means that we don’t have the luxury of assigning individuals to one and only one project for long periods of time; we have to slice up our time and devote attention to multiple projects in turn.  Given that’s the reality of our situation, though, there are still different ways we can go about doing that, some healthier than others.  We can multi-task at either an individual level or at a team level.

Individuals

Multi-tasking at an individual level means that Joe is splitting his time between the Widget project and the Froberg project, while Sally is splitting her time between the Froberg project and the Walleye project.  Every individual has a different portfolio of projects that they’re responsible for.  The benefit of this strategy is that it gives us maximum flexibility to allocate scarce engineers in a way that seems to cover all the holes on paper.  There are several very expensive costs, however:

• People rapidly shift from project to project which means that no one develops a deep and strategic understanding of any one project.
• Because people are always coming and going on a given project, it’s hard to develop a sense of team identity or to develop productive working relationships with colleagues.
• Individuals are often left to make their own choices from day to day about which project is most in need of their attention at the moment.  There’s no strategic thinking about priorities or about how to spend the overall time budget of the group.

When we multi-task at an individual level, we often end up building plans for our projects that assume 100% allocation when that’s not really the case.  For instance, say that we have work happening on the Widget project and the Froberg project at the same time.  From a group planning and budgeting perspective, it might look like we have one team devoted 100% to Widget and another team devoted 100% to Froberg and that the work should be able to proceed in parallel.  But in reality that’s not the case because Joe is double-booked for both projects.  That puts him in an awkward position because now he has to decide on a day-to-day basis which is more urgent: Widget or Froberg.  That decision isn’t being made by the project owners and it’s not being made strategically; it’s being made individually and tactically.  Despite people’s best intentions, that kind of system usually devolves into a last-in-first out work queue, i.e. we work on whatever was most recently brought to our attention.

Teams

On the other hand, we could multi-task at a team level.  In other words, we could build a stable, consistent Dev/Test/PM team that has explicit responsibility for both the Widget and Froberg projects, while another stable team has responsibility for Walleye and something else.  We still have multiple projects that need to be worked on, and we still need to make priority decisions between them, but now the trade-offs are visible in the budgeting, planning, and strategic thinking realms.  Say the team is working on a new Widget feature.  Oops, we have an urgent Froberg bug that needs to be fixed!  What’s the cost of handling that?  Well, the cost is that we postpone the Widget project while the whole team shifts its attention to Froberg.  Is it worth it?  Maybe, maybe not, but now we can have a proper discussion about it.  It’s very clear and obvious.  You can’t just sneak it in under the radar.

The costs were there in the individual model, too – if Joe is working on Froberg today then by definition he’s not helping Widget make progress – but the costs were hidden.  The individual model seems like it’s easier to work with in the short term because it avoids the  hard priority choices but those choices still need to be made and it’s best if they’re made explicitly rather than on an ad hoc basis.

Agile Means Teams

Of course there are multiple agile project management methodologies that emphasize the team as the unit of work.  Scrum prescribes a team, a backlog, and a sprint full of work that is locked.  If something urgent comes up, it gets prioritized into the product backlog for the next sprint and everything else necessarily shifts down in the stack.  The benefit and the cost are clear to everyone.

Kanban describes a similar system but emphasizes continuous single-piece workflow which is probably a better fit than Scrum if you’re juggling lots of small, unpredictable jobs across multiple projects.  If something new comes up, slot it into the backlog and everything else gets bumped down.  The team continually pulls from the top of the list and you can forecast a pretty accurate time to delivery for any point in the backlog.

Even groups who like agile methods and are trying to practice them sometimes have a hard time breaking the habit of treating the individual as the unit of work.  Every time they slip back into that old habit everything gets much more unpredictable and velocity falls dramatically.  It’s inevitable.  The way to make agile methods work is to keep the team together as a cohesive unit and feed them the work you want the most.  Don’t steal individuals for side projects.  Multi-task at the team level, not the individual level.

(Whew, I wrote that whole post without once using the word “resource”.  It was harder than it sounds!  🙂 )

 

(I originally posted this on my MSDN blog.)

Here’s another question that was asked on one of our internal distribution lists:

When do we consider a sprint to be a failure?  I don’t know the answer and have no clue about it.  We delivered 7 out of 9 stories we committed with all the release criteria, but we failed to deliver two stories due to under-estimation of the stories we picked.  Is this a failed sprint?

This stirred an interesting discussion about sprint commitments, continuous improvement, estimation, retrospectives, and numerous other things.  This was my contribution to the thread:

The phrase “sprint failure” in Scrum has a pretty specific meaning to a lot of people.  It means that at some point before the end of the sprint, you realize that your sprint plan has gone so far off the rails that the best thing you can do is to abort the sprint before it’s completed and build a new plan.

What if halfway through your sprint you realize that you’re probably going to be able to deliver only 7 of your 9 stories?  Should you abort the sprint at that point and plan a new one?  I guess it depends on the specifics of the stories but almost always I’d say no.  You’re a little off the plan but not drastically so.  That’s not uncommon.  Keep going, deliver value, and afterwards figure out if there are improvements you can make for next time.

The original poster is apparently not talking about aborting a sprint halfway through.  He’s talking about working until the end of the sprint then labeling the results.  I think he needs to define what he means by “failure” here.  Does he mean, “we should reflect on what happened and look for opportunities to improve?”  Sure, I agree with that, though I’d probably stay away from the term “failure” because it can be easily misunderstood.  Does he mean, “there are negative consequences imposed on the team?”  I emphatically disagree with that.  Not delivering 2 of 9 stories is not an outcome that should be punished.

If it’s treated as something to be punished then I guarantee that the team will adopt counter-productive behaviors.  In this case, they’ll probably just low-ball all of their commitments so that there’s very little possibility of failing to deliver.  This doesn’t help increase efficiency and reduce waste, though, because there’s no learning and improvement going on, just self-defense strategies.

One of the potential weaknesses of Scrum is that it’s easy to get too fixated on the concept of a sprint commitment and whether you fulfilled or failed to fulfill that commitment.  Some measure of predictability is important, sure.  But no estimation technique is foolproof and you can waste an awful lot of time trying to perfect something that is inherently imperfect.  Always remember that the goal is simply “good enough” estimation because estimation isn’t value, it’s just a means to an end.

I think this is one of the reasons why there’s been a lot of attention paid to Kanban and single-piece flow systems lately; because Kanban gets rid of the sprint timebox and all of the potential distractions that go along with it.  I personally feel that Scrum and Kanban aren’t mutually exclusive and if you merge the best of both systems you’ll knock the rough edges off of both.  (Some people use the term “Scrum-ban”.)  One of the best influences Kanban can have on Scrum is to put the concept of a sprint commitment into its proper perspective, that is, it’s a device for short-term planning, nothing more.  Relax!

The sprint retrospective is a powerful tool for change and improvement but it only works if you approach it from a positive perspective of “how can we become better?” rather than a negative perspective of “how badly did we fail?”.

Always beware the Law of Unintended Consequences.  Whenever you’re working with a system that contains humans you’ll find that some things you implement for positive reasons end up having negative results because they reinforce the wrong behaviors.  I think an over-emphasis on sprint commitments, and and insistence on labeling each sprint as a success or failure, is one of those things.