Scrum is a framework that gives you a set of rules and principles that HELPS YOU to build software successfully. It is based on agile methodologies and unlike waterfall methodologies it works with small iterations, producing chunks of quality software faster and, ”hopefully” on time.
The success or failure of adopting scrum will depend in my opinion on three factors: The quality of the team (people), the expertise of the scrum master and the desire of the organization into adopt Scrum.
Complexity of software development
Software development is complex because there is not only one way to develop a piece of software; there is not only one technology that can be used or one management technique to be followed. Combinations of technologies, resource management, development techniques, architecture and methodologies to develop a system can be almost infinite.
One key aspect of the complexity of software development is the volatility of its requirements. Requirements are dynamic and can change, depreciate or can be created at any time during the lifecycle.
What if during the life cycle, market conditions change? New laws regulating some functions of the software change? Or the customer forgets a very granular functionality that is really hard to estimate without seeing the system in action? Including a change in the middle of the process could be quite expensive.
Software bloat
Have you heard about software bloat? Some failures in software engineering lie on mixing all required features in one big and unique iteration. Most of the time it implies a tremendous waste of development and support funding. The deadlines are extended multiple times and the estimated budged is grossly exceeded.
Do you have a smartphone? How much of the whole functionality of that smart phone you REALY use on a daily basis? Really, how much? Probably less than 5% – 10%!
Why not focus on what really matter first and deliver it in small period of time?
Scrum helps you to solve the problem, giving you:
- A set of rules to follow to produce the most important functionality first in short iterations.
- Power to the team to take immediate decisions based on their skills.
- A way to sort requirements that allow existing ones to mutate at any stage and new ones to be introduced.
How?
- Having short iterations provides you with a tool to inspect results in early stages. That inspection is enforced with “events” across the lifecycle of the iteration. The results of that inspection should produce an adaptation in towards to improve processes.
- Empowering teams to make its own decisions, decentralizing the decisions about how to develop software to people who are close to the work.
- Working on a sorted list of wishes based on “value” allows you to focus your effort in what really matters first.
These three key Scrum characteristics can be translated in 1) Events, 2) Team and 3) Artefacts.
How do Scrum events work?
Scrum has several events. The main one is the Sprint (iteration). The others are meetings designed to inspect processes and their results during the lifecycle of each sprint.
The first event in the cycle is the Planning Meeting. In that planning meeting, the team decides what functionality will be built during the next iteration. It is divided in two parts: a) The team picks the top functionality from a unique list of wishes (previously sorted by value) and forecasts what they will develop. b) The development team discusses how that functionality will be developed.
Immediately after that meeting, the sprint starts. The sprint has duration between 1 to 4 weeks and the length of it is fixed across the duration of the whole project. In that event the development team “develops” all functionality required to produce a potentially deliverable piece of functionality based on what they selected and committed to do from the list of wishes, and based on a unique and shared definition of “done”.
During that sprint a daily scrum meeting is always held in the same location and the same time. In that meeting all developers answer to themselves three basic questions: 1) What did I do yesterday?; 2) what will I do today?; and 3) what impediments do I have? If some discussion arises, it is parked and it is discussed after the meeting. This meeting has a duration of up to 15 minutes (enough for a development team of 9 members).
The Daily meeting is the event my customers like more and in my experience is one of the sales points of Scrum. They love the idea of having a daily self-inspection between themselves. If there are some impediments, those are raised and a mitigation plan is created afterwards. Don’t be confused. It is not a status meeting. This meeting is only for the development team.
When the sprint finishes at the date defined (It cannot be extended but it can be cancelled for extreme reasons) a sprint review meeting is held. In this meeting, the team discusses the result of the sprint, a demonstration of the piece of software is presented and it is indentified what has been “Done”. A decision of release the result of the sprint could be made.
Immediately after the sprint review meeting, a sprint retrospective meeting is held. In that meeting, the team inspects itself in terms of people, relationships, process, and tools. What went well is reinforced and a plan to implement improvements is created (including the review of the definition of “done”)
All events are mandatory and all of them are time-boxed to avoid extend discussions beyond reasonable durations. Scrum focuses on producing software not on bureaucracy.
What’s the scrum team, who is there?
Product Owner
It is one person. He/she controls the destiny of the project. This guy decides two main things:
1. The order of the list of wishes (what will be developed next).
2. If the result of a sprint (increment) can be released.
Scrum Master
It is one person. He/she is the referee and the coach. This guy ensures scrum is understood and enacted, and this is done is by:
1. Teaching scrum.
2. Removing impediments.
3. Protecting the development team from interruptions.
Development Team
It is a group of “developers” with a size between 3 and 9 members. They are responsible for delivering what was committed as an increment. Their characteristics are:
1. They are able to make decisions about how to develop the increment without a central authority or a chicken imposing it.
2. Although they have different functional expertise, they work together toward a common goal.
3. No titles. Everybody has a “developer” role and everybody has the same responsibility (deliver what was committed as an increment).
Constraints:
- Product Owner (PO) cannot be Scrum Master or Developer
- Scrum Master cannot be Product Owner (PO) but he/she can be Developer
What are the scrum artefacts?
Artefacts are the result of the events. Scrum divides the artefacts into product backlog, sprint backlog, sprint progress and the increment.
Product Backlog
It is the list of wishes. It is unique and it is dynamic. Items inside of it are called Product Backlog Items (PBI) and they have information about the functionality to develop.
That list is sorted by the product owner based on value so top items are more valuable and are more detailed than items in the bottom. PBIs can be added, deleted or modified at any time so new requirements are welcomed at any time!
Sprint Backlog
It is a subset of PBIs extracted from the top of the Product Backlog and allocated into a sprint. It has the plan (list of tasks) about how to develop that functionality.
Sprint Progress
It is a set of reports (can be any you consider appropriate) that shows the progress of a sprint. The most popular reports are the sprint burndown, release burndown and velocity.
Increment
It is the goal of all this confusion. It is the result of what the development team did, consistent with what they understood was required, and aligned with the sprint goal and the unique definition of “done”.
All those artefacts need to be visible and transparent to all the Team.
To Sum Up
Scrum is not a silver bullet. It will not guarantee you the success of your project. It is just a tool that helps you to increase the probability of success on complex software developments.
Scrum excels on it because it works with short iterations, it focuses on most valuable functionality first, on delivering software and on decentralising decisionmaking to avoid bureaucracy.
If you have a good skilled team, an experienced scrum master and the desire of the organization to adopts Scrum, the probability of success will be higher. So, what are you waiting for? Scrum it!



