3 mindset shifts for agile transformations

Posted by Marcus Hammarberg on August 29, 2019
Stats

I have been involved in many agile so-called transformations over my, let’s face it, long career. And the more I get to do that the less I care about the word agile. Because agile is “just” a way to behave - it’s not an outcome. The outcomes are what we are after, the effects, the values. I’ve found it much more fruitful to discuss what those values are and means, than to argue whether Scrum holds up for scaling or not.

In this post I wanted to discuss three shifts in mindset and culture that I found: Important - as these shifts in thinking will or will not, hold your agile efforts back.

  • Fundamental - as in; goes beyond (below?) being agile or not.
  • Not talked about or understood in the same way
  • Start asking some tough questions and hence rapidly increase learning.

These topics are:

  • Shift focus from activities and utilization to value and flow
  • Realize that software development is not manufacturing and start managing in a suitable way
  • Monitor success for products or value streams rather than project or functional silos

My feeling is that if we discussed and changed this, half of the agile journey is already done. Also, if you are not ready to change any of these, then any agile transformation will give local improvements, at best.

Clarifications

This is an update to the original text that I felt was needed since I was not clear in my intentions. Sorry.

But I don’t mean that you need to make these shifts before you start thinking about agile. Or that without them agile doesn’t work. Quite the opposite in fact; even bad agile is often an improvement to our current ways.

What I am saying though, is that when you start to do agile at any scale beyond a single team, you will soon start see these mindset shifts. And they are important and will challenge the current way of thinking in the organisation. To the point where many times (own experiences only here) the old ways are harder to change, than the urge to “become agile”.

Hence I’ve found it very fruitful to at least understand and discuss these mindset shifts as we embark on the scaled agile journey. Because these are the things that agile will challenge.

From activities to value

I wrote a blog post about a client the other week, where we applied numerous agile principles and found some good practices from it. At that client, if someone asks me what we have done and I am in a hurry I tell them:

We’ve shifted focus from activities and following up plans to value and following up flow of value

Because that is the fundamental shift we made. And it’s been hugely impactful and hard to adopt in that company.

But, what does that mean in practice?

Well quite simply before (a few years back) the company was very concerned about the activities that we worked on, that everyone was busy and that we never ran empty of things to do. Key reporting was focused on how we were doing compared to the plan and the budget. But the value our effort made was talked about before and sometimes after the project (all development was done in projects) finished. But never during. During we focused on finishing those activities. And reporting how much of the budget we spent.

Now we are little-by-little moving the teams to focus on the value and effect they are creating, and less on the activities. It’s much more important for us now that everyone in the team knows why something is built and that they have ways to track that value (quality, happiness, business value or what have you) than that they are busy.

Here’s an illustrative and a little bit provocative example that we have been using; imagine that a team has 3 (balancing) key metrics that they track. They also have 6 things that they are working on to improve these metrics. At one weekly standup (see previous post) they announce:

We have scrapped those 6 things and now are working on these 2 new ones instead. We figured they would help us reach our goals better, so we’re gonna try that and see.

What should be the reaction from the company? Note - they are not doing what they said they were going to do. Well, they should get rousing applauds and congratulations. Champagne corks should fly and fireworks should be shot.

They made the best decision and they are closest to the relevant information (or should be and we can help them to get there)

Making this shift will challenge many of the current ways we do work in our organizations today. Just one example that stumped me more than once is time reporting. It gets really hard to call work development or maintenance when you are improving an overall value for a longlived product or value stream. Is this line of code maintenance, is this document new development?

In a project world this makes total sense; often work in the project is new development and outside the project is maintenance. The new development cost can be written off faster and improve the looks of the books (Hey - it rhymes)

That “small” fact has almost completely stopped two agile transformations I’ve been involved in. And significantly hindered others.

Shifting focus from activities to value is a fundamental change. Making it means improving the chance of success for agile teams and also means that we are focusing on the things that are valuable to our customer, employees, and stakeholders - the value we create. The outcome, not the output.

From manufacturing to developing

I once was invited to a lunch with two senior consultants at a big consulting company within the fields of energy, industry, infrastructure and information technology in Sweden. This was many years back and they wanted to know more about this weird thing called agile.

I explained to the best of my ability and about 30 minutes into lunch (we ate too) one of them interrupted me and said:

