Things You Need to Know about Scrum

In the previous article, we saw when we must use Scrum. If you are reading this article, it means that you have decided to use Scrum in your organization. Before you go full-on with scrum implementation, there are a few things you need to know about scrum. They are:

• Scrum concepts are very simple and easy to understand but following & implementing the same is not as easy as it sounds.
• The Scrum Master’s role is pivotal to the success of your project. He/she is the person who will make sure Scrum is properly followed in your organization.
• Every Scrum Sprint starts with Planning and ends with testing & acceptance of the product built during the sprint cycle
• The Development Team can usually start work on the sprint as soon as the initial few entries in the product backlog are ready/well defined.
• In a Scrum Environment, there is no Project Manager. The team is self-organizing and self-managing.
• The Scrum Master is not the Project Manager. His role is not to manage the team. His role is to facilitate the proper implementation of scrum in the organization and help the team if they encounter any issues/impediments.
• The Product Owners role is pivotal to the value creation part of the product being built. Any project would require significant investments and without a proper product owner  the team might not be able to deliver as much value as compared to the investments the organization is making.
• The Product Owner decides the product features while the Team is free to decide the “How” aspect of the implementation.
• The Product Owner is usually the point of contact for the Customers and acts as the bridge between the scrum team & the end users. 

Previous Article: When to use Scrum

When to Use Scrum

Scrum as you might have seen in the previous few articles is a revolutionary concept in software development and is gaining a lot of popularity. However, scrum is not the one-stop solution to all your software development needs. There are times when scrum could be better and there could be times when traditional SDLC could be better.

Now that we know the basics of scrum, we should first understand when to use scrum before we move further – in greater detail…

Look at the picture below – Most of the key factors to be considered before deciding which method to use are compared here:

To summarize:

It is better to use Scrum if there are a lot of unknowns, where projects are more complex and it is difficult to define a detailed requirements document upfront. Without proper/detailed requirements it might be impossible to estimate the size of the work to be done and hence it could result in a lot of delays during the course of development of the project.

It is better to use traditional approach when there are very few unknowns, where projects are less complex and it is easy to define the exact requirements upfront. With detailed requirements it is very easy to estimate and plan the project from the very beginning as well as track the project progress.

Important Note:

By seeing the first column of this table you might be tempted to use Scrum for software development because Requirement Changes are so frequent in real life projects. Yes, scrum would greatly help in such a situation but care should be taken not to start implementing scrum projects until the entire organization (or at least the team that is going to implement scrum and its management) is trained in Scrum.

A couple of articles back; I had explained the Different ScrumRoles. Unless the company’s senior management is clear in their understanding of scrum and all relevant stakeholders understand their roles, scrum cannot be successful. So, proper training is very important before starting out scrum implementation…

Previous Article: A Typical Scrum Sprint

Next Article: Things you need to know about Scrum

A Typical Scrum Sprint

In the past few articles, we have covered the basics of Scrum, its history as well as the key participants of a Scrum Project. Let us now look at a typical Scrum Cycle.

Before Project Start – Product Backlog

The prerequisite without which you cannot start any scrum project is the Product Backlog. The Product Backlog contains a prioritized list of Project/Product Business Requirements written in the form of user stories.

The Start – Sprint Planning Meeting

Each Sprint begins with a “Sprint Planning Meeting” where high priority requirements are considered for inclusion in the Sprint. At the end of the Planning meeting, the final list of prioritized business requirements that will be a part of the current Sprint will be ready.

The Sprint

A sprint usually lasts between 1 – 4 weeks during which the team will work together to create the Deliverables. During the Sprint, short, highly focused Daily Stand-up Meetings are conducted where the team discusses their progress. Each work activity is tracked to closure to ensure that all the deliverables are ready by the end of the cycle.

Before Sprint Ends

Toward the end of the Sprint, a “Sprint Review Meeting” is held where the Product Owner and all the relevant stakeholders are given a “Demo” of the deliverables. At the end of this meeting, the Product Owner accepts the Deliverables. A point to note here is that the Product Owner will accept the deliverables only if they meet the “Predefined Acceptance Criteria” which gets set when the sprint starts.

The End of the Sprint

At the end of the Sprint Cycle, a “Retrospect Sprint Meeting” is conducted where the team get together and discuss ways to improve processes and performance in the upcoming sprints. The picture below summarizes the Scrum Cycle.

A Scrum Sprint

Previous Article: Scrum Participants

Next Article: When to use Scrum

Participants in Scrum

In the previous couple of articles, we covered the basics ofScrum and its history. Though we took a very high level look at the 3 key participants, we haven’t covered them in great detail yet. In fact, apart from those 3 key participants, there are also other participants. The purpose of this article is to cover these roles.

The Key Participants in any Scrum Project are:

