Are You Audacious?

Ken Schwaber tells a story in his second book, Agile Project Management With Scrum, about a key contributor on a project who goes on vacation (hiking in Yellowstone park). Of course, as soon as he leaves, the critical component he is responsible for goes down in flames. The team is demoralized, the project is jeopardized, an impediment is born.

What would you do?

Apparently, if you have enormous brass balls and your name rhymes with “Schwaber”, you hire a former FBI agent as a private detective to go into Yellowstone and track down your missing developer and bring him back to the team to fix the problem. No joke (see page 117).

How many project leaders do you know would have that kind of audacity? I think there is a lesson for us in that story. All too often we turn away from problems that challenge our teams because they seem too great, too daunting to face.  I think Ken is trying to tell us that a certain amount of boldness is required to lead great teams. You have to be willing to slap down the credit card and make things happen. That’s how you build a reputation for delivering success (and perhaps a little insanity). The story could easily have gone much differently, but I don’t think anyone would argue that Ken was committed to the success of that team.

I think he’s inviting us to be audacious too.

Assessing Impediment Cost

If you are trying to resolve a particularly difficult impediment, try calculating the cost of the impediment to the team/customer. Often putting the damage into dollars and cents will help translate the problem into something that business stakeholders understand and respect, namely profit and loss.

I have a cost column in the spreadsheet that I use for tracking team impediments. I can’t always fill it in with a number (which is usually a signal to me that I need to better understand the issue), but when I can associate a cost with the impediment, I find it much easier to garner attention to the issue from executives and other key project stakeholders.

In fact, if you grab your dusty old copy of Kerzner, you will find an entire chapter on assessing the costs of risks and using it for decision making (Monitoring and Controlling Risks). We can incorporate this work into impediment management for agile teams.

The fact is, meaningful impediments cost your project, your company, and your customers money. Impediments are a threat to a team’s ability to rapidly deliver value. You could probably put it into an equation:

Stories – Impediments = Customer Value

3 Levels of Impediment Management

In this wonderful blog post, You Are The Impediment, Mike Cottmeyer argues that there are three different levels of impediment management required of a good scrum master/team leader:

1. The Tracker
2. The Remover
3. The Anticipator

He characterizes this as a sort of competence hierarchy for agile managers: Tracking being the minimum one could do, Anticipating being the desirable thing to do. I strongly agree. I see it this way:

1. Tracking = History
2. Removing = Managing/Problem Solving
3. Anticipating = Risk Management

Each level has a valuable skill set associated with it.

Having a history, whether it is a history of sprint velocity, a history of stories, or a history of impediments, is essential to creating the necessary level of information for the team to learn well. Like they say, those who ignore history are doomed to repeat it.

Removing impediments is really about problem solving. Problem solving is all about root cause analysis, building hypothesis, and tracking the results of experiments.  It’s common to see teams rush at solutions without taking the time to understand the problem well. We need to get better at using problem solving techniques to help us resolve impediments.

Anticipating impediments that have yet to happen is also known as risk management. Risk management is poorly understood in the agile community. Look for it in books regarding Scrum and XP and you won’t find any mention of it at all. Fortunately, there are some great books on risk management like Waltzing with Bears, that should be required reading for all team leaders.

A good leader needs to cultivate all three skill sets in order to maximize their team’s chances for success.

Grade Job Applicants using Impediments

Bring the candidate scrum master to the team stand up and have them listen in with you. Afterwards, simply ask them how many impediments they heard come up during the stand up.  If they didn’t hear any impediments, then they probably aren’t a good candidate (hint:  no impediments from a team is an impediment all by itself). If they heard more than one impediment, then perhaps they are a decent candidate.

Want to take it even further? Pair up for the remainder of the day and chase one impediment down together. If you nail it by the end of the day, then share a high five and hire that candidate! For a prospective scrum master, dealing with a real organizational impediment will tell them more about a company’s culture in one day than attending a week’s worth of meetings.

Impediments are the Measure of a Good Team Leader

