Passionate User Stories

November 28, 2007

Tired of writing the same old user stories the exact same way every single time? Are you losing a little bit of the agile spring in your step? Recently I found myself feeling just this way. I was reviewing the stories for an upcoming agile project and feeling remarkably unenthusiastic about getting started. What was the matter? The project had clearly written stories. The objectives were reasonably clear. Why wasn’t I excited about taking this project on? I realized it was because there seemed to be no life in the stories themselves. This wasn’t the first time I’d encountered this. The question before me was, “How can I breathe a little passion back into the stories that I work on?”

By now, many of us are familiar with what good user stories are supposed to look like. I learned how to write them from Mike Cohn’s book, “User Stories Applied”. The format he introduced looks something like this:

As a <role>
I want <function>
So that I can <business goal>

I have a confession to make – sometimes writing stories in this format leaves me completely cold. Seeing that same format repeatedly tends to drive me nuts. It can be a lot of extra work to put stories into this format.

Putting a little Passion Back into Your Stories…

Sometimes I get lazy and I just give up and create a one-word story. Here is an example of one of my one-word stories:

Mentoring

OK, so it’s a little opaque. I know what it means. Nobody else will understand this story, but who cares? A story is just a placeholder for a conversation, right? Well, having lived with one-word stories I find that they suffer from the following problems:

  1. I tend to forget what the context was
  2. The verbs are often missing – what am I trying to do?
  3. They don’t really motivate me

Let’s take my example above – mentoring. What did I mean by that? Is it mentoring for me? Mentoring for someone else? Perhaps a mentoring program? Maybe I meant all of the above? Without some sort of context, there is no way to know what this “story” was all about.

I like having an action verb in a story. Anything will do: provide, obtain, receive, implement, create. Put any of these words in front of “Mentoring” and you automatically get a little more context in the story. Obtain a mentor. Provide a mentor. Receive mentorship. Suddenly I have a much clearer picture of what the story is all about. So here we go:

Obtain a mentor

Of course, “obtain a mentor” doesn’t exactly light the fire in my belly. Boring! I feel sort of like, “OK, I’ll do it – if I really have to…”

How do we fix these stories?

We could go ahead and use the format that I was avoiding from the start:

As a project manager
I want
a mentor
So that
I can be more successful on my next project.

That’s not bad – it’s a distinct improvement really. Now I know the context pretty well. I know the who, what, and why. Not too bad at all. Nevertheless, it’s still not setting my shorts on fire.

How about adding some adjectives? Let’s give that a shot and see what happens. We have to ask ourselves a few questions first. Let’s start simple:

What kind of mentor are we looking for? I want a great mentor. OK, let’s crack open the thesaurus and see what we can find…
Great, Inspired, commanding, distinguished, dominant, excellent, enthusiastic – hey! I think we have a winner – enthusiastic. I like the sound of that. I want an enthusiastic mentor! Let’s re-write our story again:

I want an enthusiastic mentor

Who will help me be successful on my next project.

Hmmm… I am definitely starting to like this story. I dropped the “as a” phrase because it was redundant – we’re just talking about me. Furthermore, I changed “so that” to “Who will help”. It just seems to flow more naturally and better convey the meaning of what I am trying to do. Not only do I know that I need a mentor, but now I know what kind of mentor I’m looking for. This story is getting better as we build it up word by word. After all, when we only have a sentence to describe what we want, every word counts.

I wonder if I can improve this story still further? How about a trip back to our friend the thesaurus? Let’s see: successful, flourishing, dominant, leading, noteworthy, smashing, stunning – oooh, there’s a good one!

I want an enthusiastic mentor

Who will help me make my next project a stunning success!

YES! Now that’s a story I can get behind! That lights my fire! That’s a story that I want to deliver. Remember, one of the keys to successful agile development is to have audacious goals. I feel like we miss the opportunity for a little audacity in our lives when we cop out on writing good stories. Stories should be something that the customer is passionate about. They should be something that the team should be able to get passionate about. It’s hard to get passionate about single word stories. Even the standard story form is a bit bleak.

