Agile dashboard


Published on

An overview of how we designed a Jazz-based dashboard to support the transition from a small (9 people) waterfall team into a mid-sized (30 people) truly Agile team.

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Reporting is extra work and any work needs a purpose. You don't have to convince people to do extra work if there is no extra work involved. If people are motivated at a very basic level to report their activity, there is more data to work with and therefore reporting gets better, not as an end goal, but as a byproduct. Jazz is not a punch-card machine, the idea here is not to track whether people are putting in the hours, but how work has progressed and how is it like to progress.
  • Information shared out of context could not be absorbed quickly, only team leader and people immediately affected could actively participate Long side-bars if status revealed something that needed immediate attention. Information was not written down, only focus on critical issues. Daily meetings with the team, weekly meetings between scrum master and the business. Product owner not able (nor required) to understand day-to-day activities.
  • Meetings took shorter Standup information more focused Blockers solved only amongst involved party after main meeting 9 people verbally stating their yesterday/today commitments could not be absorbed quickly Overuse of continuous tense: “I am working on...”, “I will continue to work on...”. Impossible to translate standup meetings to a business status. Trees over the forest
  • Sprint activity visible at all times, not only during standup or weekly status meeting. Shared context makes standup participation shorter (“I will write the unit tests for the J2EE installer story”) allows one to inspect the story activity, status, blockers, etc. Product owner has a quantifiable amount of information to grasp. A developer is not talking about any story, but about story 3 out 7 in the list of priorities (“this blocker is more important than another blocker”, or “this story is not well-defined, it had 3 architectural blockers during the sprint”) Management team does not have to understand individual standup meetings, only the resulting status of each story and overall burnup impact.
  • Once the team gets used to the routine, there is a tendency to relax in the discipline (“the status doesn't change very much, it is ok to skip an update or two) Once we went from 9 people in one scrum to 30 people in 4 scrums, the sense or importance became far more ingrained in the team Consensus amongst the team is that it would not only be difficult, but impossible to understand the project situation without a dashboard. Even for reporting status, without fully understanding its underlying components, is that it would cost several times more to rebuild the information at reporting time.
  • One of several tabs Left column indicates how the team is doing within the sprint (ahead or behind expected) Center column indicates what happened and what is about to happen Right column represents ongoing work, such as stories in the sprint, their status, associated testcases, and their review status As a result, this single screen is the one stop tab for those without time to peruse the entire dashboard, as it shows: quantitative status (left column), qualitative status (center column) , and context (right columm)
  • Plan views offer a graphical and quantitative view of the iteration plans. A sprint can have multiple iteration plans, organized by teams and overall Classic sprint burndown view indicates when planned work starts to fluctuate inside the sprint, usually not a good sign.
  • This part of the main tab qualifies the quantitative status on the left Lists work that has been completed, outstanding adoption items (questions from customers) , work items (confirmed problems from customers, not necessarily product defects) , defects, and blockers.
  • This part of the main tab gives context to the status portion, indicating which stories are assigned to the sprint, their status, their defects, and sprint blockers. It gives dimension (how much work is planned) and depth (how well that work is going) to reports.
  • Jazz Burn up charts are extremely powerful: How much work the team can do on sprint/release How much work is actually planned for the sprint/release How much work has actually been done How much work can be done at the current rate How much team capacity has been spent Detailed explanation at
  • Kan-ban style view, background for all standup meetings Quick view into sprint progress Quick view into team member load and progress Time spent on a task update with click on watch icons Task status update or reassignment through drag-and-drop operation
  • Each scrum has its own tab All participants of Scrum of Scrum meetings look at the tab for the team reporting at that time. No time spent on quantitative status. Again, constant context breeds mutual awareness Information retention greatly improved during meetings. 30 minutes everyday
  • Agile dashboard

    1. 1. Improving Agile execution through a Jazz-based dashboard Denilson Nastacio
    2. 2. About me <ul><li>Quality and design enthusiast
    3. 3. 15 years in software development
    4. 4.
    5. 5.
    6. 6. o
    7. 7. Disclaimer: I am an IBM employee. Rational Team Concert is used in this presentation, but the focus is on the importance of a shared dashboard for Agile development, not on the usage of RTC. </li></ul>
    8. 8. Agenda <ul><li>Goals
    9. 9. The pre Agile days
    10. 10. The rough Agile days
    11. 11. The disciplined Agile days </li></ul>
    12. 12. Goal <ul><li>Data collected must improve execution, not reporting project status </li><ul><li>For every collective minute spent reporting data, at least one collective minute should be recouped. </li></ul></ul>
    13. 13. The pre-Agile days <ul><li>Daily 1 hour status calls
    14. 14. Focus on critical issues
    15. 15. Second-hand status to release manager </li></ul>Scrum Master Release Manager
    16. 16. The rough Agile days <ul><li>Daily 20-minute standup
    17. 17. Two pre-scheduled 15-minute slots to deal with blockers
    18. 18. Standup reports from 9 people were difficult to summarize </li></ul>
    19. 19. The better Agile days <ul><li>Easier to absorb 1-minute standup info by looking at kanban charts
    20. 20. Constant context during sprint generated mutual-awareness
    21. 21. Mutual-awareness available offline, outside the meetings </li></ul>
    22. 22. But we don't need a dashb...oh...
    23. 23. Sprint Overview *Not actual project data
    24. 24. How are we doing? *Not actual project data
    25. 25. Past, present and future *Not actual project data
    26. 26. Story time *Not actual project data
    27. 27. Burning up *Not actual project data
    28. 28. Standup time...for less time
    29. 29. Scrum of scrum at a time
    30. 30. Resources <ul><li>IBM Rational Team Concert </li><ul><li> </li></ul><li> </li><ul><li> </li></ul></ul>
    31. 31. Summary <ul><li>Dashboard tabs organized in incremental steps, supporting quick 30 second glances or 15 minute drill-downs
    32. 32. Focus on saving time, not on reporting. Good reporting is an unavoidable side-effect though.
    33. 33. Shared context breeds awareness, awareness breeds familiarity and teamwork. </li></ul>