Category

Courses

Search

Trending blog posts

Why Is Retrospection Needed?

The dictionary meaning of Retrospective is “contemplation of the past events”, i.e. revise and analyse the past. Agile Retrospection is a ceremony performed at the end of every sprint to analyse, document and take actions to make the project and the process more transparent and productive. While Retrospection is very important to any project, it is also important to understand the boundaries created for the meeting team. While setting boundaries we should keep in mind that the freedom of speech of the team is not affected. To understand the concept of Retrospection Meetings better let me introduce you to the basics of the meeting first – <iframe width="560" height="315" src="https://www.youtube.com/embed/-hnD43Gs_ys" frameborder="0" allowfullscreen></iframe> The Correct Time – Last day of the sprint is the ideal day to hold the meeting The duration of the meeting – An ideal Retrospection Meeting should not be more than 20-25 minutes Required Members- Scrum Master, Product Owner, Developers The meeting generally starts with the common parameters of the team like velocity, user stories accomplished etc.Then each member of the team comes up with their opinions on –  What went well? What went bad? What should the team continue doing? What should the team stop doing? Points given by each member is noted in a spreadsheet by the Scrum Master, and at the end of the meeting, 3-4 main action items are selected and are used as inputs to work on in further sprints. In every retrospective, the team should look back at the action items from the previous meetings and ensure that the ones that have been worked upon are closed.  While in a new Agile team the members are hesitant to put forward their views openly, in an experienced Agile team it is easier to get the views easily and truly. Having covered all this it is important to understand that sometimes Retrospection meetings are used by employees to cover their mistakes or throw blames at other team members. For e.g. if the work of one developer is dependent on the work of another developer, there might occur a conflict of time or ideas between the two. Similarly, one developer's work might cause an issue in an existent piece of code written by someone else. These conflicts are often pointed at by developers during the retrospect and thus a healthy meeting turns into an introspection of each other’s work in the presence of the whole team and hampers the spirit of Agile. The team participating in the Agile Ceremonies should be trained and coached well to understand the practices advised in Agile and the reason behind them. Many Scrum Masters in today's day come across situations when differences occur between team members which are not good for the team to perform with complete dedication. In such situations, it is the duty of the Scrum Master to understand the differences and solve as quickly as possible to avoid internal conflicts which may eventually lead to bad team performance or delayed commitments. To avoid such introspection and team differences, the Scrum Master should make sure that the team adheres to the below guidelines –  Always check with the teammates for any issues and try to solve in a mature and professional manner Resolve opinion differences regarding technical issues with logics and backing data Also, before starting every sprint it is very important to understand each requirement from business perspective to avoid confusion Also, it is a Scrum Master's duty to maintain a professional environment within the team and the Product Owner's duty to always clarify the business value of each backlog item so that the development team can follow the correct direction from sprint start. There are also some free tools available online like IdeaBoardz, Fun Retro, Reflect, Pointing Poker, Scatter Scope etc. Additionally, below-suggested guidelines for the meeting can help retrospect and come out to better conclusions as to what is best for the team : Each team member should contribute only 2-3 points most important according to their viewpoint When one team member is putting a point others should not contradict or speak in between Everyone should speak when asked to by Scrum Master If a conflict of opinion occurs between 2 team members then the same should be solved with only the concerned members and not to be put in retrospective When a team follows pure Agile, the Retrospective is an important ritual for the team. This helps Continuous Integration and helps the team understand each other’s point of view. A Retrospect could also be accompanied by the achievements of the team in the sprint. The Scrum Master can incorporate the team’s success in the start of the meeting to set a good tone for the meeting. Concluding, I can positively say that while good Retrospection can do wonders for the team, a bad one can break the team which is not good in the long run.  

Why Is Retrospection Needed?

669
Why Is Retrospection Needed?

The dictionary meaning of Retrospective is “contemplation of the past events”, i.e. revise and analyse the past.

Agile Retrospection is a ceremony performed at the end of every sprint to analyse, document and take actions to make the project and the process more transparent and productive. While Retrospection is very important to any project, it is also important to understand the boundaries created for the meeting team. While setting boundaries we should keep in mind that the freedom of speech of the team is not affected.

To understand the concept of Retrospection Meetings better let me introduce you to the basics of the meeting first –

