In my last post I introduced two issues that I believe are extremely important to companies that want to stay in the competition for customers.
The first is that new business techniques like microservices and DevOps really enable a different pace of innovation and hence a new way to think about giving customers more of what they want.
For teams, it means more innovation, more often in direct response to customer actions on a website or an app.
I argued that Agile is not suited to creating the agility companies now need as we innovate dozens of times a day. However Agile has given us a great basis, along with Lean and techniques such as KanBan. We now have the capacity to create a substantial FLOW of innovation.
The second issue I raised was belief. Why belief is so important is that in the modern workplace you run out of techniques at some point in your innovation cycle.
This is a critical point missed by so many people who talk about transformation. You are transforming, at a certain point, to a no-technique, process-lite way of work. You are going to depend on emotion and belief to get you through. Agile, Lean, KanBan etc, all these will take us only so far.
What you need very often is mutual belief that you, as a group, will find solutions, you’ll do it fast and with integrity plus respect for each other and customers.
Belief is an unplannable asset that you just cannot buy. It comes from giving people permission to find a way.
My teams have done that with Agile.They’ve pushed the boundaries of Agile and created new ways of work that in the end relies on us all believing we will find the right answers for customers.
If you remember from last time I said we had started to disaggregate work. People stopped thinking about the Project with its beginning, middle and end, and thought instead about units of work. The significance of that only occurred to us over time.
After wrestling with Agile in this way, we went on to explore Lean techniques and we found Lean a useful discipline for us. To a degree we became obsessed with removing waste and wait-time.
Going Beyond Lean
Put that obsession to one side though, we also found that Lean makes teams think more about why they are working.
If you consider that we had these disaggregated units of work, it would be possible to abandon any one of them if we wanted to save on costs, which is how Lean gets you thinking. So we had to find the right criteria for why we would continue to do work.
Bear in mind we could be working on dozens of work units, even hundreds. So we found that the idea of value was what gave sense to our decision making. With all these work units which ones would add value to customer lives quickest?
You can’t always know that, so to make value function for you, you have to be experimental. You have to create minimum sustainable delivery matrices that you can push through to customers to see how they react.
This was a pivotal movement for me. We now had a system where some of the traditional weaknesses of software development were intuitively being resolved.
We saw improvements in the area of productivity because it follows naturally from Lean but we also saw quality improving as our new way of prioritising work removed context switching by team members.
By that I mean, pausing work because you are blocked, starting something new and then coming back to the original task. This can be frustrating for everyone working on multiple projects, especially if you have to pick up someone’s else’s half finished tasks. Usually you have no option but to redo them.
As we began working this way each day at our stand-ups (yes I attend stand-ups), it became clear what the blockers were because we were clearer about our priorities. And wait-time or inefficient hand-offs stuck out like a sore thumb.
So our pioneering use of FLOW “demanded” that we also use DevOps. DevOps didn’t have to start as an underground activity, in the way many IT innovations do. It just made sense, and as CIO, I made it happen by co-locating teams from Development, Operations, Analysis, Testing and Product.
The consequence of that, of course, is that there are even fewer handovers and, as you can read elsewhere, our shorter cycle-times were allowing us to by-pass code collisions, multiple code branches or other complex integration challenges that still occur with Agile.
We got an additional cultural benefit. Ae we pushed back against the traditional job descriptions, everyone pitched in as if the team were a start-up.
But more importantly, the energy and enthusiasm was infectious. Guess what? We were enjoying our careers and not just doing our jobs. We had reached acceptance momentum. We had generated incredible belief.
That is the point at which the adoption of new techniques gets the buy-in, support and implementation of the entire team.
FLOW and the social significance of belief and emotion
Most accounts of digital transformation make no mention of emotion. The speakers don’t pause to talk about how it felt to have people rely on you or what it means to actually care about how we work.
In FLOW emotion is really important. FLOW leverages Lean, KanBan, DevOps, Continuous Deployment, Open source, Platform As A Service, Infrastructure as Code, Cloud, MicroServices…the list goes on. But this list has quite a few things in common.
It’s a dangerous list. It sticks 2 fingers up at the status quo and screams for change….which can be risky and can leave a pioneering CIO or CTO out on a limb.
But it also has an emotional core. it works through belief. Emotions are difficult for hierarchies and for systems and processes.
I have been quoted a number of times saying that I almost got fired introducing these elements but as a boss of mine in San Francisco once said to me, if CIO’s don’t take risks, the business wouldn’t move forward. And at our level, it’s not a question of “if” you will be fired, it’s usually “when”. Hence you have nothing to lose.
Therefore, during my career I have in fact had numerous battles with executives and even my own Technology Leaders (in previous organisations) who push back against anything new.
It’s also how I became familiar with the terms “Machiavellian Leaders” and “Toxic Employees”. My adage here has always been to encourage these people to do the best work of their careers…somewhere else.
And I recommend working with people at all levels in your organisation to seek out the ambassadors of change, the people who believe in what you are doing and what they want to do.
But we are often faced with negative feedback from some Agile Practitioners, Trainers and Consultants who’s careers depend on the current Agile methodology.
They want you to follow the script, to not stray out of the guidelines and whatever you do, don’t remove the current jargon with something simpler.
Last week I ran my 5th marathon of the year in New York and I was sitting on a Subway with my wonderful wife who pointed out one of the ads on the train. It said: “It’s called a Career Path because someone else has already been that way”.
My wife then went on to say, “that’s why some people would not like to see FLOW taking Agile forward. They are not used to creating the path. Only following the existing one”.
Bam. It hit me. I want to reach out to the Agile community and ask you to help us. Get involved, become Flow Masters or Ambassadors, see it as an extension of your journey, a new lap, the next phase. Help us to refine the 12 steps to FLOW and start enjoying a new phase of your careers!
