Basics of SCRUM - Part 1

After some thought i have decided to write and share some of the basics about Scrum. A lot of people have different views, theories and ways of doing things which they call Scrum. While i do not contest some of those practices but its essential to understand the concepts and strongly agree that every organization team will need to mold and churn some process to make things work. 

So in this series of blogposts, the first one will be addressing the following:

- Scrum and Agile
- Agile Manifesto
​- Agile Principles
- When to use Scrum VS other Methods
- Facts and Fibs about Scrum
- Scrum Timeline
- Scrum Roles and Team

At a later time, i'll share the more advanced stuff and also touch base with SAFE.

Scrum and Agile

It is not possible in some projects (especially in IT projects) to gather all the requirements upfront because of their extreme uncertainties. Therefore, we need a project management method flexible enough to deal with many change requests that appear during the project and keep the project team productive.

There are a number of systems designed to provide these two properties, and a group of them are called Agile Frameworks. Scrum is a project management method of the Agile group; it is the most famous and the most broadly used one.

Scrum is based on a certain process, which i'll explain in the next few blogposts as we progress. This Scrum process will not be effective, unless it is combined with certain roles and artifacts.

Agile Manifesto

In 2001, a group of software developers (while on a skiing vacation) published a manifesto that has since been considered the heart of all Agile methods.

Scrum is a way of realizing this manifesto.

​The complete Agile manifesto is as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.

3. Deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the Project.

5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face to face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10.  Simplicity - the art of maximizing the amount of work not done is essential.

11. The best architectures, requirements and designs emerge from self organizing teams.

12. At regular intervals, the team reflects on how to become more effective then tunes and adjusts its behavior accordingly

When to use Scrum VS other Methods

​Both approaches have their strengths, so it all depends on the type of the project and its environment. However both approaches have a good deal in common which are often forgotten; both have effective planning followed by execution, monitoring and controlling.

SCRUM	Other Methods
​Scope is not clearly defined. The product will gradually appear during the project	Scope is clearly defined upfront. Clear product description is available upfront Similar projects were done before
Requirements change frequently. Customer learns more about what they want as the project goes on	Requirements are well defined up front. Few changes are expected during the project Requirements are not expected to change much
Activities cannot be well defined upfront. Estimating (planning) is difficult	​Activities can be well defined upfront. Estimating is possible and reliable
Process is iterative (numerous cycles).  Each cycle heavily depends on the previous one	Process is more long term Project might be split into phases
​Success is mostly measured by customer satisfaction	​Success is mostly measured by achieving the project goals for time, cost, scope
​Incremental results have value and can be used by users (put into production)	​Users cannot normally start using the products until the project is complete (e.g. a bridge)

To summarize, it is better to use Scrum if there are lots of unknowns, where the projects are more complex, difficult to define detailed requirements upfront and therefore to define estimates at the beginning of the project.

It is better to use the traditional approaches when there are few unknowns, project is less complex, easy to define exact requirements upfront and therefore easy to estimate and plan the project from the very beginning.

​Care should also be taken not to try to apply Scrum if the organization is not ready for it, e.g. if they have not been trained, if their existing way of working hinders the Scrum roles and responsibilities and people are not open to learn. Many times the Scrum Team gets training in Scrum but the company management miss out. It is strongly advised not to start using Scrum until every role has received the necessary training and understands the roles and responsibilities.

Fibs and Facts about Scrum

​Some of the popular myths about Scrum, which we should be aware of, are as follows:

FIBS	FACTS
Developers are free to do what they want.	​Developers work in a productive and predefined framework and the Scrum Master makes sure they are following Scrum.
​Scrum gets rid of all paper work and allows the team to start developing right away.	There are certain planning steps involved in every Scrum project and development can only start when the Sprint Backlog has been defined.
All requirements (in the form of stories) must be agreed before the Development Team is allowed to start working on the product.	The Development Team can start working as soon as the initial stories of the Product Backlog are ready.
Scrum is very easy to implement, even without training.	​Using Scrum is a big change; It might seem easy to implement Scrum compared to other project approaches, but people must still have a good understanding of Scrum to be able to run their projects well.
Scrum is just a set of simple rules.	​Scrum is a set of rules and a framework, plus a compatible work culture and ethic.
The Scrum Master is like a project manager.	​There is no one similar to a traditional project manager in a Scrum project. The Scrum Master makes sure the Scrum framework is followed.
​Scrum does not require you to have a Business Case.	There should be a justified reason to spend any money in any company and this should be documented. The Product Owner is responsible for ensuring that there is a feasible reason for performing the project and aligning the project with it.
​Scrum allows the Development Team to decide what will be delivered.	​A Team only decides on how to deliver; it is up to the Product Owner to determine what will be delivered.
The Product Owner is the project manager.	The Product Owner only creates and maintains the Product Backlog, but does not manage the day to day activities of the Team.
​Scrum tells us everything about managing projects.	​Scrum mostly deals with the definition and delivery of the products. Many of the business oriented aspects of the project are done outside Scrum.
​The Product Owner is a representative from the customer.	​The Product Owner is one of the people from the performing organization (the organization in charge of producing the final product of the project; a contractor in many cases), and the contact point with the customer.

