Common Misconceptions

Most people feel that every Sprint MUST make an Increment which HAS to be sent to production and given to the end-users for using. This is actually not true. Sometimes, it is not possible to produce Incremental “production-ready” outcome every Sprint

What really is the outcome of the Sprint?

Scrum defines the “OUTCOME” of the Sprint as an Increment which is “USABLE”. Usability is associated with getting feedback and not necessarily “Go-Live”

Recommendations

• Sometimes, in a short sprint it may not be possible to create an “Go-Live-Ready” product. However, every Sprint must result in a deliverable where feedback can be received. The feedback may happen from internal stakeholders and not necessarily the end-users
• Sprint should be considered separate from “Release”. While “Release” is not a Scrum term, most teams use the word “Release” to describe “Go-Live-Ready” outcome. Generally, it is observed that multiple Sprint outcomes can be combined together to create a “Release”. However, this is also not a necessary condition. Sometimes, teams may create multiple “Go-Lives” within the Sprint itself. It is important to understand that feedback is necessary every Sprint so that we know as a Scrum Team that we are going to achieve the Product Goal (Long term Goal). The intent of Sprint should be to optimize the probability of achieving the long-term objective and the feedback received should be used to optimize this probability. Now, the feedback may come from internal stakeholders or end-users. Important part is that feedback should come every Sprint.
• While this article says that it is not necessary to create a “Go-Live-Ready” outcome every Sprint, that does not mean that we create “Documentation” as output. We CANNOT be doing a “Requirements Sprint” which creates a “Requirement Document” as an output. We CANNOT be doing a “Coding Sprint” to create a “Code” as output. If we create outputs such as Documents then what we end up doing is “Outputs” (which are of no value) instead of “Outcomes”. “Outputs” do not necessarily result in “Outcomes” which are of business value or feedback-able value. “Outputs” do not necessarily result in feedback where we can check progress towards the Product Goal.

Conclusions

Sprint creates an Incremental outcome which is called Increment. The Increment should get the Scrum Team feedback, which will optimize the probability of meeting the Product Goal. The Incremental outcome may be a “Go-Live-Ready” outcome many times within a Sprint or sometimes over multiple Sprints. The Increment should never be an output which is not a valuable outcome.

The post Myth about every Sprint Output resulting in a go-live to production appeared first on World Of Agile.

Common Misconception

Most people treat Sprint Review as a “gate check” forum to release the product into production. Thus, the Sprint Review ends up being a formal meeting with gate-checking checklists to go through so that the product can be sent to production.

What really is a Sprint Review?

• Sprint Review is an informal forum to seek feedback from the Stakeholders
• Intention of the Sprint Review is for the Scrum Team to find out if they are on track to meet the Product Goal, and if not, inspect and adapt the Product Backlog for future Sprints
• Scrum de-links the “go-live” or “delivery to stakeholders” and “seeking feedback”. Sprint Review’s intent is to seek feedback. The product may be delivered to the stakeholders before or after the Sprint Review

Recommendations

• Sprint Review should be a informal discussion between Product Owner, Stakeholders and Developers to discuss improvements in the product and increase the probability of reaching the Product Goal
• Sprint Review should be more like a working session instead of formalized presentations and checklists to go through
• It is better to create a separate gate check forum other than the Sprint Review. If any gate checking is done in Sprint Review, the real intent of getting feedback may be lost

Conclusions

Sprint Review is not a gate checking forum. It is a working session where Scrum Team and Stakeholders collaborate on how better to achieve the Product Goal

The post Myth – Sprint Review Being a Gate to Releasing Value appeared first on World Of Agile.

Common Misconceptions and Negative Implications

·        It is a common practice for a Product Owner to come up with a set of requirements in the Sprint Planning and disappear during the Sprint. Then appear directly at the Sprint Review forum and conduct the review of the Developers work during the Sprint Review.

·        By doing this, an important opportunity of giving feedback continuously is lost. The feedback becomes a big-bang-end-of-the-sprint activity

