VisionScrum

Team: We don’t really have anything interesting to show tomorrow. We suggest to cancel the review for this sprint.

Scrum Master <insecurely insisting> If we’re doing scrum, we must show what we completed last sprint and at least try to deliver a good review. For example we could also be talking about our problems in the review and looking at options for the next sprint, right?

Team<irritated> We have no big problems to mention. We just don’t have anything interesting to show right now.  We just want to be pragmatic now & cancel the meeting since it doesn’t make sense right now. Please let us do our work!

You might be thinking: Right, the Scrum Master is suggesting to do Scrum by the Book  while the team is somehow resisting and drifting along with ScrumBut.

But what could be the context in today’s ubiquitous & poor scrum-adoptions? Consider for example these fairly typical scenarios:

• The product is designed outside of scrum. Specialized UX experts define it using prototypes. All of this takes place outside the team. For the typical review only non-empowered representatives show up and nod at seeing the prefabricated design now working in code.
  How should the team truly engage in reviews? Decisions have been made elsewhere. Why not cancel the review – just for tomorrow?
• An enterprise architecture department has devised a solution-path that entails large packages of work to be completed before the feature can be started. How should the team deliver customer-centric features now? For this reason the backlog items presented during the last review-meetings sounded so technical to stakeholders that they stopped showing up.Why not cancel the review – just for tomorrow?
• The team is hit by a large list of bugs. The underlying phased development process is still in place and the test-department has been testing the whole low quality product during last sprint. So now bugs are pouring in swamping any tangible story progress. The last two weeks were turned into a reactive nightmare rather than a skillfully planned sprint resulting in a demonstrable increment.Why not cancel the review – just for tomorrow?

And so on..

I bet you’ve seen it before: The organizational structure around the scrum-team is sucking the life out of their ability to scrum effectively.

Looking at the example scenarios above, what are organizational changes needed for scrum to thrive?

1. Separated product management & engineering units need to merge into one product development unit.
2. Specialized engineers need to become much more broadly tasked „product developers“.
3. Architecture needs to be integrated into the teams and transition from large descriptive to emergent code-based architecture.
4. Code ownership between different teams needs to become weak.
5. End 2 End testing departments need to be integrated into the teams and heavy investment in testautomation is needed.
6. Deployment and service-departments need to be integrated into the teams and deployment must be automated.

Power, careers and role-appraisals etc. are attached to the status-quo structure that needs to undergo change before scrum can really thrive.

Without deep organizational change accompanying the adoption of scrum, Scrum by the Book will remain to be a pain while ScrumBut will remain to be ineffective regarding the promise why it was started in the first place.

What else can be done?

Meet VisionScrum

Here’s the deal I try to promote with the term VisionScrum.

I think that it should be understood by an entire organization that chooses scrum :

Each and every time truly enacting scrum does not make sense in the given moment the Scrum Master(s) are tasked to raise an impediment that addresses the root cause. For determining the delta the scrum-guide is used (the book!). It’s constraints are powerful and super clear. It is pre-accepted by everyone in the organization, that this root-cause will be a pointer to some deeper change.

Scrum by the book should not be forced for today’s process. Rather the full Scrum Guide and all it’s implications should be the vision & rhythm for tomorrow’s change. Nobody should feel bad if they only do as much of scrum they can today. As long as the delta is conscious and effective change to be able to do it in the future is started today.

Sure the teams should try even today. This very tension is what’s providing the rhythm and transparency for change. But teams may not be left alone with this! And not blamed for doing only ScrumBut or finding excuses!

Putting in a coach or two is not enough.

Rather an impediments-process based on root causes and effectively connecting Scrum Masters to senior management must be set up using an adequately powerful framework for continuing deep organizational change.

Be prepared to address existing power structures! Let everyone know beforehand that this will happen! Educate everyone in scrum, it’s promise & purpose as well as it’s implications.

Use scrum as the detailed vision and rhythm for this change.

Set up an adequate framework for continuing deep organizational change to go along with adopting scrum in your organization

John Kotter offers these necessary ingredients (and in fact in sequence) for deep organizational change (in my words):

1. Sense of urgency: Yes, we will be the next Nokia if we don’t act this year.
   But organization Development and learning is continuously held at lower priority than product development? Efficiency and speed trump organizational learning?  Adaptiveness  – the org’s capability to respond to disruption – is  and should be the reason for introducing agile & scrum in the first place. If there is not urgency to get to this, VisionScrum is not for your org. Save your org a lot of money and stress. Don’t use scrum. Use other agile methods that are not as fierce at heart.
   IDEA for communicating this sense of urgency:
   Consider looking at past local losses (i.e. the loss of business) through the light of external disruption and local response.  Make everyone and their families familiar with these stories. Consider conceptual frameworks like the Cunefin Framework or the Stacey Matrix to provide a lens for everyone (i.e. use it in trainings) to look at these stories. Point out the implications of possible disruption to the wider community (not just employees).
