In implementing Scrum, we create a team Improvement Backlog. The items in this iBacklog can be:

1. Organizational impediment: This is an organizational change, for example, to create a new role called Product Owner as the single point of contact to the team.

2. Infra-structural improvement: The adequacy of Definition of Done is limited by the infra-structural for the development. For example, ability to make hourly build and integration of code lines from various teams.

3. Team practice to be implemented: Team practices include self-organization, collaboration and empiricism. This is in  addition to engineering practices.

4. Scrum ceremonies

5. Other teams coordination

To quickly boot-strap Scrum implementation in a team, I found that prioritizing the iBacklog and starting as soon as we can increase the chances of success in implementation. For example, there may be 1-2 organizational changes to be resolved, then we agree on Definition of Done, then implement Scrum ceremonies directly.

If we succeeded in implementing the ceremonies, Scrum will help in surfacing more improvement opportunities during retrospectives and other Scrum control points. Scrum Master or coach should maintain this iBacklog with the same rigor the Product Owner maintains the product backlog.

Embedding Scrum in Kanban board

In a typical maintenance project managed using Visual board, we can have cards representing bugs, enhancements, new features or new product development. All card types can be managed using the value stream of the visual board except for new product development (NPD). The NPD represents fundamental architectural change into the product leading to break through added features to the existing product. Such NPD card can be managed as Scrum project because of the following.

Long duration
A typical NPD project can take in average 10 weeks which is much longer than cards from other kinds.

Team effort
While a typical card can have one developer, for NPD it requires team.

Requirement management
NPD by definition means requirement will evolve and new discoveries about the product would occur from one iteration to the next. This kind of convoluted development activity would require highly iterative and risk oriented delivery of slices of the requirements.

Different value stream
The value stream for non NPD card is agreeable and visualized. The NPD can have a very different value stream and can employ different skills from the maintenance value stream.

Technical risks
NPD involves myriad of technical risks and can require substantial architectural and design work.

Management oversight
For NPD management and business users would require periodic review of the increment for feedback. In normal value stream though these review  can occur but not to the extent of interactivity required for NPD.

Marketing analysis and ROI
NPD is driven by marketing and financial analysis of ROI. In additional to the technical product risk, there is also financial risks due to competition from other vendors. The revenue model is important for NPD and derives the prioritization of backlog of a NPD card.

Based on the above factors, I would recommend managing NPD card as sub-project using Scrum.

How to classify the card as NPD? Use the above factors as check list. Another rule: the card should be classified as NPD if the current value stream of the visual board fail to work.

What about code integration?
I suggest managing NPD card as separate trunk in the version control system. It can take multiple iterations before we can have shippable product, at that point we should start merging this trunk with the baseline product.

Kanban for Scrum Implementation

Two weeks ago I met a client, who is transforming to Scrum, his biggest concern was that people may leave!

Showing lot of respect to his opinion, I sensed that he had ever increasing attrition of developers. I stopped short from even mentioning what Scrum prescribes, though he was specifically asking to implement Scrum. I didn’t want to mention dedicated teams, freeze changes during the sprint or release planning, or other practices which I practiced and value.

Rather than being interviewed myself, I began to interview him. He had projects  to be delivered at Fixed scope and Fixed schedule. He was worrying that a Scrum specialist would start pushing Scrum practices causing unpredicted impact on his environment.

For his surprise, I suggested that to hold our horses and don’t think Scrum or any other tool. I suggested to implement a gradual process improvement function that would allow solving the business problem he mentioned and continuously improving his capability to respond to customer’s varying needs. He was already preoccupied about using sprints, velocity, backlogs and other artifacts of Scrum. I suggested that he might like to consider Lead Time as the primary metric driving his continuous improvement activities. I emphasized that we don’t rule out the use of Scrum or any other tool.

Based on what we would discover we can decide on what to implement, instead of just go Scrum! Continue reading

Product-Box (aka organization character)

Scrum Product Box 01

Scrum Product Box 02

