Fundamentally Agile: Why is Closing Sprints So Important?

In waterfall, we commit to (or have commitments made for us) delivering on time, within budget, and a to defined scope. In Agile, we say that for a given date, we will estimate the work that will be done, and update the business as we go.

Of course, this principle is as widely ignored as it is misunderstood. Part of the misunderstanding is that planning-driven businesses think that if things are planned properly, then teams should be able to execute them to schedule. Unfortunately, this thinking is incorrect on several counts.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

The first count is that it treats software like the repeatable, repetitive tasks that traditional project management evolved to control. The realization of Agile, however, is that software is neither repeatable nor repetitive and thus is also not predictable. Therefore traditional project management does not apply. Agile is came about in reaction to this.

If we have this constantly changing problem space and increasing collaboration growth, which precludes us from following a plan, how then do we help the business gain any predictability at all? We commit to finishing a certain block of work in a set period of time. Timeboxing the work this way is how we get to focus on completing a valuable piece of work, while also giving the business plannable increments.

By updating our overall backlog estimate at the end of every sprint and applying our velocity to it, we can then update what we estimate we can complete by a certain date. This commitment to finishing a sprint is essential because this is the mechanism by which we escape the iron triangle where somebody outside the team created an “estimate,” which became a commitment, which the team is locked into before we ever see the work. Instead, we ask the team to look at the business problem, create a backlog, prioritize and size that backlog, estimate a release schedule, and update this at the end of every sprint. This is the contract that we make with the business so that we can be self-directed.

“Working software is the primary measure of progress”

Achieving this creates trust and allows the business to make decisions. When we fail at this, we create a rolling wave of technical debt and lack of trust with our business partners. Eventually, they will come in and manage us in the only way they know how. We will lose our autonomy, and ultimately the thing we are trying to achieve – quality software – will fall wayside to the process.

“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”

The other major fallacy is that how you complete the work is independent of the work you complete. Again, Agile came about in reaction to this. As soon as you start the work, you narrow the Cone of Uncertainty, and increase the Cone of Understanding. This is not just on the development end, but also on the business/customer end.

This is why we demo: so that we can get constant, rapid feedback and adjust. Not “in case we need to” but because we embrace the fact that as we show our work to customers their understanding and needs will also evolve and instead of building the product to a preset plan, we will build the best product. Forcing a team to follow a plan to make them predictable, rather than embracing change, also forces them to create, at best, mediocre software. For this reason often when do we do everything we were asked, we still have unhappy customers. I recently worked with a group who turned of 40% of the features they delivered as having no business value. Ouch.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

One final thought. When we talk about “potentially releasable code,” it’s not just completing the Definition of Done on a single piece of software that would not add significant business value. It’s about creating new functionality every sprint through a combination of all  our stories. This is why Scrum focusses on “vertical slices” – because those slices represent finished, tested, and integrated business value. A best practice is to clearly define what this increment will be in a sprint goal. When coaching, I often challenge the teams by saying, “If we lost our funding at the end of the sprint, what value would we have added?” If we don’t close the sprint, even if we get “most of it” the answer is “None.”

Conclusion:

·       Create your own Affinity Estimate and release plan.

·       Organize the sprints to deliver business value through sprint goals.

·       Commit to delivering that value.

·       Do whatever it takes to make that happen: swarming, pairing, testing each other’s code, etc.

·       Use the demo feedback to update the backlog and maximize your business value.

·       Update your backlog estimates and communicate them out at every demo.