Overcoming Traditional Project Release Reporting with an Agile Approach Focused on Change ========================================================================================= Introduction ============ We are a 30 year old product development shop with more than 450 technical people. For years we have been using a traditional approach to the reporting of progress on releases using traditional stage-gate and project management approaches. The project management approach had been automated to a significant degree and was well entrenched within the organization. A lot of the standard discussion on release reporting fails to address the legitimate concerns of executive management for this large a development group as it focuses on team rather than the organization needs. If not addressed this creates resistance to the adoption of Scrum / Agile which, given all the other cultural issues that need to be addressed could seriously distract and even jeopardize the implementation. What is required is an approach which maintains the integrity of the Scrum team approach while still providing data to the business that allows them to make decisions. When I say "traditional" reporting, what am I talking about? I am talking about weekly schedules meetings to determine whether we are all on track, Microsoft Project based schedules with standard stage gates for approvals, pages and pages of documentation on current status, data held privately to the development shop and so on. When I say "maintains the integrity of Scrum team approach" what am I talking about? I am talking about team based estimates using points, simple encoding on user stories to allow categorization of data, roll-up reporting to generate release and portfolio views from team views and a set of 5 simple reports that really do provide everything that everyone needs. Principles of Reporting ======================= The session explores the following general principles of release reporting and provides specific examples of use. * Make everything (I really mean this) available to everyone in the organization. * Make sure that reporting can be done simply, with no additional work required by the teams, and using simple approaches to categorize data. * Base release reporting on changes that we are seeing in the progress of the release project as opposed to reporting on the plan so that everyone can understand the current state of the plan. * Ensure that reports are the same at all levels (team, product release, portfolio), based on the same information (team based estimates and velocity) and producing the same results so that everyone is looking at their view of the same data. * Ensure that you interview "C" levels in your organization to understand their areas of interest in the reporting so that, again, everyone is looking at the same data and making their decisions by the same criteria. * Ensure there is a continuum of reporting that not only helps with business but more importantly helps the teams so that the data required by the business are a natural by-product of normal team work. Questions ========= How did you uniquely scale, blend, adapt or evolve agile practices? ------------------------------------------------------------------- Starting with the basic "release burn-up" chart sourced from team data (story point estimates and velocity), we developed and sold internally the notion that five simple reports would give us everything we need to run the business: * Release burn-up, with trend-lines: "I, as a Scrum Product Owner who is trying to optimize the delivery of a product release in terms of date, scope, and cost need a way to show what the current scope in the release and progress we are making toward it so that we can make well-informed trade-offs and commitments based on the reality of our company's capabilities." * Scope change report: "I, as a Scrum Product Owner who wants to communicate with the stakeholders need a way to show how the work for a release has changed from the original baseline to the current status so that everyone is really informed about the current status of the plan." * Epic progress report: "I, as a Scrum Product Owner who wants to understand the status of the release need a way to show how work is progressing against the major epics of the release so that I can make adjustments in the plan based on completion of these epics." * Investment allocation report: "I, as a Scrum Product Owner who wants to make good investment decisions need a way to show how work is split in terms of the basic investment categories management report against so that I can make predictions for future plans based on history and make adjustments during execution of a release when these assumptions do not work out." * Project allocation report: "I, as a Scrum Product Owner who wants to make good investment decisions need a way to show how work is split in terms of the next release and existing fielded releases the Scrum Team is working on so that I can make predictions for future plans based on history and make adjustments during execution of a release when these assumptions do not work out." The only adjustments required to produce the reports were some simple attribution on the user stories which the Product Owners were glad to do since it gave them the information that they could use. What mistakes did you make? What insights have you gained that others need to know about? ----------------------------------------------------------------------------------------- The biggest mistake I made was underestimating the amount of inertia associated with the traditional reporting model. What I should have done was simply tackle this issue much earlier. If I had done this I suspect that there would have been less managerial resistance to the adoption of agile. A second mistake I made was not supplying better templates to produce the information required. This lead to confusing when amongst the people that wanted to do this reporting since they virtually had to learn how to do it themselves. What was it like integrating agile development into to the rest of your organization? ------------------------------------------------------------------------------------- The issue of release reporting became an impediment. I used to think "those management people just do not understand the whole 'agile' concept." I thought they wanted project reporting against "the plan." I found out they did have legitimate concerns that we were not addressing. What they actually wanted was standardize reporting that answered key questions about "where are we", "are we heading in the right direction", "when do we expect something", "what decisions need to be made today" and so on. While I am sure they would have liked to have a predictable plan, it was my understanding that they were asking for traditional reporting. Nothing could be further from the truth. By taking the time to understand the requirements (capturing them as user stories) I could take the issue off the table which meant that we ended up with a smoother transition. How successful were you in overcoming challenges? What challenges remain? ------------------------------------------------------------------------- The main challenge that remains is moving to this work to a tool so that we can automate the process. We have sold the concepts, are producing the reports manually but it is taking time when it should be easy to automate. If you’ve been doing agile development for some time, how have your values or ways of working changed? What are you doing now and why? -------------------------------------------------------------------------------------------------------------------------------------- Lesson learned - don't let your assumptions about others lead you to thinking that you understand everything. As an agile coach you can easily fall into the trap of hubris.
http://submit2012.agilealliance.org/files/session_pdfs/Overcoming Traditional Project Release Reporting with an Agile Approach Focused on Change v04.pdf
