Are You Delivering Potentially Shippable Product Each Sprint?
By Ridhi Chhabra
By the end of each iteration, a Scrum team is expected to produce a Potentially Shippable Product. As we know Agile methodologies emphasizes on “Working Software over Comprehensive Documentation”. When we talk about working software, it is both complete and potentially shippable.
Agile methodologies emphasizes on working software which is both complete and potentially shippable due to following 3 reasons:
It encourages feedback
It helps a team gauge it’s progress
It allows the product to ship early if desired
In order to ensure, we are delivering a Potentially Shippable product at the end of the sprint, we must understand what potentially shippable means.
Defining Potentially Shippable
As per Scrum Inc, a Potentially Shippable Product is the outcome of the Product Backlog Items delivered at each Sprint. Delivering Potentially Shippable Product at each Sprint is essential to the Scrum because when work is divided into simple pieces it can be finished in a short iterations.
As per Mike Cohn, "potentially shippable" and "shippable" are not the same thing. Some large or complex projects will require the use of "release sprint" or "hardening sprint" at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur.
Let’s have a look at some of the guidelines here:
Organizations define their own ‘definition of done’ for every product and project. However, there are some guidelines that are applicable for almost all the Scrum projects in most of the organizations.
Potentially Shippable means Tested!
There can be no situation where a product is delivered without being tested. By the end of the Sprint, the delivered product increment needs to be bug free. If needed by the Product Owner, the feature should be a bug free, it can be released to the beta users or the stakeholders to review.
Potentially shippable does not mean cohesive
Just because we know that the product is potentially shippable, this doesn’t mean that people wants us to actually ship it. Many times it takes 2, 3 or more sprints for a feature set to come together to be useful. However, during the Sprints leading up to that point, the team should still strive for a product to be potentially shippable.
The #Scrum team as a whole is responsible for delivering a working increment of the product at the end of each sprint http://t.co/NqnOc7JeUt
— Manifesto (@ManifestoLondon) September 16, 2014
Potentially shippable means integrated
A potentially shippable product doesn’t exist as different collections of source code. On a project, where multiple teams are working, the teams should define the statement of done such that it includes integrating development steams. So, Integration should be done continuously throughout the sprint.
Does Potentially Shippable means Shippable?
Well, when we define the ‘definition of Done’, We want it to be a Potentially Shippable product. This doesn’t mean that it has to be shippable. Whether the product needs to be shipped or not, that’s a decision taken by the Product Owners, or Business Owners.
Hence, Potentially shippable is a state of confidence, that the product delivered at the end of the Sprint, is so Done that it’s Potentially Shippable.
based on 1 customer reviews
Patterns For Adopting & Spreading Scrum In Organizations
By Ridhi Chhabra
When we talk about adopting any new framework or methodology, we think about how we can incorporate these changes into our organization. We simply cannot impose any change in our organization and get started with it, there has to be some process or ways to incorporate that. Also, there are some ways to incorporate Scrum changes within our organization. There include five activities in adopting the Scrum successfully:
So to remember, we call it by the acronym ADAPT.
Let’s now talk about the Patterns of Adopting and Spreading a Scrum:
Patterns for Adopting Scrum
Start Small or Go All In
Organizations go ahead with it like a Pilot project, like selecting few team members and implementing Scrum with them, It's a ‘Start Small’ pattern. The other approach can be Go All In, which is like the executives are convinced and want the whole organization to implement in one go.
Reasons to prefer starting small
It’s less expensive
Early success guaranteed
Avoids risks of going all in
Can be done without much change
Reasons to prefer going all in
Avoids problems within different teams
The All-in transition is Quick!
Choosing between the two
As recommended by Mike Cohn, one should always Start Small! It involves less cost, and guaranteed early success. Going all in should be in limited cases, only when it’s a quick need. Also, it involves more cost/money as there are a lot of changes in different departments if required.
Public Display of Agility or Stealth
The next pattern that comes into the picture is whether to Publicize it or not. We can do the Public Display of Agility. In this approach, the organization announces that it is adopting Scrum. This can vary from announcing it in a meeting room to announcing it through the press release.
The other approach is Stealth transition. In this, only team members know they are using Scrum until the project is complete.
Reasons for Public Display of Agility
Everyone knows that team is doing it and they are more likely to be focussed
Operating publicly is a firm statement of commitment
You can solicit organizational support
It sends a powerful message
Reasons for Stealth Transition
A chance to make progress before resistance starts
It keeps pressure off
No one knows until you tell them
If no one knows, no one can tell you to stop
Choosing between the two
As recommended by Mike Cohn, always choose to make a public display of Agility when you are confident and committed to the transition and when you expect a lot of resistance but want to overcome it quickly.
In contrast, choose a quiet approach, when you want to do an experiment using Scrum.
Patterns of adoption:
"Going Through the Scrum Motions as Opposed to Being an Agile Jedi " https://t.co/tpv9kIVxNU @MichaelNir (via @InfoQ)
— Stefan Wolpers (@StefanW) May 16, 2016
Patterns for Spreading Scrum
Getting started with Scrum is one thing, spreading it across the organization is another. Unless you choose an all-in transition, you will need to build upon the successes of the first few teams as you move Scrum to other teams.
There are 3 general patterns given by Mike Cohn that talks about spreading Scrum.
Split and Seed
This talks about taking a team that has begun to be successful with Scrum and using its team members to seed new teams.
It’s typically put to use after the first few teams have successfully implemented and adopted Scrum. By this time, each team member understands how Sprint work and how the ready software is delivered at the end of the sprint.
In Split and Seed pattern, we split one functioning Scrum team into each half of the original team forming the basis of the new team. New people are then added to these split teams to form new Scrum teams.
A large initial team is used to seed as many as four new teams. Collated below are the reasons to prefer Split and Seed pattern.
Add teams more quickly
Each team has someone with Scrum experience to guide them
Grow and Split
The Grow and Split pattern involve adding team members until the team is large enough that it can be comfortably split in two. Immediately after splitting, each of the new teams will probably be on the small end of the desirable size ranging five to nine members. After allowing the new teams one sprint at this reduced size, new members are added until each team becomes a large enough that it can also be split. This pattern repeats until the entire organization has transitioned.
In following cases, you can prefer Grow and Split pattern.
Don’t have to destroy any existing teams
Team members feel more continuity from sprint to sprint
The Third pattern of Spreading Scrum is Internal Coaching. In the organizations, there include types of teams. Some teams excel with the new agile approach, while others struggles. On each team, there exists one identified person who understands and implement Scrum successfully. That person is assigned as a Coach for other teams.
Coaches were given responsibilities to attend sprint meetings, daily scrum each week and coach other teams.
Reasons to prefer Internal Coaching
Well running teams do not need to be Split
Coaches can be selected for new teams
Coaches can move from team to team
Choosing your Pattern!
In general, consider going with Split and Seed pattern, when in a hurry. It is the fastest way of spreading Scrum. However, if the technology doesn’t support moving people among teams, changing the team members can affect the productivity.
The Grow and Split pattern is simply more natural and direct approach. Consider using this approach if there is no sense of urgency as it is less risky.
Internal Coaching can be used on its own, mostly when the group is large enough and when splitting teams are not possible for the projects.
based on 13 customer reviews
We’re in Agile, We don’t Plan! Really?
By Ridhi Chhabra
‘We are in Agile, we don’t plan!’ This was one of the most common statements in early Agile implementations. Many people in early Agile implementations took this step, knowing that they were giving up something really valuable. However, there was a natural reaction to this.
This is now considered as a common myth, as planning is a fundamental aspect of Scrum. The Scrum team is committed to working towards the working software delivery with the highest value. To implement this, the team and Product Owner must have an estimate of the feature, cost for development. Intelligibly, a Scrum team is committed to working according to prioritization. Hence, Planning is an essential practice!
In fact, We Plan a Lot!
Sprint starts with an event called Sprint Planning
The next step in planning is when the Scrum team estimates and commits to working towards the delivery of potentially shippable product at the end of the Sprint.
Scrum team comes up with a detailed plan of-
How much are they estimating, that they will complete within the sprint?
How much will be the cost/value/hours of the tasks to be delivered?
Planning happens on an everyday basis
The Daily Scrum for the Scrum Team is to review the progress and refine the plan to meet the Sprint Goal.
Plan on what is to be done
Plan on overcoming the impediments
How successful is your sprint planning? https://t.co/PTyozdqh7L @kbondale looks at 4 common challenges which impact this critical ceremony #agile #pmot #sprintplanning pic.twitter.com/2xS9a0zC34
— Agile Alliance (@AgileAlliance) March 28, 2018
Scrum Teams Own the Plan
In each event, we are “Inspecting and Adapting”, Scrum teams takes the Product Backlog and come up with their plan and create their own Sprint backlog. They create it, inspect it and then adapt it for upcoming sprints and better results.
Sprint Review and Retrospectives are the part of the Plan
The Sprint Review is a collaborative event where the whole team gathers, reviews the product increment created, comes up with a feedback and adapts to make changes. This all is to support the planning of the next Sprint.
The Sprint Retrospective is again a collaborative event to enable and plan for continuous improvement. Team plans to start, stop and continue doing the things in the current process.
Progressively Refine Plans
The Product Backlog should be progressively refined. It should be broken down into small user stories which can be easily implemented as we move along with the project. Eventually, the similar approach is to be taken while planning in Scrum.
Let’s have a look at the advantages of having a progressively refining a plan in Scrum-
It minimizes the time investment:
Planning is important, but it can be time-consuming. The time spent in estimating and planning is best viewed as an investment.
It allows decisions to be made at an optimal time:
Progressively refining the plan helps the team avoid falling into the trap of making too many decisions at the outset of the project.
It allows us to make course changes:
One thing we know, when we are in Agile, that change always happens. Planning enough that we know in general but not all the aspects leaves the team with the flexibility to alter the course as more is learned.
It helps us avoid falling into the trap of believing our plans:
No matter how well we understand the expectations, and that no plan is safe from change. Progressively refining a plan reinforces the idea that even the best plan is subject to change.
So, when next time you say, We’re in Agile, We don’t plan! Really? Think about it!
based on 1 customer reviews