What's Scrum?

Scrum is a Better Way of Working

Scrum is for sure a better way of working. Above all else, Scrum is an agile project management framework which provides only a few rules. It reduces risks, maximize return on investment, and tells the very truth about the project and its evolution. The metrics used to measure the team's velocity brings in another point of view upon the product development and allow for a more precise long-term view over the project development.

Foundation of Scrum

"In 1995, Ken Schwaber and Jeff Sutherland presented the Scrum Methodology at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA'95) in Austin, Texas, its first public presentation." (wikipedia.org)

"Scrum is a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that creates just enough structure for teams to be able to focus their innovation on solving what might be otherwise insurmountable challenge."

(Scrum.org)

The Scrum Team

The Scrum Team counts three major roles:

• Scrum Master, responsible for applying the rules of Scrum
• Product Owner, responsible for the best return on investment (generally the customer)
• Development Team, responsible for the implementation of the required features

Altogether the Scrum Team is responsible for the success of the project and the best return on investment - on schedule!

The Scrum Master

The Scrum Master is indeed responsible to apply the rules of Scrum, and that is:

• Removing impediments
• Guiding the Development Team in its decisions in a Scrum point of view
• Guiding the Product Owner in its role
• Writing the Sprint Retrospectives
• Writing the Sprint Reviews
• Measuring the success of the Sprints based on predefined Scrum metrics
• Informing the Product Owner and stakeholders about the evolution of the project
• Accompanying the Development Team in order to improving its way of working
• Helping the Product Owner, the Development Team and the stakeholders to understand the Scrum software development process
• Emphasizing direct customer communication
• Making sure the Scrum time-boxes are respected (Sprint Planning Meeting, Sprint Retrospective Meeting, Sprint Review Meeting, Daily Scrum Meeting, and the Sprint itself...)
• Guiding the Development Team in evaluating the user-stories' complexity
• Proposing some strategies to reduce the risk of failure
• Guiding the Development Team in estimating the tasks
• Planning the Development Team availability

The Product Owner

The Product Owner is responsible for the return on investment, and in many occasions the acceptance criterion:

• Defining the features
• Writing understandable acceptance criterion
• Bringing further details to the Development Team when required
• Prioritizing the features in the Product Backlog
• Assuring the best return on investment
• Gathering responses for the Development Team that it cannot find for itself
• Assisting to the Daily Scrum whenever possible (not obligatory and very encouraged)
• Participating to the Sprint Review Meeting
• Accepting, along with the stakeholders, delivered pieces of product at the Sprint Review Meeting
• Participating to the Sprint Retrospective Meeting
• Deciding whether a story may be accepted as Done when presented during the Sprint Review Meeting

The Development Team

The Development Team responsibility lies on, well, the development of the required features which in return encompasses:

• Evaluating user-stories complexity (aka Planning Poker)
• Estimating the tasks in hours (or whatever has been decided by the Team)
• Committing to deliver functional pieces of product by the end of the Sprint time-box (based on the number of story points evaluated)
• Defining Done, along with the Scrum Master and the Product Owner so that only one definition is used throughout the project
• Documenting its work
• Writing acceptance tests based on the acceptance criterion
• Testing the developed features to meet with the requirements and/or acceptance criterion
• Creating the tasks required in order to achieve the user-stories
• Developing the features
• Preparing the Sprint Review to present the completed stories to the Product Owner and stakeholders

Embrace the changes

The more complex the project, the more changes it brings. Any changes are to be adopted whenever possible - the sooner the better.

If any change occurs, this means an occasion to be flexible to what the end-customer really needs. Planning exactly what you'll need in month from here is quite impossible because you don't know where you'll be in a month!

Software development is a very complex profession for one must fully understand the business domain of his own field of activity, and on the other hand, have a great understanding of the business domain of the customer. That is hard-work!

The changes may come from a sudden change of mind from the customer himself, or from the Product Owner priorities. Changes might also come from the Development Team which during the development process learns more and more about the business domain of the end-customer, hence some early decisions which no longer make sens later on.

Transparency

Ostriches are rather unwelcome in the Scrum Team. Scrum requires above all else transparency, honesty. If for a reason or another you're not about to meet with the schedule, then say it sooner or later. That way, everyone including the Product Owner may work on expectations and at least understand the real situation, the real problems.

Over the years I have learned that people can understand, when they are given the right information to allow them to figure things out. That is one reason, among many others, why I like Scrum.

Speaking of transparency, this also means that the stakeholders can see the evolution in real-time of the project. Be it special tools or a simple charts in a conference room, the Development is responsible to give the right information about the project evolution and obstacles it goes through.

Waterfall against Agile

The major difference between agile methodologies and the others like the Waterfall approach is that Agile digs it vertically, that is, the Team works on every aspect of the project during a predetermined time-box, the Sprint, where the analysis, the architecture, the documentation, the tests and the demonstration to the stakeholders are all done. 

On the contrary, the Waterfall and traditional approaches do all of the analysis, all of the architecture, all of the development, all of the tests, and finally all of the documentation. Whenever a step is compromised, the preceding takes over until it is completed again with the newly gathered information. This ends with never-ending stories and both supplemental costs and time. Often when the product is delivered to the end-customer, it no longer reflects the reality since the portrait has been taken months and even years ago. 

Summary

For sure it is impossible to include everything of what is Scrum in a single blog post as many many books have been written on the subject among multiple training all over the world. I shall then write again about Scrum and cover elements which couldn't be covered here.

Thanks for reading!