Search

Four Scrum Events, Demystified

It's Thanksgiving month! Time to show our gratitude and be thankful. Don't you think we should be thankful for the new ways of working and how they are supporting our end-to-end deliveries? The world is going through a crisis with the Covid pandemic, yet human resources across the world are working from home/makeshift offices and making occasional office visits, while delivering quality solutions and collaborating with people across borders to work as a team. This is a true example of being Agile and adapting to the new environment. Organizations that had already adopted the Agile route pre-pandemic found it easier to transition to the new normal. While those that have not yet gone the Agile way have realized the shortcomings of the traditional ways of working, that prevent them from quickly adapting to changing market scenarios and competition. It is evident that going Agile is the only way that organizations can cope with the future and ensure that business outcomes are met.A quick overview of what is Scrum and its rolesAccording to the “14th Annual State of Agile Report”, Scrum stands head and shoulders above other Agile Methodologies. The reasons are obvious. Scrum is a simple and lightweight model that instills values needed to deliver solutions that work. There are multiple definitions around it but all of them narrow down to its being easy and lightweight, helping the team to work together and deliver quality products. As stated by Scrum.org “Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”. Scrum has been co-created by Ken Schwaber and Jeff Sutherland, who have recently launched a new version of the Scrum Guide 2020.  "Scrum is not a methodology. Scrum implements the scientific method of empiricism" – Scrum.org.  ‘Scrum’ is a term often used in the sport of Rugby where teams learn through their experiences, collaboratively work on the solution, and retrospect on continuous improvement. Often, Scrum is equated to Agile, but there is a subtle difference between the two. Agile is a mindset while Scrum is a framework under the Agile umbrella.3 Pillars of ScrumThe magic ingredients that make Scrum popular are the pillars that hold the values, pave the way for teamwork, and allow the team to check and readjust to the pace. The foundation of scrum is based on empiricism which emphasizes that knowledge comes through experience and with the decision-making capabilities of a team. The three pillars of scrum are Transparency, Inspection, and Adaption. Transparency - Scrum is more about making things visible to all people involved. It starts with the vision and ends with the deliverables. Each individual is responsible for making things visible loud and clear with no gap in the communication of the information or the content. Inspection - Everyone involved in the scrum process needs to inspect the scrum artifacts, namely, the product backlog, sprint backlog, team board, etc. to check if they are aligned with the Sprint goal, and to check whether the Sprint goal is itself in line with the vision.Adaption - With inspection, if the team finds any deviation in the plan, or if during the inspection they feel they need to change the way they work, they can come up with new ways to adapt. While this is usually done in the retrospective meeting, the best practice is to inspect and adapt as and when required.https://www.visual-paradigm.com/servlet/editor-content/scrum/what-are-scrum-three-pillars/sites/7/2018/10/01-three-pillars-of-scrum.png Scrum roles  Scrum Master - The Scrum master is the servant leader for the team who shields the team from outer interferences. He or she is a go-to person who is always ready to support and guide the scrum team with best practices, supports the product owner through coaching on handling and creating a healthy backlog. Scrum Masters are the gatekeepers of the process and if required, they can suggest the best approach for better implementation of Agile. The development team - This is a self-organized, cross-functional team that generates the deliverables for the stakeholder, based on the requirements received and discussed with the product owner. They come up with ideas to improve the quality and keep their skills upgraded as needed by the project. Product Owner - The product owner is a member of an agile team responsible for creating the backlog, helping the teams with the right understanding of the requirement. He or she also ensures that a quality product gets delivered to the stakeholders. https://www.knowledgehut.com/blog/agile/agile-scrum-roles-responsibilities  Who attends Scrum Events? Scrum events are an important part of the process. These events or meetings define the way forward, help the team to pause, reflect, and re-adjust the course of action. Scrum events are attended by the development team, the scrum master, and the product owner. Optionally the management and stakeholders can join as observers. In the Sprint demo/review, the management and stakeholders are active participants, and they engage in conversations and also provide clarity and feedback on the deliverables. This grid represents the participation across the roles: RoleSprint PlanningDaily ScrumSprint ReviewSprint RetrospectiveScrum MasterYesOptional Yes(but usually always there)YesYesDevelopment TeamYesYesYesYesProduct OwnerYesOptionalYesYesStakeholders (SMEs, management, clients,etc)OptionalOptionalYesNo What are the four Scrum events? Let's drive through each scrum event and discuss every minute detail that can help in running an effective meeting. It is important to understand the purpose of each meeting, why it is done, what is the benefit, the time-frames, and the best practices around each scrum event. Sprint Planninghttps://medium.com/@KnowledgeHut/from-creation-to-execution-how-sprint-backlog-helps-scrum-teams-6b01ffaf1eb Attendees  The sprint planning meeting is attended by the development team, the scrum master, and the product owner. These roles are mandatory for an effective sprint planning meeting. Anyone apart from these roles can join the meeting as an observer or speak whenever asked to. It is good to have SMEs in the meeting while planning. When? Duration? The sprint planning meeting is the first thing that happens at the start of a new Sprint and it is time-boxed to eight-hours for Sprints that take a month. But for many teams that do two-week sprints, two hours is sufficient. To be able to do sprint planning in a limited amount of time, it is important to organize refinement well. Purpose Sprint planning generates the road map and the goal for the entire Sprint. Being the first activity in the Sprint, the team comes together and pulls the highest priority item from the product backlog, clarifies any doubts, and adds them to the Sprint backlog. The idea is to come up with a Sprint goal that is in agreement with the product owner and create a doable list of work items commonly known as Sprint backlog. The meeting is facilitated by the scrum master who makes sure the team focuses on the deliverables of the meeting and the intended outcome is met. If there is any disagreement among the team or with the product owner, the Scrum master can use conflict resolution techniques to resolve deadlocks. The Scrum master also keeps the time in check and helps the team to follow the time box. The Product Owner is responsible for keeping the Product Backlog ready for discussion before Sprint Planning commences. This implies adding acceptance criteria, refining requirements, and essential details for the development team to precisely estimate the effort. Best Practice  Ensure that backlog items are sufficiently refined before Sprint planning starts. Part of refinement is estimating the size of backlog items, adding details and splitting large items into smaller ones. Any backlog item which requires a lot of clarification and discussion, should not be a part of sprint planning. It also means the story is not ‘Ready’. While planning the sprint, the team should take into account any leave, holidays, or other activities that can impact the sprint commitments. Breakdown of tasks should be done in sprint planning. Daily Scrum (Daily Standup) https://www.scrum.org/resources/blog/three-things-make-daily-scrum-waste-time-and-three-potential-solutions Attendees The daily scrum is attended by the development team, the scrum master, and the product owner. For mature agile teams, the scrum master can become optional sometimes. When? Duration? The daily scrum meeting occurs every day, same time, same place for no more than 15 minutes. Purpose The daily stand-up meeting allows the scrum team to discuss the current state. It is the time to inspect if the team is moving towards a Sprint goal or if there's any need to recourse the action. As the name suggests, it is a daily meeting which is ideally done while standing to make it quick. A common way of conducting a daily Scrum is to let each member answers 3 questions: What I did yesterday? What is the plan for today? Are there any impediments? The meeting is facilitated by the scrum master and is done while looking at the task board or the Sprint board for better transparency and visibility of the current state. This meeting should not be treated as a status meeting but as an opportunity to inspect and adapt on a daily basis. Everyone in the team gets a chance to talk about their deliverables and challenges while respecting the other’s view.A common agreement in teams is that only one person speaks at a time.  Best Practice Timeboxing is key to the event, the Scrum Master should keep track of the time. The focus should not be on finding the resolutions, any issue should be taken care of in the ‘sidebar’ It should happen at the same time and same place. Focus ONLY on what is relevant to achieve the Sprint Goal as a team. Sprint Review  https://startinfinity.com/product-management-framework/scrum-sprint/sprint-review-vs-sprint-retrospective Attendees The complete Scrum Team attends the sprint review along with stakeholders such as end-users, customers, management and other associated verticals (marketing, sales, support). It is important that the most relevant stakeholders are requested to attend and give their feedback, as varied feedback is vital for producing brilliant products. The Product Owner and Scrum Master should sync up prior to the meeting to discuss who needs to be involved to ensure that everyone is informed in advance. When? Duration? Sprint Review happens at the end of every sprint. In addition to sprint reviews, it is often a good idea to get more frequent feedback from stakeholders during sprints instead of only at the end. The duration of sprint reviews is at most three hours for a sprint of a month. But for many teams that do two-week sprints, one hour is sufficient. Purpose Sprint Review is the time where the development team showcases their efforts put to convert the raw requirement into something useful for the client. Stakeholders get a demonstration of the developed requirements as requested by them; they provide their feedback after looking at the deliverables which help to improve the product. Whatever the team presents in the sprint review meeting should meet the ‘Definition of Done’ as agreed between both – the development team and the stakeholders. The focus of the sprint review should be more on value delivery rather than points delivery. This, again, gives a platform to the team to inspect and adapt to create better solutions. Best Practice The meeting should have a clearly defined agenda as to what the stakeholders should expect. The most valuable feedback should be added to the product backlog and prioritized by the Product Owner. Timeboxing is critical while involving the stakeholders. A dry run before the actual sprint review helps to build confidence. Sprint Retrospective  https://startinfinity.s3.us-east-2.amazonaws.com/t/seLlg2lgmskxNDobnJ5kVvyy0YwukAenpsSd6bzM.png Attendees The sprint retrospective is attended only by the scrum team which consists of the scrum master, the development team, and the product owner. When? Duration? This is the last event of any Sprint and happens on the last day of the Sprint. The duration of the Sprint review typically ranges between one hour or two hours for a Sprint of two weeks. Purpose The sprint retrospective is a time to reflect and introspect/retrospect on what went well, what didn't and how it can be improved for future sprints. The focus is on inspection and creating a course of action, for better Sprints moving forward. This event helps the team voice out their concerns, their appreciations or any improvements they want to see. The scrum master creates a safe environment to help the team come up with points they like or dislike and tries to create a neutral situation. The feedback from the team is collected and the action items are derived from the owners associated with each of them. At times the team might come up with a long list, in such cases, the Scrum Master should help the team prioritize and narrow down the few high-priority actionable items. The focus of the retrospective should not be always on the product but also on the process and inter-team relationships. Best Practice The meeting should initiate on a lighter note with some ice-breakers to help the team adjust to the temperature of the room Trying out theme helps as it generates new ideas and makes non-vocal people speak up their minds. The scrum master should try ways to callout the fact that conflicts are not always bad. Quite often, some team members hold up their opinion due to fear of conflicts. Starting the meeting with previous action items builds trust in the process as they are being heard. Conclusion Scrum events, if done in the right spirit, create an empirical behavior amongst teams. The Scrum master should make sure that the team understands the why, what and how of each event. These events also help to create a flow of communication and provide transparency at every level. Please share your ideas and your experiences working with agile teams around the scrum events. 

