Agile Digital Transformation Insights Lean Startup

Time to pump up the tyres on Agile — without a budget blow-out

by Paul Scott, Director and Board Advisor at Digital Village

Photo by Henry Perks on Unsplash

The fall out from COVID-19 has yet to be fully understood, but one thing’s for sure; enterprises will be seeking fast, efficient and flexible ways to solve their problems with digital solutions. Projects have been backing up during the lockdown and now’s the time to begin clearing the backlog. It’s likely to lead to an uptick in demand for skilled resources, but will they be able to deliver fast enough and to quality?

The announcement this week of the budget blow out at the Australian Digital Transformation Agency’s son-of-Mygov project hows just how quickly things can get out of control without a laser focus on solving one problem one at a time.

The methods used to build solutions with software haven’t changed significantly for 30 years. And even though we’ve lived in the Agile Age for almost 20 of those years, the time it takes to deliver solutions, not to mention quality and efficacy are still falling short of expectations.

Beyond Agile, examined why software development failed to meet the lofty aspirations of the Agile Manifesto founders. The book also explained how to avoid some of the classic mistakes of Agile software development.

A recent talk given by one of the creators of the Manifesto for Agile Software Development, Dave Thomas, underlines the dysfunction caused when the principles of the manifesto are misinterpreted or distorted to fit a corporate IT agenda. He half-jokingly attributes the downfall as our tendency to turn adjectives into nouns; so instead of the title Manifesto for Agile Software Development, people turn it around a truncate it to — Agile Manifesto, thus losing its meaning and purpose.

Beyond Agile explored many of the noteworthy ‘lightweight’ methodologies in use today, some of which pre-date Agile. This provided context and explained why software development often fails to meet people’s expectation. One of the founders of the Manifesto for Agile Software Development, Alistair Cockburn puts it simply:

“The Agile Manifesto was the product of seventeen people from different schools and backgrounds. No one person is responsible for the words we came up with — it is clear that it was the product of all seventeen people. The addition or removal of any one person would have changed the outcome, something we recognised and discussed at the end of that meeting.

Whether you think ‘Agile’ saved the world or poisoned it, be sure always to recognise that it grew from a rich compost (joke intentional) of backgrounds. The next time you read a would-be history of the Agile movement, look for all those names. If you don’t see them, it is not a history, it is one person’s personal recounting of their own journey, years after the event (as indeed, this one is).”

Cockburn’s statement gets to the heart of why Agile is such an enigma: few people bother to understand or respect it for what it is, choosing instead to follow second-hand interpretations of the manifesto or, worse still, a consultant’s cheap imitation of it.

Agile failed not because it was inherently wrong or misguided. The Agile Manifesto was an irrefutable thing of beauty, and its core values are spot-on. The problem with Agile is it was released into the wild and then co-opted by people unwilling and unable to really think about it or understand what it meant. Kent Beck, the creator of extreme programming and one of the original signatories to the Agile Manifesto, calls this the ‘staring dog problem.’

“If you try to point something out to a dog, it will look at your finger,” he explains. “If you explain an idea in terms of concrete practices — like test driven development, pair programming, continuous integration — people will fixate on the practices and stop thinking.”

Scrum and other lightweight spawns of Agile are failures precisely for this reason. They shroud important ideas like user-centricity and fast iteration in practices, rituals, silly names and guiding principles. The Agile manifesto itself, despite its brevity, left too much room for interpretation. And now it feels like we’re back where we started in the late twentieth century with powerful technology and tools and no idea what to do with them.

Beyond Agile describes the three reasons why the method was created :

  1. To eliminate (or at least reduce) waste in software development;
  2. To create software that people actually use; and
  3. To deliver projects on time and on budget.

An analysis of fifty thousand software projects conducted by The Standish Group found that in 2015, an average of 29% of projects were successful (meaning they were delivered on time, on budget and to a satisfactory standard). The remainder, 71% were either failures or ‘challenged’ to meet expectations. Just think about that for a moment: starting a large scale technology project you only have a 1 in 3 chance of being able to celebrate success. Not very good odds. The same report in 2018 showed the situation had got worse with only 23% of projects successful and 77% wither challenged or failed.

