News

I have been looking at patterns for “agile release approaches” and in this article, I will be looking at some more patterns that I have observed. But I got a bit distracted by the philosophy of value and so I will be meandering for a little while before I get back on topic.

If a team creates value in an ecosystem and nobody hears it, did the value really get created at all? - James, when left too long to ponder.

The philosophical bit

I have always thought of agile ways of working as being a continuous cycle of both learning and the release of value.

Taking this to its logical conclusion, it makes sense to me that the shorter the cycle of learning and value creation the more agile. So the perfect agile team would create value instantly and learn which is probably impossible to do as an individual or a team.

Even if we can’t be perfect though, we could aspire to be as close as we can get. So the faster the learning and value creation cycle the better.

A slightly odd diversion

This brings me to a dark secret which I have often hidden from my friends. I say that I love all agile approaches evenly and that I don’t play favourites, but I have always had a soft spot for kanban compared to her cousin scrum and her rather opinionated friend SAFe.

Why batch value when you can deliver it continually? - I think to myself when nobody is watching.

But I also find kanban a bit lacking in imagination and a bit self-absorbed. She only seems to believe in the evidence she can see, so I often find design thinking more refreshing, where I feel free to dream and broaden my perspective, even if it distracts me from the speed of delivering a final product. Plus, just between you and me, I think kanban might be a little obsessed with being thin and lean. I sometimes feel that a little more fat here and there would help her be a bit more relaxed and resilient around withstand change. I just wish she would eat something fattening at dinner instead of always just ordering the salad – a little fat in your meal isn’t really that terrible, is it?

Getting back to the original train of thought

But then I got to thinking, can you have a perfect agile team or approach that is independent of the environment it is in?

Is there a perfect model for agility, or just an approach that matches it’s ecosystem perfectly?- James, before he realised he was missing something.

I often fall into a trap like this when I assume that there are only two answers – a best agile or a best-fit. But if we achieved “perfect agile” then we would no longer need to learn – and hence we would stop learning and cease to be agile. The whole idea becomes a bit silly.

So let’s take another view – there is no end state, just a journey. The team can continually learn to adapt to the ecosystem but becoming at one with the system is not the aim, rather I want to both adapt to the ecosystem that I am in and also attempt to change the ecosystem to better suit my goals and abilities.

OK, but where does that leave me. Well, there may be no “best agile” but there are two “substandard agile approaches” that are wrong:

• Applying a perfect model of agile in an imperfect world, where the approach does not adapt to the real constraints of your world. In this case, the unrealistic approaches that you want to use will actually impede both learning and value creation. So scrum, XP, luck-driven development and kanban are all good, but not ideal in an organisation where they do not match the constraints.
• Accepting the current constraints and adapting perfectly to them, without the ability to change. This means that you will lack resilience if things change, but it also means something far worse. It means that life will never be better than it is today – it will only stay the same or get worse. I would prefer to adopt an approach that supports my goal that tomorrow should always be better than yesterday, which is as close to best practice as I can see.

Slowly getting to the point

Enough philosophy though. I want to move onto the implications of my views.

The rest of this article is based on three ideas:

• There is no best practice that represents the perfect way to release value.
• There are however practices that we should:
• Move toward, since they are better than what we are doing now;
• There are practices that we should move away from because they are holding us back; and
• There are practices that suit our current environment, that we are already using and that we can really excel at in order to generate more value.
• There may be patterns that we can recognize that might help us to identify what we want to move toward, move away from or excel at for a reasonable period of time.

A starting point

In my last article, I looked at variations around the theme of delivering a product in continual steps.

On that basis, rather than deciding which approach to releases is the best, I am going to set aside my judgement and see if recognising multiple patterns will help me decide where to head next in different situations.

Agile people often talk about kanban and sprints, but I have also worked with a more ad hoc approach where teams assess each request or opportunity on its own merits.

While there are more considerations to make, I think we can essentially start with the question “how would our customer prefer to receive what we do?”

If they want things as soon as possible, in a consistent manner, then kanban is cool. If it makes more sense to provide work in a packaged way on a regular basis then sprinting is sweet and if they want to review, customise and consider each delivery then ad hoc is more collaborative.

There are a couple of other considerations though – where the type of work we do arrives in a consistent way then kanban can cope but when each request is a unique adventure then an ad hoc approach is often more fit for purpose. Similarly, the team might find that they work best in a factory mode, a batching mode or a new adventure mode.

It is also possible to move from one to the other, as long as the team remember to keep doing retrospectives. The team should move to a “better” approach when one of the other two ways of working creates a better combination of “matching the way we want to receive work, matching the way we want to roll and matching the way our customer wants to consume value. Change is a bit painful but entirely manageable with good collaboration and insight.

