Tag Archive: whiteboard


Due to the volatility of our developer resource we recently decided to opt-out of Scrum and adopt Kanban. Kanban is an Agile technique that is less prescriptive than Scrum. There are many similarities between the two systems including the use of white-boards and post-it notes to track progress. An important difference is that the white-board is owned by the process not the team. The board makes transparent, the flow of work through the team.

The white-board has similar columns: not done, in-progress, done. The columns have an agreed limit on how many jobs can be in each column. We agreed on up to two per developer.

Kanban does not have any notion of a Sprint. Kanban limits the number of items that can be in-progress by WIP (work in-progress). WIP limit is the key method to tweak and optimise the flow of work.
So the response time (how long it takes to respond to a change of priorities) of a Kanban team is however long it takes for capacity to become available. Capacity is measured by the general principle of “one item out = one item in” (driven by the WIP limits). You don’t have to wait for the next Sprint to progress work and testing, deployment and review are all a continual process. Due to the emphasis on experimentation and the Scrum mentality to ‘Inspect and Adapt’, we decided to include Daily Stand Ups’ in our version of Kanban.

The basic steps we took to complete the adoption were:

1. Agree Kanban adoption with Dev Team Manager

Senior management was concerned about compliance for audit purposes and the possible breakdown of process. We allayed any fears by emphasising the similarities with Scrum process.

2. Agree with Product Owner

The P.O had previous experience of Kanban in a production environment and was therefore happy to adopt the process and added value based on their own experience.

3.Training session and agree column names and WIP limit with team

There was some trepidation and a lot of discussion around WIP limits and whether the whole process offered anything better than ‘just a list’. I emphasized that though Adaptive rather than Prescriptive Kanban offered the opportunity to maintain process and measure flow.

We had a planning meeting and jumped in. The interesting thing is that quite quickly we identified that testing was a bottle-neck. We knew colloquially that this was the case but the Scrum board had never exposed the relationship between testing and deployment. We tended to remove all the jobs at the end of the Sprint and the tasks that had been awaiting test or had been tested and not deployed would be forgotten. We adjusted our working practices and white-board to clearly show whose responsibility it was to test code in Development and in our Main environment.

Our team has become less volatile recently and we have returned to the more familiar territory of Scrum. Utilising Kanban was beneficial and we have reverse engineered some of what we learned back in to our Scrum process.

Have you had any adventures in Kanban?

Resources:
E-book – kanban v scrum.pdf
http://www.infoq.com/minibooks/kanban-scrum-minibook

I’ve blogged before on the role of being a designer in a Scrum Team. I thought it would be interesting to micro-blog my actual experiences of participating in the Sprint.

Day 1
First day of being back in the Sprint with the developers. I’m feeling the subtle pressure (or is that motivation?) to get my tasks done on time. We are working on a high-profile project and I can’t afford to hold up development by not having the design work completed.

Day 2
The wireframes have been created but the layouts are all wrong, so I need to pull my finger out! The 960.gs CSS framework is a great help in the creation of the wireframes.

Day 3
I forgot to update my tasks before I left last night. Consequently we are behind on our Burndown Chart. I have to confess to the team that I didn’t practice what I preach. A humbling experience and I will definitely remember tonight and also cut some slack to my team in the future if this happens on the odd occasion.

Day 4
Chris Brogan recently said that “doing is more fun than planning”. Turns out he’s right. I’m enjoying keeping track of my tasks and having the opportunity to move my post-its across the board to ‘Done’. I think if you haven’t been in the Scrum you are losing a vital perspective on how the Sprint dynamic encourages a feeling of success.

Day 5
The post-its that have been bought from a local supermarket keep falling off the board. I had heard the team mentioning this, but hadn’t completed appreciated how annoying it is. The next purchase of post-it’s will be the genuine thing.

Day 6
I’ve cheated and added some additional screens to an existing task. I can’t decide whether this is utilising Scrum in a flexible way or I’m committing a Scrum sin. I’ll pick up the issue in the retrospective with the team.

Day 7
The Sprint has blipped. We have a developer unexpectedly out for two days. That’s a lot of ground to make up and we may need to take something out of the Sprint to compensate.

Day 8
In the Pre- Sprint Planning Meeting with our Product Owner we discussed a new design for a Blog Template. I promptly forgot to include that in the task so now I have to make up the time. In this situation wireframes are a great solution. Wireframes provide the developers with the information they need to get going whilst buying some time to complete the design.

Day 9
Being more physically involved in the Sprint has made me realise that the whiteboard could do with an overhaul. The board should be at the centre of the team, radiating information out to the wider business.

Day 10
I’ve gained final approval the last of my design work so my active tasks in the Sprint are set to Done. I’m back to the role of Scrum Master but I’ve learned a lot and been reminded of how it feels to be ‘in the Sprint’.

