You are currently browsing articles tagged agile.

Status tags are my preferred approach to visually attaching state metadata to work items.

In plain english, what this means is that if you have a task, represented for example by a standard size Post-it, you would add a physical tag, represented by a smaller colored Post-it, to indicate it has some particular status, such as “Blocked” or “Delegated” or “Bug” or “Please Test”. This creates visibility and awareness and enables the right people to react to that new status fast.

A visual alternative to tagging is creating special columns or specially designated areas in your taskboard that fulfill the same purpose.

While this is valid, and many people do it, I much prefer tagging to that approach. Taskboard real estate is expensive. If you start creating special areas or columns for each status a piece of work can have, you might quickly fill your Taskboard with empty zones. Furthermore, changing the structure of your taskboard is cumbersome. This might limit the number of status areas you create. Too many areas and columns make people think about waterfall processes, even if they are not meant to be used. For example, look at the picture of the following kanban board:

While it looks good because it was done with care, there is much wasted space in those columns and boxes. And let’s take a closer look at those separate areas at the right. In this example we see a “Back to business” box. What if this status is very temporary? In that case, you are probably better off tagging it. Creating the box has allowed work to accumulate there, unchecked. Are all those post-its supposed to be going back to the main board? Someone is going to be spending some serious time moving post-its back and forth…

Another example: let’s assume a task that involves coding but is functionally testeable is being developed. During the same day the following happens:

  • A developer starts and finishes it
  • Someone else tests it and finds a bug
  • The original developer fixes the bug
  • The task is re-tested and this time declared “done”.

This is a typical scenario in Agile teams. If you have separate columns for “In development”, “To validate”, “Defect found”, you are going to spend the whole day moving the task around columns. People might lose track of where the task went (well, not really – but it does require more effort to locate it). I prefer the much simpler solution of leaving the task in place and rotating status tags on top of it. Another advantage: if it would go through this code-test-bug-fix cycle many times, you can place status tags on top of others, creating a “traceability” effect. With columns, you can’t do that.

Tagging is very flexible. There is no limit to the number of tags you can create. Some teams create temporary tags for special occasions. In the example above, the tag “checked” was created specifically for the occasion. This can be done quickly and easily by the team by their own initiative. Almost no work is required and suddenly your visual management process includes a new status.

I think the elegance, flexibility and visual appeal of using colored tags for indicating task status cannot be denied. Even in a software tool, it looks good, as the example below shows.

For physical taskboards, my preferred tags are Post-it 653 which come in many different colors. They are the 1.5″x 2″ small ones.

Important detail: if you just stick this small post-it onto a bigger one, it will not stick, it will fall off almost instantly. That’s why I use a small piece of Scotch Magic tape with each status tag. See the first picture in this post for a detail.

Tags: , , , , ,

The flagship conference of the Agile community has come and gone. I had a great time and I’d like to post a short account of my trip with some pictures. I will later follow up with a post specifically on my Visual Management session.


We arrived with Joke a couple of days early in order to visit the city before the conference. Chicago is an amazing city with an incredible skyline full of modern buildings. I especially love that red one!


We got a room on the 30th floor with a great view. I particularly liked it by night.


We walked to the Millenium Park near the hotel where they have this really cool “thing”


Then we rented bicycles…


and biked around the park area. This fountain is one of the most beautiful I have ever seen!


Apparently Segways are not as unpopular as one would think; especially with tourists.


Segway invasion! They even have pink ones.


We then went to the aquarium. Joke wanted to see and hear a Beluga whale while she’s pregnant. She got what she wanted. This guy kept coming out of the water and I caught him smiling at us:


The Shedd Aquarium is really nice. I would recommend it even to people without kids.


Watcha staring at? Never seen an ugly fish?


Or a smart one? The legend says this guy knows TDD and refactoring…


They have the oldest fish in captivity in the world. This guy was brought into the aquarium in 1933! It’s a lungfish, an ancient beast that actually has lungs asides from gills.


But of course the cutest of them all are the little Nemos swimming in the coral reef:


The next day we went to visit the work of reknown american architect Frank Lloyd Wright in Oak Park.


And we did a tour in his old house and study. They didn’t allow pictures of the inside though :(


Ok, enough about fish and architecture. On to the conference.

The conference

This was my second Agile 200x and my first time presenting. Considering the crisis this year, I think both the organizers and us (as in “the community”) did a pretty good job of keeping our flagship conference healthy. More than 1350 people passed by the registration desk in an orderly manner…


and enjoyed well delivered keynotes from Jared Spool and Alistair Cockburn


A couple of visual management good ideas. Every day the conference program was presented in these big panels (that I later used for my session :) )


And individual rooms had a sign outside announcing the day’s sessions:


The printed program was also much better organized than last year (it was actually usable!) and the badges were the same as last year, very readable and of the non-reversible type. They also had RFID as a novelty.


Open jam was the place to hang out if you were into networking or just wanted to sleep. And even though it never works well in ths type of conference, there were still a couple of good open space sessions.


What didn’t go well?

