Scrum is an iterative and incremental process for product development and the organization of teams. Tasks will be achieved faster and with higher quality with the aid of Scrum frameworks. This is possible because of the high self-motivation of the team, which itself chooses how the tasks will be executed. The customer demands will be iterative, prioritized, and quickly realized.
This article starts with a short presentation of Scrum. It focuses on what is behind Scrum, why so many companies are skeptical of it, whether Scrum works for you, where statements such as “Scrum is chaotic” come from, and why starting with Scrum, despite simple rules, isn’t easy at all.
“Scrum is a simple ‘inspect and adapt’ framework that has three roles, three ceremonies, and three artifacts designed to deliver working software in Sprints, usually 30-day iterations.” (1. Scotland, A. Scrum @ the BBC. in JAOO. 2005. Aarhus, Denmark: EOS.)
In contrast to classical project management methods, Scrum doesn’t have and doesn’t need a product manager, a task manager, or a team leader. The three most important roles of Scrum are:
These three roles are coequal, and all have certain responsibilities, of which I want to name a few.
The Product Owner is responsible for the vision of a product, the gathering and the prioritization of the requirements, control over the budget, and the ROI. The Scrum Master cleans out problems, takes responsibility that the rules of Scrum are kept, and coaches the Team. The Team is a self-organized unit, responsible for the creation and the quality of the product. Besides these three roles, there are some Stakeholders (e.g., an observer or a counselor).
Scrum Projects are divided into iterations, which are called Sprints. They usually have a Time Box of two or four weeks.
At the beginning of such a Sprint, the Product Owner presents, at the Sprints Planning Meeting, the prioritized Product Backlog, a list of all the requirements or (as the case may be) User Stories. The Team now needs to ask questions in order to find out what is hidden behind the professional demands and roughly estimate the effort required. Contrary to classical projects, the Scrum Team is not told how many features they should realize in a certain amount of time. Instead, the members choose which functionalities can be fulfilled in one Sprint and commit themselves to realize these.
In subsequent Sprint Planning Meetings, only the Scrum Master and the Team participate. They split the User Stories into several tasks and record them in the Sprint Backlog. They are provided daily with the description of the remaining effort required. From this description emerges the always-current Burn-down Chart.
During the running iteration, the Sprint Backlog won’t be expanded, in order not to jeopardize the completion of the arranged User Stories. What is finished in the end (and finished by Scrum means tested and documented) can then be taken to the Product Owner in the Review Meeting. Common statements such as ”I’m ready for 80%” don’t exist anymore.
During a Sprint, the Team works, concentrated and undisturbed, on the tasks of the Sprint Backlog until they are done. It meets daily for a “time boxed” 15 minute meeting, the Daily Scrum Meeting. Here, they usually talk about the following things:
At the end of the Sprint, the Team presents the Product Owner with the implemented functionalities at the Sprint Review Meeting. The Product Owner then decides whether to take delivery and whether all the acceptance criteria are fulfilled.
The Scrum Master takes care that, during the entire process, the rules are kept and no extraneous disturbances occur.
The Retrospective Meeting at the end serves as a reflection on how well or badly everything worked, whether the process should be adjusted, and what needs to be changed in the next Sprint.
At first sight, that sounds very dramatic, but it actually is not. Scrum creates transparency, and through that transparency, no one can hide behind the supposed mistakes of others. Through the observance of the “Time Box”, the tasks within the Team, and the transparency with respect to when something needs to be delivered, statements such as ”…I’ve been waiting for this or for that…, or … I had to do so many other things for the customer that I simply didn’t get to it…” lose their foundation.
Yes, the introduction and observance of Scrum may lead to the fact that some employees and managers don’t feel comfortable in their company and leave because not everyone gets along with the changes that come with Scrum. But if we are honest, it’s good that way. The reasons to avoid transparency affect a company with or without Scrum – Scrum only makes it visible.
Yes, because Scrum draws out problems in the company, the teams, and the management. The simple rules of Scrum arrange that every problem that leads to difficulties in software and/or product development in a company will be recognized. Some companies, unfortunately, try not to expose problems, and therefore also not to remove them.
That Scrum cannot function that way should be quite clear. This wrong utilization is the reason for statements as “Scrum is chaotic”, or “Scrum doesn’t work for us”.
The spectrum of possible conflicts that can appear through the introduction of Scrum is large. It starts with managers who like transparency in development but who don’t want to share their visions, or who think that the rules are only for others. Classical project leaders first need to understand which role they have to take with Scrum. Furthermore, a company needs to claim the customers’ collaboration.
The number of examples of groups who have succeeded in using Scrum properly increases. Mostly, professional advice is needed, because the experience of experts shows solutions which would not be possible with only internal efforts. (At this point, I’d like to express my gratitude to all counselor colleagues, “Scrumtisch”, “Scrum Breakfasts”, and other initiatives that make Scrum successful, with people who are amenable for questions and who offer support at any time.)
Just yesterday, I made a presentation for project leaders and developers, and I had to realize that the most important question for the audience is: How does Scrum fit our established structures and roles?
As already said, Scrum defines three different roles, the Product Owner, the Scrum Master, and the Team. Matching equivalents can be found in classical projects, but the meaning and the status of Scrum roles is entirely different.
The nomenclature is definite. The Product Owner is not only the manager of a product, but also the Owner. Therefore, he is the one responsible for the correct creation of a product. Being a Product Owner means:
Scrum Master and Team
In a way different from other methods, in Scrum, a Team is not only the executive organ which receives its tasks from the project leader, it independently decides which requirements or User Stories it can accomplish in one Sprint. It constructs the tasks and is responsible for the permutation – the team becomes a manager.
This new self-conception of the team and the resulting aligned tasks and responsibilities necessarily change the role of the team leader/project leader. The Scrum Master does not need to delegate all the work and plan the project, he instead takes care that the Team meets all conditions needed to reach their self-made goals. He cleans off any impediments, provides an ideal working environment for the Team, coaches, and is responsible for the observation of Scrum rules. He becomes the so-called Servant Leader.
The changed role perception is one of the most important aspects when someone wants to understand Scrum with the intent to introduce it in his own company.
Scrum works! Innumerable projects prove that. But (and of course there must be a “but”) Scrum only works when one has the courage to really realize the rules and ideas behind Scrum. Scrum is more than just the summation of all the roles, ceremonies, and artifacts.
With the introduction of Scrum, not everything goes down the smoothest path from the beginning. All participants need to get used to the new procedure and will be unsure what needs to be done if something unexpected happens. Problems often lead to using “known” mechanisms “just for this one case” instead of solving the problem with the Scrum method.
Breaking open the synergy created by Scrum, the actual effect of Scrum, the outstanding increase of productivity, gets lost rapidly.
Here’s the worst Scrum Anti-Pattern:
There are many good reasons to work with Scrum. The 10 most important are listed here.
Competitiveness: The requirements of the market change ever faster, and only the ones who are flexible and contemporary can react in time to the market to stay competitive and create a competitive advantage.
Develop what is needed: Scrum allows incremental development of features. In time, the customer receives the first working versions, sees the progress, and can, if necessary, add some new ideas.
Confidence through transparency: Transparency plays a great deal on various levels of Scrum. Because of transparency, all the stakeholders are informed where the project is, weaknesses are discovered, and teamwork is effective, making Scum so efficient.
Build quality in: Testing is an integrative component of Scrum in every Sprint. Only if the software is tested and documented is it “ready”. Methods like Continuous Integration are applicable for securing the quality of every object from the beginning.
Recognize risks in time – systematic risk management: Regular releases establish the conditions to recognize problems in time and react promptly. Long-term statements about time factors and product completion are possible because of factors such as team velocity.
Have costs under control: The development period of a project is usually fixed, but the effort and the complexity are just roughly estimated. Scrum allows changes to the specification, includes the customer in the project, creates transparency, and allows definite cost accounting.
Changes are welcome – calculable change management: Scrum is not afraid of changes. On the contrary, changes can be shown to the Product Owner at any time and can be realized in the following Sprint. That way, the customer gets the Product he or she desires.
Keep it lean and agile – efficient collaboration and customer satisfaction: Scrum involves all the participants of the project. Communication, collaboration, respect, and understanding what the customer requires and what the team develops are the basis for successful projects.
Scrum is also perfect for system development: Contrary to popular belief, Scrum is very good for the development of complex systems and extensive/long-term projects. The exact planning has a huge impact, and the continuous integration of new functionalities assures that there won’t be a bad awakening in the end. Many production plants work with lean principles and software development – Scrum creates an optimal synergy.
Last but not least – Scrum makes fun: Collaborative functioning and making decisions as a team is an important part of Scrum. Software development is seen as what it is, a creative and multisided activity that can only work properly when everyone takes responsibility.
Isn’t that great? After so many years of projects that didn’t work out, there’s finally a method to develop software on time and on budget – Scrum. Many companies have proven that. But easy? No, Scrum is not easy. To follow the principles of Scrum, there must be courage to make changes, to make transparency, and to make mistakes. Only people who openly handle their problems in order to learn from them will be successful in developing software and systems in the long run.
Scrum works, but first we have to recognize that firm-price projects without detailed preplanning and broad specifications are possible. Confidence not only increases the productivity of the team, but also that of the customer and the service provider. Communication is just as important for development as the development itself. When this is seen, Scrum will convince skeptics.