Taking Organizational Improvement with Scrum Seriously

(Presented as Part 4 in the Scrum Alone is Not Enough series, and accompanied by this worked example of Organizational Improvement in WorldsSmallestOnlineBookstore.)

If Agile change initiatives don’t produce at least the doubling in productivity that is possible, it’s often because Scrum is used as a wrapper around the current state of work, but the organization has failed to introduce the fundamental changes that Scrum should inspire.

Some managers don’t understand the principles that underlie Scrum: self-organization, the importance of delivering working software every sprint, the impact of multi-tasking, etc. They fail to recognize that Scrum isn’t about improving one team in isolation and, as a result, they can act in contradiction to the principles.

Other managers have teams that have established Portfolio Kanban Boards but they don’t review the boards with their teams. Management hears about problems, but lacks proper understanding of their context. Lacking context, management fails to act.

Either way, people in the organization begin to feel that Scrum is just being wrapped around the existing state and that nothing changes. They feel that Scrum is only being paid lip service.

Scrum isn’t intended to work this way. Scrum is a tool to optimize the whole organization.

From the 2015 State of Scrum Report:

Interestingly, 71% also believe that using Scrum causes tension with other parts of the organization not using Scrum.

We expect some tension to be a perennial challenge, just as with any organizational change. After all, Scrum requires a shift in an organization’s culture.

… though senior management support is considered critical in Scrum adoption, only 7% of respondents reported that as visible in their organizations.

Solving these problems requires Senior Management to be involved in solving issues and obstacles on an organizational level.

One approach is to create a Change (or “Improvement”) Management Team to help coach the Leaders through the transition, to migrate toward improving to empower, and to assist those who work for their groups. This should involve a Scrum (or Kanban) like approach to organize themselves and do the work.  To minimize confusion in this article, we will call this team the “Org Team” and regular Scrum Teams “Development Teams”.

Goal

Create an Org Team whose focus is working to understand what obstacles may need to be removed or mitigated to help the organization as a whole, regardless of what level within the organization that may be. Their aim should be to:

• help both Management and the whole organization deeply understand what Scrum is and how it instigates change throughout the organization;
• help Management see the impediments their teams face on a regular basis;
• help Management improve communication with their doers;
• focus on the Strategic Goals, not just the tactical needs of the individual “Development Teams”; (See the upcoming article on defining your Organizational Goals and helping teams align with that.)
• and solve problems systemically and not just the surface issue.

Membership

Select the Org Team ^[1] with an eye to personnel who can bring about effective change. Consider:

• knowledge of the internal challenges as well as what is happening outside the company;
• knowledge of how the company is actually working – not the organizational structure or policies but what is really happening on the ground;
• sufficient influence and power, so that once decisions are made, they can be implemented without much more debate.

In many organizations this will mean the Org Team will be comprised of Directors or Vice Presidents; in smaller organizations this will include the CEO/President.

Some of these people will also be part of the Portfolio Management Group. It’s also important to look beyond the existing Management team to ensure we get greater diversity of thought, and that existing approaches are challenged.

Since we’re going to utilize a Scrum-like approach to self-organize the Org Team, an individual who has a deep understanding of the organizational problems that the development teams face should be chosen to play Product Owner. In many cases this will be a Scrum Coach or an individual team’s ScrumMaster. The person needs a deep enough understanding of the issues to help bring clarity and provide a sense of priority.

For the ScrumMaster, you should look to someone who has a solid understanding of Scrum, and who can facilitate the Org Team sufficiently to allow things to happen, but also has sufficient influence to help their executive peers achieve the commitments. It is critical that this person be an employee and not an outside consultant. We can’t afford to have the knowledge that is grown here leave when a coaching/consulting engagement ends.

The remaining team members, unlike a normal Scrum Team, will not be full time, however they must dedicate a significant amount of effort each week to resolving issues that are harming their teams.

Working Group vs Real Teams – this needs to behave more like a real team, which implies a core full time membership

Mechanics

Run the Org Team with a Scrum-like approach where they organize themselves and do the work.

Product Backlog – aka Organizational Improvement Queue. Instead of a list of User Stories, the queue will consist of a list of changes or improvements. Like User Stories, it’s best if the items state the underlying problem rather than the solution. When the statements stay focused on the problem and not the solution, we keep the door open to more creative ideas than previously imagined.

The Improvement Queue must be public and any team and their members should be able to add an item to it. In organizations where many of the teams are in the same place, it is best to maintain the queue next to the Portfolio Kanban Board, giving everyone a place to go and see a good summary of the state of the organization.

All of a good Product Owner’s standard prioritization tricks will come in handy here: Buy a Feature, Business Value Poker, Impact Mapping, and more. The key to all of these activities is to ensure that they involve stakeholders: Development Team Members, Team ScrumMasters, and others who are affected by the changes.

Also, with the queue being public, team members can see why their current problem – while important to them – may not be the highest priority for the whole organization.

Sprint Length – 2 to 4 weeks. Shorter is better as it gives more opportunity to adapt to the changing needs of the teams and more opportunity to demonstrate small wins.

Sprint Planning – At the beginning of every Sprint, the Organization Team sit down and, just as with Development Teams, it works well to break planning into two parts:

