The 2019 Scrum Master Trends Report by Scrum.org and Age of Product and the State of Agile 2018 show numbers that provide insight in the maturity of agile adoptions. More than 80% of the Scrum Masters (respondents) claim their organization is in or below a “still maturing” level. With Scrum being the industry standard (at least in Western Europe it is), these numbers are surprising.
I have seen agile transitions in many organizations and I have been through numerous learning experiences myself, deepening my understanding of Scrum and Agile. My observations can help others in their journey of maturing Scrum and make learning easier. I want to share my observations of each of these phases so that you can learn from what I did to overcome the challenges related to those situations.
Pre-Scrum Waterfall
Newly trained Agilists typically are assigned to join an existing project team by means of an experiment. Agilists tend to give classical project management a bad name and see project management exerting command and control in countless efforts trying to predict the future and meet deadlines using RFP’s, PSA’s, BOM’s, BDUF’s RFC’s and the likes.
Seasoned PM’s know their business and rest assured that this agile fad will be mitigated. The first steps for novice Scrum Masters in their new position makes them immediately aware that this is a tough profession. They soon come to realize they learned the Scrum guide, but do not grasp the essentials to show the benefits of agile in a discussion with a senior PM. Most people in the team are unhappy and try to switch projects, but not the Scrum Master. The Scrum Master shows courage by revealing project problems using non-compromising transparency.
It needs to be said that the Waterfall approach works well for smaller projects with clear requirements. The separation of phases and clear boundaries with deliverables makes projects relatively easy to manage. However, we discover that predictive planning is much like gambling and that empiricism could bring more opportunities for mitigating risk. We also discover that people leave the company or report sick if you overuse them.
Dynamics I observe in this phase :
- Newly trained Scrum Masters have difficulties mapping the Scrum Guide to their real-life situation and are unable to convey its values and principles.
- There is a growing awareness that some change is required to improve project success rates.
- Early Scrum Masters courageously use transparency to create this awareness.
Starting with Early Scrum
Following initial experiments, organizations get started with a real Scrum team. We are hidden away in a “pocket” in the IT department. A Product Owner will provide requirements and an agile-minded team member will do to cover the Scrum Master activities. We enthusiastically initiate crazy stuff like meeting while standing up and putting lots of stickies everywhere. Whatever it is we do, from the outside it looks like the majority is enjoying this new and more playful approach for software development.
After a while, the tester starts complaining there is no work for him at the start, and too much work towards the end of the sprint, i.e. Scrum is mini waterfall. Once bugs come raining down we learn that DONE software does not run on 'localhost'. Agile engineering practices are required to keep up with the speed of Sprint cycles. When repeating problems continue to pop up during the retrospectives we start to understand that we are responsible for improving ourselves.
Scrum Masters focus on themselves and the team while doing Scrum by the book. In general everybody on the team is happy with the new approach. The Sprints offer a recurring time-box of relative tranquillity in which the team can focus on delivering software.
In the stages of early Scrum I see
- Scrum Masters focus on Team dynamics and literally follow the Scrum guide.
- Small pocket experiments lead to optimism and small successes.
- Early Scrum implementations tend to be mini-waterfall approaches because we do not yet understand cross functionality.
Do you recognize these dynamics too?
Growing by Scaling Scrum
We deliver software more often and IT-people are happier now. Scrum proved it works! IT-management sees the benefits of the new framework in comparison to waterfall and transforms the IT-department by copy-pasting the existing functional and component teams as Scrum-teams across R&D.
At this stage, we (Scrum Masters) understand Scrum in general but we do not master Scrum. We know that Scrum is the way forward, but “knowing it is true” without being able to explain is believing instead of knowing.
In our ignorance and under pressure to prove Scrum really works, we choose the wrong optimization goals by 'police-ing' for the events to happen. Our events become more fun doing planning with gummi-bears in search of the perfect estimation. Scrum Masters build management dashboards to monitor (individual) resource usage based on velocity and capacity. We notice that we are impeded by other teams most of the time. Retros become a bore because impediments are beyond the span of control of our team. Development teams discover self-organization and move towards ‘Scrum-but’ and start to tailor Scrum in detriment of the Scrum principles: skip retro’s in favor of coding (because they don’t work), skip dailies (because ‘we align all day long’), skip sprint review (when there is nothing to show), stretch the Sprint (to make the release). Scrum Masters need to discover how this evolution breaks Scrum and how to turn the tide.
Scrum shows mercilessly that there is a problem with the way multiple teams interact while trying to deliver valuable software or at least something (close to) done. This discovery has a tampering effect on our early optimism. Team empowerment motivates people and brings a bottom-up change. However, we also need to discover how misinterpreting team empowerment can impede empirical process control.
Dynamics commonly seen in this stage are:
- Focus on non-valuable optimization goals in attempts to obtain "perfect Scrum".
- Scrum is seen as a best practices framework.
- Teams are deviating from the Scrum principles and create "scrum-but".
- Lack of cross-team alignment.
If you recognize these dynamics, have a look at the picture above to learn the discoveries you can do in this phase to improve your Scrum.
Stalling
Unfortunately, we are not immediately rewarded after learning teams need to collaborate to deliver customer value. This is because most companies fight complexity by adding complexity. To regain control and to make teams deliver customer value, management adds coordination roles and creates specialized departments to assemble component deliveries to done. We can see "water-Scrum-fall" emerging with build, integrate and release structures. This movement clashes with the insight we need to change our organizational setup from component to feature teams in order to make it easier to deliver customer value.
In the meanwhile, management merges teams into Dev-Ops, mainly for cost saving purposes. As a result, the number of skills required to be present in a Scrum Team increases. Team members who invested time and money in a specialist career now find out that agile requires them to become 'T-shaped' or even ‘comb-shaped’. It does not help that our yearly HR performance review still requires to increase seniority in a single skill. Management uses the tools they know have worked before to fix the stalling agile results: command and control with deadline pressure on the teams. Team composition changes frequently, keeping the people in constant storming team-formation state.
The Scrum framework fundamental principles crumble under this pressure. Agility gets lost in committing at Sprint Planning, sacrificing quality to make the Sprint, blaming in the Sprint Review and complaining in the Sprint Retrospective. Slowly, people start to become allergic to Scrum and agile.
Scrum Masters reverting to teaching the framework by flashing out beautifully drawn posters raise resistance. We need to focus beyond the teams on the organizational impediments, because there lie the root causes that stop us from moving forward. Managers need to decide to abandon Scrum or to persevere by applying a proper scaling framework and by learning to appreciate the deep impact of the Scrum values. The latter teaching that the whole company, management included, needs to undergo a cultural change to make this agile thing work.
Dynamics I see in the Stalling stage are:
- Increased management pressure on teams to deliver value.
- Anti-Scrum sentiment in teams.
- Misalignment of the Scrum teams with the rest of the organization becomes a problem.
- Lots of 'doing agile' instead of 'being agile'.
Do you observe these dynamics? I suggest focusing on Scrum values to create an agile culture.
Maturity
When the agile culture-switch has settled in the whole organization, we all understand how the parts of our organization interact as a system. Management practices servant leadership, and teams self organize or self manage to create product. We are able to engage in co-creation collaborations with customers and partners.
At this stage, Scrum will continue to reveal new challenges to overcome, only now we see them emerge outside of the organizational boundaries: Supplier-, partner-, and customer-interactions become impediments. This is because external parties that desire to collaborate with us need to find new ways to connect with us now that our knowledge is no longer concentrated in departments but spread across many teams. We will continue to further discover better ways to uphold the key principles that underpin Scrum and possibly evolve towards a structure or platform where frameworks are no longer needed.
End note
In this overview of iterations towards Scrum maturity I tried to describe the characteristics and challenges to overcome in each stage. This overview might help you as a Scrum Master or leader to assess your current situation and show you a direction in which you might find a solution for the problems you are facing implementing Scrum.
Training?
If you are looking to broaden your knowledge, consider attending one of my PSM-I or PSM-II trainings with Agilix.