Search

A Step-by-step Guide to Implementing Scrum in Organizations

When I started my Agile journey, I was very much apprehensive about Scrum, because till now we experienced the comfort zone with the implementation of Waterfall methodology, even if it made us fail! Maybe that’s how we human beings are. We feel uneasy with the new changes around us as that changes need to implement from scratch. Looking at the market scenario two years back, there was a survey done by Version One which shows, 58% of the organizations adopted Scrum as their framework to work on the products, today, Scrum has expanded in its share in the market and is being widely used, and moreover, teams are now customizing it as per their need. Let’s see what is Scrum, exactly – in a simple language – it is a way of delivering quality product iteratively and incrementally in a time-box fashion. This is a simple illustration of what the Scrum implementors and others define it, moving with it, why not just explore what they say too- “Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”– Scrum.org“Scrum is an agile way to manage a project, usually software development. Agile software development with Scrum is often perceived as a methodology; but rather than viewing Scrum as methodology, think of it as a framework for managing a process.”– MountainGoatSoftware.comTo set this framework up, we need some roles to support this process, the roles include:Scrum MasterThe Scrum Master supports the team in boosting and streamlining the processes by which they can accomplish their objectives. They also shield the team from both internal and external interferences. Product OwnerThe Product Owner is responsible for maximizing the value of the products produced, they are the owners of the product backlog and makes sure that the backlog is healthy and prioritized.The Development TeamThe Development team is one who creates the product as a whole, they are actually involved in the coding, testing etc, to make sure a quality product is delivered in a time-boxed manner.  They are self-organizing, cross-functional team of people who together are responsible for all of the work necessary to produce a working software or product.Why Scrum? Interestingly, there are reasons behind the popularity of Scrum framework in the technological market, let us look at some-First and the foremost is, “delighted customers”, so far we have been talking about customer satisfaction but now we are one step ahead and focusing on delivering delight.Next, on the list is “improved return on investment”.  Most of the projects have witnessed reduced costs and faster results, which in turn gives confidence to the clients and upliftment to the teams. These look small when we just talk on paper but these are really big advantages of the Scrum that an organization can get.Though we have talked a lot about the benefits that Scrum provides, one must not mistake this as a magic wand that can cure all the problems. There might be scenarios where Agile is not a good fit for your product. It is really important to understand if Agile is the way to go for your product or not! There are many scenarios when we can say that Agile is all we need, to quote some, frequent requirement changes, it is not essential to expend months documenting requirements that may or may not result in what the client wants or is looking for. Next big reason can be, management support for the Agile framework and its philosophy of enabling teams. When we talk about adopting Agile, it is not just a bottom-up approach rather it should go in all directions and more focused from top-to-bottom. If the top management is aligned with the change and merge it with their goals, it will work wonders!Now that we have gone past through the evaluation of Agile adoption, let’s move back quickly to the discussion we originally started with – Scrum!!What if you are asked to implement Scrum for your product? How comfortable will you be to go ahead with this move? I know you might be thinking of all those points that might go into this, no problem, let’s look at it together. For moving about how to implement Scrum, there are few pre-requisites which you are already aware of: Be ready with your product backlogThis is a very essential step in Scrum implementation. To start this up, you have to identify your product owner who can actively work with the Stakeholders and create a product backlog which contains requirements that can deliver value and also are prioritized as per the market need. A Product Owner takes up the ownership of the product backlog. A product backlog usually comprises two kinds of work items:Epics - High-level requirements that are very coarsely outlined without much detail.Stories - More comprehensive requirements for what should be doneDuring the development phase, the teams might encounter some requirements which were not covered in the backlog but are needed, so the team has all the rights to add items on the backlog but only the product can prioritize them.Let’s build our teamDefining a Scrum team is again a crucial step, as this is the team who is required to work closely bound and deliver a quality product. The team will comprise of 5-9 team members which include developers, testers, support, designers, business analysts, etc. All the members in a team will work towards a common goal as set in the commitment. Usually, we strive for creating a cross-functional and self-organizing team, getting the former is quite easy and doable but don’t worry if making them self-organized is taking time. Don’t panic, it really takes a lot of effort and time to churn out a self-organized team!Who will be our Scrum Master?So far, we have the product backlog and the team to work on it, but, where is the person who will make all this go smoothly without interruptions, who will make sure the team is encouraged and being involved productively, who will make sure the team realizes their potential, (the list is pretty long ….). In short, let’s get a Scrum Master. The Scrum Master ensures that the Scrum team is effective and progressive. The person will help the team in planning the work for the coming sprints. Here comes TIME-BOXING in ScrumWhen we talk about Scrum, we talk about Sprints. A sprint is a time-box for the Scrum team to commit and deliver items in a short span of time. It usually ranges between a week to a month, whatever the length has been locked for the team, it stays the same throughout. The Sprint starts with a commitment from a team on the backlog items, they develop, code, test, etc. and provide a demonstration at the end of the Sprint. The Sprint closes with the retrospective ceremony where the team reflects on what went well and how can they improve further. Get, Set, Go!! – First drive with the SprintThe Sprint starts with the first gear – Sprint Planning – here the team picks items from the list (typically from the top in the backlog). They set their Sprint goal and start working on the items, during the course of the Sprint, the team will regroup each day for a quick meetup called Daily Standup/Daily Scrum to talk about their progress and if there’s anything blocking their path of delivery. Once in a while, they will stop by, to talk about the next inline items for the upcoming sprint which is called the Backlog Grooming/Story Time. On the closure day, the team will demo the items they have worked on to the Stakeholders or the Product Owner. The Sprint gets over with the last regrouping called the Retrospective where they inspect how they did and work on the ideas to make it better by adapting to it.How we did on the numbersIt is really important to measure our success and failures, it gives us a chance to improve. This applies to Scrum as well. Here, we talk about our burndown charts, yes, these charts can be compared to the ultrasounds or the X-rays we have, they show how we did as a team, anyone can read out the issues and the brownies from our charts. The Scrum Master can understand, just by looking at the burndown, how the team did, the scope change, the blockers and how the team adapted to the new environment. It should be one of the goals for a team to reach Zero by the end of the Sprint in the chart.Overall, I can say, Scrum is really effective if implemented with the right spirit and the focused direction. There’s a Scrum implementation plan which has to be laid out. We have many success stories where Scrum helped the teams deliver the products on time with customer delight. The dynamic participation, teamwork, and collaboration in Scrum Teams make for a more pleasant place to work and most importantly if your teams are happy, they will go to any lengths to make your customer happy. I have been working with the Scrum teams since last 10 years and I must say, they are more contented. So it’s not just about the product or the organization, it is also about the ‘PEOPLE’, it is about us!Master Scrum and learn more about the Scrum roles and process to deliver the best to the users. Be a better Scrum Master with our Agile and Scrum online practice test! 