Well, the food was where the organization decided to cut corners in order to meet the budget, something I don’t approve of. And Programming with the Stars suffered from a lack of public, because of where the actual competition took place (extremely far from where the food was, compared to last year). Still, the sign was great!


Gordon Pask Award

07/Sep/2009 Update: This section is new, the original post has been edited. I had expressed some pre-judgements regarding the award that I wish to retract. I have re-written this part of the post based on feedback and information I received and researched. Let’s keep the award and the community healthy.

This year the first Gordon Pask Award was given to somewhat less prominent figures of the agile community (compared to previous years). As JB Rainsberger, member of the award commitee explains: “We awarded the Pask to Simon and Gus […] as an attempt to live up better to the stated purpose of the award: to shine a light on those great practitioners in the field who have something special to share and need exposure to do exactly that.”

Congratulations to the “no compromise, no excuses” zealots Simon Baker and Gus Power from the UK! They sound like people with high quality standards, something I appreciate. You can read their reaction over winning the award in their blog.

The second award went to renown and groovy David Hussman, who BTW is coming to the Ágiles 2009 conference together with previous award winner Naresh Jain this fall. Congrats to David who certainly deserves it!

Let’s start betting on who gets it next year…

Agile Alliance Board

The big surprise of the conference for me was that Cesar Idrovo, with a spectacular political campaign, managed to get elected to the Agile Alliance board! Kudos to him and I hope he gets to do lots of good work there.  I will certainly be supporting and helping him (Cesar is also Latin American / European like me). Also congratulations to Henrik Kniberg for getting elected.

All in all it was another great conference. Almost as good as Toronto last year. I met and re-met lots of friends and community leaders from around the world. There were some great sessions, and I think everybody was generally satisfied with the event.

See you in Nashville next year!

Tags: , , , , ,

Scrum of Scrums detailIn Scrum, the “Scrum of Scrums” is a way to ensure alignment and coordination across different teams, or among different sub-teams of a large Team.

How big is the Team?

A Team is a group of people collaborating towards a common goal. Sometimes it’s not that easy to pick your goal, and thus figure out who the Team is, or who it should be. On one hand, small teams are good. Small is simple, small is beautiful.  So maybe you should pick a small goal, and make a small Team.

On the other hand, you should try to look at the system as a whole. This could mean anything: a project, a department, the whole company… What is the ultimate system, but the Organization itself? Your whole company is the Team, from the Systems Thinking perspective. Especially for small companies. So maybe you should think of a large Team.

Most likely, we need to strike a balance between these two dichotomic approaches.

I have found my comfort zone with a simple, practical definition: One Team, One Backlog.

Splitting it up

Banana SplitLet’s assume you found your definition of Team, and you have more than ten people in it.  Since the ideal team size is 5 to 9, you probably want to split them up. But you don’t want to lose the concept of  one Team. The recommended approach is to break them up into sub-teams. I will discuss some ideas for creating these sub-teams and for visualizing their work, while trying to keep and respect the spirit and vision of the one (big) Team.

Feature teams

Using the same logic regarding why it is interesting for team members to be as cross-functional as possible, the best strategy for making sub-teams is to create cross-functional feature teams, as opposed to ‘component’ teams or -god forbid- teams that specialize in a certain technology or skill (like  ‘QA team’ or ‘.Net team’).

Feature teams are teams that work on features, i.e. stories. Pieces of business value. They are value-driven teams, whereas other sub-team splitting strategies (component, skill, etc) create function-driven teams that invariably fail to deliver business value and create local optimizations and waste.

You create your feature teams by spreading out the knowledge, skills and experience equally. The goal is that any team can do any story in the backlog.  You should stress that the “real” Team is the big one. Sub-teams are just created for communication and coordination purposes. In my opinion, they should not develop too strong a team identity. For example, I would not measure sub-team velocity, and I would make sure people rotate from sub-team to sub-team a lot.

You can then work with a single, large backlog and distribute stories in round-robin fashion.

Colored teams

I like to give sub-teams a color for a name. E.g “Red team”, “Blue team”, etc.  Colors are very visual and we will be able to use this to our advantage. For example I use electric tape of the same color to create their taskboard, which gives them an immediate strong visual identity (see picture below). Another reason colors are good is that they are non-hierarchical, and people don’t attach themselves that much to a color.


The Black team

In large projects, particularly in transitioning organizations, there are always some people left floating around that are not doing any actual work at team/trenches level.  I put them in the Black team. This is a pseudo-management team that mostly combines the responsibilities of Product Owner and Scrum Master (in the same team, not the same person!) and any other role that you either want to share across teams or that you simply can’t get rid of.

Typical examples of people who we have put in the Black team include:

  • all the ex-Project Managers, who now had to remove impediments full-time (they also had a lot of administrative work to do: fake Gantt charts, fill in timesheets, useless reports, etc)
  • the Agile Coach
  • the Product Owner(s)
  • an Architect from Architecture (we later convinced him to move into the trenches with the real teams)
  • a QA Team Lead who didn’t want to test (we later got rid of him, once the testers he used to C&C were doing agile testing)
  • a Release Coordinator, whose job was to beg to Infrastructure to deploy our app into production (this was a full time job)
  • etc.

