Jim Coplein posted on Jeff Sutherland’s blog basically criticising Kanban and trying to put forward a case of why Scrum is closer to Toyota’s principles that Kanban.

I’m not going to comment on the post (not directly anyway), but here is a story:

Five years ago I posted about a trend that was happening then, of asking whether a practice is agile or not. There would be endless debates about whether doing Practice X was big design up front (BDUF) or whether it violated YAGNI and what have you. Sometimes you would come across a post where a person loved a technique, but was afraid that it was big design up front. Just to set the context, in those days XP was the dominant method in the agile space and BDUF and YAGNI were the hot topics of discussion. The bone of contention was with methods like FDD that promoted up-front modeling, and Crystal which encouraged documentation and up-front UX design, and DSDM which many XP thought leaders found to be too heavy.

People essentially stopped asking “is it useful?” and started asking “is it agile?”

As any community forms around an idea, the first few years are open to playing around with it and improving it, but after a point the community attention switches over to protecting the idea from corruption and external forces. This protects the initial idea, but closes it down to growth. A lot of good ideas get discarded, because “it isn’t agile”.

I’ve learnt a lot of good things from reading FDD, and Crystal, and talking to people about CMMI. Its funny how many people in the agile community are happy to bash CMMI without ever talking to someone accomplished in it. To be frank, I was in that camp too, until I had a number of discussions with people who understood CMMI well. It turns out that CMMI has a lot of interesting ideas.

Today, people dont talk too much about XP anymore. Most of the XP thought leaders have moved on, some to the Scrum or Kanban world, others elsewhere. Meanwhile a lot of XP has been absorbed as standard practices that teams pick and choose for their project. Teams no longer talk about “doing XP” (as a package) but more about we’re doing TDD or we’re doing continuous integration.

But history repeats itself, and once again we find the question coming around once again to “is it agile?” instead of “is it useful?”

PS: Agile India 2012 is coming up next year. Be prepared to discuss a number of interesting topics, some of which might fail the “is it agile?” test Registrations are open, so what are you waiting for?

Following up on a twitter discussion, Pawel blogged about alternative kanban board designs, and showed an interesting board with columns indicating priority and stickies on a card to indicate the tasks to complete. This motivated me to search for pictures of the board we used back when we first adopted agile process. Pawel says that exposure to “standard kanban boards” has meant that everyone has ended up with similar looking boards. I think to an extent that is true. This board was designed in 2005, much before there was a kanban method, and it doesn’t really look like a kanban board you would see today. In fact, I wouldn’t even call it a kanban board as it has no WIP limits or pull. It’s more of a team board visualisation.

Early 2005

This is the board from early 2005.

The board has three sections

1. Not Started. The cards that are not started are arranged in columns, based on who is planning to pick up that card (although it could eventually be picked by someone else)
2. In Progress. Cards in progress are arranged in columns, each column containing cards of one team member
3. Awaiting verification. This column in labeled “Customer”. These are cards that are complete and are awaiting verification. Usually the verification was done by me.

The colour of the card indicated the type: Pink for important work, orange for bugs, yellow for new features and green for enhancements.

A couple of patterns jump out straight away:

First, most of the cards are waiting on the customer. That’s because the customer (me) only verified cards at the end of the release. We did three week releases, so these cards would queue up for three weeks. If any card wasn’t okay, then we would put it back into the Not Started section for the next release.

Second, look at the amount of multitasking for some team members relative to others. Some team members are overloaded for sure.

July 2005

This photograph was taken sometime in July 2005, so its a few months later.

You can see that there are two boards now. The board on the left, directly facing the camera is the roadmap board. This board contains the “big features” that were planned for the next six releases. You can see the release number and date on the top card of each column. The team board on the right has also been redone. Team names have been replaced by photographs, but more significantly you can see that the multitasking is way down. Also the customer column, while still long, is now a lot shorter compared to before as some cards were verified without waiting for the release date. It also helped that we could cards which failed verification back and fix it before the release came.

Visualisation is the important part