A Step-by-step Guide to Implementing Scrum in Organizations

6K
  • by Deepti Sinha
  • 09th Jan, 2019
  • Last updated on 11th Mar, 2021
  • 6 mins read
A Step-by-step Guide to Implementing Scrum in Organizations

When I started my Agile journey, I was very much apprehensive about Scrum, because till now we experienced the comfort zone with the implementation of Waterfall methodology, even if it made us fail! Maybe that’s how we human beings are. We feel uneasy with the new changes around us as that changes need to implement from scratch. 

Looking at the market scenario two years back, there was a survey done by Version One which shows, 58% of the organizations adopted Scrum as their framework to work on the products, today, Scrum has expanded in its share in the market and is being widely used, and moreover, teams are now customizing it as per their need. 

Let’s see what is Scrum, exactly – in a simple language – it is a way of delivering quality product iteratively and incrementally in a time-box fashion. This is a simple illustration of what the Scrum implementors and others define it, moving with it, why not just explore what they say too- 

“Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”

 Scrum.org


“Scrum is an agile way to manage a project, usually software development. Agile software development with Scrum is often perceived as a methodology; but rather than viewing Scrum as methodology, think of it as a framework for managing a process.”

 MountainGoatSoftware.com

To set this framework up, we need some roles to support this process, the roles include:

