Would you like to avoid the same trap many companies fall into when beginning with Scrum?  Last week, I got a call from a new client and it became apparent they found themselves in the same swamp like many others after a few months of doing Scrum.  The call went something like this.

Carlton: “Sooo…tell me some of the things that you have done so far.”

Client: “We started Scrum about two years ago by sending some people to Certified ScrumMaster (CSM) course.”

Carlton: “OK – good.  Education is a good place to start.  So then what happened?”

Client: “Not much.  We thought more would have happened, but after eight to ten weeks everything pretty much stalled out.”

While education is a good place to start, unless people being to change their behaviors and ways of working together not much is going to happen.  I have found the best way to encourage new, more healthy behaviors is to change the constraints of the system.  Once the new constraints are in place, the job of a ScrumMaster (or change agent or consultant) is to observe how the Scrum Team self-organizes into a new set of behaviors and nudge the Scrum Team (and the business) in the right direction.   To help you with finding the right set of constraints that support Scrum, I am going to offer a list of constraints first identified by long time Certified Scrum Trainer Michael James.  His work is consistent with my experience as well.

A word of caution, one thing that I have observed that does NOT work is being flexible with the constraints.  If you change the constraints, you change the behaviors of the Scrum Team.  These constraints encourage people to work in a way that is more Scrum-like, which I am assuming that is your goal.  If that is not your goal, then pick and choose the constraints you want.  If you are interested in doing Scrum, stick with these constraints.  Additionally, I find when more constraints are in place and the stronger the organization respects the constraints, the faster the Scrum Teams take off and the less danger the organization has of stalling out.  Finally, I find when the constraints are removed or are seriously weakened, the Scrum Teams tend to self-organize back into their old patterns of working.

1. The Team tries to build a [potentially] shippable product every Sprint, starting with the first Sprint –  Scrum is all about delivering product each and every Sprint.  Any outcome offered by a Scrum Team that does not meet this objective should be considered a failure.  I tend to view this type failure more as a learning opportunity, or a challenge, for the Scrum Team (and the organization) to figure out how we can get one step closer to that objective, rather than the means to punish people.  In most cases, people are doing their best they can within the constraints of the business and it is the environment that gets in the way of this goal.  Consistently I have found that Scrum tends to “stall out” when the business leaders are not committed to the process and fails to offer the Scrum Team what it needs to be successful.  However, if we do not hold the Scrum Team (and the organization) accountable to deliver product at the end of each Sprint, even the very first Sprint, then lots of environmental factors that inhibits the delivery of potentially shippable product are allowed to remain.  Always deliver something of value that can demonstrated at a Sprint Review no matter how small.
2. The Product Owner prioritizes – this one is really obvious, but I am surprised how often this can be troublesome for organizations starting up with Scrum.  Scrum works best when the roles are fully inhabited and committed to by the participants and the business.  IME, when the roles are weak, Scrum is mediocre at best and is on its way to “stall out”.  The Product Owner role is the most important role in Scrum and the most difficult.  It requires a great deal of knowledge and experience about how the business operates, an understanding how the product benefits the business and an awareness of the overall business trends that shape the product direction.  In the beginning, it is unusual that one person will know all this information and the Product Owner should seek out Stakeholders for this input.  While anyone can give the Product Owner advice on the priorities, in the end the Product Owner must have the final say on the business priorities to support their accountability and focus on inhabiting their role in Scrum.  If someone else is allowed to have that final say, then in reality that person is the Product Owner, not the person doing the job or who has the title.  There is only one Product Owner for the Team – everyone else is a Stakeholder.
3. Clear goals are set for each Sprint – a Scrum Team exists to deliver new value and capabilities to the business.  If a Scrum Team is not providing new value to the business, it should be disbanded and the staff assigned to other more valuable efforts.  The sad reality is that in many organizations, they do not have the courage to cancel a Team when the time is right and fail to offer clear goals and objectives.  The common result is that Scrum Teams just “do stuff” until they “stall out”.  For me the Sprint Goal – a concise, one to two sentence summary, in the language of the business, that unites all of the work the Team is doing – is absolutely essential for Scrum.  For Team members, the Sprint Goal explains why the work they are doing is valuable to the business and offers greater opportunities to contribute beyond their functional duties.  For Stakeholders, the Sprint Goal helps them understand how the Team contributes to the success of the organization and when the Team needs their feedback and participation.  If the Product Owner cannot define the Sprint Goal they either have not thought out what they are trying to accomplish with the product or we have reached the end of the life for the Scrum Team.  Do not begin Sprint Planning until the Product Owner has defined a clear, easy-to-understand Sprint Goal.
4. The Sprint timebox – again this is another really obvious constraint, but I find lots of mushy and\or porous boundaries between Sprints.  Just to reiterate, a timebox is a fixed increment of time that neither expands nor contracts.  In Scrum, it can be as short as a week and as long as 30 days.  A key breakthrough in the adoption of Scrum in an organization is when people start “to get real” about what can be accomplished with the resources available and time allotted.  This only happens when the Scrum Team finally has the courage to stop telling the business what they want to hear and ask them to make choices based on empirical data, i.e. the progress to date of the Scrum Team.  The timebox supports these new behaviors in two ways.  One, the Scrum Team and the Stakeholders get into a regular rhythm of communication, feedback and inspect-and-adapt.  While the outcomes of Scrum may not be predictable, the touch points and opportunities to make adjustments are predictable.  Two, the timebox asks the Scrum Team to make a commitments to deliver the Sprint Goal before the end of the timebox.  This commitment is not pushed onto the Team by the Stakeholders, but a commitment the Team makes based on the available information at the time of Sprint Planning.  At Sprint Planning, the Stakeholders review how close the Team came to meeting the Sprint Goal or not.  If we keep extending the timebox by “just another day or two”, the Team will never learn what is their true capability to deliver.  Never extend the timebox – when it is over, it is over.

The original draft of this article included all nine common constraints necessary to support an organization’s successful adoption of Scrum, but it was getting too long.  Come back in a few days and I will share the rest of the list.