Why Scrum Works

10 Rules to agility success

Whenever you think of agile, the first word that comes up for most people is Scrum. Born in the late 80’s and formalized in 1995, Scrum was the fore-runner of the Agile Manifesto, which was also co-created with the founders of Scrum.

It’s thus natural that when you talk about agile, Scrum comes up. Yet, more often than not, I wonder whether people realize the perfection of this framework and why it works so well. I keep hearing the same complaints and the same questions when new organizations decide to embark on an agile transformation.

The most common of these complaints are asking for a manual or book, as the lightweight 17 page Scrum Guide simply doesn’t contain enough information to succeed. With so many books on the subject to choose from, for a newbie, this is a huge challenge.

And that is exactly the beauty of agile and Scrum, and each time I hear this complaint I think to myself that it’s exactly the point! As the whole methodology is one of learning rather than doing. It’s about creating a learning organization, one who is able to make good judgement calls. Having a manual would be way too restrictive, and it would contradict the essence of the methodology.

“Simplicity is the ultimate sophistication.” — Clare Boothe Luce

What makes Scrum most enticing to me, is it’s simplicity. It’s a lightweight 17 pages consolidating everything you need for a successful agile implementation. The Scrum Guide starts off with in the this in the definition of Scrum,

“…it’s simple to understand, it’s difficult to master…”

Yet, few organizations seem to get it right. Indeed difficult to master if so many people struggle with the same issue.

But why are they struggling?

The most common complaint for new implementations that I’ve seen to date is the lack of reference guides on how to implement Scrum. The Scrum guide itself doesn’t contain enough flesh to be used as a manual for implementation without a coach, yet, if you do invest in an agile coach to help you with the transition, you can either get lucky by getting one of the many brilliant coaches out there, or not, as the industry is littered with certifications focused only on the technical skills.

Selecting your agile coach isn’t as easy and straightforward as choosing for example a team lead or a project manager. What you are looking for is not technical skills (although those are important too), but an agile mindset.

Once you understand why Scrum works so well, transitioning becomes much easier, giving more options and room for play with the implementation. Thus, improving your chances to succeed substantially.

A Scrum Mindset Cheat Sheet

At the heart of agile is creating a culture of learning, thus I embarked on a year-long education-focused gap-year to experiment with what makes learning effective, easy, and fun.

I realized that Scrum already incorporate all these things, which is why it works so well, with the only exception that it doesn’t provide options to keep it interesting. It only contains one sample of each of the required methods, and people follow these blindly until they start getting bored with it.

Which brings me to crucial element number one.

Rule # 1 Keep it interesting

Scrum and it’s practices works so well, because it’s like a breath of fresh air in the organization if you’re used to waterfall. You’re doing exactly the same things as before, but you’re doing it slightly, or sometimes very, different.

You’re still writing requirements, but they’re more fun and have more context because they’re done in a different manner. Standup meetings suddenly is a relief from the boring round table sessions, sticky-notes are colorful and grabs attention.

Trying to engage a bunch of rowdy 8 year’s taught me probably the most important rule of education.

If you don’t have their attention, and if they’re not relaxed, you’re wasting your time.

Which also nicely leads to the second crucial element of a successful business, let alone agile transition.

Rule #2 Provide a safe environment

One of the main goals of scrum is to have autonomous teams, teams who report to each other, not to a Scrum Master or a manager.

There are many reasons why this is extremely important, but mostly, if you’re not relaxed and confident to speak up in a team setting, you’re likely to make mistakes.

In an autonomous team, there is no pressure to impress your boss to get the promotion or raise that you want, and there is much less risk of being told that your idea is unwelcome or crazy. If everyone is on the same hierarchical level, it immediately creates a safe environment where each individual’s input is as important and valued as it’s peer.

In a safe environment you are relaxed, and when you’re relaxed you can focus on the task at hand, not on strategies how to avoid punishment or look better than your team mate.

Rule # 3 Stimulate different learning styles

People are sensual beings, and they learn better the more senses are stimulated. Our traditional classroom-style teaching puts emphasis on only auditory learners (learning by listening) with some visual stimulation (learning by seeing) when using the white-board or slides in the training.

The most important part of learning, however (according to me that is), namely kinesthetic learning (learning by moving or doing), is mostly neglected. Scrum includes this part of learning with it’s standup’s and requiring people to stand up and move and touch sticky notes on a board in standups, planning sessions and retrospectives.

Most learning methodologies believe that you are primarily dominant in one of these, and although I agree with that, I believe that optimal learning can only be achieved when all three are stimulated.

Making the learning even more efficient would also include the olfactory (sense of smell) and gustatory (sense of taste) senses to anchor what has been learned.

The ritual adapted by some Scrum teams to bring snacks to the Retrospective addresses this and helps to anchor behaviors in the team. The question is whether these are healthy or dysfunctional behaviors being anchored.

Rule #4 Visualize information

Software development is mostly intangible. It’s the art of translating abstract thought into functional systems, using a computer.

When you can’t see something, however, it becomes very difficult to manage it, as you can’t see the obstacles, unless the person experiencing the obstacle says something about it. Visualizing information is key to firstly awareness, and secondly process improvement.