Other sources corroborate these worrisome facts. In a paper presented to the 7th International Conference on Knowledge Management in Organisations, Stanley and Uden proved that software projects typically overrun their budgets by two hundred per cent, and exceed their schedules by fifty per cent.

But it’s the cost of the failures that’s the real issue here. The financial impact of project failure is nothing short of tragic:

  • The cost of re-worked and abandoned systems costs the US economy an estimated $75 billion per year;
  • In Australia, $5.4 billion is wasted each year on IT projects that don’t deliver value or are abandoned completely;
  • One project alone — the infamously abandoned National Health Service patient record system in the United Kingdom — cost taxpayers £10 billion.

To put those numbers into perspective, the United Nations estimates that a yearly investment of $267 billion would end world hunger by 2030. A meagre $175 billion per year would eliminate extreme poverty globally.

It’s been a long time since the Agile Manifesto was written, and even longer since Winston Royce published Managing the Development of Large Software Systems. But nothing has changed and no single methodology has really improved software development. Software development is still a hugely expensive, wasteful endeavour that rarely meets expectations. And that’s unacceptable, especially as we approach the end of lockdowns in the COVID era.

It shouldn’t be beyond humans to come up with a better, more reliable way of developing software solutions. Just as garment makers and car manufacturers in past centuries industrialised their domains, so too software coders need to do the same. Digitisation begets automation.

Methods like Beyond Agile address some of the shortfalls of alternative methods, but it’s by no means a silver bullet. It requires skilled people, disciplined practices and full engagement with users and the problem owners. Indeed its quite likely that many of the principles distilled in Beyond Agile can and should be applied to other development methods. This would go some way to fixing Agile.

In summary, to make Agile methods work there are four areas to consider which align closely to the original manifesto:

  1. Start by defining the challenge or problem to be fixed
  2. Define the outcome in terms of a quantifiable measure
  3. Describe the 6–12 features or functions the solution must have
  4. Identify the first half a dozen users you’ll engage at the outset and throughout.

Rinse and Repeat.

Digital Village is a community of IT professionals dedicated to providing flexible IT project team solutions to enterprise in Australia and New Zealand.

Insights Lean Startup

Turn Ideas Into Reality

The big product idea – where it all begins

I have come across several startup projects during this pandemic and thought it would be good to share some insights. We all have ideas and think we know how it should be executed. Whenever I catch up with a close family member and share a few beers, we talk about startup ideas and wonder how great it would be if we could pull it off. I must admit some of it is just pie in the sky. How do we then proceed with that idea and don’t just throw money down the drain?

Oops I spilled the beans

Time to spill the beans on making the perfect product

Here’s your three-step process for turning a dream into a real product:

  1. Everything is created twice, first in mind then in reality. Have a vision statement.
  2. You cannot manage what you cannot measure. Define success measures.
  3. Success is the progressive realization of a worthy goal or ideal. Validate continuously.

The product vision statement

For: «target customer» Who: «needs» The: «product name» Is a: «product category» That: «product benefit. Reason to buy»

A simple, clear and concise vision statement helps you and others understand what the product idea is and whether it is going to stack up against other solutions out there. Follow the format given above and it will help you start off on the right foot.

How to define product success

Great! You are ready to hire some developers and start executing. Have you thought about how you will know whether the right functionality is being delivered? You need to define what your objective is and how you will know whether you have met that objective. Objective and Key Results format created by Andy Grove is a useful tool. Another way is to define a goal for a quarter and the metrics i.e. success criteria to determine if the goal has been met.

Product life cycle

Continuous product validation

In this digital age, product development i.e. Execution has become easy due to availability of cloud services i.e. Software as a Service, Infrastructure as a Service, Platform as a Service, Development as a Service?, * as a service.  This allows ideas to be tested and developed quickly. As you can imagine there might be others out there thinking of developing a similar product.

To test your idea, you need to launch quickly. Change is the only constant these days and the availability of the * as a Service allows us to pivot when needed without too much effort. Quite a few founders fall into the trap of spending too much effort on defining a solution without knowing whether there is a market for their product. It is OK not to have a “normalized” database or not to know exactly how the users will interact with the system.

Take an iterative approach and release early and often. Measure the response from your users and learn from them.

Did you just think of a product idea while reading through this blog? Create your vision statement and define success measures. Get in touch and let us turn your idea into reality through continuous deployment and validation.