How we built our taskboard...

...during our sprint retrospective 

(Or how this ... became that!)

That : our brand new board

This : our old board

 

 

Context

The team I'm working with is quite new doing the Scrum. We decided to use this retrospective to ameliorate our scrum process and the team agreed that this time it would be me choosing the topics. During the previous sprint retro we have defined our process of work building a VSM [1]. During this one I wanted to fix the following items:

1.       The technical nature of the daily meeting which needs to get more comprehensible .
2.       The impossibility of knowing who is working on what and if we are on the tracks.
3.       The lack of a shared vision of the product, on what's coming next.
4.       The lack of the priorities set.

I tried to search for the root causes of those problems and finally all my thoughts converged on the task board! The board is a mess... You cannot see anything, everything is confusing... My point is: you can't have clean water coming from a dirty pipe. The board is the mirror of the team daily work. Mirror my sweet mirror...

The aim of the retro workshop was to build a GOOD board. Helping us to have an understandable daily meeting, allowing us to know who is working on what, sharing a vision and the priorities.

The purpose was to have a bottom-up approach, making the team build their own board. By experience this is the better way to have a practice approved and well adopted.

Running the meeting

• Gather knowledge on boards

First we needed to gather some knowledge on boards. What can a board represent , how, and mainly why are we using boards and visual management [1]? I always try to explain why we do the things we do! It's making sure that things will get done effectively. So we spend 30mn gathering knowledge about boards. We used a couple of docs [2].
After this we shared with the team what a GOOD board is, we take as definition of done:
-         The board should represent our process of work.
-         The board should clarify what we wanted to transmit.
-         The board should be build and used collectively.
So we needed as input a representation of our process of work. Cool this was the purpose of our previous retrospective, the way we work [3]!

Our way of work represented with kind of a VSM

• Generate insight : building the GOOD board

We used a workshop created by Xavier Quesada [4]. The purpose is to build a board as you build a project using Scrum. So as a team we made 3 sprints (20mn) with demo and retro (10mn), using a backlog of requirements illustrating classical situations on a project such as:
-         A critical bug was found in production! ASAP action is required by the team. Task board must show this. Name of the issue: "Invoices not being sent".
-         A task needs a large database to be finished. We thought we had enough disk space, but we don't! The team doesn't have the means to solve this on their own. Task is blocked. Task board must show this.
-         ...
I added another constraint: the board had to represent our VSM (previously built) and I put the VSM on the room.

The build process

a. Sprint 01

Objective: The team built a basic board representing the feature, the sprint goal, the process, some DoD.

Sprint review: The team talked about the board; some criticism came up

• How to know in which environment an U.S is deployed?
• How to manage an unplanned task?
• How to manage a correction on done U.S with bug found during Q.A

b. Sprint 02

Objective: address the sprint 01 issues, identify lost time (aka waste), impediments, show the all picture from the preparation. 

c. Sprint 03

Objective: We look for typical situations occurring during our project.

d. Result

Incoming ...

Work In Progress ... part 01

Work In Progress ... part 02 & done

toolkit

Benefits:

• You feel the added value of Scrum building your own task board: the board appears, sprint after sprint handling more and more constraints. After each sprint you challenge your board in a demo finding stuff to ameliorate.
• The bottom up approach: the team builds the board they will use.
• We really appreciate to see our real workflow
• The result is great!

Constraints:

• The definition of done(DoD) we created during the meeting is not clear (It will be the subject of my next retro, and I suggest you do so too; DoD is too important to be treated in the same workshop)
• We only built a draft and I spent one entire day to realize the final board, it took me 4 entire days to prepare, animate and close the workshop
• We appreciate too much to see our real workflow... and we decide to break a principle: moving cards back [5]. Next step should be to rearrange our board to manage this.
• We do not have limits on the board. We need more maturity to do this. Maybe during a future retro.

In a nutshell ...

The improvement of this retro was done: the new board was built. As a team we had some constraints:

1. The technicality of the meeting and the lack of comprehensiveness
2. The impossibility to know who is working on what, where and if we are on the tracks.
3. The lack of a shared vision on what's coming next
4. The absence of setting priorities
   

We respectively tackle with

1. Story focus stand-up: After one week of work with the new board instead of manipulating technical task related to user stories, the team manipulates the stories making them moving from one column to another.
2. We have some good tips like tagging the stories with the environment where they are deployed, or the status (fix me, bloc ...)
3. We have the all story lifecycle on the board, from the idea to the product. The all team share a global vision of the product
4. We have some rules for priorities (top, down) and a golden line for the top priority work to do (prod incident for example)

Closing

We did a ROTI to close the retrospective. The team vote for 4/5 (We gain more time than we spent). The team is using the board for few months now, we added some tools, fixed some stuff. The feedback is great. Some fellows come into the project room and look at the board, talk about the board. Feels good...!

(Re)-learn

-         GOOD Board == represent the process of work, clarify what we wanted to transmit, build and used collectively.
-         Mess on board == mess on the team process // the board is the mirror of the daily work.
-         How to build a board == use Scrum.
-         The board == from idea to product.
-         Actions to do on a task == use tags on your user stories.
-         Top priorities == golden line.
-         Brake technical daily meeting == story focus stand up.
-         Closing a meeting == R.O.T.I

Thank you for reading. Feel free to give me some feedback.
Special thanks to Mister Xavier Quesada for the workshop [4], Colin, Stephane, Jean-Baptiste and Anna for the review!

Sources

[1] Roots cause of visual management: http://www.ted.com/talks/lang/en/tom_wujec_on_3_ways_the_brain_creates_meaning.html

[2] Knowledge material:
-         Support Agile avec Kanban : http://www.fabrice-aimetti.fr/dotclear/public/traductions/Support-Agile-avec-Kanban-FR.pdf
-         Agile Support with Kanban : http://blog.crisp.se/2010/02/17/tomasbjorkholm/1266404160000
-         Kanban boards : http://www.xqa.com.ar/visualmanagement/2009/06/kanban-boards/
-         Comment améliorer votre Kanban : http://blog.soat.fr/2011/12/agile-tour-paris-2011-2/
-         Element for taskboard design : http://www.xqa.com.ar/visualmanagement/elements-of-taskboard-design/
-         Kanban & Scrum:http://www.infoq.com/minibooks/kanban-scrum-minibook

[3] the way we work : retrospective dedicated to build a VSM

[4] http://www.xqa.com.ar/visualmanagement/

[5] Kanban moving cards back: http://blog.brodzinski.com/2010/10/kanban-moving-cards-back.html