Four Scrum Events, Demystified

8K
  • by Deepti Sinha
  • 12th Dec, 2020
  • Last updated on 22nd Jan, 2021
  • 8 mins read
Four Scrum Events, Demystified

It's Thanksgiving month! Time to show our gratitude and be thankful. Don't you think we should be thankful for the new ways of working and how they are supporting our end-to-end deliveries? The world is going through a crisis with the Covid pandemic, yet human resources across the world are working from home/makeshift offices and making occasional office visits, while delivering quality solutions and collaborating with people across borders to work as a team. This is a true example of being Agile and adapting to the new environment. Organizations that had already adopted the Agile route pre-pandemic found it easier to transition to the new normal. While those that have not yet gone the Agile way have realized the shortcomings of the traditional ways of working, that prevent them from quickly adapting to changing market scenarios and competition. It is evident that going Agile is the only way that organizations can cope with the future and ensure that business outcomes are met.

A quick overview of what is Scrum and its roles

According to the “14th Annual State of Agile Report”, Scrum stands head and shoulders above other Agile Methodologies. The reasons are obvious. Scrum is a simple and lightweight model that instills values needed to deliver solutions that work. There are multiple definitions around it but all of them narrow down to its being easy and lightweight, helping the team to work together and deliver quality products.

 As stated by Scrum.org “Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”. Scrum has been co-created by Ken Schwaber and Jeff Sutherland, who have recently launched a new version of the Scrum Guide 2020.  

"Scrum is not a methodology. Scrum implements the scientific method of empiricism" – Scrum.org.  

