How do you organize your Scrum board?

Like many Agile teams, here at FillZ we use a big whiteboard to help organize ourselves. We still have Jira/GreenHopper to track the details, but we use a whiteboard to focus our daily stand-ups and give us a place to get some tactile feedback from moving stickies around.

We have organized our Scrum board into Four columns: Story, To-Do, In Progress, Done. We also have multiple rows, or “swimlanes” that we use to organize our tasks by theme (usually a theme is a single story).

The Story column contains the title for each group of work in the sprint. Something like “Add support for new import format”. The To-Do column is the task-breakdown for this work. Each day we move tasks (on individual stickies) from the To-Do column to In-Progress to Done.

Nothing really new here.

However, this sprint we’ve added additional swim-lanes for each developer on the team. These rows are where each developer will place the tasks they are doing in addition to the work in the other lanes. This might include professional-development projects (try using R to analyze our metrics), non-story tasks like tuning the build-system, or even DevOps issues (reduce the number of pages from system X).

We realized that we were all doing tasks like this in each sprint, but we were never accounting for them or sharing them with each other. The plan is that developers will bring their list of personal tasks to each sprint-planning session and we’ll start estimating and including them officially in each sprint plan.

Experiment in progress. I’ll let you know how it goes.


Push versus Pull

PointCast was launched in February of 1996 to much fanfare. The premise was simple: create a service that let people receive customized news and information pushed directly to their desktops. Sounds like a good idea. Too bad it failed and the PointCast network was shutdown in 2000.

There are lots of business reasons why PointCast might have failed. For the purposes of this post, I am interested in why PointCast, as a technology, was unsuccessful. I think the answer lies in Push versus Pull.

The primary problem with PointCast was that it was constantly pushing new information to users’ machines. That information was consuming huge amounts of bandwidth (for the time) and actually resulted in PointCast being banned in many corporate environments. However, the bandwidth usage might have been accepted if PointCast created an indispensable service. The problem PointCast encountered was that people were rarely able to consume content when PointCast decided to make it available.

This highlights a simple design principle that is as true in writing code as it is in public life: when the amount of information that is available is larger than the ability to consume it, push begins to fail. This is why RSS feeds and pull based systems like Google Reader have become so popular. When I have a limited amount of time to consume content, I want to be in complete control over what I consume, when I consume it, and how much time I give to each item.

There is an analog to this situation in the work place.

One of the greatest challenges in a corporate environment is to make sure everyone has the correct information they need to make their decisions. We often create elaborate processes to make sure documentation is correct, that materials are published on our corporate Wikis, and that people are alerted when important information has changed. This is all about the “push”. You think we’d have learned the lesson from PointCast by now. Teams need to put at least as much focus on Pull as they do on Push.

When was the last time your team put a focus on training people to consume documents instead of just creating them? When was the last time you heard someone admit that the information they needed was readily available but they just didn’t read it? Too much focus is placed on the need to create content but not on the need to consume it.

How can you get your team working harder at the pull?

Conflict Resolution

Conflict. It’s something you probably deal with every day. Sometimes it’s minor and doesn’t draw upon skills any more advanced than those you learned in your first few years of grade school (fortunately, shoving the other person to the ground is not an acceptable practice once you’re an adult). Sometimes however, the problems are more difficult and cannot be solved with simple tools. When you meet these kinds of problems, you need something more formal.

As a Software Development Manager, the most common cause of conflict shouldn’t be between people on your own team. Hopefully your teams run smoothly enough that you don’t have to solve those kinds of problems regularly. Instead, most of the conflict you likely encounter is with your customers.

Let’s make time for a quick side-note here. Just what do we mean when we say “conflict”? As it turns out, there is a pretty precise meaning for this word. It means quite simply that one person’s view of a situation is not aligned with someone else’s view of that same situation. The beauty of this definition is that it highlights an interesting point: one person can be in conflict with another, without the other person being in conflict in return. If you think your partner should feel a certain way about a particular issue, but your partner doesn’t care about the issue in any way, you might be in conflict, but your partner isn’t.

How can you use your understanding of conflict to resolve challenges with your customers? Well, any time you or your customer disagree about the view of a particular situation (say a scope document, or the timeline for a project) you have a conflict. I can already hear you saying to yourself “thanks Cliff, as if that wasn’t painfully obvious.”

But here’s the less-obvious point. Once you are in a conflict with a customer, the tendency is for everyone to focus on resolving the conflict before allowing any other progress to be made. If you feel you need to invest fifteen man-weeks of work to resolve that conflict, or your customer feels they have to accept a multi-month delay to resolve the conflict, you are playing a high-stakes game. Everyone ends up on the defensive and true progress becomes very challenging.