·        Since Product Owner is seeing the product first time during the Sprint Review, it can become difficult to take feedback from stakeholders

·        If Product Owner brings along the stakeholders to do a Sprint Review, the Product Owner ends up acting like the “Other party” and does not build confidence in the team doing the work

• When the Product Owner sees the newly increment only at review time, Sprint Review becomes a gate that holds back value from reaching the users. When the Product Owner sees the increment during Sprint an opportunity is created to release value earlier

Recommendations

·        The Product Owner owns the product. Therefore, it is important for the Product Owner to participate in the product development continuously and constantly provide feedback.

·        The Product Owner has to build confidence with the Developers. Developers being left alone is not a great idea. The Product Owner should not behave like an outsider and should not sit on the other side of the table. Once the Product Owner wears the “Product Owner Hat”, he/she is first part of the Scrum Team and then part of the Customer or Client or Stakeholder team

·        Developers must not fear the Product Owner. Feedback is not a cause for worry. Feedback is good. The earlier you receive the feedback, the better it is for the Product

·        Typical steps in the Sprint Review that are seen useful by many teams could be as below

o   The Product Owner should invite the relevant stakeholders for a Sprint Review

o   During the Sprint Review forum, the Product Owner should sit with the Developers

o   The Product Owner should thank the Developers in front of the stakeholders for the work done

o   The Product Owner should take ownership of the product during the Sprint Review and collaborate with stakeholders to make it a working session

o   During the Sprint Review, the feedback should be from Stakeholders and not from the PO. The PO feedback is assumed to have been taken already during the Sprint

o   The stakeholders and Product Owner should think about the next steps based on market place conditions and make adjustments to the Product Backlog

Conclusions

·        Sprint Review should be a working session between entire Scrum Team and Stakeholders

·        Product Owner should be reviewing the product with stakeholders with help of the Developers

·        Product Owner should have provided feedback to the developers continuously throughout the Sprint and should not be seeing the product first time during the Sprint Review

The post Myth – Sprint Review being the review of the Developers done by Product Owner appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Sprint Zero seems a good idea

When the team start work the team observes these typical problems

• There is no reasonable Product Backlog from which a Sprint Backlog can be created.
• Designs are not good enough to start
• Architecture decisions are often delayed

Team often struggles to create a usable product increment during the first Sprint. Often then, the teams starts with a Sprint Zero so that a usable product increment may not be expected from the team.

At the outset, it looks to be a great idea – especially those who have come from a waterfall mindset and are used to doing a lot of preparation before beginning a project.

Negative consequences of Sprint Zero

Sprint Zero is often considered an agile-sounding term for pre-Sprint preparation work where no increment of product value is provided at all. In reality, the whole intent of the Sprint is lost. To be a Sprint, something of value must be delivered in a clearly time-boxed fashion.

What could be done instead of Sprint Zero

• In Agile, we believe in just-in-time work. However, in reality this may increase the risk. Hence we should start thinking about the work (which includes designs, architectures, refinement of PB) 2-3 sprints in advance. Not too early, and not too late.
• Weak product management results in this anti-pattern. Agile does not mean that we don’t have planning. There is a lot of planning in agile. However, the planning is done such that the team has enough work for the next 2-3 sprints. Not having decisions ready, not having a product backlog ready often causes the team to resort to this type of anti-pattern.
• Critical Architecture decisions, critical design decisions, critical business decisions need to be identified. They may become show-stoppers later and the team may not have enough work for the next sprint.

The post Sprint Zero – An Anti Pattern appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Hardening Sprint seems a good idea?

Scrum Teams are under constant pressure to deliver features. The stakeholders and Product Owners often push the Developers for going to production as soon as possible. 

In these situations, the developers often postpone a lot of work to be done later. Examples include – documentation, code cleanup, defect fixing, commenting of code, hard-coding, bypassing checks etc.

Then the Scrum team introduces a “Hardening Sprint” after 4-5 Sprints to take care of all these pending activities. Therefore introducing Hardening Sprints is generally considered a good idea by a lot of teams.