Overcoming impediments is not for the timid. It requires a single minded purpose, a completely uncompromising attitude, in order to overcome the obstacles that face your team. For the scrum master, it is the impediments that you face that will define your skill and ability as a team leader. Every impediment that you fail to address reduces your value to the team. Every impediment you are able to remove increases your value to the team. It’s really that simple. Remember that the next time you face a daunting impediment that blocks the team’s progress.

The only use of an obstacle is to be overcome. All that an obstacle does with brave men is, not to frighten them, but to challenge them.
- Woodrow Wilson

When ToDo, In-Progress, and Done Aren’t Good Enough

On a task board there are two places that we can capture additional detail regarding the tasks we are working on:

1. In the tasks and stories
2. In the categories that we use to organize the tasks and stories

The common starting point for categories on a task board are: ToDo, In-Progress, and Done. Obviously this works for the great majority of cases because the categories are so vague. It’s the starting point for most teams that are using a task board for the first time. However it isn’t long before we discover that some things don’t fit this model well. For instance many tasks commonly take place in multiple ordered steps. Look around you, it happens all the time. Trying to capture tasks that have more than three steps to them on a task board starts to feel awkward. People start to ask if there should be another column on the board. The answer is probably yes.

You see, if you resist and decide not to track additional legitimate state for a task, then in essence you are keeping that information invisible. State is important. Hidden state violates the principle of transparency that we are trying to promote on agile projects. So you need to find a way to represent it on your board. There are lots of mechanisms to reflect additional state on a task board:

1. Add new swim lanes
2. Use color on the task/story cards
3. Use labels or stickies on the task/story cards
4. Additional text on the card
5. Additional task cards

All of these techniques will provide additional state information to your task board. A common symptom of a board that isn’t conveying enough state information is when the stories tend to get “stuck” under the In-Progress category for long periods of time. Now there are lots of reasons this can happen, but one reason the task/story may not be moving is because you don’t have an adequate way to express the state of the progress being made on the work. The developer may be making lots of progress, but none of it is reflected in the task board. When this happens, you need to consider that perhaps the board is not displaying information that would make the progress visible.

I was reminded of this today when looking at a team’s task board. Stuff was sitting in the In-Progress” category for too long. However I knew that the team was making great progress. So they weren’t lazy. And they were keeping the board up to date. So what was the problem? There wasn’t enough information on the board to properly reflect the work that the team was doing. As a result, there were impediments that we couldn’t even recognize because we didn’t have any way of showing progress on the hidden states. Being blocked on “In-Progress” is not very informative. Being blocked on the “certification request” is much more explicit.

So the next time that the team seems like they are stalled with their task board, consider changing the way the information is presented. Adding a few new categories could help the team identify some of the hidden issues that are currently blocking them.

Dirty Agile

I attended the Rally Agile Success Tour a few weeks ago. I didn’t know what to expect, but it turned out to be remarkably good. As I listened to the speakers talk about their experiences implementing Agile projects, I was reminded of just how tough this work is. I think that often, as leaders (project managers, scrum masters, coaches, dev leads, managers, etc.), we tend to harbor idealistic visions of what an Agile team looks like and how it performs. It reminds me of the “Retro-futurism” that I think Brian Marick refers to in his ARxTA presentation at AgileRoots 2009. We harbor these notions of a future where the team possesses the ideal tools, the ideal solutions, the ideal environment. There is certainly nothing wrong with all that. We need these goals. We need to have that expectation that Brian characterized with the question, “Where’s my jet pack?”

But the reality is anything but clean and ideal. There is no jet pack. The reality of working with teams is dirty and messy. We don’t have the ideal team, we don’t have the ideal requirements, we don’t have the ideal schedule. In fact, we never will. That’s OK though, it’s the imperfection that provides the team with the creative tension needed to make the job interesting.

Happy (Dirty) New Year!

What I Learned From My Daughter’s First Grade Classroom