‘Scrum’ is a term often used in the sport of Rugby where teams learn through their experiences, collaboratively work on the solution, and retrospect on continuous improvement. Often, Scrum is equated to Agile, but there is a subtle difference between the two. Agile is a mindset while Scrum is a framework under the Agile umbrella.

3 Pillars of Scrum

The magic ingredients that make Scrum popular are the pillars that hold the values, pave the way for teamwork, and allow the team to check and readjust to the pace. The foundation of scrum is based on empiricism which emphasizes that knowledge comes through experience and with the decision-making capabilities of a team. The three pillars of scrum are Transparency, Inspection, and Adaption. 

  • Transparency - Scrum is more about making things visible to all people involved. It starts with the vision and ends with the deliverables. Each individual is responsible for making things visible loud and clear with no gap in the communication of the information or the content. 
  • Inspection - Everyone involved in the scrum process needs to inspect the scrum artifacts, namely, the product backlog, sprint backlog, team board, etc. to check if they are aligned with the Sprint goal, and to check whether the Sprint goal is itself in line with the vision.
  • Adaption - With inspection, if the team finds any deviation in the plan, or if during the inspection they feel they need to change the way they work, they can come up with new ways to adapt. While this is usually done in the retrospective meeting, the best practice is to inspect and adapt as and when required.

https://www.visual-paradigm.com/servlet/editor-content/scrum/what-are-scrum-three-pillars/sites/7/2018/10/01-three-pillars-of-scrum.png 

Scrum roles 

  1. Scrum Master - The Scrum master is the servant leader for the team who shields the team from outer interferences. He or she is a go-to person who is always ready to support and guide the scrum team with best practices, supports the product owner through coaching on handling and creating a healthy backlog. Scrum Masters are the gatekeepers of the process and if required, they can suggest the best approach for better implementation of Agile.
  2. The development team - This is a self-organized, cross-functional team that generates the deliverables for the stakeholder, based on the requirements received and discussed with the product owner. They come up with ideas to improve the quality and keep their skills upgraded as needed by the project.
  3. Product Owner - The product owner is a member of an agile team responsible for creating the backlog, helping the teams with the right understanding of the requirement. He or she also ensures that a quality product gets delivered to the stakeholders.

https://www.knowledgehut.com/blog/agile/agile-scrum-roles-responsibilities  

Who attends Scrum Events? 

Scrum events are an important part of the process. These events or meetings define the way forward, help the team to pause, reflect, and re-adjust the course of action. Scrum events are attended by the development team, the scrum master, and the product owner. Optionally the management and stakeholders can join as observersIn the Sprint demo/review, the management and stakeholders are active participants, and they engage in conversations and also provide clarity and feedback on the deliverables. This grid represents the participation across the roles: 

RoleSprint PlanningDaily ScrumSprint ReviewSprint Retrospective
Scrum MasterYesOptional Yes(but usually always there)YesYes
Development TeamYesYesYesYes
Product OwnerYesOptionalYesYes
Stakeholders (SMEs, management, clients,etc)OptionalOptionalYesNo

What are the four Scrum events? 

Let's drive through each scrum event and discuss every minute detail that can help in running an effective meeting. It is important to understand the purpose of each meeting, why it is done, what is the benefit, the time-frames, and the best practices around each scrum event.

Sprint Planning


https://medium.com/@KnowledgeHut/from-creation-to-execution-how-sprint-backlog-helps-scrum-teams-6b01ffaf1eb 

Attendees  

The sprint planning meeting is attended by the development team, the scrum master, and the product owner. These roles are mandatory for an effective sprint planning meeting. Anyone apart from these roles can join the meeting as an observer or speak whenever asked to. It is good to have SMEs in the meeting while planning. 

When? Duration? 

The sprint planning meeting is the first thing that happens at the start of a new Sprint and it is time-boxed to eight-hours for Sprints that take a monthBut for many teams that do two-week sprints, two hours is sufficient. To be able to do sprint planning in a limited amount of time, it is important to organize refinement well. 

Purpose 

Sprint planning generates the road map and the goal for the entire Sprint. Being the first activity in the Sprint, the team comes together and pulls the highest priority item from the product backlog, clarifies any doubts, and adds them to the Sprint backlog. The idea is to come up with a Sprint goal that is in agreement with the product owner and create a doable list of work items commonly known as Sprint backlog. The meeting is facilitated by the scrum master who makes sure the team focuses on the deliverables of the meeting and the intended outcome is met. If there is any disagreement among the team or with the product owner, the Scrum master can use conflict resolution techniques to resolve deadlocks. The Scrum master also keeps the time in check and helps the team to follow the time box. The Product Owner is responsible for keeping the Product Backlog ready for discussion before Sprint Planning commences. This implies adding acceptance criteria, refining requirements, and essential details for the development team to precisely estimate the effort. 

Best Practice  

  1. Ensure that backlog items are sufficiently refined before Sprint planning starts. Part of refinement is estimating the size of backlog items, adding details and splitting large items into smaller ones. 
  2. Any backlog item which requires a lot of clarification and discussion, should not be a part of sprint planning. It also means the story is not ‘Ready’. 
  3. While planning the sprint, the team should take into account any leave, holidays, or other activities that can impact the sprint commitments. 
  4. Breakdown of tasks should be done in sprint planning. 

Daily Scrum (Daily Standup) 

https://www.scrum.org/resources/blog/three-things-make-daily-scrum-waste-time-and-three-potential-solutions 

Attendees 

The daily scrum is attended by the development team, the scrum master, and the product owner. For mature agile teams, the scrum master can become optional sometimes. 

When? Duration? 

The daily scrum meeting occurs every day, same time, same place for no more than 15 minutes. 

Purpose 

The daily stand-up meeting allows the scrum team to discuss the current state. It is the time to inspect if the team is moving towards a Sprint goal or if there's any need to recourse the action. As the name suggests, it is a daily meeting which is ideally done while standing to make it quick. A common way of conducting a daily Scrum is to let each member answers 3 questions: 

  • What I did yesterday? 
  • What is the plan for today? 
  • Are there any impediments? 

The meeting is facilitated by the scrum master and is done while looking at the task board or the Sprint board for better transparency and visibility of the current state. This meeting should not be treated as a status meeting but as an opportunity to inspect and adapt on a daily basis. Everyone in the team gets a chance to talk about their deliverables and challenges while respecting the otherview.A common agreement in teams is that only one person speaks at a time.  

