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.

1. Improving Agile execution through a
Jazz-based dashboard
Denilson Nastacio

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

9. But we don't need a dashb...oh...

10. Sprint Overview
*Not actual project data

11. How are we doing?
*Not actual project data

12. Past, present and future
*Not actual project data

13. Story time
*Not actual project data

14. Burning up
http://sourcepatch.blogspot.com/2010/11/burning-up.html
*Not actual project data

15. Scrum of Scrums...one scrum at a time

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

18. Improving Agile execution through a
Jazz-based dashboard
Denilson Nastacio
1

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

34. 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
17