Dysfunction #2: Done Increment as a Team

In this series, I am going to reflect on what I have learned about Scrum and its large-scale adoption in a non-IT environment through my own revelations and indeed, failures, while working at a large UK-based company, rolling out its own flavour of Agile Transformation. Capital “A” and capital “T” intended.

Originally published at https://www.linkedin.com in October 2020.

In the early 2000s, Agile has, beyond doubt, changed how software is crafted. In its wake, practitioners realised that complex creative work or knowledge work, where the outcome is unknown, cannot be managed efficiently using Taylorian best practices — simply because of the uncertainties and unknowns that one should embrace while writing software.

Agile has introduced a new paradigm, and due to the urge of having to present working software frequently, a new way to structure user requirements had to be devised — a structure which would yield to delivering small slices of customer value. Enter the agile cake metaphor:

Instead of upfront end-to-end analysis, followed by extensive and in-depth design, a heavy build phase and rigorous testing — what if we took a barely visible cross-section of customer value to be delivered by a tiny slice of all the disciplines we have in the team. By shipping that, we could figure out if we are on the right track. If yes, we can continue with what is most important at that moment — if not, then we can scrap the increment without losing too much time and effort. This way, we could ensure that we win small or fail fast.

But sometimes this is just not possible…

Imagine that LoveMotion, a company that organises world tours for artists, decide to embark on an Agile Transformation. In this journey, they set up cross-functional teams and use Scrum. ‘Hey, it works in creating complex software, it will work here as well,’ they say.

One of the teams, called “Live Metal” is working with prime metal bands (oxymoron, I know, I KNOW) and organises tours for them. The team has the following members ( in italics) and responsibilities: there is a legal professional who is working to sign the bands. Once the contract is signed, a logistician steps in, who is responsible for scheduling the tour. They manage the hiring and transportation of equipment, staff and the band as well, making sure they can get some good nights sleep in the most expensive five-star hotels one can find. The team also has a marketing specialist who works with a designer, a copy writer, a front-end specialist to create engaging websites, emails and other online marketing campaigns.

This team of six is clearly working towards the same goal: to make sure bands can hit the road. But does it make sense for all of them to be on the same team? When deciding what roles and responsibilities are needed in a team, one might want to try to avoid the following two anti-patterns:

Anti-pattern #1: Not everyone can contribute to delivering a Done increment

Legal nit picking is long and tedious and no customer value is delivered until the contract is signed. In this example, our legal professional is kept on the team (so the team can monitor how far a band is from signing), and is asked to attend the Scrum events where they share their update every day. Instead of being a team member, however, they serve as a gatekeeper: planning the tour or creating marketing material cannot start until the ink on the deal has dried. Additionally, the logistician also serves as a gatekeeper to the team — team members responsible for marketing and creating digital content cannot start work until the tour is scheduled with dates and exact timings.

The scenario above reveals that this team is working on three completely different time planes and cadences. There is no way they can produce a Done Increment together even though the Guide clearly states that “Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment.” Mind you: not an end-to-end product, but a product increment. The above could perhaps be paraphrased like this:

Only people with skills required to create a product Increment work in the team.

Also, I feel the need to reintroduce the image I used in my previous article:

If your Scrum team has so many disciplines that that cross-skilling breaks down, your team might be too big. This anti-pattern where not everyone is able to contribute to delivering value in a sprint might lead to the team’s indifference whether or they deliver any at all in the time box. “If legal and logistics don’t have a role in delivering customer value sprint by sprint, why should we feel committed?”, they might say and rightly so.

Anti-pattern #2: No customer value is delivered in a sprint

I have witnessed teams that fell into the trap of not feeling the need to deliver customer value each sprint — they were creating drafts, concepts. Designs, mockups. Proposals for management. Wireframes. Sub-tasks for deliverables. I have to also admit that I tagged along: “ We’re doing sprints, after all”, I said. One day, I was talking to one of our agile coaches about all the work they were creating ( Hello Ben!). All, together, in a sprint, like clockwork. “ Look at all the bells and whistles. Isn’t that beautiful”, I gloated smugly as I took a massive part in setting up the team’s Scrum process.He looked me deep in the eye, smiled with empathy and said: “But ya know the team’s supposed to deliver customer value at the end of the sprint, right?” And I stood there dumbfounded. Thunderstruck.

I felt as if I just came around from a coma. Of course! That would be the end-goal of a sprint, wouldn’t it. We need the constraint, the time box of a sprint, so that we are pressured to find novel ways of collaboration and deliver something of value to quickly test our assumptions and get feedback from the customer. “A “Done” increment is required at the Sprint Review” […] “to inspect the Increment and adapt the Product Backlog […].” echoed in my brain as I ran through the Guide again.

This is where two core pillars of empiricism come in: inspect and adapt — practices that uphold the framework of Scrum. But without the right thing delivered, there is nothing to inspect and adapt. In our example above, an updated website is customer value, a draft copy of a contract isn’t. An email sent to thousands of people is customer value, collecting the data of all those to whom we are going to send emails and saving them in an Excel sheet isn’t.

So what purpose will my neat metrics serve. What point will a precisely-tracking burndown chart prove. What value will our consistent velocity have if there is no inspectable product increment by the time sprint review starts? All this fluff for nothing. You blow off the smoke and a gaping void yawns back at you. It will be uncovered that this beautiful Scrum process supports nothing and then it will gradually implode like chocolate soufflé, won’t it.

Awakening to this anti-pattern lead to another key learning for me: Scrum mandates the delivery of value each sprint for a reason — this is one of the things that sets it apart from waterfall. When I shared this learning with my peers, there was a short discussion around the need to “customise” Scrum to meet our needs — but I felt we are missing the point. If we are OK with not delivering value every sprint, we are not doing Scrum, but a massive disservice to it.

By using Scrum terminology for the events, upholding the faux process, we front for waterfall:

We dress up waterfall and disguise it to look like Scrum — wrapping it in two-week sprints.

Additionally, we are ripping up the feedback loops designed in the framework. Our environment will think we are doing “Scrum”, because we practice the highly visible parts: the events. What they don’t see is that by not delivering value consistently, we got rid of the not-so-visible parts — and we set the framework up for failure.

Because the scaffolding that upholds nothing; that doesn’t nurture an emerging product will, in the end, come tumbling down. It has to, since we rooted out the heart of Scrum: the feedback loop, and it can have one outcome, and one outcome only: failure.

And who gets to blame? Scrum gets to blame.

Originally published at https://www.linkedin.com.