Day before yesterday I blogged that visualisation is the key to being agile. You can see that in action here. After putting up the team board, suddenly every team member knew what was going on. This enabled the team to take ownership of the work, leading to better collaboration, and better agility. Nothing rocket science about this. The success of the team board prompted us to create the roadmap board with the next six releases on it.

More patterns

The team board is just one of many kanban board pattern. Pawel’s blog post shows another pattern. At LSSC12 Alisson Vale showed me a board where the team board pattern is embedded within a larger kanban board (You can see that board depicted in our electronic kanban board tool here). Visualisation goes far, far beyond just the basic kanban board.  If you are interested in visualisation, then check the recording of my July webinar on Advanced Kanban Board Patterns.

Also, visualisation isn’t just for a team’s work items. You can see above that the visualisation of the roadmap that we did in 2005. It was rather basic and didn’t visualise everything we wanted. So I was always on the lookout for a better way to go about it. In the last three years, I’ve become a big fan of using story mapping as a way to visualise a project vision, roadmap and progress against that vision. If you’re interested in story maps from a visualisation standpoint, then sign up for my upcoming webinar this month on story mapping.

This coming weekend, I’m going to be talking at Agile Tour Chennai about visualisation in the context of agile teams.

It is my belief the visualisation is the key to being truly agile. Why? Read on..

Imagine for a moment that you’re playing a sport. Lets say football (soccer). Also imagine that the players in your team are told to wear blinkers (blinkers are what they put on horses so they can see only ahead), giving them a limited vision range, maybe just 1 metre in front of them. Only the coach can see the whole field. Therefore the coach has to tell the players where to kick the ball, and the players blindly follow the coach’s orders. How effective do you think this football team is going to be?

Donald Gray has a fabulous case study about three different leadership styles brought out while managing traffic at an intersection. This is a fantastic article and I suggest everyone read it and come back here. He shows how a policeman manually trying to manage the traffic is a lot less effective compared to leaving the drivers to figure it out themselves. Anyone who has driven in India knows this already. The traffic here is utter chaos, but it flows, even when the traffic lights aren’t working. In fact, if you see a long jam, chances are high that policemen are manually regulating the traffic!!

What these stories tell us is that when lots of complex decisions are to be taken, it is a better to decentralise decision making lower in the system.

Lets rewind back to the football team. Anybody can figure out that playing the team with blinkers, and the coach directing every move is a bad idea. It’s so obvious that you wouldn’t even consider it for a single moment. But, isn’t that exactly what we are doing in our software development teams? The project manager is often the only one who knows whats going on in the bigger picture. The team is developing with blinkers on. The project manager makes the move, communicates it to the team and the team executes the move. It’s not a very effective way of working.

In fact, like the policemen story, a single project manager who makes decisions on behalf of the team is likely to only make things worse. A project manager who assigns tasks to people in an attempt to balance work, is more likely to overload some people compared to each person picking up a task themselves when as they get free.

#1 A team is more effective when they make team level decisions for themselves.

But of course, thats not enough. If the blinkers are on, the team is going to flounder. You cant expect a team to make decisions effectively when they can only see a limited view. So you need to remove the blinkers. They have to see the same picture that the project manager sees when making a decision. They need to know what everyone is working on, and whats stage each work is in, and what is upcoming.

#2 Make the work visible.

Making work visible is good, but humans find it hard to make out patterns (unless its really obvious) from a table or spreadsheet. In this amazing TED video, David McCandless explains how the visual bandwidth of the  human brain far exceeds any other sense. Analytic capabilities are tiny by comparison. We are genetically predisposed to being very fast at identifying colour, shape, pattern and geometries.

Here is an example: Take 10 seconds (no cheating! ) looking at this, and see what you notice

Did you notice these things:

1. Everything going to Test is being blocked
2. Lots of things in progress, nothing completed
3. Sid is overloaded with work and is multitasking many stories

How does this team move forward? Take a while to think about possible next actions, before heading to the next section.

Now take 10 seconds looking at this:

Find it easier to see the patterns?

Now, how does this team move forward?