Best Practice 

  1. Timeboxing is key to the event, the Scrum Master should keep track of the time. 
  2. The focus should not be on finding the resolutions, any issue should be taken care of in the ‘sidebar’ 
  3. It should happen at the same time and same place. 
  4. Focus ONLY on what is relevant to achieve the Sprint Goal as a team. 

Sprint Review  

https://startinfinity.com/product-management-framework/scrum-sprint/sprint-review-vs-sprint-retrospective 

Attendees 

The complete Scrum Team attends the sprint review along with stakeholders such as end-users, customers, management and other associated verticals (marketing, sales, support). It is important that the most relevant stakeholders are requested to attend and give their feedback, as varied feedback is vital for producing brilliant products. The Product Owner and Scrum Master should sync up prior to the meeting to discuss who needs to be involved to ensure that everyone is informed in advance. 

When? Duration? 

Sprint Review happens at the end of every sprintIn addition to sprint reviews, it is often a good idea to get more frequent feedback from stakeholders during sprints instead of only at the end. The duration of sprint reviews is at most three hours for a sprint of a monthBut for many teams that do two-week sprints, one hour is sufficient. 

Purpose 

Sprint Review is the time where the development team showcases their efforts put to convert the raw requirement into something useful for the client. Stakeholders get a demonstration of the developed requirements as requested by them; they provide their feedback after looking at the deliverables which help to improve the product. Whatever the team presents in the sprint review meeting should meet the ‘Definition of Done’ as agreed between both – the development team and the stakeholders. The focus of the sprint review should be more on value delivery rather than points delivery. This, again, gives a platform to the team to inspect and adapt to create better solutions. 

Best Practice 

  1. The meeting should have a clearly defined agenda as to what the stakeholders should expect. 
  2. The most valuable feedback should be added to the product backlog and prioritized by the Product Owner. 
  3. Timeboxing is critical while involving the stakeholders. 
  4. A dry run before the actual sprint review helps to build confidence. 

Sprint Retrospective  

https://startinfinity.s3.us-east-2.amazonaws.com/t/seLlg2lgmskxNDobnJ5kVvyy0YwukAenpsSd6bzM.png 

Attendees 

The sprint retrospective is attended only by the scrum team which consists of the scrum master, the development team, and the product owner. 

When? Duration? 

This is the last event of any Sprint and happens on the last day of the Sprint. The duration of the Sprint review typically ranges between one hour or two hours for a Sprint of two weeks. 

Purpose 

The sprint retrospective is a time to reflect and introspect/retrospect on what went well, what didn't and how it can be improved for future sprints. The focus is on inspection and creating a course of action, for better Sprints moving forward. This event helps the team voice out their concernstheir appreciations or any improvements they want to see. The scrum master creates a safe environment to help the team come up with points they like or dislike and tries to create a neutral situation. The feedback from the team is collected and the action items are derived from the owners associated with each of them. At times the team might come up with a long list, in such cases, the Scrum Master should help the team prioritize and narrow down the few high-priority actionable items. The focus of the retrospective should not be always on the product but also on the process and inter-team relationships. 

Best Practice 

  1. The meeting should initiate on a lighter note with some ice-breakers to help the team adjust to the temperature of the room 
  2. Trying out theme helps as it generates new ideas and makes non-vocal people speak up their minds. 
  3. The scrum master should try ways to callout the fact that conflicts are not always bad. Quite often, some team members hold up their opinion due to fear of conflicts. 
  4. Starting the meeting with previous action items builds trust in the process as they are being heard. 

Conclusion 

Scrum events, if done in the right spirit, create an empirical behavior amongst teamsThe Scrum master should make sure that the team understands the why, what and how of each event. These events also help to create a flow of communication and provide transparency at every level. Please share your ideas and your experiences working with agile teams around the scrum events. 

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

12 Principles Behind the Agile Manifesto

