In your organization, some problems seem to recur, they are difficult to fix using the tools, tricks and practices you developed over the years as a manager. Maybe this problem is different and the perspective of an expert-outsider might help?

At Agilix, we regularly get asked by companies “to discuss some challenges with Scrum”. This is a great compliment for us and it is exciting to submerge into these unknown worlds, being totally blank, without prejudice and mandate; simply bringing knowledge and experience. It feels like being a “Flying doctor”, and yes, we love it!

Let me tell you a bit more how the “flying Scrum doctor” operates….

Intake

The first conversation a Scrum doctor usually has is a one on one with the manager. She starts with giving the context of the problem. It’s time to listen and try to build a mind-map of the problems, company structure, their product and customers, the teams, processes, solutions they tried before but did not work, etc. Towards the end of the conversation questions are asked to verify stuff, because we need to validate the collected data. To get a clearer picture of the problem, data has to be collected from the people in the teams and from management above the hiring manager.

Diagnose

We need to talk to lots of people, remembering their names and roles, smiling, listening carefully, trying to store everything that can be captured. Especially the things that are not so obvious; like the people not talking and nonverbal communication. It’s a bit like you are the new employee and you must meet the whole company at your first day at work. The difference is that we are on a mission: There is a pain that needs to be diagnosed and these people need help to find a cure. My personal preference is to work my way through the organization bottom-up, i.e. I want to talk to the teams first.

The problems we investigate are always systemic, if not, they would have been solved easily by the hiring manager. This also implies the intervention will probably not be found in the area where the manager thinks the problem lies. We observe the company as if it were a system, a living organism and try to understand what is really going on. Therefore, we need to collect input from different angles and layers across organizational boundaries and share all the things we learn and ask a lot of open questions. By doing this, people discover themselves how their system works and which part they play to keep the system in its current state. With the right people communicating at the right level (management and team representatives), good insights emerge and decisions to start or stop doing things to intervene in the system are easily taken. A condition for this approach to work is that all participants can communicate in a safe and transparent way. If not, we would not be addressing the true root causes.

Preparing the teams

Once an intervention has been identified and agreed we need to inform the teams and get them on board for a change. We all know from experience that change is difficult. Well is it? Really? I have learned it is not. Think about it: Did you ever move? Or did your get a new haircut? That is change too, and you did not mind at all! But if your wife tells you you must change your hairdo, it becomes a whole different ball game. Conclusion: Change is not difficult at all as long as it is voluntary.

Therefore, we need to get the change emerging from within. For this we need to ensure everybody gets the space and time to discover the system dynamics themselves and to contribute to the solution. Voluntary participation creates ownership of the change. This empowerment increases the chances of a successful change. We get all people involved by organising one or more discovery sessions in which teams go through the same motions we experienced when unraveling this mystery ourselves.

Preparing management

Some managers automatically assume that once a solution has been discovered, they need to communicate it to the teams. We need to ensure this knee-jerk reaction is gently suppressed. In other cases, management fears that the teams will not come up with good solutions and team empowerment is seen as a possible threat. In such cases it requires persuading management and informal leaders to agree on the principle of voluntary change. They need to learn that the solution they crafted so far will get better when it is discussed with all people involved.

Treatment

To solidify empowerment, we want to find people to facilitate the discovery sessions with the teams. These are not the managers, but volunteers from the teams (might be the informal leaders). In order to facilitate well, they need to know what the key principles are of the solution, for example: more flexibility, fulfilling work, learning, etc. By understanding the key principles, they will be able to guide discussions that will emerge during the discovery session(s). The details of the final solution less important than everybody understanding what is needed to fix the problem.

Conclusion

When you try to unravel and solve complex systemic problems, gather lots of data, be curious, cut across organizational boundaries. Understanding that problems are systemic and therefore that there are multiple root causes is essential. Involve all people that appear to be related to the problem and make those who are in power aware of their possible contribution to both the problem and the solution. This awareness is what people lack. Change is easy as long as it is voluntary, so engage people in the change by offering them the opportunity to discover how their system works. Remember to love the problem, not the solution. The solution will become better when more people contribute to constructing it.

Besides coaching and writing blogs, I also teach Scrum. Maybe you want to join my upcoming PSM-2 class.

The 2019 Scrum Master Trends Report by scrum.org and the State of Agile 2018 shows 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.

iterations towards professional scrum

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.

I also provide training. Find out more about our PSM-I or PSM-II trainings.