• It would seem that the first step is to unblock test and get those cards to completion. No point finishing Development cards and adding it to a blocked test queue. So the developers drop what they are working on, and pair with the Ram & Arjun to fix the bugs and get those cards passed
• Then Ram & Arjun (now free) help Sid to cut down the multitasking and get get some of the cards through test
• The bottleneck at test and development are now both untangled. The team discusses how the queue got blocked, how Sid landed up with three cards in progress, and how it can be avoided

Go back to the spreadsheet. Did any of these steps jump out? Come back to the visualisation. Did these steps jump out?

These are the kinds of decisions that team members can take for themselves when the blinkers are off. Much better than the project manager trying to make the decisions.

#3 Visualise the work

Visualisation leads to understanding. Understanding enables team decision making. Team decision making enables collaboration and agility.

Some of our case studies back this up. When teams could visualise work, they collaborate more, and self organise better, leading to better agility.

The best part?

Project managers get to take a break from all that decision making and can focus on much higher value activities, like steering the team towards the goal.

This is a three part video series that shows how you can do more with story maps. Story Maps are a really powerful method to both a) create the product vision in a collaborative manner and b) visualise the scope. Here at ToolsForAgile.com we are huge fans of visualisation, and with our electronic story maps, you can do a whole lot of cool things.

The series has three parts

1. Creating the story map
2. Release planning
3. Tracking progress against the vision

Creating a story map

Creating a story map is not simply a matter of entering data into the system, but a process of collaborative exploration. Our tool is expressly design to support this exploration. This video shows a typical session of creating a story map. Notice how cards get moved around, some cards get grouped together while others get split. And the tool never gets in the way throughout the process.

Release Planning

Release planning is where development team meets business strategy. Therefore, before you do a release plan, it is important to understand the business strategy. Which features are our differentiators? Which parts of the system are risky? Do we need early feedback on specific features? Are there some features which we are not sure the market will accept? Only when we answer these question can we make a truly effective release plan.

Unfortunately, release planning is often considered only in terms of selecting some stories and calling it a release. Most electronic tools do not allow you to effectively do a business visualisation prior to creating the release plan. The result? Product development is not aligned to business strategy!

In this video, we show you how our tool supports creating release plans through visualising the application in business terms

Execution Tracking

Once you have your vision laid out and the release plans done, then its time to execute stories. You will usually take your stories from the story map, and go elsewhere and put them in another tool or physical board to execute them. And what happens there will not be reflected back onto the story map.

But things are different with toolsforagile.com. In this video we show how to you move stories between the story map and team boards (scrum/kanban boards), and have the result overlaid on the story map.

You can now answer questions like

1. How many of our differentiators are remaining?
2. Have we implemented our risky features?
3. What level of enhancement is a specific feature?

There has been a lot of talk in the agile community about acceptance criteria. How having defined acceptance criteria beforehand makes development a lot easier. And it does. I’m a big fan of acceptance criteria. But just because someone write an acceptance criteria on the back of a card, doesn’t mean that what they’ve written is the correct criteria.

That might sound like a dumb thing to say. After all, if someone writes a wrong acceptance criteria, then what can we do about it? It’s their fault, they’re just going to get the wrong software, and they have no reason to complain… Right?

The new requirement specification

Remember the old days? Customer gives you a requirement spec, you implement the spec. Customer gets the software, and then requests changes. “But, thats not in the spec” you say.

Fast forward a decade, and what do we have

I love acceptance criteria

I earlier said that I love acceptance criteria, and now I’ve just gone and bashed it, comparing it with that waterfall document. Whats going on?

Well I love acceptance criteria at the story level. Over there, acceptance criteria do a wonderful job. It lets us know when a story is done and when we can move on to the next story.

The problem comes when you roll it up and use acceptance criteria to steep the ship. Just because we are meeting acceptance criteria doesn’t mean that we are building something useful. We build software, not to meet acceptance criteria, but to solve some business or customer goal. And lets face it, goals are nebulous beings, which most of the time cannot be translated into acceptance criteria. Look at these examples