Long before Agile came into existence, almost everything was done by the waterfall method. Its rigidity ensured that projects were easy to manage, but that also translated to more time to actually get a product deployed. So, it often happened that by the time the end product was ready to be deployed, the business requirements would have changed, thus making the product redundant. By the start of the millennium, markets had become more volatile, requirements were changing rapidly, and customers wanted quick fixes and accommodation of their changing needs.  That’s when 17 engineers got together and decided to come up with a new approach to software development that would address these problems. They came up with principles and values that would guide iterative software development. This document came to be known as the Agile Manifesto.  The authors of the Agile Manifesto came out with 4 values and 12 principles in order to help the professionals understand it easily and put it into practice. The manifesto created an impact and changed the future of project management. AGILE ESSENTIALS ESSENTIALS INTRODUCTION Agile Essentials is a set of resources intended to bring you up to speed on the concepts and principles of Agile. The Agile Essentials provide an overview of Agile values, principles, concepts, vocabulary, terms and roles to provide an understanding of the breadth of Agile and how it differs from traditional project management practices. AGILE 101:  Agile Development is a set of methods, principles and practices where solutions are integrated through the collaboration of self-organizing, cross-functional Development teams.  Agile methods, values and principles provide guidance on how to create and respond to change, deal with uncertainty and ultimately succeed in an uncertain and tumultuous environment. AGILE MANIFESTO The Agile Manifesto is a brief document built on 4 values and 12 principles for agile software development.  It was the work of 17 software development practitioners and was published in February 2001 to address the increasing need for an alternative to heavyweight software development processes. AGILE GLOSSARY Agile teams have created their own agile terminology to manage all these principles and practices. The glossary consists of 50 Agile Terms. Reference: Check URL https://www.agilealliance.org/agile101/agile-glossary/ for the list of agile terminologies. THE 12 PRINCIPLES The Agile Manifesto drafts out 12 principles for agile development practices. These 12 principles highlight on continuous delivery of valuable software in sprints and attention to technical excellence. The continuous delivery will involve quick feedback from the customer which will help reduce changes at the last minute. THE SUBWAY MAP The Agile subway map is a list of Agile practices grouped under different categories.  It helps to map out a specific practice that could help a team solve its problems.  The below picture depicts practices that are interconnected, while the colors at the bottom indicate each category. HISTORY OF THE AGILE MANIFESTO The vital value of agile development is that it should deliver value faster, ensure quality and certainty, and offer greater aptitude to respond to changes that correspond to market expectations. At a time when industries were growing rapidly and market expectations were changing, software needs and expectations were also changing and becoming more demanding. Agile software development history dates back to when the Agile Manifesto was created and Agile came into existence. In early 2001, a group of 17 developers held the (now famous) two meetings -- the first in Oregon and the second in Snowbird, Utah -- to discuss issues and solutions to overcome existing software development methodologies that were making it difficult to respond quickly to change.  The group comprised of 17 individuals, including Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas. All scenarios led to propose a working session. The working session organized by Dave, Robert and Jim had two objectives. Each person in the meeting will present to the group his lightweight method approach to build any complex software. Discuss the flow of heavyweight methods and how to address the complexities arising in the project development life cycle.THE FOUR VALUES OF THE AGILE MANIFESTO The Agile Manifesto thus tabled has 4 foundational values and 12 supporting principles. These values and principles lead to the agile approach to software development.  Agile methodology applies 4 values in different ways and these values guide the development and delivery of high-quality, working software. The four Agile Manifesto values are as follows: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Respond to change over following a plan INDIVIDUALS AND INTERACTIONS OVER PROCESSES AND TOOLS The Agile Manifesto values people higher than processes or tools because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. In case of individuals, communication flows and happens when a need arises. In the case of process, communication is designed and requires specific content. WORKING SOFTWARE OVER COMPREHENSIVE DOCUMENTATION Historically, a mammoth amount of time was spent on documenting the product for development and delivery. Technical specifications, requirements, prospectus, test plans, documentation plans, and interface design were the documents that were created which required lots of time. This mammoth list caused long delays in development. Agile does not eliminate documentation, but provides all the information that is required for the developer to complete the work without getting bogged down in finer points. CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION  Customers are involved in all the agile phases of the project. There is total transparency. The Traditional methodologies have customers negotiate before the project starts and the project ends. This results in wastage of both time and resources. In the agile development process customers are kept in the loop and information is provided to all stakeholders by the product owner; this ensures that the final product meets all the requirements as per the expectations of the client. RESPOND TO CHANGE OVER FOLLOWING A PLAN Changes should be avoided in Traditional software development as they are considered to be expensive. The intention was to develop elaborate plans, with a well-defined set of features. Higher priority features are developed first and the rest follow. Delivering in the order as prioritized by the product owner will help the team work on itemized sprints. With Agile, the iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration as required. Agile accepts changes as they are ways to improve a project/product. THE TWELVE AGILE MANIFESTO PRINCIPLES The Twelve Agile Manifesto Principles are the guiding principles that are included under the title “The Agile Movement”. Agile Manifesto architecture demonstrates the movement’s intent as described by Alistair Cockburn, one of the signatories to the Agile Manifesto, which is to bring development into alignment with business needs. The twelve principles of agile development include: CUSTOMER SATISFACTION THROUGH EARLY AND CONTINUOUS SOFTWARE DELIVERY: Customers will be happy when the software is delivered early for testing and feedback and when they are kept in the loop about the progress, the implementations, and product developers acknowledge the delivery value by fulfilling their top priority requirements first. A completed Iteration has an outcome, a working code to respond to the ever-changing user requirements. ACCOMMODATE CHANGES EVEN LATE IN DEVELOPMENT: Agile methodology stresses on responding to change instead of staying strictly aligned to an approved plan as was the case in the traditional methodology. It is a simplified version of handling changes with no formal documentation or approval. The changes are integrated for the customer’s competitive advantage because it takes care of the market changes in the business to bolster your advantage to emerging opportunities. DELIVERING WORKING SOFTWARE FREQUENTLY: Provide immediate value to the customers by delivering features that are done. The development teams are wholly responsible for completion of sprints. They ensure that each feature developed is tested, and matches the customer’s requirements before it is delivered. The project team needs to focus on the delivery of value to the customer within a fixed delivery timeframe. BUSINESS PEOPLE AND DEVELOPERS WORK TOGETHER DAILY : Agile accepts changes in software development. It is hence important to clarify requirements on a timely basis to always keep all the team members notified and up-to-date during the development of the software. SUPPORT, TRUST AND MOTIVATE TEAM: Agile depends on focused, trusted, and motivated individuals to complete projects as per requirements of the client. Development teams have all the power to select the work they are most interested in by self-organization with no interference from the external management. FACE-TO-FACE CONVERSATION WITH DEVELOPMENT TEAM: Feedback via face-to-face interaction or video conference with development teams in different geographical locations is always encouraged as it assists in easy and smooth transfer of information amongst the members. WORKING SOFTWARE IS THE PRIMARY MEASURE OF PROGRESS: The only way to measure success factors is by delivering a working product that satisfies the customer’s needs. Delivering functional software to the customer is the ultimate way by which progress can be measured. AGILE PROCESSES TO SUPPORT A CONSISTENT DEVELOPMENT PACE: Teams establish the velocity rate at which they can deliver working software, and they follow the same process with each release. Agile methodology aims to keep the work-life balance of development teams and never burden them with huge amount of work, thus keeping them happy and motivated.  ATTENTION TO TECHNICAL EXCELLENCE AND DESIGN: The right technical skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain market changes. SIMPLICITY: Focus on things that are important to add value to the project and customers. Develop the product as required and get the job done correctly. SELF-ORGANIZING TEAM ENCOURAGES GOOD ARCHITECTURE, REQUIREMENTS AND DESIGNS: In Scrum methodology, the team has overall control and is responsible for completing each sprint. The team performs in the best possible way needed to carry out the task. There is no interference of the project manager or from the human resources department. REGULAR REFLECTIONS ON HOW TO BECOME MORE EFFECTIVE: Self-improvement, process improvement, enhancing skills, and techniques help team members work more efficiently. It is imperative for Scrum teams to work and focus as a cognitive unit.  Working out new plans, checking requirements and adapting to changes will help the Scrum team to work more efficiently. THE GREAT AGILE DEBATE Agile development is a method based on iterative and incremental development. The requirements and solutions evolve in short sprint iterations through collaboration within self-organizing, cross-functional teams. The idea of the Agile method is to create a working software, compliant to change, and incorporate Face to Face interactions and collaboration over processes, tools or plans. It’s based on the principle of incremental delivery of the business value as quickly as possible through iterative development of software. The Agile Manifesto is the basis of the Agile practices, processes and principles etc used today. AGILE STRENGTHS:  It breaks tasks into small increments to allow the project to adapt and change quickly with the markets or client’s needs A project is developed in short iterations, or short time frames lasting from one to four weeks.  At the end of each iteration the agile approach allows teams to demonstrate the progress of the project to stakeholders; this ends the risk of bugs. Moreover, changes and additions can easily be adapted in each increment; this closely meets the client’s expectations. THE AGILE INDUSTRIAL COMPLEX The Agile community is now the Agile Industrial Complex.  It is that web of agile institutions, Agile thought leaders and Agile consulting firms that implicitly collude to make normal the very harmful and disrespectful imposition of Agile practices on teams without consent.  According to Martin Fowler agile had become mainstream in 2016. It is no longer exotic or frowned upon on, as in the early days. Growing agile industrial complex scenario: Organizations have spun the simple agile methodologies into complex industrial processes. This complex agile industrial has ballooned up and further used only for commercialization purposes. The agile-industrial complex trains people provide shiny certificates and pushes those people into consulting or managing positions. Focus on methodology: Every organization today focuses on agile methodologies for creating different products. This has resulted in the implementation of agile methodologies in organizations without any technical excellence of able and experienced engineers.  Focus on projects instead of products: Instead of connecting development team with clients and focusing on quality, the deadline and finishing of the project is prized or is given more importance. IS THE MANIFESTO STILL RELEVANT? The Agile Manifesto has made a profound effect on software development, even reaching beyond into the wider world of business. There’s ample evidence that the Agile Manifesto remains relevant in software development even today. The Agile Manifesto established some core elements of the best modern software development practices, which are still industry standard.  Examples of its influence include: Scrum:  A framework for small teams based on Agile Unified Process: A simplified version of The Unified Process (UP), or Unified Software Development Process Dynamic Systems Development:  An approach to project management and solution delivery Agile Alliance - Guide to Agile Practices: A collaboration between the Agile Alliance and PMI The emphasis on fast shipping had a major influence on changing the way physical goods are delivered around the globe.  WHAT DOES IT ALL MEAN? Agility means development with incremental approach, making small changes quickly, and learning from it through stakeholder feedback, making adjustments to our understanding of problems and repeating this many times. What to do: Find out and Plan the development incrementally within sprints. Initiate small steps towards your goal with quick deliveries. Adjust the understanding based on the feedback received. Lessons learnt should be implemented efficiently. Repeat all the steps. Below are a few simple steps that really describe what agile is all about.  Decide the goal to achieve. Perform small changes, test it, learn from it, adjust and repeat. Try to write code in agile way which is easy to change later. Implement small changes, get immediate feedback, initiate small iterations and make decisions that remove impediments for future changes as much as possible. Resolving problems using these basic agile principles, step by step at a time will ensure smooth transitions. The tools and methodologies will help to achieve agility. Avoid adding more processes.  Agile is a simple and fast way of learning and improving by taking small steps, one after the other. CONCLUSION Implementation of agile values to the project development process promotes communication both horizontally and vertically throughout the organization. It enhances innovation through high-performance multidisciplinary development teams and enhances business value by involving the client throughout the incremental delivery process. Improved communication, teamwork, collaboration, and organizational change improve the business value of products during the preliminary stages and throughout the project development lifecycle stages. Below are the concluding thoughts about Agile implementation Agile was born to simplify the lives of software developers, testers, and organizations. Transition from plan-based approach to Agile should result in the reduction of management overhead and lessen the burden of formalities from the creative development team. Be mindful of eliminating the right column of Agile Manifesto i.e., processes, tools, documentation, contract negotiation and the plan.  Agile methodology leads to avoiding misconceptions and helps in creating complex products. 
5369
12 Principles Behind the Agile Manifesto