Of course, this story still has a weakness – it’s not testable! I need to define what I mean by a “stunning success”. How am I going to define success? Let’s try this on for size:

I want an enthusiastic mentor

Who will help me make my next project a stunning success

by doubling the project revenue!

Aha! Bring it all back to money! Nice! Now we have a compelling AND testable story. Sign me up!

Now let’s try this technique with another story. Maybe something that feels a bit more like a real customer request. How about this:

Prioritize Tasks

So I have a list of tasks and I want to prioritize them. Let’s play with it and see where we end up:

I want a quick and intuitive way to prioritize tasks

So that I can maximize the productivity of those who use this tool

You’ll notice that I’ve taken some artistic license in interpreting the words that apply to these stories. The simple act of looking for different ways to describe something using a thesaurus brings up all sorts of interesting related ideas. We don’t have to settle for the most spartan explanation possible.

Here is my theory: If we invest some time, and perhaps just a little imagination, we can transform our stories into something that is really worth doing. Take a few adjectives and put the passion back into your work! I guarantee you that the time will be well spent. Be audacious! Be passionate! Have fun!


Hanging My Test Driven Christmas Lights

November 26, 2007

Every once in a while I have one of those, “Science catches up with reality.” moments. Take, for example, this weekend. I was putting the Christmas lights up on our house. You know, that yearly ritual where an otherwise sane man will risk life and limb in the pursuit of putting more lights on the outside of his house than his neighbor has. I fall victim to this peculiar form of insanity about once every 12 months. So there I was, cursing as I disentangled myself from a particularly aggressive set of C9’s. I was just about done. Icicle lights along the roof line, LED’s along the garage, rope lights arrayed down the driveway, lighted Christmas tree and snowman in the front yard – my chest positively swelled with pride. All I had to do was to plug it in and survey this masterpiece of suburban manhood. I stick the plug in the socket and I hear a “pop!” as the fuse in the snowman blows, and then I look up to notice that half the lights on my roofline are not lighting up. Cue more vehement cursing.

I had broken the first rule of agile development – Test First! Of course, any reasonably competent handyman would have known to try plugging in each strand of lights before beginning the life threatening task of suspending them from the roof – right? As I stood there at the foot of the ladder and contemplated my predicament, It occurred to me that the consequences of failing to test in the real world are a whole lot more painful than in the digital world. It’s really quite amazing that Test Driven Development hadn’t come along much earlier. If you stop and look around, people are doing it everywhere! Doing some woodworking? Measure twice, cut once.

Why did it take so long for us developers to catch on? Perhaps it is just because in the digital world, the consequences of failing to test your work really don’t have any physical pain associated with them. Anguish maybe, but pain? No. Was I going to be in pain replacing those lights? Oh yes.

I’ve always suspected that every developer’s chair should have a Taser installed in the seat. Broken build? Bring on the voltage baby! Maybe a more severe appreciation for the consequences of breakage is what we all need. As I returned to my roofline to retrieve the dead strands of lights, I realized that even the most trivial activities can benefit from the application of Test First or TDD. After all, if you had asked me, I would have described putting lights on the house as anything but a challenging intellectual activity. Hah! now I was the idiot desperately clinging to the frozen eves of my own house, praying that I wouldn’t fall. As my flimsy ladder shifted beneath me, my life flashed before my eyes like a bad ‘B’ movie (very boring – gotta get a new writer) I realized the error of my ways.

To make matters worse, I had a string of lights that would sort of randomly turn off if I happened to jiggle them just right. My tests on the ground would prove they were fine, but then if I moved them a little, they just might just as easily test as bad. What can I do to solve this problem? Test first doesn’t do me any good here. Then I had an epiphany: why not use Continuous Integration! If I leave the lights on while I’m hanging them, then I can always visually see if I’ve created a problem as I’m in the process of hanging the lights. Cool! I can make changes to the layout of the lights based on the feedback I get as I actually lay the strands out. Blow a fuse? No problem, time to rethink that strand arrangement. So now I’ve managed to incorporate two principles of agile development into my process for hanging Christmas lights: Test Driven Development, and Continuous Integration.

I know what you are thinking – this guy seriously needs to get a life.

