The Nokia test provides criteria to measure the adequacy of Scrum implementation. If we have ScrumBut (aka inadequate Scrum), then we should not expect the accomplishments in terms of higher velocity, better quality and increased customer value.
Even while we are implementing ScrumBut, we should strive to show some value from using Scrum. This value will allow us to remove handicaps for Scrum implementation and therefore improve our score in Nokia test.
ScrumBut introduces risks to the project. Such risks should be managed using the rigor of Risk Management (RskM) process. PMBOK® and CMMI® have in-depth addressing of RskM details. Traditionally, software development is driven by risks. There are two drivers that can help us start brainstorming for risk identification.
- Risks originated from ScrumBut.
- Risks originated from not achieving the value which management expects as a result of using Scrum.
- Monitor the risks
- Update risks status
- Identify new risks
- Create actions to address risks
Such meetings and the outcomes tasks are planned in the sprint backlog.
Process Improvement (PI) projects are known to lack momentum to deliver quick results that derives value to the business. Though the PI team may have the required skills and motivation, however, the lack of results fades the importance of PI.
PI is vital apart from the industry. Organizations embark into PI initiatives hoping to solve business problems, improve productivity, reduce defects, and to cope with changes.
PI projects fail because of the inherent change in focus and redefinition of the problem. Having Scrum as evolutionary framework for managing PI projects can help in addressing the turbulent conditions accompanying them.
It’s worth mentioning that implementing certain practices (e.g. Agile) should not be considered a process improvement. It’s more a transformation initiative. PI is characterized that the solution is unknown.
Characteristics of PI
Process Improvement or PI is like sailing in unchartered waters. Those who have the courage can discover new destinations and increase their knowledge. If you are complacent, others will discover better ways and you may not be able to compete.
PI effort fraction- The output from the PI effort can become the norm of the whole organization in the near future. Both practitioners and PI professionals co-work on the PI effort to achieve business objective. A typical business objective can possible be to reduce defects found by the customer by 50%.
The story starts when we are unhappy with the current situation and we like to move to a new destination. For example, we want to reduce defects in our products; however, we don’t know how our processes should be. Not knowing the destination adds other sphere of complexity to PI projects.
Discover Journey- We spend most of the project time in learning to uncover the real problems. We collect data to provide objective understanding of the situation. We analyze potential factors that could contribute to the problem. We are uncertain about the real measures of success; we keep refining these measures as we progress in the project. Findings, can initiate the need for more discoveries.
Harvesting the outcome- We spend lot of effort exploring the possible solutions to address the identified causes. Once we select the solution we begin cycle for implementation or product development. We are unsure whether we solved the problem and realized the ROI till we measure the performance after the solution is implemented.
Schedule commitment- The fact that PI is discovery focused raises greater need to find innovative ways to demonstrate progress on short time intervals. Management can discontinue the project if we kept doing discovery without showing quick results to cope with the urgency of the problem. Having meaningful findings and intermediate results can be key requirement for visibility and securing the continuation of the project.
Budgeting- How to reply to management if they ask you to reduce the defects found by the customer by 50% in three months? The key is to identify root causes at the earliest to have understanding of possible solutions to address them. If there is an imposed time limit, then, this might limit the options and can lead us to reach a solution that is not aligned well with the real issue.
A turbulent PI project
Low speed- A factory is not able to refurbish the high volume of returned boxes they receive monthly. The understanding was they need find way to increase the refurbishment speed. They were looking for a solution to help increase the productivity.
The factory can only refurbish 60,000 out of the 200,000 boxes they receive monthly.
Focus shift- The discovery phase has proved that 140,000 of the boxes should not be received in the first place. This has re-focused the project to other groups. Also, it has redefined the problem. If only the eligible boxes are sent to the factory, then there would be no problem in terms of their productivity.
Cost of Poor Quality- It was estimated that the annual cost of refurbishing the wrongly received boxes is $10,000,000. Management focus was changed to how to stop the drain of money, instead of increasing the productivity of the factory.
More groups- The problem became inter-organizational wide and required hand-offs with other departments. The attention turned to solve a problem at large that is far beyond of being an issue with the refurbishment center.
Business value- No value would have been gained from solving the problem as it was originally defined. The real value came from discovery and exposing unexpected facts.
Scrum as framework for PI projects
The turbulent nature of PI, continuous change in focus, not knowing the product and constant change makes Scrum a suitable project management framework. PI projects similar to the above example can be easily terminated as almost the focus has been directed toward different priority. Setting goals at short sprint (two weeks) is key advantage to the project.
The built-in structure for inspect and adapt allows the project to change focus towards different problems. The high interaction inherent in Scrum helps to maintain momentum and increase the sense of urgency towards solving cross-organizational problems.
|Improvement||Business Value||Deliverables||Stakeholders||Priority||Estimate (story-point)||
|Reduce returns by 50%||$5M annual savings||Critical|
|create Value Stream (end-to-end)||Sales, Customer Op, Factory, Vendors, Transportation, Provision, Billing||100|
|Analyze hand-offs of Value Stream|
|Time study for sample returns||VH|
|Identify causes of return||60||M|
|Statistical analysis of findings||Sameh||13||L|
Improvement Backlog (IBL) can be vital for driving the project work. The IBL consists of:
- Improvement stories: These should have money value attached to each as expected ROI.
- Discovery stories: These are the deliverables which if produced and studied can help in deriving intelligent and unexpected facts about the causes of the problem.
We cannot have improvement stories without having first discovery stories.
Because of change of focus in PI projects, the stakeholders are highly dynamic. The sprint demo serves to synchronize among stakeholders and create a sense of ownership on the problem. As project focus is changed, the attitude of stakeholders will change too. They can become supporters or roadblocks.
Product Owner (PO) She is the person that mostly impacted by the existing situation. She is ready to defend the cause of the project and finance it. The Scrum Team should translate the pains of the PO into stories in the IBL.
Scrum Team (ST) in PI projects is formed of Practitioners, Process Analysts, Database Analysts, Statisticians and other Business Owners. The team uses the findings to derive what should be added to the IBL. The team heavily relies on the PO to help providing details of the business processes and rules. The team should be highly interacting and on daily basis. The activities of the team require regular meetings with various business owners. The team should implement mechanism for internally reviewing the work product.
Scrum Master (SM) This role is currently debatable in the Scrum community. It is even more questionable in PI projects. She helps the project by ensuring having unbiased re-focusing and re-definition of the problem. The project management background of the Scrum Team tends to conflict with this role.
Why am I here? According to Ken Blanchard, “The key to successful leadership today is influence and not authority”. This saying applies squarely to the role of Scrum Master. The Scrum Master facilitates 1) the ability to cope with change, and 2) the ability to deliver in regular cadence. These two practices are missed in traditional PI projects.
Traditional PI projects lack the momentum to survive as the focus is changed. Agile PI projects are run by facilitators instead of the highly analytical people of the tradition PI world. This helps the project to evolve to produce better value to the business.
Table of Acronyms
References and links
- Mark A. Nash, Sheila R. Poling and Sophronia Award: “Using Lean for Faster Six Sigma Results”.
- Ken Schwaber and Mike Beedle: “Agile Software Development with Scrum”.
- Larry L. Constantine: “Beyond Chaos- The Expert Edge in Managing Software Development”.
- Jim Highsmith: “Agile Project Management”
- Mary Walton: “The DEMINGS Management Method”.
- Mike Cohn: “Agile Estimating and Planning”.
Here are the points I discussed with attendees during the Open-Space session of Orlando Scrum Gathering. The topic was the current state of Process Improvement and how implementing Scrum, as Project Management framework, can help.
- Why Process Improvement (PI) is perceived as second priority?
- There is always disconnect between the PI professionals and practitioners. Practitioners believe that they know what matters, while PI does not understand the real issues.
- PI professionals should be part of the product team with accountability similar to the practitioners.
- PI is continuous commitment.
- PI is best done by the people who do the job. These people own the process and they can improve it better than anyone else.
- PI should begin with a point where we unhappy with the existing situation and like to move to a new destination that is not known. For example, 10% of the defects are escaped to the customer and we want to improve our processes to reduce this to 2%.
- The discovery phase of PI is vital to uncover the root causes.
- We should restrain ourselves from suggesting solution till the discovery phase is completed.
- Discovery phase should be completed as fast as possible and the output is the quantifiable result of the causes of the problem.
10. The solution should NOT address the problem; instead it should address the cause.
11. We will always be surprised that the cause we find is far from our initial expectation.
12. Rushing to implement a practice to solve a problem without discovering the cause, will lead to noise and distraction to other problems which are not the real ones.
13. Scrum team is formed of specialists and generalists. Trained generalists can provide PI support to the team. The Scrum Master is a generalist who can lead the PI activities for the Scrum Team.
14. Improvement should be classified as either improvement story or much more important discovery story and they should be part of the product backlog of the project. The PI stories should be given equal priority to other non PI features.
15. The success of PI is measured quantitatively in terms of improving the metrics related to the problem and reducing the Cost of Poor Quality.
16. Scrum can give momentum and visibility to PI by ensuring meaningful delivery at the end of each sprint. This allows PI activities to survive and help the organization to realize business value.
17. Scrum PI can be applied to non software industries.
18. The role of Scrum Master is influencer and should promote PI to find causes of the problem which are beyond boundaries of the team.
19. Scrum PI is managed by facilitators who are more capable to deal with the constant change in PI. Traditional PI is managed by highly technical people who tend to control the scope and are less open toward the turbulence accompanying PI projects. This contributes to higher success rate of Scrum PI over traditional PI.