Negative consequences of Hardening Sprint

User of Hardening Sprint introduces following problems

• Pending work increases. Many times the Hardening Sprint does not get taken and the work just keeps accumulating
• It becomes more and more difficult to tidy up the mess
• Teams end up forgetting things later on
• Increase in the possibility of the defects since things get fixed later

What could be done instead of Hardening Sprint

• Follow the agile principle of “Simplicity” – the art of maximizing the work not done. That is, don’t push more features. Try to complete a lesser number of features with all things done.
• Slow down – focus on quality rather than speed
• Make the Definition of Done more stringent
• Focus on engineering practices such as Automations, CI/CD, Automations, TDD
• Say NO to a hardening sprint. Do not keep pending activities.

The post Hardening Sprint – An Anti Pattern appeared first on World Of Agile.

Common Misconceptions and negative implications

Some teams treat the Sprint Backlog as just a smaller version of the bigger plan (Product Backlog) and start creating baselined Sprint Backlogs for multiple future Sprints. The negative implication of this practice is that the “Inspect and Adapt” cannot happen. This becomes just disguising the waterfall and calling it Scrum.

Recommendations

• There should only be one Sprint Backlog. This represents the forecast for the current Sprint. At the end of the Sprint, the Sprint Backlog is emptied. All remaining items are taken back to the Product Backlog. All completed and done items are taken into Increment. The reason why this is done this way is to give opportunity to the Product Backlog to be re-ordered if needed.
• It is possible that the Product Backlog item changes the order since there might be change of business priorities. If the Sprint Backlog is baselined for multiple sprints at the start then an important opportunity for inspection and adaptation is lost.
• The discussions in the Sprint Planning result into a new Sprint Backlog based on the business objective to be achieved this Sprint. Even during the sprint, the Sprint Backlog emerges – more details get added and new things get clarified.
• To see how to handle changes in scrum please click here

The post Myth about creating multiple Sprint Backlogs before first sprint starts appeared first on World Of Agile.

Common Misconceptions and negative implications

Most teams implement Sprint Planning as three parts – Part 1, Part 2 and Part 3. The Product Owner comes in part 1 and 2, helps with setup of the Sprint Goal (WHY) selection of functionality (WHAT) and then the Developers sits and thinks over the technical (HOW) during the Part 2 of the sprint planning. The implication of this is that PO then does not get involved in the detailing and the road-blocks that team faces and technical feasibility problems that result during the Part 3 becomes a back-and-forth discussion between PO and Developers. This obviously results in a loss of productivity.

Recommendations

• The whole Sprint Planning process is an iterative, incremental and collaborative process and therefore there are three Topics and not three Parts to the meeting.
• First topic – WHY – is the business objective
• Second topic – WHAT – is the selection of the Product Backlog Items which may help achieve the goal. So, it is forecasting what items should be part of this Sprint. The scrum team should self manage and pickup items that they think they will be able to deliver in the Sprint.
• Third Topic – HOW – is the discussion of details and feasibility of the items and the help required from Scrum Master or Product Owner to get this done.
• So, you can consider the WHAT and HOW are iterative in nature where the HOW revolves around the WHAT and joint discussions are necessary. There are possible considerations that may happen to the WHAT because of the HOW. Technicalities do influence to a large extent on WHAT can be done and what cannot.
• The Sprint Planning Event can end with a decision on THE WHY – Sprint Goal, a forecast of WHAT needs to be done and the HOW for at-least a few things to be done over the next few days. However, the Sprint Planning PROCESS does not end with Sprint Planning EVENT. The Product Owner and Developers keep doing the discussion on the two topics – WHAT and HOW throughout the Sprint. Many-a-times, the teams do these detailed discussions on the HOW for the WHATs after daily scrums on the plan for next 24-48 hours.

So, my recommendation is not to call the Sprint Planning as Part1, Part2 and Part3 but iterative, incremental and collaborative process of Topic1, Topic2 and Topic3 which starts with Sprint Planning and continues throughout the Sprint.