The next time you are in this situation, try something different. It starts with remembering that conflict is about each person’s view of the situation. You might genuinely want different outcomes from the situation, but that’s not the conflict; the conflict lies in each person’s views. If you can resolve the conflict of views, you can remove a very real source of stress and difficulty, and put the project in a better position to find a solution both parties will accept.

Enter the Gap document.

This is a document that articulates the points of a conflict, turning what was a disagreement into something two parties can agree on. Once everyone agrees on the gap, it breaks the conflict’s momentum and allows everyone to start finding paths forward.

Gap documents are essentially very simple things. They state, point by detailed point, what each person in the conflict believes to be the truth, and describes the gap between those two positions. For example, one entry in your Gap document might be:

Customer: The product must collect dollar amounts in any number of international currencies.

Developer: The product was only specified to support US and Canadian currencies. It does that well.

Gap: The product does not support non-US and non-Canadian currencies. The customer requires additional currencies to go into production.

Why is a document full of this stuff useful? Because it gives both parties a single item they can agree upon. If you have captured the customer’s expectations properly, they will readily agree to the statement about their needs. If you have captured your corporate position properly, you can readily agree to that statement. If you are honest in the document, and don’t use heavily biased language, both parties should be capable of agreeing on the Gap between the two statements.

The beauty of this document is that nobody has given up their position, yet both parties now agree on a common statement. From this document there is a clear path forward: you take the Gaps one at a time and work out a path to resolution. The document doesn’t make the resolution steps any easier, but it removes the conflict, which is often a huge part of the problem in the first place. Now you have two parties agreeing on what is wrong and working together on the solution.

If you aren’t convinced this can work with your customers, try it inside your team first. If you’ve never used a method like this before, I am confident it can make a difference.

This Meeting has 22-Minutes (or does it)

There has been a lot of attention lately on the idea of a 22-minute meeting. Scott Berkun blogged about it here, while the original source of the concept seems to belong to Nicole Steinbok who has a page dedicated to the idea here.

This is great idea and you can get a lot of benefit by adopting it. But I don’t think it is complete. I’d like to make a few modifications to the original idea that I have found particularly useful.

Ensure Everyone Agrees  With the Meeting Goals

The 22-Minute Meeting requires you to have a “goal based agenda”. That’s a great start, but it’s not sufficient. A goal-based agenda is only useful if everyone in the meeting agrees with the goals. At the start of every meeting, it is critical that everyone agree on the expected outcomes. Take two minutes at the beginning of every meeting and ask “Does everyone understand the goals of this meeting? Does everyone agree that those are the correct goals?”

If you  have don’t consensus on these two questions, don’t hold the meeting. It will be a waste of everyone’s time. Instead, you should change the agenda of the meeting right then and there, to have a quick (five or ten minutes max) discussion of the goals, why they are critical, and if the team thinks they should be changed. If the meeting was important enough to have, then it is critical to get agreement on the goals before you proceed.

If you think you can have a productive meeting with a few people disagreeing with the goals, then those people weren’t required in the first place and you shouldn’t have wasted their time with an invitation.

Ensure You Specify the Deliverables

As part of the defining the goals for your meeting you need to specify the expected deliverables. This is important because you can easily specify a goal for a meeting without being clear on the desired product.

You shouldn’t specify the expected outcome of a decision, but you must indicate what form the results of each goal will take. Perhaps it’s a product decision, or a project plan, or an agreement on who will produce the plan. Regardless, for every goal on your agenda you should specify the expected product or deliverable.

Assign a Meeting Maestro

One of the most valuable, and empowering, roles you should assign for each meeting is the Maestro. This person’s job is to conduct the meeting like a finely tuned symphony. Just as a traditional conductor doesn’t often write the music, the Maestro shouldn’t be the one who planned the meeting. However, their purpose is to see that the meeting happens according to plan.

Everyone in the meeting should know who the Maestro is before the meeting begins. The Maestro’s responsibility is to identify any off-topic conversations and to assign people to take that subject “off-line” and get the meeting back to focus. They are also responsible for watching the agenda and the clock to make sure that no discussion runs overtime.

This role is critical, and the person filling it must be confident enough to cut off conversation as required. Likewise, everyone participating must be willing to let the Maestro do their job.

Use a Time-Based Agenda

