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.
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.
Posted on August 12th, 2011 in Kanban by siddharta || No Comment
This weekend is a little event called in50hrs. The idea of the event is build an application from scratch within the weekend (you get 50 hours). It might not seem like it, but these events are the perfect way to fine tune your agile development skills. Because you have such a short timebox, it makes you really think hard about the way you split your features, their relative priorities, and implementation challenges. Within two days you need to go through the whole cycle of planning and executing. The first time you do these types of events, you find yourself planning a lot and then running out of time before you can execute enough to do a decent demo. As time goes on, you get better and a few events later, you learn how to slice your idea into really small user stories, execute them one story at a time (single piece flow), and deploy continuously. Because you never know exactly how much you can complete in 50 hours, it trains you to think about having an always deployable application, with the core features delivered up front.
In other words, you learn to start doing extreme agile.
I did this little video for the event tommorow, which describes a very lightweight 4-step kanban process. Although it is meant for the event attendees, a similar lightweight process can really get you well along the way to agility at your day job as well. Take a look below
But could an electronic board be better than a physical board? Sure.
Here are five reasons why:
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.
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.
Yesterday I gave 