Data and Analytics Resources

Provide Confident Assurance to Your Organization

Agile Principle Part 3: Deliver Working Software Frequently

by Ken Rickard

Dec 11, 2017

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

Building software is not the same as constructing a building. We can build software in pieces, unlike construction where I can't build the 2nd floor until I've built the 1st. Software is malleable.

Let's break this principle down...

Deliver Working Software - Every company has that moment where someone in a meeting, or just in passing says something is "done". Undoubtedly the person saying it and the people hearing it interpret "done" differently.

Working software is an important distinction because it means you can't build 3 out of 5 steps and call it done. Instead you'll need to produce some amount of everything top to bottom in order to call it working. However "working" can still be subjective, which is a good thing because it requires us to agree upon what working means. This is not an agreement between just the developers, instead developers should be agreeing directly with the people that asked them to do the work. More communication equals more understanding, less risk, and better outcomes.

My career has revolved around Business Intelligence. I've spent the majority of the past 6 years teaching and coaching developers on these projects how to tackle vertical slices of work to make sure we can deliver value quickly. Building things horizontally not only takes longer to find mistakes and value, but also has a higher rate of failure. Most developers are not conditioned to work vertically, especially if they've been in the industry for some time. I go into further details around this subject in a previous article - Scrum for EDW/BI.

Vertical work is almost always possible, even when building data warehouses, we just have to "unlearn what we have learned", to quote a famous little green guy from long long ago.

Shorter Timescale - For the second time in the first 3 principles we find a reference to time. In principle 1 it was "early and continuous", and now we find ourselves thinking about frequency.

"Shorter" to me means picking a time cycle that is just across the line of painful, while still providing consistent value. If you pick a more comfortable time cycle how will the team respond? Will there be enough pressure to keep things moving at a good pace and still build innovative products in a timely manner?

"To achieve great things, two things are needed: a plan, and not quite enough time" - Leonard Bernstein

How you create the "plan" in this case is Agile, and you could say that adding Scrum, and sprinting provides the limited time box required to produce exceptional products.

This 12 part series was published by Ken Rickard on LinkedIn Pulse, to read the original version of this blog click hereTo read the entire 12 part series, click here for a table of contents. 

Interested in learning more about the Agile Methodology or incorporating it into your business? Contact a representative at CCG by emailing info@ccgbi.com or call (813) 265-3239.