Faster, Better, Stronger, Wiser

The Journey to Delivery Efficiency

For as long as I can remember in my career in the Information Technology industry, there’s been talk about faster time-to-market, reduced waste, ideas on how to exceed (or simply meet) customer expectations. You get the picture. This notion of how to do things faster, maintain quality and give the customer what they want is proclaimed in the practices of Lean, Lean Six Sigma, Agile Development (including Scrum, Kanban, and Scrumban), Incremental Development, XP (Extreme Programming), Test Driven Development, and DevOps, to name a few (whew!). What strikes me, though, is that the faster we try to deliver solutions, the more likely I am to hear things like “let’s just get started” or “we don’t really need architecture”.  An example I heard a few weeks ago in a meeting between a consultant and a project delivery team:

Consultant: What’s your timeline in your project plan?

 

Delivery Team: We don’t have a project plan, we’re doing agile.

Is this the way to faster time-to-market? It certainly is a way to get something done. But let's put the planning and architecture debates on hold for now and take a step back. When we step back I like to pose the question: "What is it that we're trying to do here?" Invariably the answer comes back to what I like to call Delivery Efficiency. What do I mean by "delivery efficiency"? Delivery Efficiency is working smarter (not harder) to deliver faster on better solutions that meet the demands of the customer.

Delivery Efficiency is Faster, Better, Stronger, Wiser

Delivery efficiency doesn't happen overnight, though. It's a journey. The tenets of the methods I mentioned above can certainly help, but there's more to it than simply the mechanics of [insert your preferred approach here]. Adding to the complexity is when we have to take smaller components like applications and stitch them together to create systems to meet the needs of the customer. Again, there are various approaches to accomplishing this (like Scaled Agile Framework), but before we get to these points and debates, there are a few fundamentals that I've found are essential to being able to leverage your approach to its fullest. Let's start with the first three.: The Thing, The Life(cycle), and The Who (Cares).

The Thing

It may seem obvious, but it is surprising how many times I've encountered the fundamental challenge of articulating even what the "thing" is that we're trying to do. And this isn't just about using a cool new technology (although it may be about building the a new technology). We first have to be clear about what is the thing that we’re trying to produce that someone wants and how to get them that thing faster, better, stronger, wiser. Getting a team to have a shared vision of the thing is the first fundamental of Delivery Efficiency. Give the thing a name and describe what it is supposed to do. This may change over time, but make sure everyone on the team knows what this is so we can all head in the same direction.

The Life(cycle)

After we know what the thing is, we then need to understand that this thing (and every other thing) has a lifecycle. It doesn't matter what type of thing this is. It can be an application, infrastructure, or it can be a service or product that we offer. There are numerous frameworks that help manage the lifecycle of these things. A few examples are: PLM (product lifecycle management), ALM (application lifecycle management), ALM+ as I’ve started to call when we have software that defines both the application and the virtualized infrastructure it sits on (that's the “+” part), or even QLM (quantum lifecycle management from The Open Group). But irrespective of the lifecycle approach, these things all have a beginning, a middle, and an end. During the middle, we may evolve many times through an iterative approach which involves new design, building, testing, and deploying all while being operated and supported. The figure below illustrates some of these concepts.

The Who (Cares)

Whether we go fast or slow or the thing is large or small or even if lifecycle phases overlap, we'll hit these stages at least once. If we dig a little deeper as we progress through the lifecycle, we begin to see that different roles get involved and care about the thing at different stages. Note that these are roles and not necessarily people or teams.

Here are a few examples:

• Architecture is pervasive from the time a thing is conceived through to when it goes to its grave;
• Security needs to be involved into account starting during design to ensure the thing is protected (and protects) and then during operations to make sure it stays secure;
• Engineering or Development may build and test components of the thing through multiple iterations;
• Operations cares throughout the iterations of deploying through to when the thing may be archived.

Communicating the knowledge and information about the thing to the roles that are ultimately required to ensure the thing thrives is the third fundamental of delivery efficiency.

Up Next...

What are your experiences in the lifecycle of your things that you build and develop? How has the thing, the lifecycle and the who helped or hindered efficient delivery? I’ll come back to these point in later posts as I discuss how we take the delivery of these things from a low efficiency to high efficiency and how this evolves when there’s a paradigm shift in the underlying technology.  #guerrilla_ea