Sprint Till You Drop, and three other tales of Scrum gone wrong

Scrum can easily go wrong. Let’s take a look.

(This post is an excerpt from our earlier article A Pretty Good Summary of Lean, Agile, Scrum.)

‣ The Spiritless Scrum: Sprints as Mini-Waterfalls

Often, User Stories become mini specification documents. With that, coding or whatever activity gets executed, and then a UAT (user acceptance testing) or other sign-off process takes place. At first glance this doesn’t sound wrong, and a lot of teams fall into this trap.

The problem is, this is just running a mini-project in mini-waterfall style. Analysis, design, coding and testing are done in sequential fashion, possibly across multiple Sprints and most likely as a hand-over process between functions (e.g. BA (business analyst) > developer > QA (quality assurance)).

Lean & Agile is about discovery against uncertainty. In Scrum, the build-measure-learn cycle is designed to occur within Sprints, and team members who work on hypothesizing, MVP (minimum viable product) building and testing need to work as close as possible with each other; i.e. cross-functional teamwork. Work does not have to be sequential — if something is not working or missing the mark, it’s totally okay to make design changes and modifications, or make the conscious decision to pursue a different approach; i.e. tweaking and mini-pivoting. Mini-waterfalls defeat the purpose of iteration and only achieves the small increment benefit of Scrum.

‣ Territorial Scrum

Agile is now common place in software development teams. The problem is, in many organizations it’s just the development team that is running Scrum, effectively creating an island within the organization.

The result is a hand-off culture between the development team and the rest of the organization, i.e. to the sales team: “we’ve put together the product as per your specification, now go sell it”.

The key to propagating organization wide Agile is to let people perceive Agile as a wider notion of communication, cooperation and co-creation, and not just a mere project management framework. Ask the question, if we can’t connect well enough among ourselves internally, how can we connect with our customers? This should sprout the persistent customer value creation and product market fit thinking across teams.

In terms of actual implementation of organization wide Agile, Scrum on sales and marketing can be ran in parallel to the development team’s Scrum. Eventually though, it would be best to aim to shifting to cross-functional Scrum teams where development, sales and marketing functions are all within each Scrum team, aligned by products or client projects.

‣ Scrum Master in Command

During the Daily Stand Up, if people are giving status updates to the Scrum Master, and the Scrum Master is telling people what to do, then you’re defeating the purpose of Scrum.

Scrum is a systematic effort to get organizations out of manager-worker mode. Commanding leadership models fail in problem solving enterprises — it relies on the leaders to have all the answers, making the leaders themselves the impediment.

In an Agile organization you try to bring out all the “co’s” from people — cooperation, collaboration, coordination, co-creation, communication, connection and so on. The Scrum Master’s role is to keep the “co” flow sideways, not vertical as in being in command.

We also have to understand the passive comfort of the “worker” in manager-worker mode: taking instructions for work is comforting because you don’t have to think of the whys and hows, and you are free from the responsibilities of decision making. Scrum addresses the pain of transformation to autonomous working mode in many ways; the small building block approach makes work easier to manage, the Daily Stand Up is meant for team members to help each other when they’re stuck, and the no blaming people culture encourages individuals to take on the risk of experimentation.

‣ Sprint Till You Drop

If a leader devises “sprints” as a systematic means of making people work as hard as they can on perpetual high alert, that’s simply a habitual management by crisis, or worse, exploitation of labor.

A less evil leader may position “sprints” as something akin to interval training in track or swimming. He may argue, by going through a continuous cycle of intense work, the team will be able to push the boundaries of its performance. But this risks team members to mental exhaustion. It would be hard to attract and retain talent to work in such high stress environment.

After one Sprint, the next Sprint begins immediately. If the team begins the new Sprint trying to recover from the last one, clearly they are over pacing themselves. Sprints have to be ran at a sustainable pace where no breaks or recovery time between Sprints is needed.

Scrum Sprints probably shouldn’t be called sprints, actually. It should be called more like jogging or something. Yes it’s true that you would want your team’s “velocity” to increase (in Scrum we use “Burn Down Charts” to measure this), but it’s not terminal velocity that you go after. It is improvement in average velocity that you pursue, i.e. more distance covered in the same amount of time. And as any long distance runner will attest, finding the right pace and rhythm is the key for going the distance.

Sound familar? At Lifecycle, we have a good understanding of organizational behavior and a method of hacking to drive a successful Agile Scrums. Contact us to learn how we can help you fix your Scrum. 【engage@lifecycle.management】