Scrum Roles
Scrum Master

The Scrum Master supports the team in boosting and streamlining the processes by which they can accomplish their objectives. They also shield the team from both internal and external interferences. 

Product Owner

The Product Owner is responsible for maximizing the value of the products produced, they are the owners of the product backlog and makes sure that the backlog is healthy and prioritized.

The Development Team

The Development team is one who creates the product as a whole, they are actually involved in the coding, testing etc, to make sure a quality product is delivered in a time-boxed manner.  They are self-organizing, cross-functional team of people who together are responsible for all of the work necessary to produce a working software or product.


Why Scrum? 

Interestingly, there are reasons behind the popularity of Scrum framework in the technological market, let us look at some-

  • First and the foremost is, “delighted customers”, so far we have been talking about customer satisfaction but now we are one step ahead and focusing on delivering delight.
  • Next, on the list is “improved return on investment”.  Most of the projects have witnessed reduced costs and faster results, which in turn gives confidence to the clients and upliftment to the teams. These look small when we just talk on paper but these are really big advantages of the Scrum that an organization can get.

Though we have talked a lot about the benefits that Scrum provides, one must not mistake this as a magic wand that can cure all the problems. There might be scenarios where Agile is not a good fit for your product. It is really important to understand if Agile is the way to go for your product or not! 

There are many scenarios when we can say that Agile is all we need, to quote some, frequent requirement changes, it is not essential to expend months documenting requirements that may or may not result in what the client wants or is looking for. 

Next big reason can be, management support for the Agile framework and its philosophy of enabling teams. When we talk about adopting Agile, it is not just a bottom-up approach rather it should go in all directions and more focused from top-to-bottom. If the top management is aligned with the change and merge it with their goals, it will work wonders!

Now that we have gone past through the evaluation of Agile adoption, let’s move back quickly to the discussion we originally started with – Scrum!!

What if you are asked to implement Scrum for your product? How comfortable will you be to go ahead with this move? I know you might be thinking of all those points that might go into this, no problem, let’s look at it together. For moving about how to implement Scrum, there are few pre-requisites which you are already aware of:

 Be ready with your product backlog

Prerequisites to implement Scrum

This is a very essential step in Scrum implementation. To start this up, you have to identify your product owner who can actively work with the Stakeholders and create a product backlog which contains requirements that can deliver value and also are prioritized as per the market need. A Product Owner takes up the ownership of the product backlog. A product backlog usually comprises two kinds of work items:

  • Epics - High-level requirements that are very coarsely outlined without much detail.
  • Stories - More comprehensive requirements for what should be done

During the development phase, the teams might encounter some requirements which were not covered in the backlog but are needed, so the team has all the rights to add items on the backlog but only the product can prioritize them.

Let’s build our team

Defining a Scrum team is again a crucial step, as this is the team who is required to work closely bound and deliver a quality product. The team will comprise of 5-9 team members which include developers, testers, support, designers, business analysts, etc. All the members in a team will work towards a common goal as set in the commitment. 

Usually, we strive for creating a cross-functional and self-organizing team, getting the former is quite easy and doable but don’t worry if making them self-organized is taking time. Don’t panic, it really takes a lot of effort and time to churn out a self-organized team!
The Agile-Scrum Framework

Who will be our Scrum Master?

So far, we have the product backlog and the team to work on it, but, where is the person who will make all this go smoothly without interruptions, who will make sure the team is encouraged and being involved productively, who will make sure the team realizes their potential, (the list is pretty long ….). 

In short, let’s get a Scrum Master. The Scrum Master ensures that the Scrum team is effective and progressive. The person will help the team in planning the work for the coming sprints. 