The post Myth about Sprint Planning consisting of three parts Part1, Part2, Part3 vs Topic1, Topic2, Topic3 appeared first on World Of Agile.

Excitement is in air. The new scrum guide is out. Like always there is a great curiosity among agile enthusiasts to see how the guide to scrum is evolving. This article attempts to capture this very aspect. Here, in this article I have articulated my understanding and perspective on how the guide has evolved in its latest avatar.

Length of the Scrum Guide reduced – Now more Precise

First thing I noticed was the length of the guide – it has been reduced further. I certainly do not think that the authors had page count reduction as a specific objective in mind – However as they have put elegantly in this version, “The Scrum framework is purposefully incomplete” I see this as the driving theme behind quite a few of the changes. The reduction in page count derives from the very fact that the guide now has sharpened the focus on scrum being a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” The guide now is consciously moving away from being prescriptive and the core theme revolves around Value

Focus of Scrum changed from being a “process framework” to being a “individuals and interactions” focus

In fact, the scrum guide no longer says that Scrum is a “process framework. It very clearly states “Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.” I believe, this was always the intent but articulating it so transparently, the guide is reiterating the belief that people are founding formation that continually delivers value and scrum is a lightweight framework that helps people, teams and organizations generate this said value.

With the increased focus on people- their relationships and interactions, there are a few changes in how the guide describes the people aspect of scrum guide: the roles and the team interaction.

Articulation of scrum as the framework that guides interactions and relationship between people is further cemented when the guide refers to scrum team as the “The fundamental unit of Scrum”. Ownership of value is shared between the entire scrum team. The roles now have morphed in accountabilities, more or less the accountabilities remain same – the change of term makes the difference between responsibilities and accountability abundantly clear while keeping over all ownership of value delivery with the team. This Scrum team is made up of a group of 10 people consisting of a Scrum Master, a Product owner and Developers. This count of 10 now covers the entire Scrum Team rather than the 3-9 limit for the erstwhile development team. In a small change in wording the development team is now referred as “developers”. This further progresses the idea about whole of team being one scrum team.

Scrum – “Purposefully Incomplete”

Beautiful way of clarifying to many who expect lots of details in Scrum. It emphasizes the importance of collective intelligence which defines Scrum rather than giving detailed instructions. Clearly now the emphasis on Scrum being a framework rather than a detailed methodology.

Definition of Empiricism – now more precise

Empiricism is now defined as “Making decisions based on what is observed”. This is a much better wording than “Making decisions based on what is known”. Removes ambiguity around the word “known”.

“Product” and “Product Goal” – Now defined formally

The product is now formally defined as a vehicle to deliver value.  This makes it clear that value is of importance – whether the value is delivered by a service, an abstract concept or a physical product does not matter.

Product Goal is also now formally defined. This makes the objective of each product very clear.

Ambiguity with the Development Team and Scrum Team removed

Now there is only one team and that is “The Scrum Team”. Product Owner, Scrum Master and Developers are part of the Scrum Team. Hence the ambiguity whether the Product Owner/Scrum Master are part of the team or not is removed. Now it is very clear that there is only one team and that is the Scrum Team which consists of Product Owner, Scrum Master and the Developers.

Organizing larger Scrum Teams – now clearly defined

It is now clarified on how the Scrum Teams scale. For larger products, the teams could be organized with multiple Scrum teams however, the Scrum Teams share a Product Backlog, Product Goal and a Product Owner.

“Commitment” associated with each Scrum Artifact

This theme of transparently stating the focus to be value and not the process continues and each of the 3 artifact now is associated with a clear commitment. This commitment ensures that the artifact provides information that enhances transparency and focus against which progress can be measured. For the Product Backlog the commitment is the Product Goal. For the Sprint Backlog it is the Sprint Goal. For the Increment it is the Definition of Done.

Product goal is a new term introduced and defined as “the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.”

Increment – now more clarity

The guide also clarifies that multiple increments can be a part of the same sprint as long as the sprint goal is intact. For the first time definition of “Done” is now clearly called out as quality measure.