How do teams actually deploy value?

Whether the team is sprinting along or flowing like a river, there is still the question of how the team moves from “ready to deliver” to actually delivering.

In some teams releasing value is not a drama. The person or group building value can simply hand it over when it is ready. This is probably the best if you are confident in your testing, your work is fully packaged in the way a customer wants it and the customer is ready to start using it right away.

But simple is not always easy. For IT teams this usually involves excelling in automated testing and either integration or the ability to release changes without others having to change their systems. For factories outside IT, it still involves “just in time” inventories or backwards-compatible components and other jargon. Essentially – you and your client and those who support your client must all be able to pass change to each other, confident that the change will be predictable and that it will integrate into whatever is there before the change.

But what if the customer is not ready? I faced this recently when I went to a tailor. He said that he could repair some pants in about 2 hours, but I was going to have gone home by then. This was no drama though because he said he could simply hang onto the pants until I came by again. I was even able to test them when I came back because he maintains a change room ready to go.

I guess the equivalent is where the team can complete work, then wait for the customer to come by and test it, at which point it is released. The team would probably prefer continuous integration because they don’t have to maintain a test environment (change room) or keep hold of things that the client has not started using. But it is really a question of which works better for the client.

Sometimes though, the work we do is not actually in a finished state for the client to collect it. An example might be that the team write some code, bet the clients wants to package this with some training or updated user manuals. So the team complete their base product and hand it to someone (in the same team or in a separate one) to add documentation, chocolates or whatever is needed to make the receipt of the product easier and more enjoyable for the client. I call this a packaging centre in my picture.

A similar situation occurs though, when my finished product may not be fully tested and integrated for the client, but we want to release on a regular cadence. In this case, I usually complete my work and then it is released when the next “train” arrives to deliver it to the client. Essentially this means that our team can make several changes and then the packaging happens on a regular rhythm, which makes life predictable for the client and means that we can do a combined release test and client instruction manual release.

Finally, my team has sometimes been part of a bigger action, such as a major invasion of occupied France on D-Day.

Well, actually I was not there at D-Day, but someone from the army told me that they had a saying along the lines of “hurry up and wait.” Which sounded stupid to me until he told me that they needed to coordinate several people to act at the same time, but needed them all to be in a pre-agreed position first so that they could act in unison as quickly and effectively as possible when the order came. As a result, they wanted everyone to get into position as quickly as possible so they could all act together sooner, but they did not want people rushing forward when others were not yet ready.

In my less dramatic experience, I have sometimes had training material ready and code ready but needed to do a backup, tweak some configurations and then have everyone move forward together. This is more complicated than having each team do their own bit in isolation so we have all met together in a staging area first (whether virtual or physical).

"Patience usually wins over arrogance. It is better to be at one with the universe than to pursue a course that is at odds with the forces of heaven and earth." - Lao Tzu King – agile coach for a production support team in ancient Delphi.

So … this means that a team could be kanban, ad hoc or sprint-based. But they might also look at how they actually deploy their finished work in order to create predictability or meet the ability of their client to absorb change.

I guess this also applies to how you get things delivered from your supplier.

If work is predictable and consistent then maybe the best approach is continuous integration but in practice, the best approach for your own team depends on the current way you collaborate and integrate with those around you … and maybe the way you aspire to work together in the future.

What about project-based patterns

Young people often what to scale agility these days but old people like me are hesitant.

"Small amounts of effort applied consistently will eventually overcome large burst of effort applied sporadically."- A fitness instructor who watches my attempts to lose weight and become fit.

When asked how to scale agile I often ask if it is better to shrink to work to allow teams to chip away rather than form giant teams. But there are often times when we do want to work together as a large group. There are also times when it takes more than a month to build something worthwhile.

In that case, we have a slower feedback loop – our learning and our value delivery is slower. But this is still valid if we would not actually get sufficient value or learning from continually deploying small pieces of something.

Since agile people like to think of products, this would mean that we accumulate enough change to justify a new version of a product. But I have chosen to call this a project flow because in Scrum you can still launch a new version every week.

So here I am looking at patterns where a team decides to withhold the release of value, for reasons of client grumpiness with small changes, ineffective release approaches.

Working at scale will create additional overhead but can still be done. Here are the patterns that I have observed.

Fixing time means that teams can create predictability of when something will be ready. Thus your product will definitely be ready for the trade show or the Christmas sales. In an IT team, this sometimes means that your stakeholders can plan on when to expect you to be finished. However if you fix time then you have to give something else up and if you give up on quality to guarantee every feature is delivered then you will be sad and your grandchildren will ask “What did you do in the great release grandpa – did you really create that humiliating bug that caused everyone to hate the team?”