Here comes TIME-BOXING in Scrum

When we talk about Scrum, we talk about Sprints. A sprint is a time-box for the Scrum team to commit and deliver items in a short span of time. It usually ranges between a week to a month, whatever the length has been locked for the team, it stays the same throughout. The Sprint starts with a commitment from a team on the backlog items, they develop, code, test, etc. and provide a demonstration at the end of the Sprint. The Sprint closes with the retrospective ceremony where the team reflects on what went well and how can they improve further. 

Get, Set, Go!! – First drive with the Sprint

The Sprint starts with the first gear – Sprint Planning – here the team picks items from the list (typically from the top in the backlog). They set their Sprint goal and start working on the items, during the course of the Sprint, the team will regroup each day for a quick meetup called Daily Standup/Daily Scrum to talk about their progress and if there’s anything blocking their path of delivery. 

Once in a while, they will stop by, to talk about the next inline items for the upcoming sprint which is called the Backlog Grooming/Story Time. On the closure day, the team will demo the items they have worked on to the Stakeholders or the Product Owner. The Sprint gets over with the last regrouping called the Retrospective where they inspect how they did and work on the ideas to make it better by adapting to it.

How we did on the numbers

It is really important to measure our success and failures, it gives us a chance to improve. This applies to Scrum as well. Here, we talk about our burndown charts, yes, these charts can be compared to the ultrasounds or the X-rays we have, they show how we did as a team, anyone can read out the issues and the brownies from our charts. The Scrum Master can understand, just by looking at the burndown, how the team did, the scope change, the blockers and how the team adapted to the new environment. It should be one of the goals for a team to reach Zero by the end of the Sprint in the chart.

Overall, I can say, Scrum is really effective if implemented with the right spirit and the focused direction. There’s a Scrum implementation plan which has to be laid out. We have many success stories where Scrum helped the teams deliver the products on time with customer delight. 

The dynamic participation, teamwork, and collaboration in Scrum Teams make for a more pleasant place to work and most importantly if your teams are happy, they will go to any lengths to make your customer happy. 

I have been working with the Scrum teams since last 10 years and I must say, they are more contented. So it’s not just about the product or the organization, it is also about the ‘PEOPLE’, it is about us!

Master Scrum and learn more about the Scrum roles and process to deliver the best to the users. Be a better Scrum Master with our Agile and Scrum online practice test

Deepti

Deepti Sinha

Blog Author

Deepti is an Agile Coach by profession and Freelance Trainer with over 11 years of industry experience working primarily with healthcare & finance clients in delivering business. She has played a wide variety of roles in the graph of her career, whether it be, management, operations or quality. She likes reading fiction, management and loves to write her experiences. Her colleagues mostly describe her as very detail oriented person with a knack of creativity and imagination. And yes, she loves feedback more than her coffee!!

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Combination Of Agile & DevOps – The Roots

