Part 1: Have you thrown your customer out the window yet?

Initially, when I step foot inside an organisation, I try to get a snapshot of what the business looks like. I look at how the business is managed, how is it structured, what does it value? I do this because I believe that the success of any Agile endeavour is primarily dependent on its relationship with the core business management framework.

 

Lesson 1 - Agile needs the right context
Lesson 1 – Agile needs the right context

It is well known that new and emerging enterprises, your typical technology and software companies, are built from the ground up to support Agile ways of working. Everything from the structure of the organisation to the processes and the culture of the people who work within are agile centred. It is also well known that many large and global corporations, in all industries from banking to manufacturing, are really struggling with Agile concepts.

And the primary  reason is very simple. Because what is important to the business, and hence, the values that the business model are built upon, can be anything from hostile to being diametrically opposed, to the values that implementing Agile bring. 

Lesson 2 - Predictive versus Adaptive
Lesson 2 – Predictive versus Adaptive
  • Adaptive – respond to change
  • Predictive – Follow a plan

Expanding on this thinking, I can say that many enterprises value Predictability over Adaptability. 

 

You will never hear leadership in a large bank saying to the development team, “here is some money, build me something that helps my customer save money” They will want to know up front, exactly WHAT we are going to build, they want to know WHEN we will build it by and HOW MUCH is it going to cost. 

Taking it a step further, everything from financials, to recruitment, to inventory values predictability. And for good reasons!

So, if our business model values predictability, the bottom line is that our business will  favours complicated product delivery frameworks over complex frameworks. This understanding of the difference between complicated practices and complex practices is crucial.

  • Lesson 3 Complicated Versus Complex
    Lesson 3 Complicated Versus Complex
    Complicated- Starts with a specific product to build and then commit to this idea  through fixed Budget / Time /Scope. Suits a linear development model (analyse, design, build, test, deploy)
  • Complex – What we build is less important than why. It is the purpose that is important. We fund people, offer guidance and governance and support their skills to deliver. It supports practices like design thinking, lean startup processes and Agile.

There are many ways to describe the difference between complicated and complex frameworks but one angle is to use a simple example. If you build a production line in Germany and then you desire the same thing in the US, you can build it to the same specification, add the same inputs and you will get the exact same outputs at the other end. With complex, if you build an eCommerce site in Germany, and then replicate the same in the US, you will not get the same results. While the sites would be similar, the customers and their needs and expectations would be different.  I always say that anything to do with people and humanity, get’s complex very quickly!

Lesson 4 Output Versus Outcomes
Lesson 4 Output Versus Outcomes

I am not insinuating that many of the large enterprises out there today do not focus on Value.

What I am saying is that Agile focuses more (if you get it right!). 

And do not get me wrong, I am very aware that I just used a pivotal word in the last sentence, “VALUE”. I am also aware that I should write a parallel blog, just to explain Value within Agile. But for now, let me just say that I am talking more about Customer Value through this article, perhaps even going as far as to say that business value, without giving it too much thought, is an output of customer value (Am I allowed to say that?)

 

So, if our business values predictability, then the business model we use will be structured in a complicated way including areas like organisational structure, governance, processes, HR etc. And working in this complicated fashion, leads to results that are more focused on outputs above outcomes.

But here is the crux, if our customers values outcomes above outputs, in a world that is evolving to demands that are complex and not complicated, then we need to have a product model that focuses on adaptability above predictability. (you might need to read this a few times!)

It could be the case that Agile is not feasible at this moment but at the very least,  the enterprise must recognise and understand the tension and opposition between the two models and understand that any movement in one direction must recognise the loss in predictability against the strengthening of adaptability, or vice versa. If this is the case, then we have two choices, either throw our customer OR our business model out the window!

And if we pick door number two, then Agile has the framework, the mindset and the system we need to deliver this.

Final Thoughts
Final Thoughts

Part 2: So, how do you introduce Agile when the Values oppose those of the business model

Phase 1

Let’s assume that you have come onboard and that you have assessed the situation and agreed with all parties that we need to move in a more Agile direction.

I usually start by stabilising the current environment. The first hurdle , is simply to get things working. For me, there are 4 or 5 criteria that I focus on for this phase.

  1. Drawing an initial interpretation of Value
  2. Stabilising the team
  3. Ensuring that there is a functioning product backlog
  4. Reaching the point of delivering a consistent increment of Done product

