The document discusses how a Jazz-based dashboard can improve Agile execution. It describes challenges with status reporting in "pre-Agile" and early Agile days when information was not easily accessible or absorbed. A dashboard with tabs showing sprint overview, burn-up charts, story details and team scrums provided constant context that bred awareness and facilitated quicker status understanding. The shared visibility of work improved execution by saving time otherwise spent reproducing status outside of meetings.
2. About me
● Quality and design enthusiast
● 15 years in software development
● http://rtpscrolls.blogspot.com
● http://sourcepatch.blogspot.com
● http://www.linkedin.com/in/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.
3. Agenda
● Goals
● The pre Agile days
● The rough Agile days
● The disciplined Agile days
4. Goal
● Data collected must improve execution, not
reporting project status
● For every collective minute spent reporting data, at
least one collective minute should be recouped.
5. The pre-Agile days
Scrum Release
Master Manager
● Daily 1 hour status calls
● Focus on critical issues
● Second-hand status to release
manager
6. The rough Agile days
● Daily 20-minute standup
● Two pre-scheduled 15-minute slots
to deal with blockers
● Standup reports from 9 people
were difficult to summarize
7. Standup time...for less time
● Adjust time spent right
on the chart
● Reassign tasks or
update status through
drag&drop
8. The better Agile days
● Easier to absorb 1-minute
standup info by looking at
kanban charts
● Constant context during sprint
generated mutual-awareness
● Mutual-awareness available
offline, outside the meetings
16. Summary
● Dashboard tabs organized in incremental steps,
supporting quick 30 second glances or 15 minute
drill-downs
● Focus on saving time, not on reporting. Good
reporting is an unavoidable side-effect though.
● Shared context breeds awareness, awareness
breeds familiarity and teamwork.
17. Resources
● Burnup charts
● http://sourcepatch.blogspot.com/2010/11/burning-
up.html
● IBM Rational Team Concert
● http://www-
01.ibm.com/software/rational/products/rtc/
● jazz.net
● http://jazz.net
19. About me
● Quality and design enthusiast
● 15 years in software development
● http://rtpscrolls.blogspot.com
● http://sourcepatch.blogspot.com
● http://www.linkedin.com/in/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.
2
20. Agenda
● Goals
● The pre Agile days
● The rough Agile days
● The disciplined Agile days
3
21. Goal
● Data collected must improve execution, not
reporting project status
● For every collective minute spent reporting data, at
least one collective minute should be recouped.
4
● 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.
22. The pre-Agile days
Scrum Release
Master Manager
● Daily 1 hour status calls
● Focus on critical issues
● Second-hand status to release
manager
5
● 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.
23. The rough Agile days
● Daily 20-minute standup
● Two pre-scheduled 15-minute slots
to deal with blockers
● Standup reports from 9 people
were difficult to summarize
6
● Meetings were 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
24. Standup time...for less time
● Adjust time spent right
on the chart
● Reassign tasks or
update status through
drag&drop
7
● 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
25. The better Agile days
● Easier to absorb 1-minute
standup info by looking at
kanban charts
● Constant context during sprint
generated mutual-awareness
● Mutual-awareness available
offline, outside the meetings
8
●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.
26. But we don't need a dashb...oh...
9
● 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.
27. Sprint Overview
*Not actual project data 10
● 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)
28. How are we doing?
*Not actual project data 11
● 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.
29. Past, present and future
*Not actual project data 12
● 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.
30. Story time
*Not actual project data 13
● 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.
31. Burning up
http://sourcepatch.blogspot.com/2010/11/burning-up.html
*Not actual project data 14
● 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
32. Scrum of Scrums...one scrum at a time
15
● 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
33. Summary
● Dashboard tabs organized in incremental steps,
supporting quick 30 second glances or 15 minute
drill-downs
● Focus on saving time, not on reporting. Good
reporting is an unavoidable side-effect though.
● Shared context breeds awareness, awareness
breeds familiarity and teamwork.
16
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