Agile and DevOps are two notions that originate from the same schools of thought, but whose paths now have digressed. However, a major amount of confusion still remains within the IT services industry with regards to the relationship between the two and has emerging agile & devops trends in 2017. Hence, it is of value to look at the origins of each and to clarify the disparities between them. ‘Tell me what you want, what you really really want!!’ Does the tune ring a bell? Back in the 1990s, the Spice Girls were expressing to the world what they really really wanted, and similarly business owners and corporate leaders were doing pretty much the same, indicating what they wanted to software developers who were working on enabling these organizations through technology. Unfortunately, these business owners were not as lucky as the Spice Girls. More often than not they really didn’t get what they wanted. By the time business requirements were properly understood, validated and finally realized through software products the business requirements more or less had changed.  This was mainly due to the ‘application delivery lag time period’ that sometimes went up to three years. The result of the aforementioned delay from concept to realization meant that a large proportion of projects were stopped before completion. Even then, those that eventually reached the finish line more often than not did not meet the end users’ expectations.  The introduction of Agile – The change-driven management approach The search was on for a more lightweight approach to solution delivery and the result was ‘agile’ – a project management approach with a series of new concepts with regards to collaboration between business owners and the implementation team including UI / UX engineers, developers and even QA engineers. Instead of eliciting, documenting and signing off all the requirements up front and getting it signed off before work began, the focus shifted to delivering value through increments of functional software that would evolve over time. The results indicated that the software implementation team had become more productive, businesses could be more responsive in responding to queries of the implementation team, and user demands could be met more efficiently. However, problems remained. The agile approach didn’t always deliver on the promise of continuous, seamless software development. Blockers continued to exist. So, what is DevOps? The first thing to note is the fact that DevOps is not an individual tool or a suite of solutions but more of a philosophy whose primary purpose is to reduce the distance between the worlds of software development and IT operations. It defines how the original concepts of agile have moved downstream to the level of infrastructure and operations. The DevOps concept sounds relatively straightforward, but in reality it is a little bit more complicated. Software development and IT operations have historically had very different approaches. Software developers appreciate the ability to change things quickly and often they do end up changing things rapidly. In the meantime IT operators focus on stability and on minimizing alteration. This philosophical disparity has often resulted in conflicts. Thus, one of the main challenges of DevOps is to ensure that this conflict decreases before it affects the businesses. Importance of DevOps Principles For this very reason indicated above, it is very important to consider and act up on the core principles of DevOps. They are, Close collaboration and communication between developers, system operators and software testers Continuous integration that requires developers and operators to commit to changes more frequently Continuous delivery to increase the team’s speed and efficiency while enabling early detection of bugs Continuous deployment to ensure new developments can be released without system downtime The DevOps philosophy goes hand-in-hand with the delivery processes described in ITIL Framework in terms of support and IT services management. DevOps can therefore be seen as a way to implement ITIL processes in such a manner that meets the demands placed on systems today.  
3323
Combination Of Agile & DevOps – The Roots

Agile and DevOps are two notions that originate fr... Read More

Metrics that matters for DevOps Success

DevOps is generally introduced for the development teams to speed up the software delivery. DevOps is considered as a step beyond Agile. Many enterprises accepted DevOps as a part of software delivery process from planning, developing, deploying and updating an application, according to reviews. In this competitive world, DevOps allows businesses to speed up with the rapid pace of demands by the customers.Here are the top Ways to Obtaining Business Benefits of DevOps. Customers of today demand quality as well as security based products. DevOps, making the best use of its principles, provides superior quality and lowers the risk. On the contrary, in traditional software development approach, increased speed often results in poor quality and increased vulnerabilities. Why are metrics essential? Most organizations implement DevOps because of the demand for quality, time improvement and the need for defect-free products. Since DevOps has no specified framework, there exist a few standard ways to measure DevOps success. How do you find out how well it can work? How will you come to know whether it is working or not? The answer to this question, and the solution to all the existing problems, is the use of Metrics. Metrics are essential to stay in sync with DevOps. DevOps will be used extensively which therefore requires continuous treatment. But if you are not measuring its outcomes, you cannot understand how to incorporate DevOps in your organization. The focus of DevOps metrics is on deployment, operations, and support (feedback). Let us have a look at the Devops metrics which will lead to improved delivery performances. People: People are the major elements of the DevOps process. People-oriented metrics measure the things like yielding, capacity and response time. People are the hardest element of DevOps. So always start with the phase ‘People’. Process: In some ways, DevOps is considered as a process of  continuous deployment. There are many process-oriented metrics. Development to deployment is a large process-oriented metrics. Process metrics can be the measurement of speed, appropriateness and effectiveness. Technology: Technology metrics also plays a major role in DevOps. It measures the things like uptime (time during which the computer performs operations), network and support, and failure rate. Deployment (or Change) Frequency: DevOps metrics includes continuous deployment. Updated software deployment in every few days can be possible with fast feedback and piecemeal development. In a DevOps environment, deployment frequency can be measured in terms of the response time, the teamwork, the developer capacities, development tools and the overall efficiency. Change Lead Time: Change lead time is the time period between the initialization phase to the deployment phase. In DevOps, it is a measure of development process efficiency, code and the development systems’ complexity, and also of team capabilities. A protracted ‘change lead time’ is an indicator of an inefficient deployment system. Change Failure Rate: One of the main goals of DevOps is to do frequent deployment with less failure rates. Failure rates metrics should be decreased over time, as the experience and the capabilities of the team and developers get increased. If the frequency of failure is very high, it is definitely a red flag, as it gives rise to problems in the overall DevOps process. Mean Time to Recover: Time taken between ‘recovering the failure’ from the ‘failure’ is known as Mean Time to Recover (MTTR). It can be fragmented into three phases- detection, diagnosis and recovery phases. MTTR metrics is the sign of a good teamwork which identifies how effectively the teams handle the changes, and also, how collaboratively they do so. By all means, this metric is becoming a trend for DevOps to remodel organizational processes in a better way.
Metrics that matters for DevOps Success