As you can see these were mostly roles that existed because we were doing Scrum within a traditional large organization. In any case, the idea is to group all these people into one “team” so as to not leave any loose ends. Ideally they will jell and work cooperatively, otherwise at least you can visualize their work by putting up a taskboard for them. For example on this picture below, most tasks are either impediments or things that have to be delegated to people outside of the Team. The horizontal lines are not stories but simply priority slots, i.e. High Priority, Medium and Low. If I would have known at the time, I would have put WIP limits, because nothing was ever getting done here. :D

Scrum Black Team

The Scrum of Scrums

Ok, let’s move on to the interesting part. Each sub-team has their scrumboard with the stories they have selected for the current Sprint, divided into tasks as usual. How do we visualize what is going on at Big Team level? How do we keep track of so much work? We need to change the level of granularity. In the Scrum of Scrums, you only visualize stories. You create the “Scrum of Scrums storyboard” where every story that is currently open is visualized, with the team that has it and the current status indicated. The picture below shows such a board at the beginning of a Sprint. Click on the picture for a larger version. Note: This is actually the same physical whiteboard as pictured above… you are just looking at the other side! The Scrum of Scrums side is pointing towards the hallway, so passer-bys can look at it.

Scrumboard Scrum of Scrums 1

There are only two columns: “Story” and “Status”. Story has a copy of the story card that is on the team board. Status is normally “not started, “in progress”,  “done” or “done-done” (a curious distinction between “we think we’re done” and “we’re sure we’re done”). This last done-done was indicated with a red star. Each story has a little magnet indicating which team is working on it, but we also experimented with other visual elements like creating status tags of the color of the team. In this example you see both at the same time: a Green Team story will have a green “in progress” tag, and also a green magnet.

The mechanics for the Scrum of Scrums are simple: after the daily Scrums, each team sends a rotating delegate to give a brief status report on each of their open stories to the other delegates and the Product Owner. The delegate is then responsible for updating the rest of his sub-team members on what’s going on at project level (something that never happens, but oh well). Of course sometimes a lot more people show up during the Scrum of Scrums. Anybody who is interested in knowing what’s going on at Big Team level goes.

Note: The black and blue tape indicate nothing in this case, we simply didn’t have enough tape of the same color, and our boss was a fan of Club Brugge (whose colors are black & blue), so we made it for him.

This is how the board might look like towards the end of the Sprint, on a good Sprint where lots of stuff got done. (Click for large version)


Note how you can quickly visualize different types of problems.

  • Several top priority stories are not getting finished. In particular the #1 top priority story.
  • The yellow team seems to be in trouble. I see 3 yellow “in progress” and only red star with yellow magnet. Also comparing yellow to green, red and blue you can see the difference.

If you looked at the large version of the picture, you probably noticed those white horizontal lines that say for example “End of Sprint 9 Demo: 8/Sep”. This is a visual way of indicating what was the scope taken for Sprint 9. The point here is that this was a Team that was not delivering all they started, and was dragging along open stories. Some stories were blocked, others underestimated, some teams had sick people… for whatever the reason work wasn’t getting finished, and since it was not possible to limit WIP for political reasons, we just let the teams take more work, keeping existing stories open. But with this board at least the situation was kept clearly visible and the Product Owner knew perfectly well what was going on.

A last picture with some comments, in a style similar to my original “Scrum Board with Comments” picture:

Scrumboard Scrum of Scrums with comments

Tags: , , , , ,


Mary Poppendieck, Henrik Kniberg and a bunch of other people are on a Lean Tour in Japan that might turn out to be historical.  According to this blog post, a Toyota software development manager has spoken openly for the first time on how they develop software, and guess what? Yep, it’s waterfall. We’re waiting for more details on the Lean Development list regarding how they manage to pull this off and what they think of the Agile community, but I think we’re going to learn a lot here.

Update 2/May: this is what Mary says about what Toyota is doing and thinking

The person we heard from at Toyota – Ishii-san – deals with embedded software in production automobiles.  I understand that for a prototype part, software can take a matter of days.  In production parts, the cycle was 3 months.  When you are dealing with embedded software in production hardware, a 3 month waterfall is really fast.  And note that at Toyota, people really do talk about “bad news first”, so what we heard about is what they consider a problem, as opposed to what is going well.


To answer your question about agile, Ishii-san said they are studying agile, but their architecture is not particularly supportive of it.  His real motivation, as I heard his comments, is that improvement is necessary because of the late detection of defects.  I imagine that they will focus on early removal of defects, and adopt whatever processes prove (after PDCA cycles) to be more proficient at doing this.


Toyota people will not just do agile because someone says it is good.  They will look at their objectives and adopt whatever process gives them more of what they consider good.  And Toyota is  VERY good at doing this – I would not want to be competing against them!

Tags: , , , ,