• I’m building a search engine. A key goal is to deliver more relevant hits than Google. What are “relevant hits”?
• I’m making a game. A key goal is that the game should be fun. What is “fun”?
• I’m writing an iPhone app. A goal is that it should be easy to use. What exactly is “easy to use”?

None of these goals can be translated into acceptance criteria. The only way to get there is to do something, make changes, and repeat.

Build with acceptance criteria, steer with goals

Now, you might think this is obvious. After all, being agile is all about responding to feedback. So it is rather surprising that many agile teams have their sprints and acceptance criteria and definition of done, but have no techniques to validate the application against goals and change direction. In essence, they are playing the “requirements specification is God” game all over again.

If you are a product owner, then your job is NOT to simply to accept or reject stories, but to keep validating the product being built against goals and steer the ship.

via Geek and Poke

Agile is Bloated

I realised this the other day when, on a mailing list, someone asked about what the “Sprint Goal” was supposed to be. A reply came from someone else that they didn’t have a goal, but since “scrum mandates a goal”, they decided that their goal was “to implement stories”. Of course, this is a rather meaningless way to have a sprint goal.

So that got me thinking: Have agile processes become so complicated that they confuse the hell out of most people?

Take something simple, like user stories. Originally they were just little pieces of features to build.

Nowdays you’ll be told how user stories have to be from the user’s perspective. And they have to follow this “As.. I want.. So that” template. And that they have to be INVESTable. And oh, the stories have to be small. Like really small. Really, really tiny small. There is a whole industry around just making your story so small that it cant be cut any smaller. (PS: dont forget, vertical slicing only! Like a sashimi).

And you have to estimate them. There is a whole another industry around how to estimate these really, really, tiny small INVESTable stories. Using these things called ‘story points’. Y’know relative estimation and all that (psst.. relative complexity, not relative effort). But only with fibonacci numbers (they’re cool!). And overlapping probability distributions (also cool!). But be careful young padawan, because when it comes to tasks (which are SMART by the way), then you don’t use story points.

I could go on and on, but you get the picture. What a mess. And this is supposed to be a lightweight process? COCOMO is easier than this stuff (just kidding). I’m not surprised that most people fall into the pit of despair before they can get their Hello, World user story ready (see cartoon above).

How did we get here?

Just as we get anywhere: One step at a time. You see, people mess up. So we add a couple of rules. But they still mess up, so we add a few more. But they still mess up, so we add a few more. But they still mess up. And this time its because they cant comprehend all those rules that were put in.

Why do we have all these rules?

A fragile process requires a perfect environment and perfect execution. Without that, it will fail. Worse, it fails much more spectacularly than whatever was done before it.

A forgiving process process works in a variety of different environments and execution skills, perhaps with a range of results, from mild improvement to much more radical improvement.

Unfortunately, most of the attention has focused on fixing the environment and execution instead of making the process more forgiving. So, an agile transition goes

1. Fix the organization
2. Follow all the steps of the process

There are a whole bunch of people who will validate whether the organization is ‘ready’ for agile. It is the spherical cow syndrome again.

Today you need a PhD to understand agile. Woe betide you should you fail to understand the difference between a complicated system and a complex system. What?? You don’t know the difference? No wonder your agile team failed!

Agile really IS simple

When you really think about it, agile is pretty straightforward. There are only two concepts to it.

1. Release a few features, get feedback, adjust accordingly
2. Improve your collaboration and communication

Thats it!

All those things like iterations and user stories and fibonacci story point estimates are nice, but you can be perfectly agile without them too.

Start where you are

So your first release is three months long. You’re release cycles are  not of the same duration. You don’t use user stories. Your features take three weeks to deliver. You don’t do TDD. The team isn’t colocated.

That’s okay. The main thing is to delivering once a quarter or less, and incorporate the feedback. Then, see what you can do to improve collaboration.

Some of the agile folks are going to laugh at you and your ‘agility’. Just ignore them.

Yes, some of these things do help, but you don’t need everything at once right from the start. All these things are just practices. You can implement them if you want to, or skip them if you don’t, or implement them later if thats better. For what it’s worth, I’m no longer a fan of user stories.