It was interesting session during Deep Agile on May 15th, 2010, in Cambridge, MA which Lyssa Adkins facilitated to build a Scrum Product-Box® . A Product-Box® is one of the  innovation games from http://www.enthiosys.com/. In this post I am giving my own reflections. The  description of this game can be found in this book by Luke Hohmann.

This game helps  the vendor to collaborate with the customer. The customer will design the product-box of the product which the vendor is trying to sell her so that she can resell to her end customers. The process of directly working with the customer and allowing her to design her own flavor of the  product is so powerful. I found that the customer  is  hesitant to buy the product unless she can resell to her own stakeholders. This collaborative game early resolves doubts and risks and allows the vendor to have more understanding of the concerns of the customer.

Scrum Product Box 03

During the game, each attendee played the role of the customer to design her own product box to so that she can resell internally. The product was Scrum itself. Imagine the roles as The vendor (Agile consultancy) and The customer ( IT services in a large organization who are considering using agile/ Scrum). By designing the product-box herself, the customer in-fact formulates the story in a way that she can resell to her management.

The second phase of the game starts after the customer finished designing the product-box. The customer begins reselling her product-box to her own customers by describing the drivers for her design and the benefits to the organization as indicated by the product-box. The box at the top has attracted my attention. This product-box reflected waste removal as result of implementing Scrum by limiting the team’s commitment in fixed length Sprints and have team members do different things. This should have  economical appeal from the perspective of the organization in addition to the promise of delivering something valuable every iteration.

Before playing the product-box, the team had identified the impediments towards Scrum implementation, please see the picture below. During selling the product-box, we related each design to how it can address the identified impediments.

Impediments to Scrum Implementation

It appeared during the selling session that each product-box is able to address certain impediments that are different from the ones addressed by others. This for me reflects the importance of design in selling our proposal to our organizations. The customer can make sure that her design addresses certain concerns that are particularly important to her organization. In other words, the product-box reflects the character of the organization.

The selling session is the most important part of the game. The customer is going to be challenged on the effectiveness of her product in addressing the pains of her organization.


If we know that we will be challenged by our organizations, then why should not we by prepared by creating a design addressing the impediments before attending selling session? Also, as a vendor we should put ourselves in the shoe of the customer and understand her situation and the requirements of the end user, who we don’t directly deal with.

Risk management in Scrum – Insights

I am writing this post after exchanging tweets with @flowchainsensi.

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.

  1. Risks originated from ScrumBut.
  2. Risks originated from not achieving the value which management expects as a result of using Scrum.
I suggest implementing weekly RskM as 30 minutes meeting to:
  1. Monitor the risks
  2. Update risks status
  3. Identify new risks
  4. Create actions to address risks

Such meetings and the outcomes tasks are planned in the sprint backlog.

Using Scrum to manage Process Improvement


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 Backlog

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
60 VH
60 H
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

PI Process Improvement
IBL Improvement Backlog
PO Product Owner
PM Project Manager
SM Scrum Master

References and links

  1. Mark A. Nash, Sheila R. Poling and Sophronia Award: “Using Lean for Faster Six Sigma Results”.
  2. Ken Schwaber and Mike Beedle: “Agile Software Development with Scrum”.
  3. Larry L. Constantine: “Beyond Chaos- The Expert Edge in Managing Software Development”.
  4. Jim Highsmith: “Agile Project Management”
  5. Mary Walton: “The DEMINGS Management Method”.
  6. Mike Cohn: “Agile Estimating and Planning”.

Discounting the role of Scrum Master?

In Scrum we have:

– The product owner (PO) is responsible on the project and involves the customer and other stakeholders in each iteration.
– PO along with the team estimate the user stories and the team pull what they can commit to.
– The team is self organized and sign-off for their tasks.
– The team are free to add or update tasks any time.
– Risks are impediment which are daily tracked.
– No formal management reporting is required.
– Many retrospectives are conducted not exceeding one hour and asking what went, what didn’t, what we should do. Continue reading