Out of all the different software development approaches that found their place under the Agile umbrella, Scrum has been by far the most successful, both in terms of adoption and the actual results achieved by teams and organizations working within this framework.
While the majority of teams that adopt Scrum grow to appreciate it and (dare we say?) like it, the fact remains that introducing Scrum to teams which never worked in it can be challenging.
Today, we will be looking at the biggest of those challenges and how to overcome them.
Disrupting the Status Quo
Most people do not like change. It is one of those eternal truths. Even when things are not that great, many people would rather leave them be than introduce change.
Software development teams are no different. Teams are perhaps even less welcoming to change – they develop their own little ecosystems where people know their place and role (either formal or informal) and where people have their way of doing things, both when it comes to work and when it comes to interpersonal relationships.
Introducing Scrum is a disruption. It is a major disruption, even for software development teams that have already adopted certain agile practices.
For one, it dismantles existing roles and positions. It does away with distinctions between senior and junior developers, at least formally. The development team is just that – a team. This stings for some people. Scrum’s emphasis on communication can also cause friction in teams that kept certain things under the wraps for whatever reason.
Scrum also introduces a certain structure to the way things are done and it is often unlike what teams already do. This can put pressure on some people and make them feel uncomfortable early on.
The only way to address this is to have long, frank conversations with the software development team instead of just dropping Scrum on them. Lead with the beneficial impact Scrum will have on their team and their work but never sugarcoat anything.
Be honest. There is a lot going for Scrum and sticking to the facts is usually enough to convince people to give it an honest try.
Emphasis on Transparency
Scrum implements an empirical process in order to make the teams as productive and as forward-moving as possible. The three pillars of empiricism that make this possible are Transparency, Inspection and Adaptation. Logically speaking, it all starts with transparency, as no real inspection and adaptation is possible without transparency.
The challenge here is the level of transparency that Scrum demands – total. In Scrum, everything should be absolutely, 100% transparent to any and all stakeholders. Everyone knows what everyone else is doing, the state of the product is available for inspection every step of the way and all doubts, problems and even conflicts are brought to the light.
Of course, all of this is aimed at building trust and improving the way in which the team works and grows together.
Unfortunately, some people do not see it that way. Some of them may feel micromanaged. Others may feel that the only point of all this transparency is to push them to overwork. Some may feel that they will be judged or admonished for not being as good as some other team members.
There may also be people who will accept the concept of transparency, but who will look for ways to keep certain stuff to themselves, completely missing the point.
The best way to approach this is to be very clear about what the point of all this transparency is. It is about making the team better, adapting to problems more readily and actually reducing the pressure on individual team members by putting everything out in the open. You also need to stay alert and talk to and encourage people who seem particularly dishevelled by this emphasis on transparency.
Intricacies of the Scrum Framework
You will often hear or read about software development teams or companies that have introduced some Scrum elements and practices in their day-to-day operations. Some of those experiences will be positive, but you are most likely to hear that they gave up on most of them relatively soon.
The reason for this is that the Scrum framework is an intricate structure where every element supports and strengthens another.
Take Sprint Planning as an example. A good sprint planning meeting will require a well-prioritized, dynamic Product Backlog (nurtured by a vigilant Product Owner), active development team members and a Scrum Master who will together take advantage of the data and the insights from the previous Sprint Reviews and Retrospectives to best estimate and plan the upcoming Sprint.
For long-time practitioners of Scrum, this interconnectedness seems logical and organic. For someone new to Scrum, this is not a given. Some people will see all these roles, events, artifacts and underlying concepts as unnecessarily complicated. Some people may find certain elements of Scrum particularly annoying, wasteful or even outright harmful.
There are a few things you can do to dispel these misconceptions and ensure the team understands the interactions that make Scrum such a positive impact on team dynamics and the quality of work that is delivered.
A good way to start is to provide some learning material for the team to go through in advance. Scrum.org and the Scrum Alliance are great places to start. It would also be a good idea to hold a few informal classes and meetings where you will share your insights into Scrum and answer any questions your team might have (it is possible they will have plenty). In case you plan on using Scrum software, letting your team get acquainted with it in advance can also help them get familiar with the intricacies of Scrum, besides providing training they will find useful down the line.
Some people find it helpful to see things in practice.
Iterative Development Mindset
One of the core ideas of Scrum is to encourage and support software development teams in developing usable software in small iterations that continuously add functionalities and value to the end product. In other words, iterative development is one of the cornerstones of successful Scrum practice.
Despite the fact that Agile software development has been around for decades, many developers and teams are still not on board with iterative development, despite its many advantages – earlier feedback and detection of issues, better adaptability to changing requirements, quicker delivery of business value, and so on.
You do not have to look far to find developers and entire teams that spend huge amounts of time on pixel-perfect features or entire projects only to find out they are too complex, useless for users and do not add any value. In the vast majority of cases, such developers and teams have the absolute best intentions, but the traditional way of doing things simply does not agree with the world we live in and the realities of the modern software development industry.
When such teams are faced with Scrum’s absolute insistence on small iterations and continuous delivery, it can take a while to change this mindset. They might feel like this approach is too haphazard and that planning and design are being sacrificed for speed.
Once again, you will want to hear them out, acknowledge their anxieties and try to cooly and factually explain why small iterations are a more efficient and actually safer way to go in the modern world.
The good news is that it does not take too long for most developers to recognize the positive effects of iterative development. Once they realize that they spent only two weeks on an early version of feature that ended up rejected instead of 4 months trying to perfect every line of code, they will be 100% on board.
Closing Word
Introducing Scrum to a software development team that never worked within the framework is definitely challenging and you might say it asks a lot from a team. That being said, once you meet those challenges head on and find ways to ease people’s minds, Scrum will show its full potential.
There are good reasons why Scrum turned 21 this year and why it is the first thing that comes to mind when you mention Agile to developers.
