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 http://sourcepatch.blogspot.com/2010/11/burning-up.html
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
Improving Agile execution through a Jazz-based dashboard Denilson Nastacio
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>
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>
The pre-Agile days <ul><li>Daily 1 hour status calls