Task Board Evolution

1. Task Board Evolution NayanHajratwala Lean / Agile Coach Chikli Consulting LLC Saline, Michigan, USA 985002021 陳柏彰

2. Outline • Introduction • 1th case: Greenfield project • 2nd case: Legacy project • Conclusion

3. Introduction • The first core property of Kanban is to “visualize the Work”. • If the whiteboard can not be clearly see what work is actually being done, it becomes very difficult to improve the process. • Thus, designing task board is an important work for development.

4. Greenfield project • The team had been brought in to build Web Services. • There was no existing system that was capable of consuming the services.

5. A. Startup • The team agreed they would have several categories of work: • Features had been thought of • Features that were the next thing to work on • Features being worked on • Features had been completed.

6. A. Startup

7. B. Anatomy of a Story Card • The story card contained the following information: • The dates were used to calculate Cycle Time from Development.

8. C. Before Done • They need QA to check the stories is “done”. • The User Interface is turned out a separate team in Brazil but they were about six months behind this team in development. • Therefore “QA” and “Waiting for Godot” columns were added before Done. • The idea was to highlight the large amount of work that was piling up in this state.

9. C. Before Done

10. D. Acceptance • Around this time, they started doing demos to the stakeholders. • They demo stories before QA state because the QA process was no more than a formality for their team since they were using ATDD and TDD techniques. • “Ready for QA” column was added as a buffer, and they put blue dots on cards that had been demoed.

11. D. Acceptance

12. H. Merging Processes • They merge two teams’ board. One board is moved underneath the other board and lined up the columns. This highlights the total WIP in any given state across the two teams. • With the process being truly reflected across two teams now, they began to see bottlenecks exposed in places where it had been hidden in the past.

13. H. Merging Processes

14. LEGACY PROJECT • The next client was a team that had an eight-year-old product, built with no agile practices.

15. A. Understanding the Current Process • They were using some of the Scrum process practices, but no agile technical practices. • Their existing board consisted of “Next”, “Not Started”, “Development”, “QA”, and “Done” columns. • They weren't effectively using velocity metrics of any kind, so the author start calculating Cycle Time and added a Cumulative Flow Diagram (CFD) to the board.

16. A. Understanding the Current Process

17. B. Continuous Improvement • The team was having regular retrospectives at the end of each iteration. • Unfortunately, some improvements were generally ignored or forgotten. • The author suggested that improvements need not wait until a retrospective to be initiated. • A Continuous Improvement area was added right next to the main task board. It contains “To Do”, “In Process”, and “Done” columns.

18. B. Continuous Improvement

19. C. The Big Expansion • Redesign the board: • “Analysis” column was added since a lot of time was being spent by thinking of detailed definitions of the desired functionality. • WIP limits were added to Analysis, Development, and QA columns. • A Prioritized Backlog was added with a WIP limit of 7 since the team was spending a lot oftime re-prioritizing the backlog and most of this effort was wasted. • Added a swim lane for production support issues. • Added another swim lane for development work being done outside the development team so as to visualized their work.

20. C. The Big Expansion

21. D. Streamlining • Move out of the pseudo-cubicles and into a more open workspace. • Development and QA efforts had been merged. • To make the work follows a single development process, the development work being done outside the team's process was ceased and swim lane was removed.

22. D. Streamlining

23. E. Beyond Production • A new area of the board was added after production. This was titled “Communicated to Business.” • It was the product owner's responsibility to move cards from production into this area when he had performed the necessary communication.

24. E. Beyond Production

25. Conclusion • From these two clients, it has been the experience that a task board should have the following attributes: • A. Reflects the actual process • To expose bottlenecks and hidden work in process. • B. Easy to modify in unexpected ways • Can make changes such as merging the board. • C. Rough • When a team lovingly creates a task board with perfect lines & lettering, they are much less likely to be willing to make changes • D. Big & Visible • If you can’t see your task board from where you’re working, you’re unlikely to think of it as a source of “process truth”.