Ok - I get it. You’re talking about lean, my friend. We know that well.

But his colleague cut in and replied instead of me:

Ap ap ap, now you got it wrong. We know lean from manufacturing - he is talking about development. That is a very different story.

I was so happy he cut in, because at this point in my career I could not explain that difference nor had I reflected over the difference between agile and lean before. I faked being very occupied with a meatball as he spoke.

But what he put his finger on is another key shift in mindset; software development is developing. It’s not manufacturing. Manufacturing software would be finding the executable, go CTRL+C and then CTRL+V - BOM! A new copy of the software.

No company wants that from their development department. We want a solution to a problem that no one has had before, at this time in this setting. It might not be deep science but make no mistake - it is discovery.

My favorite way to make this clear is a thought experiment that goes like this (I think Liz Keogh or Dan North is the originators):

Imagine that you’re just about to finish some work that took you a year. Just as you’re about to deploy it everything goes up in smokes. Nothing is left; no code, no docs and no fancy impact map. Only you.

We need to build that exact thing again. How long would that take, you?

Most people guess half the time. Why? Because we will not make all of those time-consuming mistakes. Why? Because now we’ve learned about them. The bottleneck is learning.

Ok, so what is the problem with not realizing that software development is development and not manufacturing, then?

Well, we should manage these two activities totally different, the goals of them are different, processes are different.

Imagine a team of researchers trying to find a cure for a decease:

  • Would it make sense ask them to write faster?

  • Would it make sense to ask them an estimate of when they are done?

  • Would you track their progress on days spent?

  • Would you have them work separately so that we get more things typed - or together to try to solve problems?

  • And in the language of Cynefin - you cannot use best practices on complex problems. By definition, there are no best practices in a domain where novel and innovation is needed.

Much of traditional management comes from the Age of mass production - this where Taylor and Ford flourished. We built organizations as we built machines and tried to get each component (department) to execute as fast as possible.

That is great (or - check out the origins or Taylor and Gannts ideas?) - if you want to produce many things fast. But if you want to discover what to build and create a single instance of the solution - you should probably organize a bit different.

Allowing the team to discover and learn as fast as possible. Support them to be autonomous and free to do this discovery better.

From functions to value streams

The last shift in mindset is one of organizational paradigm - agile will promote a shift towards a product mindset. Much of the agile literature and thinking is geared towards product thinking.

In my experience, this is particularly challenging to grasp and understand, in organizations that have been project-driven on top of a functionally structured organization. One where you will find a “business”, an IT department and a separate operations department. Or even a development and testing department.

In organizations like that the way to get “anything” done is through projects. I’ve written before about my mental breakdown about the strange reasoning here, but from my point of view and experience, a project is basically a hack. Value is created, with the cooperation of all the departments, but since they are not built to cooperate or share goals, we pull people from all of the departments and create a temporary organization that can deliver that value.

In organizations like these, the notion of organization around a product can feel very apart. Product is not a concept that fits in the thinking of the organization, its department, and processes.

Instead of product we could organize around a value stream, that is; “Value streams are artifacts within business architecture that allow a business to specify the value proposition derived by an external (e.g., customer) or internal stakeholder from an organization.”

While this might be easier to grasp, for a functional oriented/project-driven organization - I’ve noticed that finding, identifying the value streams can be very tricky and often lead to value streams that cut across many departments and or team. Much like a project needs to do to deliver value.

This will, of course, challenge the current structures quite a lot and might lead to new, supporting teams coming into need. Like an operations department that now has the goal of enabling the cross-functional value streams teams.

But that change is just the start because if we organize around the value stream or product, we very soon will see the need to track value, cost and other key metrics - for that value stream (or product). Typically we have, up to now, not tracked metrics like that. Departments (like IT or sales for example) often have their metrics, that cuts across all products that we sell.

Conclusion

The purpose of agile transformations is a transformation, a change of the current ways - to better support the flow of value.

The goal is not agile - the goal is to improve.

The shifts in mindset that I’ve listed are things that I’ve discovered often holds this transformation to something better back. As I wrote in the beginning; if these shifts can be accomplished or even started, half the agile journey is already done.


If you liked this post ... here's more for you:


Published by Marcus Hammarberg on Last updated