SCRUM Timeline

This section will give you a basic idea of how a Scrum project works. The business representatives has already agreed to build something for the organization and a Vision Statement and Product Map will be provided to define and describe the vision and the goal of the project.
​
The following diagram shows the complete timeline. The Vision Statement and product roadmap are not part of Scrum, but are essential parts of managing projects and are covered in other Agile frameworks such as DSDM Atern

What happens prior to the Sprints (Pre-Sprint):

1. The Vision Statement provides a concise description of the goals of the project which help the team stay focused on what is important from the organization point of view.

2. The Product Roadmap is an initial visual timeline of major product features to be delivered and is normally created by the Product Owner; one of the Scrum roles which will be explained later.

3. Gather user requirements, and turn them into deliverable features - these are called stories. Stories are normally written by the Product Owner and the requirements that make up these stories come from the customer.

4. All these stories make up the Product Backlog. In Scrum, we do not wait until the Product Backlog is 100% prepared with all the details to start the Sprints; we can ​start the Sprints as soon as the Product Backlog is mature enough and has enough stories defined. We also keep updating the Product Backlog during the project.

Sprint Activities:
 
5. Sprint Planning meetings are held to plan what will go into a Sprint (a fixed period of time used to deliver parts of the final product). The Product Owner prioritizes these requirements and therefore decides on the contents of the Sprint Backlog.

6. These stories (features, functionalities, or deliverables) make up the Sprint Backlog, so the Sprint Backlog is a list of all stories that will be developed in the next Sprint.

7. The Team breaks down (expands) these stories into tasks.

8. The Team then takes 30 days or so to deliver an agreed amount of stories.

9. The Team holds a Daily Scrum meeting of 15 minutes each day to collaborate with each other.

10. At the end of the Sprint, the Team demonstrates the completed stories (products) to the customer in a Sprint Demo (aka Sprint Review) meeting.

11. The last activity is the Scrum Retrospective meeting, where the team reviews the Sprint and looks for ways of improving (lessons learned).
​
12. The Scrum Master makes sure the Scrum process is followed entirely and offers coaching to everyone involved.

SCRUM Roles and Team

In some circles this is a hotly debated topic since every organization structure of teams differs due to its business needs, resources and product requirements. I will try to break it down on how things can be modified to a certain level without getting in to a never ending debate about it in later posts but right now lets focus on what actually is a Scrum Team and its role.

There are three roles in a Scrum project; no less, and no more. We are not allowed to define any other roles, because it is harmful to the unity of the team, and it is not compatible with the philosophy of Scrum.

A Scrum Team consists of the following three roles:

The term “Scrum Team” refers to all the project team members: everyone internal to the project. Scrum Team members usually have only one of the three standard roles of Scrum: Product Owner, Scrum Master, or Development Team member. It is possible for a single person to be assigned to more than one of the standard roles, but it is not recommended and in my personal experience this is a recipe for disaster.

The Scrum Team is a part of the performing organization (the company which executes the project either for itself or as a contractor for an external customer).

Other persons can also be involved in the project but they are not considered internal to the project and Scrum theory does not have much to say about them. They should have a certain set of behaviors though (e.g. respect how a Scrum project works), to make it possible for a Scrum project to succeed.

When the project is not internal (you are not doing the project for your own company), you should also consider the customer as another stakeholder. You may or may not have a ​ separate customer, but you always have some external stakeholders (shown in the figure below) and should consider them in your development style.

The environment of an internal Scrum Project

The environment of an external Scrum Project

The customer should understand and adopt the Scrum framework too, as the relation between the customer and the performing organization and the way we deliver the project completely changes when we switch to the Scrum framework.

The Scrum Team has two essential characteristics:
​

• Self-organized: The Scrum Team manages its own efforts rather than being managed or directed by others. In traditional methods, management efforts are separated and centralized; a subset of the project team is responsible for project management and others are only responsible for specialist activities. However, management and specialist efforts are not separated in Scrum.
• Cross-functional: The Scrum Team has all the expertise and competencies needed to get the job done without any help from outside the team.

These two characteristics are designed to optimize flexibility, creativity, and productivity, needed for the Agile environment of Scrum.

Product Owner

Each project needs a business oriented person, aimed at maximizing the value of the product and the work of the Development Team. In Scrum, this person is called Product Owner. Product Owners, like the two other roles, are from the performing organization, rather than from the client.

