Home arrow Blog

Agile in the real world part I - The personal card wall

The first item we are going to tackle in the adoption of agile principals is the card wall. What is it? What problem does it solve? How do I get my organization to use it?

Let’s take a step back. How do you currently track the status of a project? Microsoft Project or some related piece of software? Excel (*gasp*)? There are a number of issues with this approach:

  1. Project status is not publicly available.
    When the progress of a project is stored in a software product like Project or Excel, it is easily hidden or is at least difficult to access. This encourages things to be hidden. Things to be changed.
  2. It’s hard to use
    The implementation of project planning is, in essence, a very simple process. It is the alignment of resources and tasks against time (the hard part is the alignment piece). Why do project management tools need to be so complex to essentially display timelines?
  3. Developers can’t take ownership of what they work on.
    Typically when projects are tracked using software products as stated above, they are maintained by a lead or manager cutting the developer out of the process of delegation of tasks.
  4. Collaboration across tasks doesn’t occur.
    Developers don’t use Project. Developers despise Excel. Because of that, they usually don’t look at it. So they don’t get a big picture of the project flow and prevents the implementation of operational efficiencies that could occur with simple reordering of tasks.

Card walls attempt to address the above issues.

Project status is not publicly available

A card wall is the ultimate way to communicate project status to the entire team. You have a wall of cards divided into three or four categories: Ready for development, in development, in QA and in production (with the fourth one optional. There are some other nuance options that you can add in, but we won’t go into that here.). To obtain project status, all a person needs to do is look at the wall. If the card isn’t in the ready for development yet, the story has not yet been written (it’s in the BA’s hands). If it’s in development, typically you’ll have a picture or name associated with the card. This makes it quite clear who is working on the functionality. If it’s in QA, development is complete and it’s being tested. If it’s in production…well, I’ll let you figure that one out.

Project software is hard to use

Well you could go to Excel or Project training and spend thousands of dollars. However, I prefer spending that money on better things, like high quality developers. Instead of paying for licenses for Project and training, etc. Cards are intuitive. People get the card wall. When the BA has completed a story for development, they put a card on the wall with the name of the story. When a developer is prepared for a new story, they choose the card to take and move it into development under their name or picture. When they are complete with the story they turn the story over to QA by moving the card to in QA. Once it moves to production, typically the project manager will move the card to production. Developers don’t need to worry tabout what drive the Project file is on or if someone else is in the Excel file. Cards, scotch tape and a wall. If you can’t figure that out, you probably can’t write the code to implement it anyways.

Developers can’t take ownership of what they work on

This is one of the most important in my opinion. The traditional way to assign tasks was exactly that. A project manager assigned tasks to developers and they worked on them. However, which are you more likely to work your hardest on:

  • A list of things your spouse gives you to do.
  • Something on the list that you created that needs to be done.

You are more likely to put your all into things you choose. By allowing developers to work on things that they choose as they complete tasks empowers them to learn more about the application. This prevents the funnel problem. The funnel problem is when there is one person that knows how to work on a particular part of a system. Developers tend to spread their knowledge around the application which benefits everyone. Finally, there is an empowering psychological event that occurs when someone take a card they were working on and moves it. The job well done. The beginning of a new endeavor. We don’t experience this enough at work and this is a simple way to do so.

Collaboration across tasks doesn’t occur

I consider this reason a tie with the previous one with regards to importance. When we use Project or Excel or most other project management tools, the people in the trenches loose site of the big picture. If you are a project manager that is working on a project that is expected to last a year with 30 developers, you may pass out copies of the project plan to each developer. But what I’ve seen in most cases is that project managers pass out the piece of the task list that pertains to the person you are giving it to. By doing this, blinders are being put on the team with each person being forced to focus on their own small corner of the world. But what if developer A worked on something that developer B will be working on in two weeks and developer A knows that he had to do something unusual to get things to work. If he knows that B is going to be working in his old code, he can share the knowledge he gained when working on it the first time. This cross task collaboration has huge productivity benefits that should not be ignored.

So how do I do it where I work?

So now that you have an understanding on why you would want to use a card wall, how do you get one past the IKEA Police on your team? You don’t have a wall you are allowed to use. You don’t run the project so you can’t get others to maintain cards. As with anything in life, work with what you can control. In this case, you can control how you work.

A little background. I work for a large IT organization (about 1000 employees out of about 2000 total for the company) in a very old school, risk adverse company. Until very recently the word Agile might as well have been a four letter word. It was crazyness. I work in a cube. The typical cubical with a desk on two sides, a tall cabinent for hanging my jacket and a cabinet above my desk along one side.

So with Agile and any of it’s practices viewed as insanity, I decided to change what I could and that was how I worked. I had a list of tasks that I knew I had to complete. I purchased a deck of index cards and setup a makeshift card wall on the doors of the over desk cabinet. Since I was the only person the cards were for, I didn’t need a large amount of real-estate. I put my tasks into the ready for dev section. The card I was working on moved to the in dev section and any cards I completed were moved to complete.

So I worked like this for the life of a three month project. It didn’t take long for managers to notice the wall of index cards hanging in my cube. Some of my co workers made fun (I was out of the office one day due to food poisoning….I came back to a card in the complete section that said “food poisoning”). Managers, however noticed. Anytime they asked what my status was, I directed them to my card wall. I made sure to point out that any time they wanted to know exactly where I was on the project, all they had to do was take a look. You know what happened? They stopped asking.

They stopped asking me what I was working on or where I was on something because they already knew. They knew how fast I was moving cards, they knew how many and which cards I had moved. They knew exactly where the project was in a glance.

The manager I directly report to loved the idea. We started expanding it by creating a tech debt wall. Now, I have to come clean here. We still are not 100% past the IKEA Police. Our building operations staff still doesn’t want the cards to be visible in the office. So instead of putting them on a wall, we have ours on a window. In fact, if you stand outside our building and look up, you can see my boss’s cube because the window in his cube is covered in index cards.

From the tech debt wall, we have finally expanded it to full project management. The project I am currently working on is scheduled to go live in April. The card wall is not the only reason for this success, but it has contributed to it, but we are months ahead of schedule. Many months (5 to be exact). The agile principals discussed here and what I will covered in the future posts are the primary reason for that.

Conclusion

So that’s it. Over this post, I covered why a card wall is useful for project management as well as how I took a small amount of rebellion and harassment and proved that it can be a very valuable resource management tool. What are your experiences with card walls? Do you have your own version of the IKEA Police? Share your experiences in the comments!

No Comments

Add your own comment...

Tweets

    Twitter Button from twitbuttons.com