Long before Agile came into existence, almost ev... Read More

Career Boost with CSM Certification

The ecosystem and landscape around every business is changing drastically. Digital technologies enable entities to develop digital products / services and to conduct their business significantly differently.  Example: Physical gift cards are now digital gift cards., like Amazon’s gift cards which can be shared with the near and dear ones during festive seasons or occasions. Customers can quickly buy this digital product online and gift it in a matter of a few seconds. This creates value for the customers and benefits the company that sells this product.  Organizations are heavily investing in newer technologies and at the same time focussing on refining their existing processes and working culture.  This enables them to increase and improve the speed and quality of the deliverables and also enhance customer experiences.  This is why global entities have taken on many best practices to contribute to the success of the interactions they have with different stakeholders. In this digital era, faster turnaround time is seen as one of the important traits of organizations developing and selling digital products. To accomplish this objective, IT organizations are exposed to a gamut of agile development models.   Today, “Scrum” (an agile development practice) is widely used as a mainstream practice in software development lifecycles, to create digital products like software. Let’s take a look at the overview of Scrum practices and understand how Certified ScrumMaster® (CSM®) certification can help you and your business. Scrum - an overview:Scrum methodology is based on principles like KISS (Keep It Simple & Straightforward) and progress iteratively with feedback.  This practice is: lightweight and implementable model. based on team collaboration. deceptively simple yet difficult to master.  based on “just enough” process and documentation mindset. An Analogy: Think about running a ten thousand metre race as a marathon run and slice the same race into some equal segments or sprints. Speed and quality increases when we slice the effort and maintain a constant pace or cadence.Scrum revolves around a concept called as “sprint” or a “timebox”.  So, sprint is a timebox of 2 to 4 weeks used to deliver some parts of the complete software in an iterative fashion. A simple sprint structure is expressed in the below diagram.  An Analogy: A teacher teaching the principles of abacus to the children divides the learners into four groups. The first set of children are beginners. They are taught to learn the abacus tools from scratch. They don’t have any targets as such. The second group of children know how to use the abacus tools and formulae. They are provided with a set of sums to solve with an upper time limit (for example 10 sets of sums in 10 to 15 minutes). The third set of children are in the advanced level. They are proficient enough to solve seventy to eighty sets of sums using abacus tools in less than five to seven minutes. Fourth set of expert level kids solve hundred plus sets of sums within five minutes with very minimal errors or no errors at all even without having a time pressure.  From the above analogy, we can conclude that when we repeatedly practice a simple method many times over and over, we gain perfection, maturity, speed and quality. We can now relate it with Scrum methodology. Scrum operates around simple processes which revolves around the Deming’s cycle (Plan-Do-Check-Act). Let’s get introduced to some of the basic elements of Scrum which revolves around roles, artifacts and ceremonies.  Basics of Scrum: Scrum Roles:   Product Owner: The Product owner understands business, customer, market and stakeholder needs. This role serves as the voice of the customer who is responsible for maximizing the value of the product or software.   Scrum Master :The Scrum Master is responsible for ensuring that Scrum is understood and enacted by all the stakeholders who interact with the scrum teams. Anyone who wears the cap of a Scrum Master has to take up a versatile range of roles such as facilitator, coach, mentor, trainer, enabler, change agent, servant leader etc.  Development Team:The Development Team consists of T-shaped professionals who do the work of delivering a potentially releasable increment or a minimum viable product at the end of each sprint. Cross-functional teams who can collaborate and self-organize are capable of delivering the products to the stated quality.   Scrum Artifacts: Product Backlog: The product backlog is simply all the things that need to be done within the project. In traditional project management, a product backlog can be referred to as a Requirements Documentation. This document is owned by the Product Owner and the requirements are prioritized based on the business value. Needs are captured in the form of user stories with acceptance criteria.  Example of a user story:  As a customer of the bank I want to update my latest communication address on my own using the bank’s app So that I can receive all the parcels/documents sent by the bank without missing them.Sprint Backlog: The Sprint backlog is a list of tasks identified by the scrum team to be completed during the sprint. During the sprint planning meeting, the team selects some number of product backlog items usually in the form of user stories, and identifies the tasks necessary to complete each user story. In traditional project management, this is also called as an Activity List.  Minimum Viable Product:  A Minimum Viable Product (MVP) is the sum of the Product Backlog items delivered during each sprint. Delivering the MVP in each sprint is fundamental to the scrum because when work is divided into simple pieces it can be finished in a short iteration. Example: An insurance company’s software development team is developing a mobile based app to sell their insurance products. In the first 3 sprints, the development team, delivers functionality and features that enable customers to buy insurance products online. Iteratively, the team delivers minimum viable products such as network locator, branch locator, feedback, track/modify policy, e-insurance card and so on.  Scrum Ceremonies: Sprint Planning:  The purpose of the sprint planning meeting is to estimate and forecast the work that can be accomplished by the team in the given sprint. Sprint backlog is the output of this meeting. Daily Stand-up: The purpose of the daily stand-up or daily scrum is to plan the day, identify risks and ways to mitigate them. Updated sprint backlog and burn charts / scrum board / Kanban board are the outputs of this activity.Sprint Review: The purpose of the sprint review is to showcase or demonstrate the developed feature to the product owner and other stakeholders. This promotes quick feedback.  Sprint Retrospective: The purpose of the sprint retrospective is to identify improvements and mature the ways of working in the subsequent sprints.Certified ScrumMaster (CSM) Certification from Scrum Alliance: This is an instructor-led training program designed and crafted to increase the knowledge base on fundamental elements of scrum practices in about sixteen hours. This program will be driven by a Certified Scrum Trainer® (CST®).  This certification is apt for professionals who: aspire to become a Scrum Master are project managers who encounter Scrum work with Scrum teams are Business Analysts who interact with Scrum teams are in IT Operations team and collaborate with Scrum teams want to begin their agile journey want to take other advanced certifications offered by Scrum Alliance want to learn the foundations of Scrum Exam:  After successfully completing the course, a candidate can take an online examination. 37 right answers out of 50 will enable a participant to earn the CSM certification. The time limit for the exam is 60 minutes.  Maintaining the certification :  Keeping the certification active is a good way to continue reaping the benefits of being certified. An active certification will help practitioners stay connected with the agile community, share and gain knowledge and help the community thrive. To keep the credential active, a renewal fee of $100 for two years is applicable. One also has to clock 20 learning hours called SEUs (Scrum Education Units®) once in two years towards maintaining the credential.  Benefits of CSM certification: helps in improving career prospects helps in marketability of one’s profile helps in demonstrating and improving the credibility of one’s profile Conclusion:  In a nutshell, Scrum is a software development framework which supports the value statements of the Agile Manifesto. Roles, artifacts and ceremonies of Scrum encourages “individuals and interaction” promoting a transparent, self-organizing, trustful, collaborative environment, focuses on delivering “working software” or minimum viable product with just enough documentation, promotes “customer collaboration” and infuses a mindset to “welcome changes” based on feedback and business value. Scrum facilitates a disciplined way to develop products in an iterative way using timeboxing as its core mantra.  Other agile practices such as Lean, Kanban, DevOps, Test Driven Development, Behaviour Driven Development, Feature Driven Development, eXtreme Programming, can be used alongside or to complement Scrum practices.  Scrum can also be scaled up to make it suitable to work with larger sets of teams. Existing project management practices can be tailored to infuse Scrum into their ways of working. Any organization adopting Agile, can kick start the adoption by embracing Scrum as a steppingstone. Although there are many different certifications available on agile practices, CSM is seen as a simple and easy way for professionals to begin their Scrum/Agile journey. As per the data published in www.scrumalliance.org there are more than a million professionals across the globe who are certified in various agile certifications offered by Scrum Alliance. So why wait? Grab your opportunity now! 
9565
Career Boost with CSM Certification

