A Change Management lens on Scrum & Agile adoption
A project or program makes the decision to "give Agile a go". They hire a Scrum Master and start the ceremonies. As far as people, process, tools and culture are concerned, this is a significant shift. What can be expected from this change?
I've found that the typical "velocity/enthusiasm curve" for a waterfall (or ad-hoc) team adopting agile (or any kind of process) looks like this:
The y-axis is the velocity + enthusiasm + productivity of the Scrum Team. This is a qualitative measure of the team's level of performance, taken from the velocity measurement, retros, the Scrum Master's assessment of the team, outstanding impediments.
The x axis is in general terms of sprints. This is deliberately not in days or weeks. It is the sprint and it's self-inspecting ceremonies (review, retro) that assist in making improvements. Thus changes to a team are best measured at a sprint-ly level.
Original velocity is the amount of velocity/enthusiasm/productivity originally possessed by the team before the change.
Scrum starts/Change uncertainty. As the change is first implemented, the first sprint can seem like pure chaos at the lowest level. Sprint planning meetings may be hijacked by parties who have an axe to grind - "why isn't X prioritised over Y? Why is item Z even in there?". Ceremonies from the standup to the review are filled with questions about the process, mistrust in the ceremonies, misunderstanding and deliberate misinterpretation. Even worse for the team's change are the people and parties who "switch off", buying out of the process. There's a whole month of blog articles about the actions that Scrum Masters can take to help alleviate this (coming soon!). Skipping that level of detail, and assuming there is a reasonably good Scrum Master directing retrospectives, the team as a whole generally "gets it", and the team starts seeing benefits.
Peak enthusiasm. "People are communicating better!" "I feel like I'm actually listened to!" Comments such as this are typical of this stage, between 2 and 3 sprints into the change. People in the team have seen what the benefits of people and interaction over process and tools are; the benefits that visibility, inspection and adaptation can provide. Thus, enthusiasm is high and the team has a chance to be highly empowered.
Change shock. Any change manager knows that people are resistant to change. Agile makes change an everyday occurrence; it normalises it as part of everyday activities and allows for it to a great degree. People working in waterfall are used to keeping things static, part of waterfall's "control and manage" mentality. Any change is analysed and rejected or incorporated. It's extra work. As the team realises that absolutely everything is subject to change in a managed manner, this causes fear and uncertainty.
Without a skilled Scrum Master, this drop can be very steep.
Change weariness. For people used to waterfall, there can be too much change. They may be pushed out of their comfort zone and into the unfamiliar (but very productive) learning zone, where they are forced to engage with others in changing both how the team (and they themselves) work. This is usually when a good Scrum Master gets very unpopular. As the agent of change, the Scrum Master is seen as the source of discomfort.
Make or break point. At this point, there may be "risks and issues" escalated directly with scrum, the Scrum Master, agile as a concept to leadership teams. How this happens depends on the organisation's commitment, the exact people involved and their positions and personalities, but is inevitable to some degree. At this point, some of the good aspects of scrum work against it - the highly visible impediments on the team are raised as "issues" and taken as signs that Agile or Scrum "won't work for us." You know, what applies to Google, Yahoo, Microsoft, Facebook, Adobe, Amazon, Nokia, Siemens, BBC, CNN, General Electric, Bank of America, Novell, Unisys... doesn't work for us. A good Scrum Master or Coach will have foreseen this and will have engaged executive management in understanding of Agile; and will have won their for continuing their support long before this point.
Moment of clarity . Once the team realises that Agile is here to stay and that change is now a reality; a good Scrum Master directs them to address the very issues that they have raised. The key here is that the team realises that no-one is responsible for their impediments, velocity and change management... but themselves.
The team has completed it's forming, storming, norming phase; and starts to perform. As the team takes responsibility of self-diagnosing impediments and addressing them, they gain a massive spike in productivity as they reach a performing stage.
The holy grail of this is the "self-organising" team, which we'll discuss in a subsequent post.