Sprint Planning – more clarity

One event which is described with more clarity is Sprint Planning – The objective of sprint goal definition is now highlighted as the deciding fulcrum of the Sprint since the Sprint goal is now  visibly tied to the value a sprint brings. The erstwhile guide talked about topic one and topic two as “what and how” part of the planning. The latest guide divides the planning in 3 topics – why , what and how. This brings a better flow and central idea about Value delivered being the core of each sprint gets re affirmed.

Scrum Master clarified as a Leadership Role

The accountabilities and characteristics of the scrum master have also evolved in this guide. One key verbiage change is the Scrum Master is not referred as a Servant leader but “who serves the Scrum Team and the larger organization”. While seemingly small change it clarifies that Scrum Master is indeed a leader, a leader who leads by serving.

Self Organized to Self Managed

The word “Self-Organized” has been updated to “Self-Managed”. I believe, the essence remains the same. The independent and contained nature of the Scrum Team – which “manages its own work” is better conveyed by the word “Self-Managed”

Definition of Done – A Quality Measure

Now it is crystal clear on what Definition of Done is. Most people implemented DoD as nothing but acceptance criteria. Now clarity has been created on DoD being a “Quality Measure”. This removes a lot of ambiguity on what DoD really is.

Prescriptive Stuff removed

Prescriptive stuff around conduct of Sprint Review and Sprint Retrospective is removed. In sprint review a big portion of text surrounding on how to conduct the review is removed – the event description now focuses on sprint review being a collaboration event. How to structure the event is being left to the discretion of teams working within Scrum boundaries. Same thing can be seen for Sprint Retrospective, the detailing around how the event is structured is now replaced by a concise text about the purpose of event which “is to plan ways to increase quality and effectiveness.” The guide no longer states that the event is about “creating a plan for improvements to be enacted during the next Sprint.” But emphasizes on a more long-term objective of ongoing attention to increasing quality.

The guide no longer mandates that the sprint plan contains “at least one high priority process improvement identified in the previous Retrospective meeting.” The guide still does state the importance of implementing the improvement items quickly but it stops short of getting prescriptive and mandating how and when these items are implemented.

Prescription of “usually 10% of time for product backlog refinement” is removed.

Attributes of Product Backlog Items has been removed and in fact, it is made more generic by saying “Attributes often vary with the domain of work”

Daily Scrum – the details around the 3 Questions has been removed. Even though the three questions were made optional in the 2017 Scrum guide, the three questions remained a major roadblock during implementation of Scrum. The three questions disturbed the flow of the Daily Scrum from being an inspect and adapt forum to a status meeting.

Conclusion

Friends, as the heading said – These are my views on what has changed with the new scrum guide. It is equally important to ponder  upon what has not changed. While the lightweight framework has become more nimble, the core of Scrum – Scrum Theory, principles of empiricism and  the Scrum values remain unchanged. Anytime you have a confusion while you are  on your journey discover scrum, these are the beacons that will guide your way forward.

The post Scrum Guide 2020 – What’s New? appeared first on World Of Agile.

Common Misconceptions and negative implications

Sprint Review is thought to be a “sign-off event by the Product Owner” or “a demo forum by developers” by most organizations. This is an INCORRECT understanding of the Sprint Review.

Sprint Review is actually a feedback solicitation forum. The Scrum Team seek feedback from the stakeholders during the Sprint Review. This helps address the deviations. The Product Owner and Developers work together on a day-to-day basis. The Product Owner DOES NOT wait till the end of the sprint to give feedback to the Developers.

Recommendations