<iframe width="560" height="315" src="https://www.youtube.com/embed/-hnD43Gs_ys" frameborder="0" allowfullscreen></iframe>

The Correct Time – Last day of the sprint is the ideal day to hold the meeting
The duration of the meeting – An ideal Retrospection Meeting should not be more than 20-25 minutes

Required Members- Scrum Master, Product Owner, Developers

The meeting generally starts with the common parameters of the team like velocity, user stories accomplished etc.Then each member of the team comes up with their opinions on – 

What went well?

What went bad?

What should the team continue doing?

What should the team stop doing?


Points given by each member is noted in a spreadsheet by the Scrum Master, and at the end of the meeting, 3-4 main action items are selected and are used as inputs to work on in further sprints. In every retrospective, the team should look back at the action items from the previous meetings and ensure that the ones that have been worked upon are closed. 

While in a new Agile team the members are hesitant to put forward their views openly, in an experienced Agile team it is easier to get the views easily and truly.
Having covered all this it is important to understand that sometimes Retrospection meetings are used by employees to cover their mistakes or throw blames at other team members. For e.g. if the work of one developer is dependent on the work of another developer, there might occur a conflict of time or ideas between the two. Similarly, one developer's work might cause an issue in an existent piece of code written by someone else. These conflicts are often pointed at by developers during the retrospect and thus a healthy meeting turns into an introspection of each other’s work in the presence of the whole team and hampers the spirit of Agile. The team participating in the Agile Ceremonies should be trained and coached well to understand the practices advised in Agile and the reason behind them.



Many Scrum Masters in today's day come across situations when differences occur between team members which are not good for the team to perform with complete dedication. In such situations, it is the duty of the Scrum Master to understand the differences and solve as quickly as possible to avoid internal conflicts which may eventually lead to bad team performance or delayed commitments.

To avoid such introspection and team differences, the Scrum Master should make sure that the team adheres to the below guidelines – 

  • Always check with the teammates for any issues and try to solve in a mature and professional manner
  • Resolve opinion differences regarding technical issues with logics and backing data
  • Also, before starting every sprint it is very important to understand each requirement from business perspective to avoid confusion

Also, it is a Scrum Master's duty to maintain a professional environment within the team and the Product Owner's duty to always clarify the business value of each backlog item so that the development team can follow the correct direction from sprint start.

There are also some free tools available online like IdeaBoardz, Fun Retro, Reflect, Pointing Poker, Scatter Scope etc.

Additionally, below-suggested guidelines for the meeting can help retrospect and come out to better conclusions as to what is best for the team :

  • Each team member should contribute only 2-3 points most important according to their viewpoint
  • When one team member is putting a point others should not contradict or speak in between
  • Everyone should speak when asked to by Scrum Master
  • If a conflict of opinion occurs between 2 team members then the same should be solved with only the concerned members and not to be put in retrospective

When a team follows pure Agile, the Retrospective is an important ritual for the team. This helps Continuous Integration and helps the team understand each other’s point of view. A Retrospect could also be accompanied by the achievements of the team in the sprint. The Scrum Master can incorporate the team’s success in the start of the meeting to set a good tone for the meeting.

Concluding, I can positively say that while good Retrospection can do wonders for the team, a bad one can break the team which is not good in the long run.
 

Shreeti

Shreeti Bhattacharya

Blog Author

Shreeti is a full time Scrum Master with Wipro and aspires to share her knowledge across.

Join the Discussion

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

SPECIAL OFFER Upto 20% off on all courses
Enrol Now

Trending blog posts

INFOGRAPHIC: How E-Learning Can Help Improve Your Career Prospects Published 24 Jan 2017 Infographics
What is Blue Green Deployment? Published 12 Jan 2021 Blogs
12 Principles Behind the Agile Manifesto Published 22 Jan 2021 Blogs
ScrumXP Published 22 Jan 2021 Blogs
ITIL Service Lifecycle And The Stages Of Successful Implementation Published 28 Mar 2018 Blogs
Four Scrum Events, Demystified Published 12 Dec 2020 Blogs
Write for US

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. 
12 Principles Behind the Agile Manifesto
Blogs
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! 
Career Boost with CSM Certification
Blogs
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. 
ScrumXP
Blogs
5364
ScrumXP

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

Useful links