The new school year is beginning and my daughter is starting first grade. I had an opportunity to go to her elementary school open house the other day. A word to the wise: never let an Agile development geek into a first grade classroom. I thought I had died and gone to information heaven. I took a camera with me and took some pictures of the kinds of information that they put on the walls in a children’s classroom. It was amazing! In the meantime, my wife fervently denied that she was with the dork taking all the pictures of the walls. Here’s what I discovered before I was escorted from the building:

The first grade classroom is the prototype for a learning environment. These folks are the undisputed masters of the information radiator.  Everywhere you look there is information being displayed. The variety of different kinds of information displayed is amazing! The density of information here is incredible! In one corner of the room I see the following information:

• Monthly calendar
• Weather graph
• Password(???)
• The alphabet
• A tally of how many days they’ve been in school
• Numbers from 1-10
• Days of the week
• A chart of all numbers from 1-200
• A list of who has lost a tooth (Try that on your team! If the number is greater than five, you may be working in a biker bar)
• And a few other things I can’t quite interpret

What else can we see going on here? Well for one thing, there is LOTS of color. It catches the eye, calls attention to certain details, and livens things up quite a bit. It’s like an interior decorator went nuts in the place. Next, you may observe that much of the information is presented using multiple modalities. Multiple modalities? OK, they use pictures AND words AND color AND shapes. A lot of effort is being made to transmit information in a variety of different ways. Now, just for giggles, what if you were going to put together this exact same board for your team at the office? What would it contain? Here’s how I might do it:

• Monthly calendar – team vacations, releases, events, barbecues
• Release graph – How many releases per week are we doing?
• Word of the day (“Spurtle” – yeah, it’s a word)
• A quick reference containing all of the major Ruby commands (pick your API/Language, etc)
• A tally of how many days they’ve been working on a project/sprint/release
• Numbers from 1, 0 (hey, it’s computer science, you only need two numbers!)
• List of major business holidays (they always sneak up on me)
• A chart of all error codes used in our project
• A ladder of World of Warcraft names/rankings

Hmmm. That’s actually not a bad list. Give it a little color, play with the “modalities” and I just might have some pretty compelling information there. I wonder what else the first graders have to teach us? How about this:

I see at least three things here that I could try out with my team back at the office. First, there is information about today: we have the date, and then  below it is the day’s schedule. Now, I don’t know about you, but back at the office, I don’t have anything like a daily schedule posted on the wall with my team. We all have outlook, and perhaps some would say that’s enough, but for me it’s not quite the same. Outlook reflects MY schedule, not the team’s schedule. And there are significant team events that could use some advertising: Planning meetings, releases, retrospectives, reviews, scrum of scrums, and so on. I know that where I work, everyone is left to their own devices to manage these things and show up or not. Nothing wrong with that, but what if we had a daily schedule, a reminder if you will, that sat next to our task board at our standup meeting? Frankly, I think it might be useful. As a scrum master, it might be a way for me to rather subtly remind the team of the big commitments for the day. Or not.

Let’s move on from the schedule stuff. What’s up with the bottles of ketchup, mayo, and mustard? OK, it may be a little cheesy, but if you look at the image closely you will see that these are clever little symbols for “Catch-Up”, “May Do”, and “Must Do’s”. Do you track Catch-Up work on your team? No? Me either…wait a second…we do keep a list of technical debt. Isn’t technical debt a kind of  Catch up work? So keeping that list of catch up items makes a lot of sense to me. Also, the “May Do’s” and “Must Do’s” make a lot of sense to me as well. I think that defining work as “Must Do” will help the team prioritize the work that is most important (assuming you don’t abuse it) and the “May Do’s” gives the team the ability to identify the things that are available to be pulled on their own initiative. Adding may do and must do to a team’s daily activities would certainly be interesting to try out. I can see pros and cons to doing it. Maybe we could even use these criteria to categorize our backlogs? It’s a possibility…

How about the noise level trumpet off in the corner there? In the wonderful Agile Open Space that you work in, do you ever have issues with noise? Here is your answer! I wonder how well that actually works in a room full of first graders? OK, I’m not going to give them grief for this – it’s probably an experiment.

