The ways that Scrum can fail
Is your Scrum implementation failing? We could know the reason why. Read on as we explore this different kind of agile software development framework.
The advantages of Scrum are definitely the main attributing factors to its popularity: the quick delivery of products, the promotion of transparency and better workforce management to name a few. Of course, these advantages are all dependent on the successful implementation of Scrum and how committed the team is to the process.
For many companies, Scrum is beneficial for customers, the organisation and management alike. But what if it fails? What if the framework can’t support the business? What if there’s too many chickens and not enough pigs?
Other than the fact that these labels have since been removed from the official Scrum guide, the problem with roles won’t be the only reason why your Scrum implementation is doomed. Simply sending a few staff project managers to Scrum Master training is insufficient to foster the degree of change required to succeed.
Rather than applaud the achievements of Scrum, learning from its failures can be a good way to improve your own understanding and implementation of the process. With failure, we are presented with an opportunity to learn and improve. Assuming as a reader that you already know the basics, lets get into five ways that Scrum can break down and flounder.
Our list of defeat
- Resistance to reorganisation
First of all, agile is not something that we can implement, but is a characteristic that we try to achieve. This means that we do not “do agile”, but we practice techniques that help us become agile, that give us the ability to become adaptable and resourceful.
Seeing as this methodology requires a change in the way people think, approach and manage teams and projects, your implementation may fall short too soon due to unwilling parties at the middle management and executive levels. Even members of the Scrum team itself can be antagonistic towards the process.
For established organizations, Scrum can be incredibly hard to deploy. Scrum works when an organization is open to change and while disruption can be good, it’s also extremely risky. This is where the resistance lies.
Jimmy Bogard believes that Scrum implementation can work if the organisation finds the transition easy. If it’s easy, then it will work for you. However, if its seen as difficult to adopt, then Bogard claims that “you’re using a process to force organizational change, and that’s a rather lousy, failure-prone way to do it.”
SEE ALSO: Agile Product Management with Scrum
- Lack of leadership
Sure, with Scrum, your team is self-managed. But at the end of the day, the project still requires strong leadership in order to get it’s development game on point. A Scrum team needs sufficient support and guidance to work, so even though there’s a self-organisation element in the equation, support from the executive level is paramount in achieving desired results.
The role of Scrum Master doesn’t translate to ‘Overlord of the Project’; a novice Scrum Master may try to manage the team instead of leading, coaching, and guiding them. A command-and-control management style is antithetical to Scrum and other agile methods, where a more collaborative approach is best. However, some kind of leadership, or coaching, is still required to make sure the team are well coordinated and that impediments to the project are taken care of.
The better the level of engagement you get from all stakeholders in the project, the better off your project will be, and it’s the Scrum Master’s job to adequately guide and educate the team rather than administer and control.
- Blaming the process
Scrum exists merely as a framework – it’s not the magic wand that is destined to solve your production problems. The thing about Scrum is it’s tendency to highlight issues fast. The issue mightn’t be with the process, but with the project itself, which could mean discovering that what you’re trying to build is unclear, overambitious and unrealistic.
These scenarios often result in the users blaming Scrum for the project failure, when in fact, it’s done it’s job. Henrik Kniberg over on Crisp’s Blog has commented on how easy it can be to confuse project success/failure with process success/failure.
As Kniberg says, Scrum fails when it’s misapplied. You don’t need to get it right from the start, but you do need to continuously inspect and adapt the process. Organisations are often too quick to dismiss the process as flawed due to a project’s inability to gain traction. However, one significant advantage of Scrum is that it reveals problems at quite an early stage in the development process, which can unfortunately be misinterpreted as a breakdown in the framework.
- The definition of ‘done’
The rules of Scrum are somewhat considered as gospel to those who implement it. Mike Cottmeyer suggested that once Scrum started to go mainstream, all people seemed to remember were the rules. They forgot the meaning behind the rules. The purpose of the methodology is to focus on maximizing the team’s ability to deliver quickly and respond to changes better, however, there’s a lot of teams being caught up in the act of “doing” Scrum.
While Cottmeyer believes the rules are important, the problem for him is cultural, or societal, in nature:
I say this is a societal problem because I think people do this in lots of different areas… not just work… not just agile. Think about all the areas of your life where folks are just going through the motions without any real understanding of what they are trying to accomplish.
This idea of ‘going through the motions’ incorrectly glorifies the Scrum process over the end result of its implementation, which is essentially to deliver the product. Knowing the short term goals of the team isn’t enough – as Jeff Sutherland states, the secret to working software is to complete testing inside the Sprint. If your testing practices aren’t tip-top, your teams are probably struggling, your clients are probably frustrated, and you most likely don’t know when the product will ship.
Exit-criteria should be beefed up by testing to save the team from going through another three Sprints in order to deliver.
SEE ALSO: Daily Scrums explained
- The client’s acceptance
The final hurdle that your Scrum implementation needs to overcome is the matter of client acceptance or misunderstanding. It’s important that the client is not only aware of what you are doing but that they embrace it. A client expecting to see detailed documentation but is instead given a prototype will be disappointed, even if that disappointment feels unjustified to your team who have worked hard to produce said product.
Your client needs to accept the Scrum process and become agile as well. Typically, most clients want to hear the following assessment at the beginning of the project:
- How much it will cost
- What the product will look like
- When it will be done
For the client, these approximations sound completely reasonable, but this approach is incompatible with agile frameworks. Essentially, it’s all about having a shared understanding around what the team are going to build, with a little education about how this will take place.
Agile stresses agility – responsiveness to change and uncertainty – and because of that the expectation is faster production. However, it requires a different mindset and can make high-level planning more difficult, which is traditionally what a majority of clients and companies expect.
Scrum isn’t designed to be the king of methodologies, but its implementation can help to improve the production and cost of working software, if done right. Organisations who wish to implement Scrum need to remember that taking the time to reprioritise is important.
The failures outlined above are meant to represent the general areas of contention when Scrum breaks down. Of course, each area has its own niched issues and we didn’t even approach the question of the backlog, but Cottmeyer’s assessment is a great place to start for backlog-related questions.
Just resist the urge to implement the half-arsed agile manifesto.