But this is a great approach if you focus on maintaining quality while delivering the most critical things adequately early on and then keep adding and refining until you run out of time. That way less important features become your contingency.

I guess this pattern appears in Nexus and SAFE, as well as other places.

My first agile projects were like this and I kind of assumed it was normal. But in fact, some people do a series of releases that are not fixed in time. Instead, they release a series of step changes that create some value for some of their clients when it is both stable and sustainable. This is sometimes called MVP (Minimum Viable Product). It can also be called MMF (minimum marketable feature set) or thin slice of goodness.

You might also have heard of MLP (Minimum Loveable Product) which used to be something marketing people would ask for, although I always thought it sounded more like the husband that someone settled for rather than the one she really would have gone for if she was willing to wait for Prince Charming, so I didn’t really take to that.

Anyway this is sometimes better than fixing time but it takes discipline to actually deliver “minimum” and to ensure there is a next step rather than dumping a “bloated viable product” or a “tactical solution” on the client and then making good your escape, which is more correctly called an MEP – minimum escape-worthy product.

But there are more approaches too. There is one called “Waterfall with agile in the middle.”

Waterfall with agile in the middle is where your team is agile but you wait on giant business cases and then you often have to do a lot of sprints before the organisation does a quarterly release. The is less awesome than going the full kanban with continuous integration (CI), to be sure.

But I have recommended this approach to teams and so I should try to explain why. In some cases, I have a team who is absolutely ready to go agile in a large organisation that is certainly not ready. In this case, I see three choices:

• Don’t adopt any improvements.
• Launch an extraordinary effort to overthrow and modify the entire organisation so your team can be more effective.
• Do what you can within the constraints you have and be ready to move if you see an opportunity.

The question of “how good at agile is your team?” is not really a question of how agile your environment could be if Google bought your company, it is a question of how agile your team chooses to be while effectively managing the real constraints of your existing environment. - James King, justifying pragmatic approaches.

In this case, though, you might adopt some approaches that you only do because you are in a wider waterfall type environment. You might still choose to excel at these while looking for other approaches to slowly integrate within your environment and ditching those wasteful practices you can do away with.

Again – continual effort will generally outperform ad hoc bursts of effort. But you improve your own practices and also the opportunity when you can help others to change as those opportunities inevitably arise.

Still, there are more approaches. There is the lean startup, agile for dads (now called disciplined agile rather than DAD though) and design thinking.

Design thinking and the lean startup both see value in learning. So they focus on learning early rather than just incrementally building the final product. They may sprint or work in a state of continuous flow. But the fixed date or the MVP is not initially about creating customer value – it is about exploring assumptions and failing/learning cheaply.

These approaches have a series of stages moving from guesswork to prototypes to expose customer needs and then potential solution options. So rather than just planning sprint by sprint, they have planned a goal of either learning, building customer value or improving sustainability.

Finally, there is the idea that we should create a model/hypothesis and then build the minimum to deploy it and then manage its transition to usage while creating a new model for an improved version. This pattern appears in Disciplined Agile as well as RUP, FDD, many off the shelf system implementation and many complex architectural things such as data warehouses.

I think of this as similar to the “design pattern” but the approach is designed for managing a different emerging risk.

Design thinking sees our greatest risk as building something irrelevant to the user, regardless of how well we build it. So we validate and innovate around user needs before spending too much on building something that is hard to change. But at some point, we have to rebuild our system to make it sustainable, maintainable and scalable.

On the other hand, the spiral approach is (I believe) ideal for managing technical risk and the fear of technical debt. For example, the user needs for a nuclear reactor are quite straightforward (produce lot’s of electricity, avoid death from radiation and it would be nice if we could produce some isotopes on the side). The real requirements challenge is how to bring those together – which is an engineering challenge rather than a user insight one.

It does not mean doing all the design upfront (although I assume that happens with a nuclear reactor). Instead, it involves doing enough modelling to build a component and then building it before

So a “spiral” approach makes sense when you want to build an internally cohesive system that allows you to always take the next step by moving from a stable system to a better stable system without creating the technical debt or nuclear meltdowns.

It beats sprinting along without planning in many situations, but it also distracts from paying attention to the real needs of the user and from being able to focus on creating user value earlier in other situations.

So there you have it. This was a long article but I thought I would delay the release until I could achieve an MWP – maximum waffle product. Hopefully, though, you can see these patterns in your own agile implementations.

I believe now that we can use several potentially useful patterns and models to plan our next steps rather than having to build a perfect model before acting or having to completely reinvent the wheel each time.

Let me know how you go and whether you see the same (or different) patterns.

Posted by James King
Copyright © James King