...during our sprint retrospective
(Or how this ... became that!)
|That : our brand new board|
|This : our old board|
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 . 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
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 !
|Our way of work represented with kind of a VSM|
Generate insight : building the GOOD board
- 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.
|Work In Progress ... part 01|
|Work In Progress ... part 02 & done|
- 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!
- 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 . 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:
- The technicality of the meeting and the lack of comprehensiveness
- The impossibility to know who is working on what, where and if we are on the tracks.
- The lack of a shared vision on what's coming next
- The absence
- 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.
- We have some good tips like tagging the stories with the environment where they are deployed, or the status (fix me, bloc ...)
- 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
- We have some rules for priorities (top, down) and a golden line for the top priority work to do (prod incident for example)
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...!
- 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 , Colin, Stephane, Jean-Baptiste and Anna for the review!
 Roots cause of visual management: http://www.ted.com/talks/lang/en/tom_wujec_on_3_ways_the_brain_creates_meaning.html
 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
 the way we work : retrospective dedicated to build a VSM
 Kanban moving cards back: http://blog.brodzinski.com/2010/10/kanban-moving-cards-back.html