The ecosystem and landscape around every busines... Read More

ScrumXP

This article briefly talks about popular Agile methodologies Scrum and XP, and how both these frameworks have been merged into ScrumXP—giving you the best of both worlds!  Scrum Scrum is the leading Agile framework practiced in the industry today. It follows an iterative approach where development cycles are 2 /3/4 weeks long. At the end of every iteration an incremental version of the product/solution is ready to be shipped.  Scrum prescribes events / ceremonies and specific roles within the team in order to achieve alignment and agility.  Sprint Ceremonies /Events Sprint Planning at the start of the Sprint Daily Stand-up during the Sprint Sprint Demo and Review to showcase the incremental working software developed in the iteration Sprint Retrospective at the end of the Sprint Scrum Roles Product Owner – Responsible for the product that is being developed. Is the representative of the Customer and Business. Scrum Master – Facilitates and orchestrates the various Scrum events, guides the team to align with Scrum values and principles. Team Member – Focusses on achieving Sprint goals, continuously strives to improve. Scrum Values  Courage - Every team member feels safe to fail and learn, to seek help, to say ‘no’ and question something that is going wrong. Commitment – Commits to Sprint goals as a team. Does not overcommit.  Focus - Aims to complete what is started and steer away from distractions and unprioritized/ "shoulder tap" work. Limits Work in Progress. Openness - Seeks and values feedback and opportunities to learn. Makes impediments, failures and learnings visible. Respect - Team collaborates and acknowledges the work and achievements of every member. Builds trust. Extreme Programming (XP) XP is one of the earliest ,most successful and proven Agile Methodologies.  It is very specific regarding the practices to be followed. XP is recommended to be used when the Customer is fully committed to deep involvement with the development team. XP teams rapidly produce software in short(mostly one week) iterations taking immediate feedback from the Customer. XP Values Communication – Communication within the team is as important as communication with the Customer Simplicity - Building a system that is easy to revise and maintain. Trying not to engineer too many and too much and only do what is required at that time. Feedback – Continuously striving to obtain feedback and acting on the feedback from Customer, Team and the Product. Courage – Courage to persevere and do the right thing. Respect – Respect for fellow team members and all stakeholders. XP Core Practices XP mandates certain core Engineering practices that distinguish this Agile methodology from the others. These practices take care of different aspects of agility and are interconnected at the same time.  They are grouped as below. Fine scale feedbackWhole TeamAll the contributors to a project – Developers, Testers, Analysts, Coaches etc who are part of the Project are part of the “Whole Team” that is centered around the Customer.Planning GameThe Customer presents the desired features and lays out an initial plan for the project. XP teams revise the release plan regularly.During Iteration Planning, the Customer presents the features desired for the next two weeks. XP teams build software in two-week “iterations”, delivering running, useful software at the end of each iteration.The total involvement by the Customer during Planning is an important practice of XP.Pair ProgrammingAll production code is touched by two team members. This ensures there is already another “reviewer” at work as the code is getting produced. This practice largely avoids bugs and coding errors.Test Driven DevelopmentTest before code is religiously practiced. Before a single line of code is written, a test for the same has to be written and run. This immediate and short feedback loop immensely helps to avoid waste, like bugs and wrong code.Customer TestsAcceptance Tests are defined by the Customer to validate if the features that are being introduced are fit to the purpose. The team automates these tests and builds a suite of such tests to run whenever required and to get immediate feedback from the system to check if all is well.Continuous processContinuous IntegrationContinuously integrating the code avoids the major problems that creep up when it is done  just before the release. Testing on a fully integrated system helps to detect critical bugs that might otherwise stay undetected for long.Design ImprovementDesign Improvements and Refactoring happens at healthy intervals to ensure system is cohesive and loosely coupled. This ensures the system can be easily extended with new features, scaled when required and maintained in good health.Small ReleasesWorking Software is delivered to Customer at the end of every iteration – either for actual use or evaluation and to obtain feedback.Shared understandingCoding Standards are practiced so that there can be collective ownership and any team member will be able to understand the code.Pair Programming and Coding Standards ensure that code is not owned by one single person and is the responsibility of the team.Design is kept simple and continuously improved and revised to cater to the current functional demands. Design is not done up-front but done at regular intervals.XP teams use a common system of names to ensure a common understanding of the system.Programmer welfareSustainable PaceXP ensures the team members work at a pace that can be carried out for a very long time.  The system avoids situations where the team members are left wanting for work at times and then have to scramble to finish deadlines.Scrum and XP – What is common and different. Scrum and XP are two popular Agile Methodologies having the same larger goal of delivering to the customer incrementally and iteratively. Both the methodologies lay great importance to customer centricity, feedback mechanisms, continuous improvement and building sustainable empowered teams.  There are few differences in the implementing mechanisms of these methodologies.  Iteration Duration: Scrum Iterations last for 2 /3/ 4 weeks. XP iterations are usually very short – one week long or at the most 2 weeks. Role of the Customer: XP and Scrum have Release Planning and Iteration Planning sessions. But unlike Scrum, in XP the Customer drives the planning and schedules the Release.  The Customer continuously interacts directly with the Teams in XP, while in Scrum the Product Owner represents the Customer and Business. The XP teams ensure to deliver a working bug free system at the end of every iteration. Customer chooses to evaluate and provide feedback or Release to the end users. Scrum teams deliver working software at the end of every iteration. The Product Owner with the input from teams decides on the right time for General Availability (GA) Release depending on the Market Readiness, Customer input etc. Practices: Scrum recommends using Engineering Best Practices like TDD, Pair Programming, Code Refactoring etc. but XP takes it to another level by mandating these Engineering Practices. Scrum recommends that items planned within a Sprint are unchanged until the end, but in XP, teams accommodate a sudden change of priority even during the iteration, by swapping items if work has not started on it. Roles: Scrum has dedicated Scrum Ceremonies whereas XP does not prescribe it per se. Scrum has a dedicated Scrum Master who facilitates these events, but XP does not have a Scrum Master.  XP teams get guidance from Agile Coaches.  ScrumXP- Using the best of Scrum and XP Practices When there are two great practices, there is always a tendency to combine both and get the best of both the worlds. “Lean-Agile”, “Scrumban”, “ScrumXP” are some examples of hybrid terms that have become increasing popular by combining two philosophies (e.g Lean and Agile ) or two methodologies (e.g Scrum and Kanban / Scrum and XP). ScrumXP is a hybrid practice making the most of both Scrum and XP. XP has laid out some very effective Engineering practices that teams practicing Scrum can greatly benefit from.  Many teams practice Scrum as their process framework and include the very effective and efficient core Engineering XP Practices in their way of working. This gives rise to the highly productive ScrumXP hybrid model of working. Mostly the ScrumXP teams retain the Scrum Master and Product Owner roles within their teams to take care of the required orchestration and facilitation. ScrumXP and SAFe “Team and Technical Agility” is one of the key competencies of SAFe. By following  ScrumXP the SAFe teams take care of the team Agility through Scrum Practices and Technical Agility through XP Practices.  The robust Engineering practices of XP ensures the product being built is of very high quality, easily extendable, maintainable and sustainable. In conclusion, ScrumXP provides the best of both worlds. Teams can begin with Scrum and continuously improve by including the robust core XP Engineering practices like TDD, pair programming, code refactoring etc— not because it is mandated but because they find it effective. Although, interaction with the Customer is through a Product Owner, the Scrum teams can borrow the Customer Centric approach of XP to remain aligned with Customer expectations. 
5364
ScrumXP

This article briefly talks about popular Agile m... Read More