• Product Owner needs to participate during the Sprint and provide feedback throughout the Sprint to the team. This gives an opportunity to the team to work on the feedback by the PO and adapt if required. This also gives opportunity for the PO to get the product ready by the time the Sprint ends.
• Product Increment is considered as an INPUT into the Sprint Review and not an output as thought by many people. Therefore, sign offs (if any) have to be done before the Sprint Review starts. Also the sign-off – if anyone has to do – it has to be the Product Owner. That’s why the word “Owner”.
• When the Sprint Review starts, the Product Owner and Developers have to be in sync with what is being shown to the stakeholders. If both the roles are in sync, then Sprint Review becomes an excellent opportunity to solicit feedback from stakeholders – who could be sales teams, marketing teams, sponsors, end-user representatives etc.
• If one wants to use the word “Demo”, then my recommendation is to use the word during the Sprint when Developers demos the product continuously and seeks feedback from the PO. Demo should be ongoing and day-to-day where-as the Sprint Review is the minimum opportunity to solicit feedback from stakeholders.
• Some may argue that getting Increment is impossible considering that stakeholder feedback happens in a Sprint Review. What we really recommend is that Sprint Review should be a “minimum” forum to seek feedback from stakeholders. Scrum does not stop you from getting more feedback from stakeholders during the Sprint.
• The objective of the Sprint is to get a “usable” Increment at the end of the Sprint. This is possible if feedback is taken frequently from stakeholders – at a bare minimum during the Sprint Review. The Product Owner feedback should be day-to-day

Sprint Review therefore, is an informal opportunity for the Scrum Team to solicit feedback from stakeholders and make sure that the deviations are addressed.

The post Myth about Sprint Review being a sign-off event or a demo forum appeared first on World Of Agile.

Common Misconceptions and negative implications

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing a SoW or a contract.

Recommendations

• Scrum Guide recommendation is to keep the Sprint Length “Consistent”. Scrum Guide does NOT recommend a “Fixed” Sprint Length. We can change Sprint Length if there are negative implications being caused because of incorrect Sprint Lengths.
• Considerations for changing the Sprint Lengths
• Changing Longer Sprint Lengths to shorter Sprint Lengths (say 4 weeks to 2 week)
  • The scope keeps changing during the Sprint and Sprint Backlog becomes a mess. What we started off at the time of Sprint Planning and what we ended up in a Sprint Review is drastically different
  • Teams develop a “student syndrome”. Means – team takes it easy for the first couple of weeks. Then goes for a dash to the finish. The team then ends up working 18 hour days for last 2-3 days
  • The feedback is so drastic each Sprint Review that you need to re-work the whole thing. Think about the Sprint Length if this happens frequently.
  • Teams and PO don’t speak to PO often and communication breaks down resulting in no or minimal feedback during the Sprint.
• Changing Short Sprint Lengths to Longer Sprint Lengths (say 1 week to 4 week)
  • Teams come under a huge stress. Deliverable every Friday is not easy. The stress levels take a toll and teams get sick of the stress.
  • Innovation goes down with very short sprint lengths. Teams become very “short-term” focussed.
  • Dividing items into smaller units becomes difficult. Beyond a point, breakdown of Product Backlog Items becomes a formality/academic rather than a real need.
  • Spilled-over work to next Sprint becomes common with very short sprint lengths. Teams are unable to create something useful.
  • Motivation goes down because of stress levels or not being able to get the Sprint to produce something usable every Sprint or stakeholders constantly feeling upset about not being able to complete.
• DISCLAIMERS SO THAT YOU DON’T MIS-UNDERSTAND OUR STATEMENTS ABOVE
  • DO NOT keep changing the Sprint Lengths often. Try a Sprint Length, see if it works. If it does not work, then change. Once you find a length which is solving most of the problems, then stick with it. Be CONSISTENT. Being able to change the Sprint Length does not mean you become random and chaotic in the way you work.
  • DO NOT think that there is a “PERFECT Sprint Length”. There can never be a “Perfect Sprint Length”. See what Sprint Length solves “MOST” of your issues.
  • DO NOT change the Sprint Length when you are inside the Sprint. Just because you are not completing a Scope, does not mean, you change the Sprint Length by extending it. Sprint ends when a Timebox ends. You may think about changing the Sprint Length from the next sprint onwards.

The post Myth about baselining the Sprint Lengths at the start of the project and never changing it appeared first on World Of Agile.