This role belongs to one person. There can be a committee to handle the responsibilities of this role, but in such a case, there should be one person representing this committee and we call this one person the Product Owner.
They do not need to have application area knowledge of the project; they are focused on the business aspect. In software development projects for example, Product Owners do not need to be developers themselves, they just need to know a little about development, but a lot about how the business operates.
​
The Product Owner is responsible for the Product Backlog. The Product Backlog is a prioritized list of items (aka stories or user stories) that the client expects from the project; this is the main planning tool in Scrum. It is also the responsibility of the Product Owner to make sure that each item (user story) is easy to understand for the Scrum Team, and other stakeholders.

​Product Owners should communicate effectively with the customer (the inevitable success factor in every project management method), and use the information to keep the Product ​Backlog updated with all the changes. They also measure the performance of the project, forecast the completion date, and make this information transparent to all stakeholders.

Product Owners understand the business, so they can rank each Product Backlog item based on its return on investment as well as any other factor they find suitable for the business point of view of the project. The items will be sorted based on their value, so the higher they are on the list, the sooner they will be developed by the Development Team.

The entire organization must respect the Product Owner decisions for the project to be successful. No one, even the CEO, should allow themselves to try to override those decisions, and no one should tell the Development Team what item to deliver, except for the Product Owner who sets and orders the items. A Product Owner’s decisions might be influenced by others, but he/she must have the final say.
​
A Product Owner might delegate some of his/her responsibilities (such as preparing the list of items for the Product Backlog) to the Development Team, but stays accountable for them.

SCRUM Master

Scrum Masters are those who fully understand Scrum, and help the Scrum Team by coaching them, and ensuring that all Scrum processes are implemented correctly. The Scrum Master is a management position, which manages the Scrum process, rather than the Scrum Team. He/she is a servant-leader for the Scrum Team.

Besides ensuring that the Development Team understands and uses Scrum correctly, the Scrum Master also tries to remove impediments to the Development Team, facilitates their events, and trains and coaches them. The Scrum Masters help the Product Owners too, by helping or consulting them on finding techniques, communicating information, and facilitating related events.

The responsibilities of the Scrum Masters are not limited to the Scrum Team. They should also help those outside the Scrum Team understand the appropriate interactions with the Scrum Team to maximize the value created by the Scrum Team. The Scrum Master usually leads the organization in its effort to adopt Scrum.
​
It is possible for a single person to be both Scrum Master, and a member of the Development Team, although this is not recommended. Being a Scrum Master of a project might not occupy 100% of the time of a person; in this case, the best solution is to assign that same person as the Scrum Master in more than one project, rather than making them a member of the Development Team.

Development Team

Members of the Development Team are application area experts that are responsible for delivering backlog items, and managing their own efforts.

They should be cross-functional; being capable of doing the A to Z of the creation of each Product Backlog item. They should be self-organized; find their own way instead of receiving orders. They should be aligned with the goal of the project instead of working blindly. A task might be assigned to a single member throughout the Sprint, but the whole Development Team will be responsible and accountable for that task; no individual owns any task.

The Development Team delivers the final product of the project in step by step Increments, as defined in the Product Backlog. They always work in a product-based way.

It is highly recommended for members of the Development Team to work full-time in a single project, to stay focused and agile. The composition of the Development Team should not change so often. If there is a need to change team members, then this change should not happen during a Sprint and there will be a short-term decrease in productivity when the composition of the team changes.
​
Scrum is mostly effective when there are 3 to 9 Development Team members. For large projects, we can use a scaled model with multiple Scrum Teams. However, the use of multiple teams is not common in Scrum.

Other Roles

You might have the temptation to give Development Team members more specific titles, such as designer, tester, quality inspector, and team leader; but Scrum does not allow this! All members should have the same role, and the same title: Development Team member.
​
Scrum is completely depended on collaboration and team-work. Development Team members should be united and completely aligned with the goal of the project. If you give them different titles or roles, they will focus on their own specific role in the project instead, and they might not pay enough attention to the final product which is necessary for agile projects. Each Development Team member is responsible for all the outputs created in the Development Team, even though each of them might be focused on a specific set of tasks.

Who is the Project Manager

Now that we have reviewed all the Scrum roles, you might ask yourself, who is the project manager?

The answer is simple: there is no such role in Scrum; and none of the 3 roles of Scrum act as a traditional project manager.

Some people consider the Scrum Masters to be the equivalent to traditional project managers; but it is not true, because the Scrum Master responsibilities are very different than a traditional project manager.
​
So, a better question to ask is: what happens to project management?

The project management responsibilities are distributed among the three roles of Scrum and there is no centralized project management in Scrum.