What Does a Lean/Agile SDLC Look Like?

 Comments Off on What Does a Lean/Agile SDLC Look Like?
Feb 102013

My instincts tell me to be sceptical about having a defined SDLC (Software Development Life Cycle) – it feels like an old paradigm that is fundamentally waterfall in approach. However, it’s entirely understandable for organisations to ask questions like “This Scrum/Agile thing is working fine for engineering but is that as far as it goes? How do we decide what to build? What do we report to the board? Where do non-IT teams fit in? How does the whole process work, from idea to live product?”

There’s some great books and an active community focused on these questions, but much as I would like everybody to embrace the complexity and nuances of Product Ownership, Lean Startup, DevOps, System Thinking – and more – most people don’t have the appetite or enthusiasm to study and digest all of that. That doesn’t make their questions any less valid. In fact, the breadth and complexity of this field is crying out to be brought together in one coherent picture of a system that turns ideas into high-quality production software, adding business value and delighting customers.

I like a challenge (!) so have put together a software product life cycle with five stages. The stages can be mapped to other models, but I believe are more naturally named here and more clearly aligned to Agile/Lean principles:

  • Imagine. Ideas are the lifeblood of business and product development. At this stage we need to pull contributions from all internal and external stakeholders, engendering a culture where anyone feels like they can contribute and get recognition. Ideas beget ideas, and volume is a virtue.
  • Assess. The challenge with ideas is that while each might at first seem valuable, it will turn out at some future point that the majority are not. We need to find out which are worthwhile as quickly and cheaply as possible – to “fail fast” with the majority so we can find and focus on the real winners.
  • Envision. Once we have found an idea that is worth pursuing, we need to clearly set out the problem or opportunity we want to tackle, and how our idea meets that challenge. It’s also valuable to talk about scope, stakeholders, technical architecture, potential problems, team make-up, and approximate size and duration of effort.
  • Deliver. Agile and Scrum focus on delivery, because that’s where software projects have been notorious for failing. Technology, quality, and engineering practices come to the fore here but we must not lose sight of why we are building the software and for who.
  • Operate. Approaches like Lean Startup and DevOps have shown us that building software, and even delivering it, shouldn’t be the end of the process but only the beginning. Once software is in customers’ hands we need to support them, measure performance and usage, get feedback, and push what we learn back into the Imagine stage.

This cycle fits for small features – in which case it may last only hours and probably have no outputs other than those integral to delivery. It fits best, however, for substantial new product or feature development – in which case it may span several months. (Initiatives likely to be longer than several months should be split.)

Note that meeting the purpose of each stage is much more important than the amount of time spent or the artefacts produced, and the cycle can (and should) be abandoned at any point if a change to the business environment or new insight means the idea is no longer of value.

Six core values run through the cycle, reflecting the Agile/Lean mindset while retaining a practical slant towards the needs of the modern enterprise:

  • Business Value. First and foremost, businesses need to make money to survive. Whatever approach we ally ourselves to, we should be united in a common goal of helping our organisations succeed.
  • Customer Focus. All businesses have customers, and we need to focus on them through the whole life cycle to successfully deliver products that will delight them.
  • Measure and Assess.We should be generating and analysing metrics continuously so new ideas that won’t work are weeded out fast, new technology is evaluated and leveraged, and production software tuned and enhanced – based on real data, not guesses or the whims of the powerful.
  • Collaborate and Communicate. In an enterprise setting, the development of revenue-generating software tends to involve many functionally-based stakeholders from finance, sales, product, user experience, marketing, IT and so on. The best results come from being transparent and accessible to all stakeholders, and where appropriate working with them as team members.
  • Excellence in Technology. Being great at software engineering isn’t a nice-to-have, it’s fundamental to an organisation’s ability to prototype quickly, deliver often, and make changes safely when new opportunities (or threats) arise.
  • Governance. Executives need to “see into” the process, most often at a high-level but with supporting detail when needed, so they can make informed decisions and communicate clearly to investors.

In my next post I will show how the stages and values map together, and the activities that support them. I’ll also highlight suitable tools, techniques and outputs.