1. Goal Setting (which problems do we commit to resolving that Sprint)
2. Task Breakdown (team members take a crack at potential solutions to get a rough idea of what they need to do to solve the problems)

Who: Organization Team Members and stakeholders (i.e. Development Team Members) whose problems are at the top of the Queue.

Product Backlog/Organizational Queue Refinement ^[2] – (the Org Team version of Product Backlog)

Just as effective Development Teams refine their Product Backlog, the Org Team does the same at least once per sprint for a couple of hours at a time, to ensure the Organizational Improvement Queue is ready in detail for the next couple of Sprints and to ensure that they have a sufficient understanding of the work in the medium term (3+ Sprints).

The recommended focus is on Organizational Challenges rather than Stories, but the outline remains the same. Also, I have not found the basic planning poker estimation to be as effective in this context. Our Organizational Team needs to meet a group of ScrumMasters and members from Development Teams to refine their collective understanding of the problems that need to be solved. This will be a time-consuming exercise. Some clients have short-changed this, and I’ve seen them waste considerable time solving the wrong problem.

In addition, as part of the Queue Refinement Session, the Organization Team should review the Portfolio Kanban board to see if there are issues that they can help address easily.

It’s important to note that this is not a forum for Senior Management to complain about their teams or to hold the team’s feet to the fire. In general, Development Teams want to be more productive. They want to hit their goals in terms of delivering greater value to the customer.

This is a mechanism to give management an opportunity to be true leaders by resolving the issues that are getting in the way of their teams.

Daily Scrum – Given the part-time membership of this team, having daily meetings is likely to be too frequent. Instead, they should meet 2-3 times a week. With many clients we’ve done this just before any of the team level Daily Scrums, then Org Team attendees can go on to share the progress towards resolving their issues with their teams.

Along with the usual goals of Daily Scrum (prepare for collaboration, check if we’re on target, and sense impediments), there is an important additional goal: help all Development Team members see that change is coming even when it is slow.

It is most effective if this event is held in a public place, often in front of the Portfolio Kanban board.

Who: Organization Team members and representatives of Development Teams.

Sprint Review – Development Teams normally demonstrate working software to their stakeholders. In this case, the Org Team’s demonstrable product is solutions to organizational problems. Where practical, actually showing the solution is best. This activity is the primary means to let people know how problems have been solved and how this will make their world better, so it needs to be fun and engaging.

In addition to the regular Sprint Review, the Org Team needs to share their successes and changes through whatever channels they can – internal email newsletters, posters on walls, town hall meetings etc.

Who: Organization Team Members and a large cross section of the Development Teams.

Tracking – We can either maintain a separate Sprint Backlog or include these as part of the Portfolio Kanban board.

Retrospective – While all of the other activities need to be public, the retrospective needs to be internal to the Organizational Team so they can be open and honest about how they’re using Scrum and how they’re working together. Like all Scrum Teams, the improvements that the Org Improvement Teams agree to make in their own should be made public.

Conclusion

From the 2015 State of Scrum Report: “Respondents report that senior management sponsorship and support is far and away the most important factor in adopting Scrum.”

To succeed

• Small Wins – early on it’s important to show that this group isn’t just another committee that doesn’t make real change. Find small things that can be improved and do them.
• Communicate – use the Sprint Reviews and Daily Scrums as a opportunity to share successes and help people know what has happened on their behalf.
• Show how we’ve engaged Management to constantly review Portfolio Board, to understand Scrum, and to be involved in solving the problems that Scrum finds.
• Build on the previous successes.
• Tie changes back to the bigger reason that the organization is undertaking the change (usually Quality or Time to Market).

Risks

• Where I’ve seen this fall apart – when Management feels this is special and not part of their **work**. To succeed, it is important that this becomes part of their normal work. Consider bringing all Management work through this group.
• Not closely tied to vision or strategy.
• No real urgency – See Jon Kotter – “It all Starts with a Sense of Urgency” (pdf).
• Not enough energy from Management to solve the problems revealed. Will signal to the teams that Scrum is fine at the team level, but the organization doesn’t believe in real change.
• Tactical and not Systemic focus will wear out the people who are involved in the change without making the real changes needed.
• Without sufficient backing and support for real change, this just turns into a gripes forum.
• Wrong people in the room – usually people without enough organizational heft and skill.
• Lack of leadership skills and Change Management Experience.

Alternatives: Some people take the same approach except the Org Improvement Team uses Kanban instead of Scrum. Personally, I prefer them to use the same approach as the majority of their development teams, but whether they use Scrum or Kanban is less important than clear and visible progress towards solving their organizational impediments.

Scrum requires real change from an organization at all levels, not just the team level. This pattern describes one way of ensuring that the executives are involved, that this becomes the core of their work, and that they truly understand Scrum. (See this in action though the case study example.)

Integral to doing this well is an approach to Visualizing all the work items (see Portfolio Kanban – part 1, part 2) and Managing the work itself (see Portfolio Management – part 1, part 2).

~

References: https://www.forbes.com/sites/stevedenning/2015/07/22/how-to-make-the-whole-organization-agile/

My thanks to Zuzi Sochova for their feedback in writing this.

---