1. The Scrum Team
2. The Product Owner
3. The Scrum Master

The Product Owner:

The Scrum Product Owner is the hybrid combination of a Business Stakeholder and a Business Analyst in regular Project Management Terminology. The Product Owner is responsible for achieving maximum business value, by taking all the inputs from the customer or end-user of the product, as well as from Team Members and stakeholders and translating this into a prioritized list of business requirements. In some cases, the Product Owner and the customer may be the same person. In most of the cases, the customer is someone different from the Product Owner.

• The person responsible for maximising the return on investment of the development effort 
• Responsible for the product vision
• Constantly re-prioritizes the product backlog, adjusts the long term expectations like release plans
• Final arbiter of requirement related questions
• Accepts or rejects the product increments
• Decides whether to ship the increment produced by the development team
• Considers Stakeholders interest
• Plays a Leadership and Decision Making Role 

 The Scrum Team:

The Scrum Team is the team that will be building the product that the customer is going to use, for ex: The software product or website. The team in Scrum is “cross-functional” which means that, the team already has all the expertise necessary to deliver the potentially shippable product during each development Sprint. On top of this, the team is also “self-managing” which means that the team has a high level of autonomy and accountability. In the world of Scrum the team doesn’t need a manager to make sure they work properly.

The team in Scrum is typically five to ten people (In most cases). However, teams as large 15 are also known to work effectively. For software projects, this team will include analysts, developers, interface designers and even testers. The team builds the product, but they also provide input and ideas to the Product Owner about how to make the product better.

In real life, there may be scenarios where team members split their time between Scrum Projects and other projects. Though this is very possible, the team members would be more productive if they are fully dedicated to the scrum project at hand. Similarly, there may be situations where team members have to be changed when moving on from one sprint to another. Though this is inevitable, retaining the same team for subsequent sprints can be greatly beneficial in retaining the productivity of the team.

Projects with larger teams are organized as multiple Scrum Teams, each focused on a different aspect of the product development, with close coordination of their efforts.

• A Cross Functional Team which includes members with different skillsets like development, testing, business analysis etc. 
• Self-Organizing and Self Managing (No Project Manager is assigned to manage the work)
• Negotiates on delivery commitments with the Product Owner – one iteration/sprint at a time
• Has autonomy regarding how to reach these commitments
• Very collaborative
• Preferably co-located (in the same room or office) at least for the first few sprints
• Preferably a stable team instead of moving people between teams or splitting peoples time between teams
• Preferable team size 6-8 pax 
• Team has decision making authority on their work as well as the product scope being considered for the sprint

The Scrum Master:

The Scrum Master is one of the most important elements of Scrum Teams success. The Scrum Master does whatever is in their power to help the team succeed in their attempt at building the product.

The Scrum Master is not the manager of the team; instead, the Scrum Master serves the team, protects the team from outside interference, and guides the team’s use of Scrum. The Scrum Master makes sure everyone on the team understands and follows the practices of Scrum, and they help lead the organization through the often difficult change required to achieve success with Agile methods.

Since Scrum makes visible many impediments and threats to the team’s effectiveness, it’s important to have a strong Scrum Master working energetically to help resolve those issues, or the team will find it difficult to succeed. Scrum teams should have someone dedicated full-time playing the role of Scrum Master. In case of smaller teams, the same scrum master could play that role for multiple projects.

An Important Point to note here is that - The Scrum Master and the Product Owner Cannot and Should Not be the same individual. This is because; there may be times when the Scrum Master may have to push back on the Product Owner. A classic example would be when the Product Owner wants to introduce new requirements/deliverables when the Sprint is mid-way through.

• Facilitates the Scrum Process
• Resolves impediments
• Creates an environment conducive to team self-organization
• Captures empirical data to adjust forecasts
• Shields the team from external distractions 
• Enforces Timeboxes
• Maintains scrum artifacts 
• Does not have any authority over the team or decision making capability reg. the product 

Difference between a Scrum Master and a Project Manager:

The Scrum Master does not tell people what to do or assign tasks like a traditional project manager. The Scrum Master facilitates the process as well as supports the team as it organizes and manages itself. If a Project Manager is taking over the role of a Scrum Master he/she would need to significantly alter their mindset and style of interaction in order for the team to be successful with Scrum.

Other Participants in a Scrum Project Environment

Apart from these 3 Key participants in a Scrum Project, there are other roles in a Scrum Project Environment. They are:

Stakeholders – The term Stakeholder is a blanket term that includes customers, users, sponsors and everybody else who may be involved or impacted by the project. Though the Product Owner acts as the liaison between the scrum team and the business stakeholders in real-life the team may end up interacting with these stakeholders directly as well.

Scrum Governance Body/Group – Just like we have a PMO’s office in traditional project management world that sets up the standards and guidelines for Project Management in the Organization, the Scrum Governance Group will set up the guidelines and standards in the practice of Scrum in the organization.