DevOps is generally introduced for the development... Read More

Agile and DevOps Or Agile vs DevOps: Differences

Agile is the standard in today’s application development world. Development teams are adopting it over the last 10 years, as it has been proved to be more efficient methodology of getting quality software. Agile has improved user experience by frequently rewarding with focussed goals and quick delivery. In addition to this, the broad use of DevOps in Agile methodology has made it a more compelling approach for IT commercials. In this context, it is important to know that Agile is not DevOps, and DevOps is not Agile. It is difficult to achieve success in DevOps, if Agile practices are not followed. While Agile can make sense independent of DevOps, it can be more complete when accompanied by DevOps practices.Here are the emerging Agile and DevOps Trends. Many people have set their minds about Agile, that Agile means Scrum and DevOps means continuous delivery. This simplification creates unnecessary confusion between Agile and DevOps, making people think that they are perfectly compatible. So, let us have a look at the practical connections between Agile and DevOps. Planning for Unplanned work: In the DevOps circle, those using Agile acknowledges that Scrum is used to track the planned work. Tasks like releasing updated system, performing system upgrades etc, can be planned. On the other hand, the operations like performance spikes, system expiry, and standard security, can be unplanned. These types of tasks need immediate response. You cannot wait for the next sprint planning session. For this reason, many organizations embrace DevOps (more than Scrum and Kanban), which helps to track both kinds of work. Before, there were priorities from multiple masters, but now a single set of priorities are in use. Similarly, for a long list of assigned work, the time period is planned to accomplish the work. These lightweight management practices by Scrum make a huge difference for a team. Speed vs Risk: Teams using Agile with or without DevOps have to remember that, to support the rapid change, a sound application structure and a solid foundation are mandatory. Applications must have good underlying framework that must be used constantly by the team members. In the DevOps context, the teams must make sure that the changes which are made to the architecture should not introduce any risk. Also, there should not be any hidden side-effects associated with the changes, because the iterative process consists of regular changes in the architecture. So you should be concerned about the risks associated with each and every change made. Only with this type of work will you get rapid delivery without any risk. Agile and Quality: Both Agile and DevOps help develop an application fast, keeping sound structure and risk-free application.  But neither of them concentrates on the quality of the product. Mostly, IT organizations rely on the ‘fail fast’ principle- “ Early failures cost less to fix”. But with this, only fast deployments can be maintained, not quality. Agile produces applications that fit better with the desired requirements and can adapt quickly to respond to the requirement changes made on time, during the project life. DevOps, along with the automation and early bug removal, contributes to creating better quality. Developers must follow Coding and Architectural best practices to  embed quality in the applications. Agile and DevOps should try reach the next level to become highly effective within the organizations. They must conform to the industry standards using Agile and DevOps practices, to allow the development team to improve quality, make delivery faster and avoid software risks.
1442
Agile and DevOps Or Agile vs DevOps: Differences

Agile is the standard in today’s application dev... Read More

Useful links