But honestly, I think it helps to try and find examples of these principles in your daily life. As we focus more and more on changing our fundamental paradigm for software development from waterfall to agile, we need to keep seeking validation in the “real” world. Look to other disciplines, look to the mundane, the everyday things that we do. Check and see if the premises that we use for Agile Development apply elsewhere. So, the next time you find yourself facing one of those everyday challenges, take a moment to reflect on whether the application of a few agile principles might be just the thing to help you out. And who knows, you might actually get those Christmas lights working…

Merry Christmas and Happy Testing!


Task Boards: Telling a Compelling Agile Story

November 24, 2007

The task board is the single most important information radiator that an agile team has. A task board illustrates the progress that an agile team is making in achieving their sprint goals. Usually the task board is located in an area that is central to the team. For example, it’s in their work area or in the war room where they hold their stand-up meetings. I would maintain that the task board is an expression of the personality of the team. Some teams operate in a very minimalist style – only the most essential information is displayed. Other teams are quite disciplined. Everything is neatly laid out and you can get a very clear picture of the product that they are working on. From what I have seen, every task board is unique. It’s interesting to look at the different kinds of task boards that teams use, and compare and contrast the differences.

A Survey of Task Boards

Out in the “wild” there are many different examples of what a task board looks like. For example, this one uses a corkboard and three by five cards. One way to improve this task board would be to add a burn down chart. Then you not only see the status of the tasks being worked on, but you also see the burn down information which provides a overview of the progress that the team is making on the tasks for that sprint.

Coarkboard

Figure 1 – The Corkboard Task Board

Below is a rather more elegant version of a task board. I call it the “Beautiful Mind” task board. We just took some of that blue masking tape used for house painting and laid out the task chart directly on the window. Post-Its were used for everything else. It was located in an office building where there were many windows, but not very many walls. It was sort of a “low impact” solution. This demonstrates that with a little imagination you can create a task board just about anywhere.

Beautiful Mind

Figure 2 – The “Beautiful Mind” Task Board

It also makes you look smart if you stand next to it and gesticulate.

Here are a couple more examples of some task boards that we have seen “out in the wild”.

3 by 5 Cards

Figure 3 – The Minimalist Task Board

This one is just 3 by 5 cards taped on the wall. The yellow cards indicate the stories and the teal cards indicate the tasks. Task progress and status is indicated by putting little stickers on the cards and updating the hours remaining. Again, we see the burn down charts displayed prominently next to our task board.

Now we venture into the den of our very own CTO, Brent Barton! I wonder what he does?

Brent’s Board

Figure 4 – Our CTO’s Task Board

It seems that he prefers the “Beautiful Mind” style of task board. Very interesting! Again, it has the same columns that I described above. The interesting thing about this task board is that it is used just for tracking the work that Brent does. So, a task board can be applied not only to a team, but also to the work of an individual (especially one as busy as Brent). We should leave now before he wakes up…

Now I would like to share a rather unique idea for a task board that I was introduced to the other day:

Laminated Poster

Figure 5 – A Laminated Poster Task Board

This is a laminated poster that was created a team member with an innovative streak! He’s done a great job of standardizing the information and making it easy for people to update. It’s organized a little bit differently than the other task boards that I have shown you. There are some little bits that I might change, but I love the idea in general. I’ve seen a few more of these posters springing up lately, so maybe they’re catching on.

Here is another example of a printed poster that was used as a task board:

Excel Spreadsheet

Figure 6 – Excel Spreadsheet Task Board

This is just based on a printout of an excel spreadsheet. That certainly makes it easy. Just print it out and fill in the blanks.

So What’s in a Task Board?

These are just few examples of task boards in the real world that many of our customers use to track their sprint progress. All of these task boards have a few simple things in common:

1) 4 basic columns (there can be more)

a. Stories

b. To Do

c. In Process (In progress, WIP, etc.)

d. Complete (Completed, Done, etc.)

2) A Row for each story