2. Guiding coalition:  A committee of managers always does exist. But what about it’s alignment & trust? What about it’s diversity in respect to change? What about it’s commitment to the adoption of deeper scrum in the organization? Did the members actually read the scrum guide? Are they trained in the implications of truly applying scrum? What do they really know about agility? Consider
   Scrum Alliance’s Certified Agile Leadership (CAL) courses. One flavor of CAL I can recommend are the personally daring but strongly effective trust & alignment building courses based on temenos.
   Look into Scrum@Scale for advice on how to set up an effective Executive Action Team (EAT).
3. Clear & Published Vision: Using the scrum-guide somewhere near the vision of change is what I’m suggesting. Sure, scrum is not a purpose by itself, but if you want the learning development organization, scrum is probably the most challenging framework to point your organization to places that could&should be changed next. You could also try to develop such a list of criteria for change yourself. But it will be hard to beat the sharpness of the scrum-guide. 
   What is needed to publish this kind of vision? A few days training for the key practitioners (Scrum Masters and Product Owners) as a means of sharing the vision with all it’s implications? Clearly insufficient. What about product managers, testers, architects, managers, HR, etc.. All are deeply impacted by a real application of scrum. Instead consider repeated open space with the entire development organization (see Daniel Mezick’s Open Space Agility). Since there are implications on power-structures and current roles in the vision, it is essential to be clear to guarantee job safety and individual appreciation but not role safety. 
4. Enlisting of volunteers: If you plan to start small, volunteers should be doing it. It’s that simple. Not enough volunteers? Don’t start scrum. Start something else.
5. The removal of impediments: I’m not talking about the ScrumMasters getting a broken cable in the meeting-room replaced. The real impediments to scrum are organizational structures with implications on power. Good ScrumMasters can do a lot by doing good retros in the team etc. But after a a few weeks the organizational structures start becoming the most important thing to address. Avoid creating an atmosphere of coping here. Sure the team should take responsibility for what they can do and avoid getting into the habit of blaming „them up there“. But they do need hope, that even the hard structural impediments will be effectively & promptly addressed by senior management. They need feedback on management’s progress. Then they can be patient and focus on their sphere of control. Connect the ScrumMaster community with a direct communication process to the senior management.  Don’t let agile coaches or highly paid consultants get in the way and block out the ScrumMasters. Cut the slack. Much about Scrum@Scale is about impediment removal by the Executive Action Team as a response to ScrumMaster-Input.
6. The implementation and demonstration of quick wins – Be crystal clear about what is to be achieved by scrum in the first year. It’s not _cultural_ and it’s not to do with a lot of PostITs. It should be something more tangible like: „Get the current phased development project de-scoped and delivered on time and in blazing quality without wasting any effort by using empirical process control. Itemize the backlog and shorten lead time. Do this entirely driven by self-organizing X-functional teams“. Depending on your situation, you can do much more (e.g. achieve bug-free continuous delivery of features based on hypotheses validated in optimal user-facing experiments). But for most organizations this is not the first step. Be clear about expectations on the first business values that scrum is expected to produce and focus on those.  Consider using a strategy map or some other publicly visible and unavoidable piece of information.
7. The widening and acceleration of the practices to larger parts of the organization. Only scale when you’re really good in doing scrum in the smaller circle. Consider Tobias Mayer’s Scaling Agile Metaphor of a fish. First get rid of all the things you don’t want to eat about the fish, before moving on to feed it to your org..
8. Institutionalize the change – Promote agile supporters. Get rid of bonuses. Get the new roles payed well. Provide perspective to generalizing experts, probably by innovating  on your compensation model.

You can’t do ScrumByTheBook today. Nobody can. Doing ScrumBut is costing the industry a lot and frustrating the hell out of people.

Senior Managers in product development: Please start to view scrum as a detailed vision and rhythm for deep organizational change in product development. Please use VisionScrum over ScrumByTheBook or ScrumBut.

Please stop rolling out scrum to the team-level in isolation. It creates a world of pain and will not deliver the results justifying their cost! Rather start surrounding teams with an effective framework for deep organizational change! Options exist. Please use what’s out there.