Agile Flow in Diversity

Here we are. The final blog on my take to connect agile behaviour throughout the organization. Always fun to see an idea develop into something which grows. Starting with the idea to write my thoughts in one blog. Suddenly there were two. Then three... Hours of reflection. Relate them to experience in the field. Talk with colleagues to bounce off ideas. It was a nice journey indeed.

My first blog discussed: ‘How to assure service experience when dealing with continuous MVP delivery?’ This provided the foundation for an organizational wide agile connection, introducing and contrasting Maximum Viable Service (MVS) in service management to Minimal Viable Product (MVP) in agile development. If you are interested to know more, you can read this blog here.

The second blog was into storytelling. ‘How (not) to spoil a perfect MVP with poor service?’ is an attempt to express my appreciation to the whole agile development movement and their agile journey, for bringing and exploring these new concepts. So kudos to you for laying out the agile foundation in our digital world. But with ‘the Definition of D..euh’, it equally is a shout-out to operations to take up their agile glove. If you are interested to know more, click here.

In this third blog, I would like to share some ideas on how operations can tune into the agile movement and how to evolve towards ‘end-to-end’ agility. Not by imposing frameworks or going for uniformity, but by embracing the diversity in the organization and building agile bridges. Welcome to ‘Agile flow in diversity’.

The gap

So why stressing ‘diversity’? Because the very nature of development and operation teams is inherently different. Understanding that makes it clear you can’t just ‘copy-paste’ agile development concepts. Development is principally driven by creating value increments in products and features. Being creative, thinking out of the box, acting to requirements on a continuous basis, translate business ideas into digital functionality. This drive resulted in emergence of frameworks/models/practices…, which further increased enablement for digital speed.

Operations is principally driven by maintaining what is working. Catchphrases like ‘keeping the lights on’ and ‘if it isn’t broken, don’t fix it’ might sound familiar. In essence, operation is risk averse. So stability and minimal changes are the foundation to provide good support. That resulted in framework/models/practices..., which provided guidance to become more efficient in being in control.

Taking a step back, one might (still) say they are conflicting. As an ‘operations guy’, I experienced this divide on numerous occasions over my 30-year career. But over the past years, there is a change appearing in the operations guidance. The growing pressure on delivering at the pace of the business has (finally) opened the door towards operational agility. This in turn facilitates that shift towards enabling flow or velocity throughout the organization.

It is OK to be different.

In my mind, that shift took place while trying to make sense of what ITIL4* had to offer. Let me stress ‘trying’, because it is amazing how former obvious operational truths prevented me from looking with an open mind, understanding the opportunities in front of me and how it can assist in the flow promise. But once I realized that, a whole new world opened up for me. It made me see that operations had their own agile challenges. Why? As mentioned, operation is inherently ‘risk-averse’ when it comes to support. Variability in outcome has a fatal impact on experience/trust of the consumer. Hence the ‘Definition of D…euh’ in the second blog.

Agile in operations?

What can agile in operations look like? What defines being agile? Providing good support faster? Ultimately, yes. However, to get there, some conditions need to be met. The most important thing is to 'remain in control’. Not adhering to that condition, will never result in agile operational behaviour. Not being in control will result in more ‘D...euhs’, affecting the support of the consumer.

Essentially, there are three dimensions involved to get there:

1) Know

Everything running in the operational organization must be understood. It must be clear who (human) or what (digital) does what, when and how. People understanding how they fit in, have the knowledge ‘how and when’ to intervene. There are no unknowns in the techno/application stack. Never, even when the application landscape is under frequent change.

Evidence:

• Knowledge is shared
• Project transitions no longer result in increased incidents
• New-hires are quickly operational
• Root cause analysis is maximally automated
• Dashboards are meaningful and facilitate interaction
• Emergence of swarming replacing the L1-L2-L3 tiers
• Cross-silo collaboration, enhanced conflict handling

Result : No variability in execution

2) Because you know, you can engage to connect