Day 11
I was reading ‘Agile Coaching’  and came across the following link:
http://www.xqa.com.ar/visualmanagement/2009/02/visual-management-for-agile-teams/
Combined with my recent interest in visual thinking, this opened my mind to the possibilities of expanding the purpose of the current whiteboard. The current board is simply a ‘task board’ and there is a clear opportunity to make it a ‘team board’.  We are shortly transitioning to VS 2010 Agile 5.0 templates. After that change has been completed I’ll talk to the team about shaking up the whiteboard.

Day 12
It’s the last day of the Sprint and we managed to bring it in on-time. This is a great achievement as we lost some resource and velocity mid-sprint. I will be including my work in future Sprints, as it’s been a great reality check.

Are you a designer in a Scrum Team? Should design work be included in the Sprint? Let me know what you think.

Scrumadoodlelicious

There are some fascinating developments in the area of visual thinking. It’s highly relevant to Agile practices and it’s based around the simple art of doodling. Sunni Brown makes the point in her TED talk that 75% of the cerebral cortex is devoted to a single sense – sight. The prevalence of visual aids such as whiteboards are used heavily in Agile and the whiteboard can be a key tool in communicating within the team and exploring concepts with the product owner or project stakeholder.

Sunni also mentions research that suggests that 72 hours after seeing text we retain just 10% of the information. In comparison 90% of drawings are retained in the memory a year after the fact.

We already use extended visual indicators on our board such as the ‘flag’ to add value and transparency to our Sprints. The addition of a further descriptive element would make sense. During a longer Sprint (2-3 weeks +) it’s easy to start losing track of the detail of Sprint Backlog Items. The introduction of a small doodle to act as an ‘aide memoir’ might be just the thing. I’ve introduced this concept to the whiteboard in the last couple of Sprints.

Doodles on whiteboard

I’m excited about the possibilities of fusing the strengths of Agile with visual language and I’ll post how the experience plays-out.

You can watch the TED talk on vizthink.com:

http://vizthink.com/blog/2010/05/14/sunni-brown-and-the-doodle-revolution-a-tedx-talk/

More from Sunni:

http://sunnibrown.com/

Flag waving Scrum teams

Flag waving Scrum teams

As a designer I’m a sucker for colour and also have an understanding of the deeper taxonomy this can represent. The Swiss and Dutch design schools with their deep history of typographical and colour simplicity offer a world-wide showcase for this design trend.
Check out the work of Dietwee for beautifully simple colour construction:

Dietwee website

In a recent change we started putting smaller colour coded ‘flag’ post-its on the bigger ones. The flags denote which developer is working on the task. I’m a designer so this visual prompt works very well for me and reminds’ me who is working on what ‘at a glance’.

Previously we had tried writing initials on the post-its but this got messy if tasks moved from developer to developer. As an alternative we talked about using character stickers which would have been fun but the benefit of being able to un-stick and re-stick the flags gives them the edge.

3 Is The Magic Number

3 is the magic number – well it was for a long time

We recently moved away from a 3 column view to 6 columns on our whiteboard. Following Ken Schwaber’s advice (and numerous others) we had been working with 3 columns for 15-16 months and had found them to be excellent. The company I work for had gained ISO accreditation and the development process was looked at in some detail. Code reviews and testing was an area that required further attention and new statuses were added to tasks to reflect this.

5 column Sprint whiteboard

We soon found that our whiteboard was not giving a true indication of the state of the Sprint. ‘In Progress’ had become a bucket for tasks in varying stages of completion. On one hand this was correct, on the other not knowing at a glance if a task was being reviewed or was ready for test was a problem.

We have been working for about 6 months now with 6 columns and it has been very successful. I have tried to resist the temptation to over-complicate the whiteboard as this defeats the purpose.  A yardstick I use is to ask myself the following question:

“is it possible to glance at the board and see what the state of the Sprint is”

My ‘at a glance’ approach is applied and extended to much of my design work and presentations.

There’s a great discussion of three column whiteboards here:

http://blogs.msdn.com/b/danwhite/archive/2007/02/07/scrum-whiteboard.aspx

Is she or isn’t she?

Is she or isn’t she?

Scrum is founded on the principles of honesty and visibility. It’s vital the business understands who is working on what and when it will be delivered. The common phenomenon of a business leader asking is she/he working on my project or not, is no longer an issue when a simple whiteboard is brought in to play.

‘At a glance’ is my mantra for an effective whiteboard. It should also serve the same purpose for team members and anyone in the business. I still remember the relief I felt when, not long after adopting Scrum a senior manager came over and asked the historically tricky question:

“So what is the team working on?”

I simply wheeled the whiteboard over and talked him through the next three weeks work. The manager was then able to pass that clear picture on to our clients. I knew then that Scrum works and whiteboards are worth their weight in post-its.