Previous Article: History of Scrum

Next Article: A Typical Scrum Sprint

History of Scrum and why Scrum is Better

In the Previous Article we covered the basics of the Scrum Methodology. In this article we are going to cover the History of Scrum…

The Origins!!

In the early-mid 80’s, two people named Hirotaka Takeuchi and Ikujiro Nonaka wanted a better strategy for building products. They defined a flexible and all-inclusive strategy where the development team works as a coordinated unit to reach the common goal. They described this innovative approach as the “Rugby Approach”.

So, what is the Rugby Approach?

Have you ever watched a game of Rugby? The whole team has one goal – to move the ball towards the end-line as a collective unit. They keep passing the ball back-n-forth until they actually reach the end line.

Takeuchi and Nonaka felt that product development must be like a Rugby game where the team works as a collective unit instead of the traditional approach which can be compared to a “Relay Race”.

The Birth of Scrum…

Two Gentlemen - Ken Schwaber and Jeff Sutherland can be considered the founding fathers of the modern day Scrum Methodology. In the year 1995, they both elaborated on the Scrum Concept and its applicability to software development and presented the same at the Object Oriented Programming, Systems, Languages & Applications (OOPSLA) conference the same year in Austin, Texas.  

Since that point on, many experts and scrum practitioners have continued to refine the Scrum Concept and Methodology.

Why Scrum is Better

If you are an experienced Project Manager who is used to managing projects the traditional PM way, you may be wondering is Scrum Better? Are you?

I cant really say Scrum is the Best Project Management Methodology because not all projects are the same. If you have concrete requirements which are baselined and would not change over the duration of a project, the traditional plan & build approach will work just fine. But, if you are building something new which the business has never seen, using the Scrum Approach would be much better  because at the end of each Sprint, the customer is going to get a deliverable. Based on the csutomers feedback we can improve the product during the subsequent sprint cycles.

Lets say, you are building a new product over a period of 1 year and during the User-Acceptance Testing Phase (UAT) the customer realizes this isn’t what he wanted. One year worth of development, cost and everything else is down the drain. Instead, if you had a delivery that happened at the end of the 1^st month, the customer would’ve passed on his feedback immediately and we could’ve done course correction. Isn’t that a Benefit?

Previous Article: Scrum Basics

Next: Scrum Participants

Scrum Basics

 Scrum is a very popular Agile Project Management Methodology that can be used to manage projects, programs and portfolios of any size or industry or complexity. The purpose of this article is to give you an overview of Scrum.

What is Scrum?

Scrum is an Iterative and incremental project management framework that can deliver Significant Business Value quickly and throughout the project to the Customer/Stakeholder. Scrum is fast, adaptable, flexible and also very effective.

Each Iteration is called a “Sprint” or a “Scrum Cycle”.  A Scrum Project involves a collaborative effort to create a new product or service as defined in the Project Vision Statement. As you might be aware projects are impacted by the following:

• Scope
• Time
• Cost
• Quality
• Resources
• Organizational Capabilities and
• Other Limitations

Key Participants in the Scrum Project

There are 3 Key Participants in any Scrum Project. They are:

• The Scrum Team - This is a cross-functional, self-organized and high-performing team that works on the Project Deliverables. 
• The Product Owner - The Product Owner in a Scrum Project is the liaison between the Project Team and the Business Stakeholders. He maintains a list of project features/requirements that are ordered based on priority. His key purpose is to make sure the project team understands the requirements properly and validates the finished product for its “Fitness for Use” once the cycle is complete. He or she is also responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer
• The Scrum Master - The Scrum Master is the equivalent of a Project Manager to a regular project. He ensures that the Scrum Team is provided with an environment conducive to complete the project successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project and ensures that Scrum processes are being followed

There are other participants in a Scrum Project like – Business Stakeholders, Scrum Guidance Body etc.

Why Use Scrum

Below are some of the key reasons why you should consider Scrum for your Projects:

1. It is Adaptable – The Project can Incorporate Changes much more easily than regular projects.
2. It is Transparent – One of the founding principles of Scrum is transparency. All the information about the project is shared and easily available to all participants thereby making the whole process Transparent.
3. Delivers Quick and Continues Value to Stakeholders – Scrum Projects not only deliver value quickly (The first cycle deliverables), it continues to deliver value continuously throughout the project duration.
4. Customer Centric – With an iterative process, the customer is engaged continuously throughout the project and hence his needs and requirements are met better making scrum very customer centric
5. Collective Ownership – Each participant in a scrum project has his own set of responsibilities and are together responsible for the successful completion of the project. This cultivates collective ownership.

In the following few articles, we will learn more about Scrum… Watch out this space for more!!!

Next: History of Scrum and Why Scrum is Better