Tag Archives: Lean

An Exploratory “Lean Startup” Lifecycle

One of the key philosophies of the Disciplined Agile Delivery (DAD) framework is that it presents software development teams with choices and guides them through making the right choices given the situation they face.  In other words, it helps them to truly own their process.  Part of doing so is to choose the software delivery lifecycle (SDLC) that is the best fit for their context.  In this blog posting we overview the DAD Exploratory lifecycle which is based in part on Lean Startup strategies.

This lifecycle can be applied in two ways:

  1. As a replacement of the Inception phase of other lifecycles.  In the Inception phase we invest a short yet sufficient amount of time and effort to validate that the initiative being considered makes sense and to gain agreement on the stakeholders’ vision.  In a situation where the actual need and value of what is being proposed is in question this approach is a very good way to determine the true market need before scaling up the initiative and moving into the Construction phase.
  2. As the implementation approach in the Construction phase.  After applying the Exploratory approach to validate your vision, a decision needs to be made regarding which of the four DAD lifecycles to apply as we move into Construction. For instance, you may choose to use DAD’s Scrum-based basic agile lifecycle if there is sufficient confidence from the learnings in the Inception phase regarding the viability of the vision.  However, if there remains some uncertainty regarding the feature set to be delivered it may make more sense to continue using the Exploratory lifecycle to build out the product in Construction.

The following diagram overviews the DAD Exploratory lifecycle.  This lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.  As a result they need to quickly explore what the market wants via a series of quick learning experiments.

Disciplined Agile Lifecycle Exploratory

Now let’s describe how the Exploratory lifecycle works.  There are six activities to this lifecycle:

  1. Envision.  Your team will explore the idea and identify a potential implementation strategy for implementing it.  This could be as simple as getting a few people together in a room to model storm both the business vision and your technical options on whiteboard and paper.  You want to do just enough thinking to identify a viable hypothesis for what your customers actually want.  This hypothesis needs to be testable, which implies that you need to identify how you are going to measure the effectiveness of the new functionality that you produce.
  2. Build a little.  Your team should invest just enough effort to build a solution that tests the hypothesis.  In lean parlance you want to build what’s known as a minimally viable product (MVP).  The amount of effort will vary, from several days to several weeks – your goal is to make something available very quickly so that you can test your hypothesis.
  3. Deploy.  Once your current solution is ready it is deployed into an environment where you can test your hypothesis. This deployment may be to a subset of your customers, in many ways what used to be called an “alpha” or “beta” release, so that you can determine whether the solution is of interest to them.
  4. Observe & measure.  Once the solution is available in production you want to determine what aspects of it, if any, are of interest to your user base.  To do this you will need to instrument your solution so that it logs data regarding important events within it.  For example, you may decide to record when a screen/page is accessed, when a sale occurs, when certain business functions are invoked, and so on.  The idea is that you want to understand which functionality end users find useful, which functionality leads to customer retention, which functionality leads to greater sales, … whatever is important to you.  Generation of this data enables you to monitor, to observe and measure, how well the new functionality is received by your user base.  This in turn allows you to make a fact-based go-forward decision.  If the functionality is well received then you may choose to continue with the existing strategy and add more functionality.  Or your strategy may be so successful that you decide that you’re ready to productize the development of this solution. If the functionality wasn’t well received your team might choose to pivot and continue in another direction or even give up completely.
  5. Cancel.  Sometimes you discover that the product idea isn’t going to work out after all.  In fact, this is particularly common in research and development (R&D) environments as well as start ups.  The advantage is that if an idea is going to fail, then it is better that you learn that it’s a failure quickly so that you can devote your energies into other strategies.
  6. Productize.  After several iterations of building a little, deploying, and then observing & measuring that you’ve identifying a product that will be successful in the marketplace (or in the case of internal application development successful with your user base).  As described above, although you may choose to continue following this lifecycle, a common decision is for the team to adopt one of the other DAD lifecycles – such as the Scrum-based agile lifecycle, the Kanban-based Lean lifecycle, or the Continuous Delivery lifecycle – and effectively treat the time they spent following this lifecycle as their Inception phase.

To summarize, the DAD process framework takes a flexible, non-prescriptive approach to software-based solution delivery.  As a result of this philosophy DAD supports several development lifecycles, one of which is the Lean-Startup-based Exploratory lifecycle described in this posting.  This lifecycle is typically followed in situations where you are unsure of what your user base wants, and sometimes even when you are unsure of who your user base (your customers) will even be.

Successful Agile Software Development Requires a Hybrid Approach

Hybrid

Disciplined Agile Delivery (DAD) is a hybrid framework that builds upon the solid foundation of other methods and software process frameworks.  The DAD framework adopts practices and strategies from existing sources and provides advice for when and how to apply them together.  In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DAD the mortar to fit the bricks together effectively.

The DAD framework adopts strategies from the following sources:

  • Scrum.  The Scrum method focuses on team leadership and requirements change management during the construction portion of the delivery lifecycle.  Scrum captures some really great ideas that have become commonly adopted by agile teams.
  • Extreme Programming (XP). XP is an agile method that focuses primarily on construction-oriented practices such as continuous integration (CI), test-driven development (TDD), pair programming, sustainable pace, small releases, simple design, and many others.  Although XP’s practices appear straightforward on the surface, many of them require significant technical skill and discipline on the part of practitioners.
  • Lean software development.  Practitioners of agile development are increasing looking to adapt ideas from lean thinking.  Lean software development is based on seven principles: Eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole.
  • Kanban.  Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is visualized and team members pull work from a queue or work item pool.
  • Unified Process (UP).  The UP is an iterative and incremental process framework for software development.  Although often instantiated as a heavy-weight approach, it has in fact been instantiated in a very light weight and agile manner, particularly in the form of Agile Unified Process (AUP) or OpenUP.  The DAD framework adopts and enhances several critical governance strategies from the UP.
  • Agile Modeling (AM).  AM is a practice-based methodology for effective modeling and documentation of software-based system. AM was purposely architected to be a source of strategies which can be tailored into other base processes, something the DAD framework takes explicit advantage of.   AM strategies adopted by DAD include initial requirements and architecture envisioning, just in time (JIT) model storming, continuous documentation, and several others.
  • Agile Data.  The Agile Data (AD) method defines a collection of strategies that IT professionals can apply in a wide variety of situations to work together effectively on the data aspects of software systems. Practices for evolutionary/agile database development include database refactoring, database regression testing, agile data modeling, and continuous database integration.
  • Enterprise methods. DAD is starting to adopt strategies from enterprise IT methods such as Scaled Agile Framework (SAFe) and Enterprise Unified Process (EUP).  These strategies address enterprise architecture, product management, portfolio management, operations and support, release management and other important IT disciplines. These strategies reflect the DAD philosophy of enterprise awareness.
  • Other methods.  DAD adopts techniques and practices from other methods such as Dynamic System Development Method (DSDM), Feature Driven Development (FDD), Evo, Outside-In Development (OID), and Crystal Clear.
  • Agile development practices.  There are many practices that are not specific to agile methods that have been developed within the agile community, and DAD leverages many of them.

One of the great advantages of agile and lean software development is the wealth of practices, techniques, and strategies available to you.  This is also one of its greatest challenges because without something like the DAD framework it’s difficult to know what to choose and how to fit them together.