Understanding the organization is the foundation for what matters most, being able to connect with the consumer. It facilitates insightful communications, both for the consumer who understands how support will be provided and for the organization who understands how to fulfil the commitment. No assumptions, no blind spots. The foundation for good support.

Evidence:

• The support organization knows what is going on in the business, with the consumers
• Ticketing solutions enable connection, not stalling for administration
• Priorities become dynamic, altering as business goals change
• Dashboards become platforms of collaboration
• New KPI: 'First Time Right'

Result : No variability in experience

3) Delegate decision to the work-floor

To add a further dimension for speed, keep ‘low risk’ decisions as much as possible inside execution flow. Because the environment is known and under control, minimizing risks allows contextual decisions to be taken immediately. Give the workforce the responsibility to act. This will provide good support faster.

Evidence:

• Higher commitment to serve
• Increased team cohesion and resilience
• Increased creativity
• Self-organizing teams
• Disappearance of toil

Result : Pro-active handling, which is in my book the ultimate agile operational accomplishment.

With this operational agile foundation in place, the ‘Definition of D..euh’ ceases to exist. Every touchpoint with the support organization matters. Making the experience count, providing the right support all the time. With that in mind, let’s build the organizational wide agile bridge.

Agile throughout the organiZation

Imagine that integrated agile organization. Close your eyes and let it sink in. In fact, don’t close your eyes, because you cannot continue to read… Can you see the potential of introducing what is mentioned into operations and how it will facilitate agile behaviour? Agile behaviour that existed already for years in your development teams. All the experience they have acquired. Surely an enabling factor to build up that agile organizational momentum. Absolutely! But… Here is where diversity comes into play. Some thoughts…

Redefine the ‘Definition of Done’. (DoD)

Taking everything agile into account, there is only one type of agility that matters. Having a customer who feels good every time there is an interaction with the organization. This leads me to believe that the DoD needs revisiting to connect Agile Dev. – Agile Ops (AD-AO).

A generic DoD in agile is ‘A checklist of technical, functional and practical criteria for a proposed increment of value like a product or a feature’. Perfect for agile teams, their POs and requestors to shape scope and afterwards validate results.

The common DoD should be more inclusive. ‘A confirmation of the consumer that the intended value purpose of a product/feature is achieved’. This can only be realized when AD-AO work in harmony. So let’s go for that unifying, all-covering, optimized organizational agile interaction. Some might call it the ‘perfect new shiny bit’**. But there is more…

Go for velocity, not uniformity

I concur that agility is a cornerstone for being purposefully fast. But don’t forget there is the fundamental difference between (AD-AO) (in most organizations). AD creates Minimal Viable Products (MVP) in a ‘controlled’ environment. AO supports in a ‘lively’ (but stable?) environment in which all active MVPs co-exist.

Moreover, AO wraps MPVs into service offerings, further enabling the connection with the customers. Service offerings are provided combining both products and services to attract consumers. The focus for AO is to provide Maximum Viable Service (MVS), as explained in my previous blog.

My point: AD, be good at providing flawless value-add MVPs. AO, be good at delivering the service offerings. AD-AO, be perfect in collaborating.

Velocity is built on collaboration. Agile velocity is therefore a joint responsibility where all involved stakeholders, whatever their competence, understand their involvement and their role in flow enablement. As an organization, there is a shared responsibility for minimizing variance in service experience and understanding variance of the business to tune for action. Both AD-AO play a vital complementary role in facilitating this.

The construct of value streams has huge potential to assist. What I have learned so far experimenting with value streams? Value is omnipresent in organizations. However, it is at best sub-optimal if it exists in isolation. Learn to collaborate to make value flow for the consumer and using value stream is a great way to start, improve, and evolve as integrated teams, whatever name you go by.

Final reflection

In the end, the only shiny bit that matters is your organization and how everybody/thing involved makes it glitter for your consumers.

References:
‘* Kudos to all involved in transforming ITIL4 into a framework facilitating agile service management.
‘** Check Paul Wilkinson, Chief architect of 'The Shiny New Thing that Really Helps' for more insights.