In addition to knowing your goals, deliverables, and having a Maestro, you need a schedule. Too many meeting organizers create an impressive list of goals, but never stop to think about how much time each item will take. If you are invited to a meeting without time-allocations next to each goal, ask the organizer to fix their agenda. Without times, the Maestro can never hope to keep the meeting on time, and you’ll never stick to the 22-minute limit. In my experience, unless an item is truly trivial, no topic can be discussed in under five-minutes. That limits a 22-minute meeting to a maximum of four non-trivial topics.

Provide a Relief Value

Even the best organized, best orchestrated meeting can sometimes fail. Accept that fact. If you are ten-minutes into your 22-minute meeting and nobody can stay on topic, or your discussions have identified problems with your goals, call the meeting off. Just stop. The meeting you wanted to have, and everyone prepared for, isn’t happening. You now have two choices: call a new meeting later with a modified set of goals, or use the remaining time to figure out why the meeting hasn’t worked and how the next meeting should be different.

Whatever you do, don’t keep meeting just because the agenda says so.

It’s OK to Go Over 22-Minutes

Despite all my previous suggestions, and as much as I love the 22-minute meeting concept, it’s important to be realistic with your goals. Some things simply cannot be done in 22-minutes. Even with loads of pre-reading and pre-meeting discussion, some deliverables cannot happen in such a short time.

If this sounds like your agenda, perhaps you aren’t even talking about the same kind of meeting anymore. Maybe we need to recognize that 22-Minute meetings are exactly that: only those meetings that can create something of value in 22-minutes.

I know this sounds like mere word-play, but I think it’s an important point. If every employee tried to ensure that no meeting took more than 22-minutes, there are entire classes of productive work that would never get completed. So remember to be realistic.

Every meeting should be exactly as short as it possibly can be, but no shorter.

What suggestions do you have for more effective meetings? How could you keep your meetings to 22-minutes?

A Retrospective on Retrospectives

If you follow the Agile movement, you have no doubt run into the idea of retrospective meetings. In fact, you have probably run into them in lots of other places too. The basic idea is very simple: at the end of a project, iteration, event or whatever, the team involved gets together to discuss how things went and see if there are things they could do better the next time.

Sounds simple, but I’ve seen enough of them to suggest that most groups are probably overdue for a retrospective on their retrospectives.

Common Mistakes

  1. Trying to do too much. Any group that leaves a retrospective with a list of more than three things they are going to change have too long a list.
  2. Not holding them often enough. If your lists are too long, or you seem to be discussing too many items, you probably aren’t holding your retrospectives often enough.
  3. Meeting for too long. If you feel the need for a ½-day meeting to discuss the results of some project, you haven’t been meeting often enough. These things can, and must, be kept short.
  4. Not organizing your outcomes. Even if you have a short list of three items, if they are all for the same person or group, you have too much.
  5. Not using a formal structure. Does everyone just get together in a room and complain, or do you have a method for these meetings?

For Best Results

  1. Use a formal structure. To begin, make sure you have a single person in charge of running the meeting. Their job is to keep everyone on topic, and the meeting clicking forward. Then choose a structure that works for your group. At GenoLogics, we do our retrospectives in three phases: first we brainstorm all the things we need to STOP doing. Then we brainstorm everything we need to START doing. Finally, we highlight anything we should CONTINUE doing. This simple structure keeps everyone on topic and guarantees you have useful output at the end of your meeting.
  2. Keep them short. If your retrospectives last longer then 30 minutes, see the previous point. You probably need a better structure.
  3. Try to fix one thing at a time. I suggest every individual come away with one item, each group choose one item, and each department or company pick one item (this last is optional).
  4. Meet often. If you have two- or three-week iterations, hold a retrospective after every iteration. If you don’t use iterations, or you use longer cycles, hold a retrospective once a month. If you wait too long you’ll forget important ideas.
  5. Record your commitments and follow-up. Since you are holding retrospectives regularly, they are an ideal time to follow-up on everyone’s actions. Take the first ten minutes of each retrospective to ask everyone a quick “did” or “didn’t” for their assigned actions from last time.
  6. Publish the results. By making the results public, everyone can learn from the same mistakes. The cheapest mistake to learn from is somebody else’s. Don’t lose this opportunity.

I’m sure your situation has its own characteristics. Some of these ideas may not apply to you, but they are a good place to start your own discussions.

How does your group do retrospectives? What lessons have you learned? Please add a comment and share your ideas.

(Someone will no doubt notice that this retrospective has six items, not three. I guess every rule has a proper time when you should break it.)