Start where you are.

You collect requirements a certain way? Just do the same thing. Estimate a certain way? Continue that. Then add or replace pieces one by one as you hit roadblocks.

It’s not the most efficient way of doing things, but it is the most forgiving.

Somewhere along the way, the whole agile movement got derailed.

One set of folks went into researching how the organization could be fixed.

Another set went off into adding more and more rules so that people wouldn’t shoot themselves in the foot.

All this has just made things much more complex (or is that complicated ). And the more complex something is, the harder it is to get right. It’s a positive feedback cycle.

Back to Basics

All the jargon is unnecessary.

You dont need a PhD to understand this agile stuff.

Feedback. Collaboration. Thats it.

It’s time to cut the agile crap and go back to the basics.

The user story is one of the most fundamental bedrocks of agile processes. It is the unit that we divide the requirements into. It is the minimal unit of value. It is the unit that we work on at a time. It is the unit of deployment and it is the unit of measuring progress. And now, it seems that the time has come to retire the user story.

The user story as a unit of deployment and progress

The user story used to be the minimal unit of deployment and progress. If you don’t deploy the whole user story then you count zero against your progress. In Scrum, this would mean you get no velocity for a half complete story. However, the new revolution in deployment, DevOps and Lean Startups is changing all that.

The latest advances in continuous deployment have meant that it is now very possible to deploy half complete features. What is the use of that you ask. Well take a look at this scenario

Consider a user story that requires some database migrations. Lets say we want to migrate data from an old column to a new column. In the old days we would implement the story, along with some database migrations and at the end of the Sprint we would deploy the story and migrate the database simultaneously.

In today’s world of continuous deployment, that happens very differently:

• First a database migration is created to create the new column. Checkin, test and deploy
• Write code so that all writes on the old column also write to the new column. Checkin, test and deploy. At this point the new column starts getting filled for some users.
• Write a database migration to migrate all the existing data in the old column to the new column. Checkin, test and deploy. At this point, the data in the old column and new columns are in sync.
• Wait a few days to verify that everything is working so far.
• Write code to start reading data from the new column instead of the old column. Checkin, test and deploy
• Write code to stop writing to the old column. Checkin, test and deploy
• Wait a few days to verify that everything is working so far.
• Write a database migration to drop the old column from the database. Checkin, test and deploy.

As you can see, we do many many deployments into production long before the story is complete. There are pieces where we wait to verify that everything is going okay so far before continuing. This is just one use case. There is the use of “feature flags” to deploy incomplete user stories into production, where some incomplete stories are deployed and then hidden from users. There is the use of “special access” where priviledged users can use the story, but not the general public. Some teams use “gradual rollout” where a feature is slowly rolled out to users over a few weeks.

The “user story” is only complete when the last of these steps is over. But progress happens at each of these steps. In other words, we can no longer say that the user story is the minimally deployable piece of functionality, nor can we say that it is the minimal measure of progress.

The user story as a unit of requirement and value

Agile processes are based on the user story as the fundamental unit of requirement. Different processes call them different things – Scrum calls them Product Backlog Item for example – but the concept remains the same. You divide up the overall requirements into these small user stories, and that enables you to independently implement stories and build up the product incrementally. And that has worked wonderfully – until now.

When user stories first came upon the scene, they were pretty large pieces of functionality that took a couple of weeks to implement. Over time user stories have become smaller and smaller. A user story today is about a couple of days to implement. The upside of that is that you can split stories really small and deploy small increments of software. The downside is user stories have become divorced from customer value. Look at the following example:

Lets say that we want to implement GMail’s priority inbox. This piece of functionality has three stories (assume)

• Allow the user to turn the feature on/off in the settings
• Implement the algorithm to sort emails into priority buckets
• Allow the user to adjust the algorithm by manually overriding the categorisation of the algorithm