While point number one, determining a first draft of Value is crucial, it should not be difficult.We are not looking for a final draft. It is a case of having a purpose that we can all understand and get behind. I will absolutely focus on continually improving our determination of Value over the coming period.

Stabilising the team revolves around words like; Collaboration, Cross- functionality, Dedicated. I might simply say that we need teams with a single purpose and with all the skills to deliver that purpose and structured in a way that allows for coordinated delivery against that purpose

The basics of a product backlog might start with:

  1. A single backlog per product
  2. A focus on the INVEST quality characteristics
  3. Acceptance criteria  and
  4. An evolving Definition of Done and Definition of Ready

Bullet point 4 is more difficult to state at a high level in any kind of meaningful way, simply as it varies from product to product, enterprise to enterprise. I will not address it here. But, needless to say, having a functioning team and a working backlog are the initial steps to success. 

I will add that we need to start to understand our impediments, the hurdles to reaching our four  Phase 1 goals. Impediments could be anything from issues with technical debt to having no access to crucial SME’s like a technical architect.

 

Phase 2

Let’s assume that we are a few months down the road, and we have now reached the point of understanding what is valuable to us, that we have stability in our teams, in our backlogs, and we are delivering working product. This in itself, is a fine achievement. Phase 2 focuses on improvement. I usually focus on three areas:

  1. System
  2. Process
  3. Culture

In phase 1, we wholly focused on structural foundations, the core of of our System. We now begin to make initial improvements in each of the three areas. We start to determine and improve our system, beginning with the governance structures. 

With Process, we begin to outline a set of metrics to begin to measure our success. At this point, we need to start looking at our deployment / release cadence. We ask if it is fit for 

purpose and we need to start to look at how we can improve it.

With culture, I would begin by embedding a mindset of Continuous Improvement in our team. I want to note that many Agile practitioners view culture (or mindset) as a critical component to the success of Agile. But more than that, they regard it is a cornerstone to their very involvement in the Agile movement. In my experience, this shift away from people as a tool and a focus on their wellbeing, was one of the very reasons for Agile’s growth, stemming from the dis-satisfaction with older business-success focused models.

But we need to be careful. A focus on mindset from the outset, is all well and good for a team of 6-9 people working closely together. But Agile at scale, with 100 people, or 1000 people, cannot be led from a shift in culture. You have to put in place the system level structure to support the culture, then the processes, before finally focusing on mindset. By leading with foundational system changes we start to alter what the organisation values. Following with a migration to Agile processes will lead us to think in Agile. Finally, we begin to see the benefits of Agile and become interested in the Agile mindset. Hoping to embed an Agile mindset in our people, when the enterprise does not even value Agile and our working processes are not Agile is just not going to happen.

The second area of Culture I will mention, revolves around Communication. Communication covers a wide spectrum, from our meetings and events, to visualisation of the backlog, to the way we transparently measure and how we report. Agile and Agile frameworks, like Scrum and Kanban, are very clear on some very fine communication channels and practices that are widely known and used. And while I would say that culture comes last in terms of rollout of the three, once rolled out, it needs to become a key focus of the Agile coach.

My final note in this section is to say that while the 4 principles in phase one, covering Value, Team, Backlog and Increment, are set in stone, for phase 2, I believe that we can relax this rigidity. I would advise building a roadmap that incorporates the products and enterprise that you are working with. It is about being pragmatic. You might decide to stay as is with parts of the company. You might determine specific practices to improve area A but not Area B due to its need for critical delivery precision. It is up to you and the business to decide.

So while phase 1 revolved around principles of stabilisation phase 2 might focus on principles like;

 

  1. Deliver value early and often
  2. Optimise Flow
  3. Respond Instantly – Feedback

Phase two is really the starting point for our Agile transformation strategy. It is at this point that we begin to evangelise Agile practices and mindset. How you progress is dependent on the business. I have listed an example process below.

Agile Transformation Steps:

  1. Assemble a transformational leadership group
  2. Understand purpose and values
  3. Determine what value means
  4. Stabilise the platform
  5. Progress a Vision / Strategy / Roadmap 
  6. Build teams around our purpose
  7. Lay out a 3 month plan
  8. Put  in place a Communication Plan
  9. Determine Success Metrics
  10. Regular Planning, sprints, Reviews and Retrospectives

And while this plan is good practice, there is no best practice. I simply recommend a plan centered around Value and Purpose