Going agile with scrum: The taskboard

A mayor deficiency of our and perhaps any IT software department is that it seems we just can’t make clear to our stakeholders what the !@## we are doing. How familiar do these remarks sound from your business and marketing people to you? It might be the product owner who fires these questions:

– Hi Teamlead, who is going to work on feature X now?
– You want to go live in 6 weeks with this? What about 14 days?
– “But..? That feature should have been finished four weeks ago!”

These three examples are taken from real life; and no, I did not save these up from last few years, it’s just from the last few weeks… Is that a problem? Yes of course it is, and no, it’s not because our business people, marketeers or product owners don’t know anything about software development (well maybe), but the problem here is total lack of communication, publication, presentation and managing expectations about what the !@## it is that we are doing.

Should we make that more clear? Yes of course!

Point made? Great, but now how to solve that? How can you as a teamlead make clear what your team is doing? Here come scrum and agile to the rescue. It was only four weeks ago we decided that we had to change this now. So we finally started.

The first thing we did: We created our taskboard

Looks neat, doesn’t it? And you only need a board and either sticky notes or in our case plastic-magnetic cards where you can write on with markers. Luckily, we had these available so we did not have to ask for any funding to do this. If you don’t have a board: get the physical strongest developers of your team, go round in your office building and just grab a board from someone else 😉 Just make it happen; you are the factory of your organisation and if you need it to get your factory going than everyone else will understand, right?

We also asked the whole team to read up on our skills with Kanban and scrum by Kniberg and Skarin. Read it! It’s a very good introduction.

So what do you see on the taskboard? We decided to start with five columns, from left to right these are:
– Analysis and design
– Ready for development
– In development
– Ready for dev-stable
– Ready for staging

To all software developers this will be easy to grasp. The leftmost column contains the items that still need to be thought about ‘how to implement’, and when that is ready we can move the item to ready-for-development. If a developer asks the teamlead for new work: she can pick up the task. Than the column in the middle in development. Here are the tasks that developers are currently working on. Basicly the middle column defines our capacity. When development is ready, we move the card to ready for dev-stable which means the software is to be integrated with other necessary modules and tested by a tester. And only if things have been approved on our dev-environment, we move the task-card to ‘ready for staging’, which is the environment where our stakeholders like marketeers or other business people who asked for the features test our work for the first time.

The last column also defines our definition of done.

The second thing we started was: daily standups at the board.
Daily standups are easy and effective. Well, people have to get in at about the same time in the morning so that you can agree on an early start-time: that greatly helps as well. Three questions are answered by each individual developer:

– What did you do yesterday?
– What are you going to do today?
– Are there any obstacles?

Doing the standup at the taskboard helped us moving cards from left to right on the board on a daily basis; if there is no flow for certain work items it immediately can be discussed at the board and help is offered to each other.

Introduction of the taskboard is not really a big change in the way of working but having the work items visible instead of only in a stale issuelist on the screen helped a lot with our communication; also it is now impossible that items stay in the same process step without anyone noticing…

Third thing you need to do to effectively start agile and scrum: Keep track of the number of items in each column. Thus: Monitor progress.

In about two weeks this is our taskboard progress:

Keeping track enables the team to have a retrospective
afterwards.

Earlier, we also kept track of progress by using the Agile estimation sheet that works very good but having workitems visible on a taskboard works even better!

We suddenly realised that we could not make all items that we thought we would realize. So what we did was: We simply took those off the board and than our bottleneck became very, very clear: integration-testing! Nothing got approved and the business was pressing us to start more work…. but we haven’t finished our current work yet. “We” as in we the organisation. We got that clear to our stakeholders and are pulling them into our testing process because our tester was occupied firefighting live issues. Testing: that’s where the factory needs help from the business!

Next time; a followup.. we have not yet done but will definitely do a retrospective
with the team when the major features of this iteration get released to our live websites….