Now, suppose we implement and deploy the first user story alone… how much customer value have we delivered? None! Because what is the value of adjusting the settings when there is no algorithm implemented? And if we implement and deploy the second story alone? No value still! In fact it could be negative value! Because you’ve implemented this algorithm and some users don’t want it, and they are fiercely complaining that there is no way to turn it off – this is a potential PR disaster on your hands.The bottom line is that no customer value is delivered unless all three stories are implemented and deployed.

Welcome to the MMF

The replacement for the user story is the MMF – minimally marketable feature. The MMF is a bigger component of requirement compared to the user story. It recognises that a single story by itself may not have customer value, and often you need a group of user stories to deliver value. The MMF is this group of stories. It is minimal meaning that it is not possible to remove a story and still deliver value. It is a marketable feature, which means that it has to be big enough to deliver value. Being minimal and being marketable are two opposite constraints. The equilibrium point is the MMF. Sometimes the MMF is just a single story. At other times it could be a collection of stories.

The second thing to consider is the move away from “user”. The user story was conceived as a way to focus on end user benefits, and that is good. The problem is that is focused only on end user benefits. This led to some extremely contrived mechanics when you wanted to do things that didn’t impact the end user.

For example, a refactoring could not be a user story because it had no end user benefits. Instead the recommendation was to combine it with another user story that required the refactoring. This is extremely contrived, touching your nose around your head because the “rules” of agile said so. What if we needed to migrate architecture? Should we wait till tiny a user story came along and then estimate 3 months to implement this user story because we need 2 months and 29 days migrating architecture? It makes no sense. And people ran around this limitation by creatively writing user stories like “As a developer I want to refactor so that the code is easier to maintain”, and then claimed themselves as a user of the application.

In the MMF world, an MMF is any piece of work that has value to someone. So if we need to implement an analytics system for a web app, then we can create MMFs out of it, because it has value to us, even if it has absolutely no end user benefit. Similarly, an architectural migrating is valuable to us, even though it has no end user benefit – just make it a separate MMF and track it the same way.

The user story in today’s world

The MMF is the new unit of requirement. This is what a customer or stakeholder cares about. Where does that leave the beloved user story?

With the MMF taking on the duties of “minimal” and “value”, the user story is now just a plain old work item (POWI?). Its the minimal piece of functionality that can be deployed – whether you deploy complete user stories or you deploy stories in pieces. Each time you deploy some functionality then thats a user story. Of course the term user story doesn’t really fit this, so I just prefer to call it a work item. Progress is made when each of these work items goes into production. Value is delivered when all the work items under an MMF are complete.

RIP user story – you were fabulous when you were around, but its now time to move on.

A lot of people doing agile want to use an agile tool for a vague notion of “tracking stuff”.

They assume

• That their execution will somehow be more “efficient” if a tool is used
• That by spending a little bit (or lot) of money, it can replace the time and hard work required to get agile to work
• That they can forget about process and do some other work

Well, if these are the reasons for using a tool, then I can confidently predict right now that your tool investment will fail.

There are many, many valid reasons to use a tool – where the tool can make a difference you could not do without it. But let’s be clear – all these reasons depend on your individual context, they do not universally apply for every team. Which is why you need to think carefully about your needs in a tool.

A tool is extremely valuable when

• You have distributed teams and you are finding it difficult to keep in sync
• You want to involve customers, stakeholders or management and they are not in the room with you
• You would like historical data or archival records of all the past actions in the project
• You need to keep a record of data for compliance purposes
• You want to calculate certain metrics every day and it is too time consuming to do it by hand
• You need to coordinate multiple teams together

If you don’t have a clear picture of why exactly you need a tool, and all you know is that you want to “track stuff” (why?) then you are throwing money down the drain.

Finally, take a look at the Physical board vs Electronic board debate and weigh the pro and con of each approach for your context.

Yesterday I gave 5 reasons why physical boards are better than electronic boards.

But could an electronic board be better than a physical board? Sure.

Here are five reasons why:

1. Collaborate with distributed teams: Lets face it. A large number of teams are globally distributed. Either the teams are split between locations, or there are multiple teams in different locations, or the management, stakeholders or customer is not co-located, or some team members sometimes work from home. Every which way, there are some people who need to know whats happening who aren’t going to be in the proximity of the physical board. Electronic boards are accessible from anywhere, giving remote teams and stakeholders the visibility needed to collaborate effectively.
2. Ease of modification: This is a funny one, because we tend to assume that its easier to modify a physical board. Actually, it can be a lot easier to change the structure of an electronic board. Want to add a column to your physical board? You’ll need to take down all the cards in that area of the board. Then peel off the existing column markers. Stick new column markers. If you are running out of space, then create some space by reducing the width of the adjacent columns. Finally stick back all the cards you took out. Keep aside 30-60 minutes to do this. With an electronic board, you just go to the board configuration screen, add the column and you’re done.
3. You never run out of wall space: Unless you are lucky enough to have a large section of wall available, chances are that you have limited wall space. This is even more true if there are two or three teams competing for the space. If you are on a big project with lots of cards, its easy for the board to get cluttered – cards overlapping one another, cutting across column boundaries, falling behind tables. And once that happens, you lose the benefits of visualisation. The second problem is if you need to make the cards too small, then you have to get really close to read them. And if you make them bigger, then you need more wall space. An additional downside is that you also need to stand further back to see the whole board, so you need sufficient depth in the room. It’s very hard to find that balance of being able to see the whole board at once, and yet being able to read all the cards. With electronic boards, this is not an issue. You have infinite wall space, its easy to quickly zoom in and out and its quite practical to be able to view the whole board and still be able to read all the cards.
4. Eliminate overheads: With physical boards, you need to spend a lot of time doing low value clerical work. Want to generate a burndown or cumulative flow graph? You’ll need to spend 15 mins a day counting up the cards and plotting it on a chart. Need to calculate lead time or throughput? More manual work. Management needs status reports daily? Still more work to get to the board and make notes and send an email. Every day!! Even if you only spend an hour a day on this low value work, thats 12.5% of your time. If you are a project manager earning $10K a month, then it means the organization is spending $1250 per month to do this counting work. An electronic tool will do all of this automatically – collecting metrics, making graphs and emailing reports – leaving you free to do more important high value work, like delivering that project.
5. Go beyond a single team: Physical boards are okay for single teams, but when you go beyond a team then the physical board does not have the context. Want to see the flow of work across multiple teams involved in delivery? You’re out of luck. Want to update the backlog everyday with support tickets filed by customers online? Out of luck again. You have to sit and manually copy the tickets from the ticket system and put them on cards. When data is stored electronically, you can write scripts to process and manipulate the data automatically as per your needs. For example, you can use APIs to automatically pull in data from multiple boards and display it in a particular visualisation. Or to synchronize support tickets with the backlog. The possibilities are endless.

So there you have it. Five reasons why electronic boards are better than physical boards. Comments?

People often ask whether it is better to use a physical board or an electronic board. The answer of course is that it depends. What is the context of the team and the project? How many team members? Are you distributed? and so on.

In this post, I’ll talk about five reasons why physical boards are better than electronic boards. Tomorrow, I’ll do the opposite, with five reasons why electronic boards are better than physical boards. Finally I’ll do a post on how to choose between the two.

Are you ready? Here we go:

1. Physical boards are always visible: You put it up on the wall and its always visible from anywhere. At any time, you can just lift your head and know the latest state of the board. Anybody walking by will peek in and get an idea of the board.
2. Physical boards are tactile: There is something about picking up cards and moving them that is nice and makes team members feel more involved. I don’t know what it is, but it works.
3. They encourage conversation: When someone is walking by and sees the board, they tend to ask questions about it and it builds a conversation.
4. They are flexible: You can easily make the physical board in any form you want. Need extra columns? Need a completely custom board design? Want to decorate the card with stickers to denote different conditions? Want to annotate it with custom information? Want to write on the back of the card? You can do all of that.
5. They are simple and intuitive: Everyone knows how to use a physical board. You don’t need one week of training to figure out how to put a card on the board

There you have it – 5 reasons to prefer a physical board.