The Scrum Board is one way that information can be visualized. Kanban and Lean uses different methods of visualization, yet they all have one thing in common — everything important, is stuck somewhere on a wall.

Rule #5 Provides Focus

The entire Scrum method is built to allow teams to focus on a specific goal.

“the people who multitask the most just can’t focus.”
― Jeff Sutherland

The planning session is designed to allow all the role players to be in the same room while you plan the sprint ahead, without any distractions. The sprint itself is a container helping the team to focus on a specific sprint goal, and the retrospective clearly dedicates time to focus on learning, and how this learning can be integrated to improve the next round of development.

The backlog is another example of creating focus in the team as well as the organization, and each daily standup is intended to focus the team members’ efforts on their daily tasks to ensure they will stay on track towards the sprint goal, and ultimately the product road map and vision.

Rule #6 No end point

Traditional project management clearly plans for each project to have a definitive start and end, and maintenance teams or operations are mostly separate division, removed from the development team.

That implies that you only have one chance to get it right, but it also separates the learning from the development. Where each reported customer issue is an opportunity to better understand the needs and react, separating development from maintenance broadens the gap between the product and the customer, and it splits the ownership of the code.

Scrum, on the other hand, is designed to continuously grow and evolve, much like a tree. The product keeps on growing, with each sprint an opportunity to align with the customer’s changed requirements. Each sprint the team knows the customers and the customer’s needs more, and is better able to fulfill these needs.

The goal is a vision that keeps changing, and each sprint only focuses on taking one step to get closer to the goal. When the goal changes, there is no big impact, as you only need to adjust one step, not an entire journey.

Rule #7 Makes fair judgement calls

The entire agile manifesto, Scrum to a lesser degree, is designed around the concept of judgment and decision making. Each time you do something in Scrum, whether it is estimating the effort, selecting or creating user stories, or choosing a task, you are expected to make a judgement call.

It is a constant weighing of factors in order to make the best decision with the information and resources that you have at hand now, knowing that tomorrow you will know more.

There are no hard and fast rules, processes and procedures. Rather, there are objectives that need to be met and guidelines and best practices. Each time you deliver , you need to way up these factors to decide how best to meet your objectives.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

It’s all about decision making, and how you make decisions.

One sprint it might be more important to document the release notes carefully to limit support calls from customers on how to use a new feature. The next sprint an emergency fix might need to be rolled out, requiring the team to spend all the effort in managing the risk, rather than write documentation, and they will rather phone the customers than write a release note. Yet another sprint, the team might focus on refactoring, updating the architecture and deciding to document the model (or not).

Depending on the situation, the decision will be different, and each sprint, you will know more than the previous one, thus each sprint you need to ask whether what you did the previous sprint is still the best way to do it.

Rule #8 Provide context

What was missing in most of the waterfall methodologies, was that each requirement and each function were so granular and specialized, that the overall context were often forgotten. Often times a really good feature was rolled out, only to realize that it is for the wrong customer, or doesn’t address the customers most urgent needs.

Scrum is designed to provide more context, which makes it easier to deliver the right product, every time.

The team structure is intended to be cross-funtional, self organizing teams, implying that everything that needs to be done to deliver are included in the story. No longer does the developer work in isolation with a tester criticizing their work at the end of the development lifecyle. Now the developer and tester work hand-in-hand to take more viewpoints into consideration earlier in the development process.

User stories in Scrum is another example of providing more context , where each requirement now explicitly includes the end user it is intended for, and the value or benefit of this requirement. This allows a developer more autonomy in designing a technical solution, while being closer to the end-user, reminding them constantly who the requirement is for.

Rule #9 Enables effective learning

For learning to be effective, there needs to be three elements present:

A clear purpose.
Room for exploration and experimenting with options.
Reviewing what has been learned, integrating the skill.

Scrum includes all these elements in each sprint, starting at the planning session, ending with the retrospective.

The sprint goal set at the planning session serves as the purpose, with the user story and it’s acceptance criteria purpose on a more granular level; the team selecting their tasks (rather than being allocated a task), and the inclusion of spikes and building prototypes allows the team to experiment with different options; while the review and retrospectives both allows the team to review whether the goal was indeed met, and what could be done better next time.

Rule #10 Improved communication

The biggest benefit of Scrum, more than anything else in my opinion, is the design to improve communication throughout the team, as well as throughout the organization.

The smaller, autonomous teams reporting to each other daily, the inclusion of the Product Owner, and the focused rituals where team members give input into the planning, while being given the opportunity to discuss failures in a safe environment, all are designed to create an environment for improved and effective communication.

Scrum provides an infrastructure that supports communication, knowing that face-to-face communication is the most effective means of communication.

More than 80% of communication is non-verbal, and relying on tools and electronic communication such as Skype, Trello or Slack instead of face-to-face communication, means that the message being conveyed are possibly misunderstood or incomplete, which in turn means lower quality development with more errors introduced, requiring more time to develop the same requirements.

Conclusion

Scrum works. If it’s not working for you, evaluate whether your implementation is meeting the rules of the game, as outlined in this post.

The framework itself is a perfect model for agility. Understanding why Scrum works, makes it possible to fill in the blanks tailor made and suitable to your unique organization.

Originally published on Medium: https://everydayagile.com/why-scrum-works-f74638b13ea5