Chapter 7. Project Reporting Keeping Everything Visible

Transcription

1 Chapter 7 Project Reporting Keeping Everything Visible A Scrum project is controlled by means of frequent inspection of the project followed by necessary adaptations

2 Daily Scrum to get a feel for the tone, attitude, and progress of a Sprint. Sprint Review Meetings End of Sprint assessment: What is the status of all the work associated with the Sprint Backlog? Has valuable functionality been created? What is the quality and capabilities of the functionality? Product Backlog can be evaluated

3 New Project Reporting How to keep stakeholders informed about progress? There are no traditional artifacts to refer to (statement of req ts, architecture, models, designs, code etc.) Without intermediate artifacts how do stakeholders know? Traditional projects provided reports on % of completed tasks, slippage in task completion, and any problem and recommended remedies Typically, such reports did provide useful information for stakeholders Gantt Chart reports were used to track progress (a visual representation of the project s work and the relationships between the work and the resources used)

4 Gantt Charts Gantt charts was devised by Henry Gantt It represents project schedule with respect to time periods. It is a horizontal bar chart with bars representing activities and time scheduled for the project activities.

5 Gantt Report represented by a PERT or CPM chart Program Evaluation & Review Technique Critical Path Management Start Milestong Design Task 1 Resource A, Resource B Succc: 5, 7 Pred: 4 Succc: 11 ID# 4 0 Days ID# 5 10 Days 1/1/1996 1/1/1996 1/1/1996 1/11/1996 KEY Task Resources Design Task 2 Resource A Pred: 4 Succc: 8 Pred Succc ID# 7 15 Days ID# Days 1/1/1996 1/16/1996 Start End

6 Features are defined by a series of stories

7

8 SCRUM Burndown Chart Initial Product Backlog contains 160 Story Points of work At the end of Sprints 1, 2 and 4 changes result in an increase in Scope

9 Key point Functionality provided at the end of a sprint is production ready users should be able to use the functionality in their everyday work. Scrum proves its value as projects succeed a radically different approach from traditional project management, expecting change rather then fearing it. Progress is incremental and visible.

10 How to change from the traditional approach to SCRUM? Shifting to SCRUM requires a major shift in thinking and acting Providing extra reporting helps provide transparency and understanding of the work and the status of the work from sprint to sprint. This becomes a primary responsibility of the ScrumMaster The team should continue without interruption following SCRUM rules without interruption

11 When everything is not visible Service1st Case Study Team commits to developing a lot of functionality in its very first Sprint Claimed they could complete a lot of the Product Backlog it had selected for the 1 st Sprint At the Sprint review, all the functionality was demonstrated, as well as additional features The demo was scripted and did not stray from the script The reality when non-scripted functionality was tested, problems emerged functionality had not been fully tested and bugs were not fixed Their done criteria did not result in go live software that could be successfully added to the build

12 Rule of Sashimi Every increment of potentially shippable product functionality that is demonstrated at the Sprint Review must be complete. The means all the analysis, design, coding, testing, documentation, and any thing else appropriate for the application Without each team member clearly identifying what he or she was working on, the Daily Scrum is useless! No real commitments are being made Team members don t know areas of code each other is working on no advice or help occurs Team members reporting that they worked on it yesterday and were planning to work on it today is meaningless!

13 The Reality The Agile Manifesto is a statement of values and principles that describe agile methodologies SCRUM 7 th of the Twelve Principles: Working software is the primary measure of progress Stakeholders and Product Owners expect delivered software to be complete (done). When any increment is not complete (done), it must be identified and added to the Product Backlog as incomplete work!

14 the hard parts Managing yourself is hard it s much easier to let someone else manage you When a team is hacking together functionality, it often does not spend much time on analysis, design, and testing. They code, code and code again ( code and fix ) A coherent approach plans and allocates all of the work necessary to build a complete increment of functionality The Sprint Backlog should reflect this attention to detail The case study Sprint Planning

15 To recover from work not done in the Previous Sprint The team s Sprint Backlog consisted of two types of work 1. Functionality demonstrated in the previous Sprint that required needs to be fully tested 2. All bugs found are to be fixed All work assigned to the Sprint needs to be specified in sufficient detail to allow for estimating the time needed to do the work Scrum works only when everything is visible and everyone can inspect progress and recommend adaptations.

16 The team needs to know current status Only happens when everything is visible and everyone can inspect progress and recommend adaptations When team members report on their work, other team members need to know whether they can help Specifics Team members report on he specific test employed and the specific bugs found Tests cover every aspect of functionality coded The team owns the responsibility for Quality Assurance (QA)

17 Lessons Learned Commitments are real only if they can be assessed. In the absence of specify, the team doesn t know the work/functionality being worked on and progress. I m fixing the bugs is not an assessable commitment Self-organizing teams are not unmanaged Teams must plan and report against that plan The details of the plan and the reporting must be specific enough to be meaningful The team needs to be able to synchronize its work

18 Self-organizing Scrum Team Sprint Backlog: visible evidence of the team fulfilling this responsibility Teams need to think through what they are doing and write it down so that team members can refer back to a plan as they work The Daily Scrum synchronizes everyone s work only if the work has bee thought through! The ScrumMaster teaches, reinforces the rules of sashimi Once the team understands that the process of developing functionality includes analysis, design, coding, testing, and documentation, all these activities can be collapsed into one Sprint Backlog task.

19 Conclusions Scrum works only if everything is kept visible for frequent inspection and adaptation everyone must know that about which they are inspecting. Sprint Review meetings, daily Scrum, the Sprint Backlog, and the Product Backlog provide the means to keep everything visible To create visibility, the ScrumMaster had to teach the team the importance of the Sprint Backlog practices to self-organization the Spring Backlog is the team s Sprint plan

20 The essential role of the ScrumMaster Making sure everything is visible Making Scrum understandable to everyone in his or her vocabulary Translate the Scrum vocabulary you can connect it with the vocabulary of traditional approaches Example The work required in each sprint might be easily understood as a mini-waterfall process with the responsibility of delivering error free functionality at the end of each spring with all the work and responsibility for success belonging to the team.