A task board is really just a glorified swim lane diagram. I wonder what Edward Tufte (The data visualization genius, http://www.edwardtufte.com/tufte/index) would have to say about task boards? I bet he would like them. So if we are going to toss together a basic task board, then we need to take the ingredients above and find a little wall (or window) space to work with. The layout is very straightforward. Here is a simple diagram to illustrate this:

Simple task board

On the left, you have a list of the stories that you are working on for the sprint. In the next column, “To Do”, you have the tasks necessary to complete the story. You move the tasks from “To Do” into the “In-Process” column while you are working on them. When you are done, you move the task from “In-Process” to “Complete”. It’s really pretty simple.

Transitions

You can also do a more complicated version that looks something like this:

Taskboard

Notice that there are some extra columns in this one: Tests Ready and Hours. Test Ready indicates that the acceptance tests for this story are ready. This serves as a sort of gate that prevents work from moving forward on a story until the acceptance tests have been written. Having the hours remaining summarized at the end of the row just makes it easier for the team to keep track of time remaining for that story. Combine the hours remaining with a burndown chart and you will find that the chart gets to be very easy to update.

Electronic Task Boards

So, by now it should be clear that there are many different types of task board a team can easily create. They work great for people who are all co-located, but you might ask, “What about people who aren’t located in the same room as the team?”

Well, I’m glad you asked!

There are many tools out there that provide electronic versions of team task boards. One that I’m very familiar with is Rally. It gives a nice detailed summary of the stories and tasks that a team is working on in a sprint. It tracks time remaining, who’s responsible for the task, and what state the task is in (Defined, In-Progress, Complete). It has nice reports and burn down charts. In fact, some teams that I work with will display the burn down chart on a monitor above their desks so that the whole team can see the current burn down status. Good idea!

Rally

Figure 7 – Rally Task Board

As you can see, there is a lot of information on display here. In this view, Rally displays a hierarchical list of stories and their associated tasks for a given sprint. However, instead of moving tasks from column to column like we have seen in previous examples, Rally uses icons to indicate the current state of each work item (‘D’ for Defined, ‘P’ for In Progress, ‘C’ for Complete, and ‘A’ for Accepted).

Perhaps a web-based tool like Rally isn’t what you are looking for. Then perhaps you might consider looking at a tool like ScrumWorks. Their product has been around for a long time and continues to evolve in interesting ways. Again, ScrumWorks provides an information rich display of the current stories and tasks for a sprint. Overall, the Scrumworks interface is somewhat cleaner and simpler than the Rally interface. You aren’t plagued with a host of different tabs and options on each screen. Everything is pretty straightforward and simple to use.

Scrumworks

Figure 8 – ScrumWorks Task Board

The ScrumWorks display shows us the list of stories and tasks and that’s just about it. They don’t overwhelm you with multiple columns of information like other products do. However, there is no real analog to a task board here.

Just when I thought I understood all the players in this domain, our friends at ThoughtWorks brought their own product to the playground. The new kid on the block is Mingle. Mingle is based on a very flexible, wiki style platform. I haven’t had as much experience using it as I have with the other two products, but it looks like it’s going to give folks like Rally and ScrumWorks a real run for their money. The UI is clean and the product seems to allow a nearly endless variety of configuration options.

Mingle

Figure 9 – Mingle Task Board

So there we have a few of the electronic tools for task board management that are available out there. Most of my software friends run straight to the electronic tools like moths toward a bug zapper. I’ve done it myself – I’ve got the scars to show for it. The fact is that electronic tools have their uses, but they are not a good substitute for a nice tangible task board that a team can stand up in front of and work with together. Online tools seem to keep people in isolation. Everyone at his or her own desk, staring at the screen – that’s just not agile. I prefer to have the team working with a real physical entity that they can manipulate, edit, whatever. The quality of interaction is much higher.

In addition, electronic tools tend to hide information. They tend to make things less transparent rather than the other way around. If I walk into a team’s work area and they have no task board, then there is no way for me to quickly assess how they are doing. For a team member, the information is gone the minute I switch to any other activity on my computer. The information remains hidden until I select the tool again.

If you have a customer that can’t see your task board (as is often the case), then using an electronic tool makes a lot of sense. The same applies to working with distributed teams. However, use the electronic tools as a supplement, rather than as a replacement for the physical task board.

Let’s Review

Here’s a radical idea: Maybe we should be thinking of a task board as a recruiting tool. We should be showing off the cool stories that we are working on. They should be compelling enough that people passing by might take interest in them. They might stop, look, and think to themselves, “I would like to be a part of that…” Perhaps they might pass by, stop dead in their tracks and say, “No, no, no! I have a better idea!” Task boards should tell us all how the project is going. They are something to be proud of. A team slogging through incredible obstacles could show off the stories that they’ve accomplished like tattoos on the arm of a war veteran.

Task boards should be vivid illustrations of the achievements of a team. They should present a compelling picture of the challenge the team has undertaken. Along with a vision statement, they should draw us in. Like the TV commercials, they say this is where “The Few, the Proud, the Daring” will go. Give me an audacious goal, a compelling story to get there, and I will sign up in a heartbeat.

I can imagine walking through team workspaces and reading the task boards for each team. Some may have stories for teams that are just getting started and looking for new team members. Exciting stories full of promise. Others might reflect the work of projects that have been in progress for months or years, representing a tale of the battles that our grizzled IT veterans have fought and won – their challenges and triumphs. As I walk around the company, the task boards should reflect the nature of the work that each group is doing. Maybe I see financial projects near the CFO’s office. Perhaps corporate initiatives are tracked near CIO’s office. I bet there would be some exciting stuff up there.

When I think of the task boards, they remind me of those thermometers that HR puts up when we are doing a food drive. There is some compelling goal or vision (feed the homeless, toys for tots), and a big visible indicator of how close we are to achieving that goal. We need more of those. Make people want to work on your team – take the time to make your task board tell a compelling story.


Sustainability and Plateaus in Agile Development

November 20, 2007

I’ve been thinking about how to keep the project pace sustainable a lot lately (my wife says I need a hobby). My experience has been that agile projects generally demand a lot more focused engagement by the team than plan driven projects. This is both good and bad. The short, intense sprints enable some remarkable productivity, but they also come with a cost. Without a doubt, the highly collaborative environments found in most agile projects require a lot of energy on everyone’s part. Eventually it can take a toll on everyone. I am fortunate enough to work in an environment with lots of agile teams, and I think I see a pattern emerging.

Here’s how it goes: The team starts off slowly, builds up some velocity, works out some issues and is soon a fairly highly performing unit. But the challenges don’t stop coming. Some of this is good, challenges are what make the work interesting. However, some of those challenges have an emotional component – and they can be real killers. For example, problems getting the product owner to engage, internal team conflicts, defending the team from micromanagement by upper managers, etc. All of these challenges are quite normal, and frankly they are to be expected in any agile environment. After maybe a year of these challenges you might start to notice the scrum master starting to look a tad bit crispy around the edges (is that a nervous tic or is he winking at me?). The team might start showing up at 10 AM rather than 9. Give them another six months, and while there may have been many successes, they all start to get a bit of that “thousand yard stare”.

One of the benefits of highly transparent environments like those found in agile teams is that problems are often raised more often and more visibly. This is often touted as being good for the overall health of the project, but it can also be hell on the team. Bringing conflicts out into the open is great, but it’s also exhausting. Continuous improvement is great, but it’s also a lot of hard work. I think that it contributes to a very real feeling of burnout.

Recently I realized that I’ve encountered this phenomenon before: back when I used to be involved in amateur weightlifting. Burnout is a very common phenomenon in many different sports. It’s symptoms can range from the very simple (physical exhaustion) to the more subtle (such as a lack of enthusiasm, depression, etc.). And in my opinion, it is probably the single most difficult challenge to face when you are trying to push yourself (or perhaps your team) to the next level of performance – mental or physical.

In sports there is even a terminology used to describe advancement through these different levels of accomplishment: “I’ve hit a plateau” A flat spot, an inability to make further gains. No matter how hard you throw yourself at the problem, nothing you do seems to lead to an improvement. It’s as if the body and the mind have conspired to say, “We aren’t going any further – we’re gonna take a break.” So what do you do?

Maybe you thrash for a while, trying to continue to make those magical gains that you first experienced (you want that endorphine rush!). But at some point it becomes apparent that progress just isn’t going to continue forever. The day to day monotony takes over and you simply deal with the basics: you show up, you do your work, you endure the pain, you go home and you rest. I think there is a very close parallel between these plateaus that we reach in athletics and the plateaus that we reach as software development teams.

With software teams, the challenges are a bit different, but the “plateau” is the same. We’ve got our continuous integration working. We’re using pair programming. We have beautiful burn down charts showing our progress – and yet we still haven’t reached our goal of delivering fully tested software to our customer every 2 weeks. What’s the matter? I think this is the point where we may lose a lot of people who are trying out agile methods for the first time. They think, “We tried it the new way, and it felt good for a while, but in the end it was just more of the same hassles.” Same issues, different methodology. The fundamental problems don’t change.

I’ve seen this happen in weightlifting countless times. Go into any gym the week after New Years day. The place is packed! People are feverishly pounding iron like there is no tomorrow! This is going to be the year that they get in shape! Here comes that six pack! Then the inevitable happens: toward the end of January the gym starts to get less crowded. By mid February the place is almost back to normal again. No surprise I guess, it’s just human nature at work. But what about those guys who are still there in June? How do they manage to keep it up? What is it that makes them different?

Now, in my own experience there are two factors that can make a huge difference for the guys who pound it out day after day: they have almost maniacal discipline, and they have a plan.

After hanging out with the die-hard weightlifters for a while, I discovered that they all had different strategies for pacing themselves in order to hit a long term objective. Say for example, that you wanted to bench press 300 pounds, but right now you were only able to bench press 275. How do you create a long term strategy that will allow you to gradually work your way up to the desired weight?

I think the first strategy was discovered by the ancient Greeks – you simply increase the weight in tiny increments until you reach your goal (actually there was this guy who was fond of lifting a calf every day until it was full grown – don’t ask me for the details – it’s all Greek to me). That strategy of building in tiny increments is a start, but it doesn’t really model the way we typically make gains. Typically athletes make gains after long plateaus or stable periods in their training. Then it sort of happens all at once. One day you are pounding the same weight as yesterday, then BOOM! the energy comes and you are ready to go to the next level.

It suggests that the body needs time to acclimate to each level of performance. That there is no such thing as truly non-stop continuous improvement. You improve for a little while…and then you plateau… You might want to go further, but you are just not ready yet – and there is no forcing it. However, you can plan for it. That made me wonder, are there plateaus for teams? How do we get past those plateaus?

Weightlifters and other athletes use a strategy called “cycling” to try and simulate the highs and lows of normal development (physical development that is…). It’s a plan to enable them to reach their “Peak” without burning out. Cycling involves gradually working your way up to a heavy weight, and then backing off. The next time you start a cycle, you start with a baseline just a few pounds heavier and go a little bit closer to your peak from there. To do all of this, you need to do a fair amount of planning. If I have a competition three months away, then I might put together a workout that allows me to “Peak” or cycle about three times (once a month) before the big event. I calculate the weights that I need to lift on any given day, then it’s just a matter of showing up and doing the work. That’s where the dedication comes in.

The cycles or plan that I have created give me a set of milestones or deliverables to work with. If I discover that one month from now, I’ve added 20 pounds to my bench press – hooray! I’m ahead of schedule. Or I may find out that I’m 5 pounds shy of my goal. Then I adjust my plan for the next cycle and keep moving forward. By the time the day of the competition arrives, I should have had enough experience with my previous “Peaks” or deliverables that I should be fairly confident of what I can accomplish. It shouldn’t be much of a mystery. To me, this technique bears a strong resemblance to the short, delivery oriented iterations in agile – and even to some of the agile planning techniques.

For me, the hardest part is not the planning, but the discipline to consistently execute. It’s that maniacal discipline that I was talking about – and it ain’t easy. There are so many different excuses I can come up with to skip some apparently trivial part of the plan on any given day. The really hard part is to show up and do the work, and report the results the same way – every single day without exception – regardless of whether it is raining, snowing, you have a cold, your mother-in-law is in town – whatever. You get the idea. I think that all too often I have used these excuses on my projects too: Skip the stand-up meeting because we all really “know” what’s going on, forget to report burn down time accurately – I’ll catch up tomorrow, delay creating tests because the code doesn’t *really* need it. You name the lame excuse – I’ve used it.

I see potentially strong parallels in the efforts that development teams and athletes might use to pace themselves whether they be weightlifters, runners, swimmers, or golfers (wait…scratch that, golfing is *not* a sport). So if you find yourself unsatisfied with the pace of your teams progress, if you are wondering if you will ever find a way to meet the next challenge – try looking a the way people in other domains pace themselves. I think there is a lot that we could learn from other disciplines such as athletics. Maybe your development team has reached a plateau – that’s perfectly natural. We talk about continuous improvement, but other disciplines learned a long time ago that it’s much more complicated than just changing a little every day. For example, some teams need to reach a certain level of collective maturity before they are ready to take on something like pair programming. If you try and force them to do it too early, it’s like trying to teach a pig to sing – it frustrates you and irritates the pig.

Speaking of pigs, that brings me back to Scrum. Maybe we need better mechanisms to help assess where teams are in their development, so that we can provide the mentorship and/or the tools they need to make it to the next level. Whatever the answer is, I think that I learned a few valuable lessons from my own athletic experience with regard to keeping the pace of a team sustainable. I would invite you to consider your own experiences outside of the software domain and see if there are similar parallels that arise for you.

Go Seahawks!


Anti-Patterns: When Scrum Becomes Ordinary

November 15, 2007

Scrum was named for the formation of a Rugby team that is contesting possession of the ball during a Rugby match. It is characterized by a unified front formed by the entire team. Teammates are literally locked together arm in arm, shoulder to shoulder. Everyone on the team is intensely focused on the same objective: get the ball. When there are two teams lined up against each other like this, you can tell that it is a herculean effort. It is a contest of strength, of will, of iron resolve. It’s tremendously exciting to watch. There is nothing ordinary about it.

Scrum shares many of these attributes with the sport of Rugby. The team is focused on the same goal. It is a unified effort that is driven by the strength, will, and iron resolve of a team. Think back to those first few times you worked with a Scrum team. Were you energized? Did you believe in the promise of agile development? Did you really want to see it work? It’s normal for a team to be very enthusiastic at the beginning of a project. If your team isn’t enthusiastic at the beginning of the project, you probably have a problem on your hands.

Regardless, teams march forward, sprint after sprint, chasing the ball. After doing it for a while, it’s easy for complacency to set in. You do the planning, the daily scrum, the review and retrospective, rinse, wash, and repeat. Simple. Somewhere along the line, the team gets into a rhythm and everyone knows what to expect next. The customer is seeing increments of product value, the team is delivering, and everybody is happy. This is when a Scrum team is most vulnerable to its greatest enemy: The Ordinary.

The Ordinary is very seductive. It whispers warmly in the ears of your teammates, “Why change now? Why mess with a good thing?” The Ordinary croons some of my favorite tunes, “If it ain’t broke, don’t fix it.” And “Good enough.” The seeds of The Ordinary seek to take root everywhere: in your goals, in your user stories, in your code, in your impediments. When things get “ordinary” on an agile project, it’s really the beginning of the end.

What do I mean by ordinary? Let’s go to the dictionary (Mirriam-Webster):

Main Entry: 2ordinary
Function: adjective
Etymology: Middle English ordinarie, from Latin ordinarius, from ordin-, ordo order
1 : of a kind to be expected in the normal order of events : ROUTINE, USUAL <an ordinary day>
2 : having or constituting immediate or original jurisdiction; also : belonging to such jurisdiction
3 a : of common quality, rank, or ability <an ordinary teenager> b : deficient in quality : POOR, INFERIOR <ordinary wine>
synonym see COMMON

I’m talking about definitions 1 and 3. Some people might argue that an agile team becoming ordinary is a desirable thing – not me. Ordinary is the archenemy of inspect and adapt. A team that settles for the routine, the usual, is not looking for ways to improve themselves. They’ve become set in their ways and stopped looking for new ways to improve. I’ve seen it happen over and over again. The teams start out gung-ho and launch themselves up the agile learning curve with great gusto, only to stall out midway to their goal. I’ve seen it so much that I think of it as an agile anti-pattern. I’m sure I’m not the only one to notice this – in fact I’m willing to bet that someone else has coined a term to describe it (but I won’t let that slow me down).

What are some of the symptoms of the ordinary in a scrum team? Here are the top 4 places I look for the ordinary on an agile team (in order of importance):

1. Impediments – Missing or failing to resolve them

2. Failing to Act on Retrospective Action Items

3. Meaningless or Missing Sprint Goals

4. Boring Stories

Whenever I go to a standup meeting and one by one everyone says, “No impediments” I know the team has succumbed to The Ordinary. They’ve lost the will to keep seeking improvements. Impediments often seem like deceptively bad things. Impediments slow you down, right? No! Impediments are opportunities to speed up your team! Impediments are a gift, a chance to make things a little better. They are tiny things with subtle impact. They are EVERYWHERE! We live in a veritable soup of impediments every day. That’s part of the problem – we have gotten so used to them that they have become ubiquitous. We fail to recognize them because we have gotten so used to accommodating them. Finding impediments can be hard because we have conditioned ourselves to ignore them. It’s easy to come to the daily stand-up and report, “No impediments.” And get on with the rest of your day. After all, if it was a serious problem it would be staring you in the face, right? No! I would propose that you think of your stand-ups differently. Think of the 15 minute standup as your one golden opportunity to do one small thing to help out your team. Count on it – this is a chance to make big difference to your team. You have just a few brief seconds to identify what you did yesterday, what you’re going to do today, and identify an impediment. An impediment is a gift that you bring to your team every day. Everyone should strive to find one every day – and the scrum master should be striving to eliminate them by the end of the day. Conversely, failing to identify an impediment every day is letting your team down when they need you.

One area that I have failed my team as a scrum master is with the Retrospective. Here is what I mean, part of the Retrospective is to identify the things we would do differently in the next sprint. It’s another one of those golden opportunities for change. However, it is deceptively easy to walk away from the retrospective and forget about those things. It’s almost like we treat it as a purgative experience. We flush out all the bad ju-ju, wave a magic wand, and move on to the next sprint. We sit around and share what went well, we anguish over what didn’t go well, we feel each other’s pain…and everybody goes home. We come back the next day all refreshed, and we continue to work as normal. What’s up with that? When nothing changes, The Ordinary has won again.

Meaningless or missing Sprint Goals are another sign of the Ordinary. When sprint goals are missing, it says to me, this team isn’t willing to take the time to come up with a real reason for accomplishing this sprint. It tells me that they are content to trudge onward without a goal. One story after the other, one foot after the other, marching forward without a goal. That just sounds like drudgery to me. In rugby terms, the objective goes from “Score a goal and win the game” to “get another 5 yards”. The reason, the passion, the objective for why you are doing what you are doing is completely lost. This isn’t a team pushing the envelope – this is a team that forgot to lick the stamp!

I’ve already written about “Passionate User Stories” before. Who wants to work on boring stuff? If you can’t bring any passion to your work, who is going to sign up for those stories? Are you really going to get the team to work hard on something that bores them to death? I don’t think so. The teams that win consistently are the teams that put an equal amount of passion and zeal into everything that they do. Nothing is too ordinary to be elevated and made worth truly doing. When I read boring stories that lack passion, I know that The Ordinary has set up house with that team.

So how do you defeat The Ordinary? You don’t settle for the status quo. You keep pushing yourself and your teammates to bring greatness to your team. Set audacious goals. If you aren’t trying to become the best agile team in your company, then your goals are too low. If you don’t want to be the absolute best, then scrum probably won’t be much more effective than any other methodology. In fact, you have to do more than want it – you have to demand it. You have to expect it of your team. You have to seek out the The Ordinary and root it out where ever it hides. You must hunt it down, identify it, and exterminate it relentlessly.

So what is your job? Your mission is to perform The Extraordinary and settle for nothing less.