Here’s another gem that I captured before being chased out of the room by a rather menacing looking old battle axe with a broom (where DO they get these people?):

Would you look at that! They use the “Fist of Five” in first grade too! I was wondering where that technique came from! I need a copy of this poster for my team!

Ooh! Look here! They are graphing their moods over time! Cool! I’ve seen other teams do this, but I’ve never tried it myself. It seems like an idea with some real merit. It certainly makes sense to track the teams mood. It would be very interesting to review information like this at team retrospectives. It would certainly provide an interesting metric to compare against recent “improvements” or other team experiments. One other thing I want to point out here: these teachers seem to think that these information radiators are so important that they will try and cram them just about anywhere! Anyplace is game: the backside of a bookshelf, the side of a locker, the face of a cabinet – any place they will fit. Look around your office. Are you using all the space you have available?

Here’s a quick challenge: So what do you think this is?

Well, as my daughter ever-so-patiently explained to me, this is their “Job Wall”. I like the beehive image – after all we Agilista’s like to “swarm” don’t we? It seems that everyone has regular tasks that they are responsible for. These are tracked here. I like the way it makes responsibilities explicit for everyone involved. It makes me wonder where the teachers get all this stuff? Of course if I were to show up with this silly little beehive, I’m pretty sure that the team would laugh me out of the room. Of course that never stopped me in the past…

You know, if they ever  lift the restraining order and let me back on school property again, I’m definitely going to take some more pictures of the classroom walls. How come more offices don’t look like this? Why aren’t the environments we work in as information rich as the ones that children work and play in? I presume that in the office we are learning too, right?

Day 1 of Agile Roots Conference

This conference has an awesome speaker lineup for its relatively small size (~200). It’s really great! Great first day. Lots of notes. I’ll have to take some time to try and synthesize some of it and share. My presentation is tomorrow, so I’d better get my beauty sleep!

Technical Product Owner

So here’s the problem: Some teams have stories that are very “technical” in nature. By technical I mean that these stories are usually development oriented (in language, and in subject matter) and they are hard to relate to direct customer value. Often these stories are related to maintenance activities that have a strong perceived need to be done by various stakeholders, but are not explicitly requested by our external customers. Some examples include:

1. Stories requested by operations
2. Stories that have to do with infrastructure improvements
3. Stories related to technical debt

In some cases product owners have a real problem working with these stories. They complain that the stories refer to technologies or acronyms that they don’t understand. They maintain that they are a customer advocate and don’t care what the details are – just fix it. They don’t know how to judge when these stories are done.

To address this problem we have created a sub-category of product owner that we call a “technical” product owner. If you are starting to feel a bit squeamish at this point, I don’t blame you one bit. So who is a technical product owner? In this case it is usually the development lead for the team – or perhaps a director of development.

The solution is a well intentioned one, but there are consequences. The problems with using a “technical product owner” that I see in practice:

1. The technical PO has no connection with the rest of the Product Management/Business/Customer organization. This basically sets the team up to operate without having to deliver value that the rest of the organization recognizes. It seems to aggravate silos within an organization.
2. The Product Management (PO) team gets to ignore important decisions regarding the maintenance and upkeep of business systems. When you buy the car, you need to be responsible for it’s upkeep. All too often I know PO’s who refuse to address technical debt when it is brought to them. Instead they prioritize new features higher – sooner or later it comes back to haunt them.
3. Teams get out of the habit of working with user stories that customers can relate too. Or they take perfectly good user stories and break them down into “technical stories”. There are all sorts of reasons this happens to teams – but we don’t want to codify the practice by creating a special “technical PO”.
4. It can reflect an organization’s unwillingness to organize projects that are aligned across the organization rather than within technical silos.

Personally, I think that we should be able to put all stories – regardless of where they originate into terms that anyone can understand. Failure to do that may lead you down a path that leads to the “Technical Product Owner”. Watch out.