One of my recent articles on Flow received some constructive criticism on-line from Academics quarters, which, is perfectly fine but it was also branded as a “fad” and I couldn’t be more delighted!!
The reason being is that throughout my IT career, I’ve spent more than my fair share of time explaining new ways of working to very sceptical (and at times hostile) leadership. In the longer term, my other “fads” are now very much in demand across many organisations.
I really respect researchers who compare IT structures across organisations. We can learn a lot from them. But I would caution one thing. My leadership career goes back more or less to the beginning of the World Wide Web and since it was widely commercialised we have never stood still. Many organisations though still didn’t get used to this idea. They think that what one leader group learned twenty years ago or ten years ago or even five years ago still applies today.
The business literature tends to treat constant change as a theoretical requirement: What if organisations had to constantly change? When you are responsible for implementing change constantly it’s a different ball game. You search for something that can give you stability. Hence Agile was attractive to us. Borrowing from Lean Manufacturing was too.
But where we’ve reached is a point where you have to see constant change as your advantage and that’s what Flow is trying to capture. I say “trying” for a very important reason. Everyone is trying to maintain flexibility and adaptability. We design processes that give us that opportunity to change quickly, even daily, so in a sense the processes don’t perform like processes used to. They are not anchor points because anchors drag you back. They are signposts that you may be onto something or that you’re up a creek without a paddle.
Flow is going to get up some people’s noses. Experienced IT leaders are used to that. Implementing KanBan set the Scrum fans squarely against me, introducing DevOps almost got me fired, Continuous Deployment was seen as my anarchic days and in the early 2000’s, Agile got me branded as a snake oil Salesman.
Recently, I talked about my experiences on a Panel debate and, as I did so, reflected ‘real-time’ on this phenomena. It occurred to me that the reasons these things often hit the rocks is that leaders (and that includes me) have a hard time admitting sometimes that we don’t understand something. And that’s why Flow talks just as much about culture as it does about process and continual improvement. It is up to everyone to try to understand the needs right now and adapt accordingly.
Back in the day, Leaders rejected Agile because they didn’t understand it. They didn’t know the lexicon, they were not included in the ceremonies (back-log grooming, stand-ups etc) and of course, they didn’t get any training.
The fact that you need training is half the issue but with Flow, we are adamant about sharing easy to digest concepts. Which is why Leaders can jump past the current rush to introduce Agile and get into a way of working with Flow that screams common sense: we reckon it’s better than Agile! You can think of it like those countries who missed out on fixed line telecom networks and are now at the forefront mobile technology & e-commerce.
I do remember a CEO saying to me once “This Agile stuff is just a reason to throw untested work over the wall and let others sort out the crap. It’s the technical Wild West”. He later admitted to me that he had a read an article on “Extreme Programming” and didn’t understand the context but rather focused in the word extreme.
In contrast, and in the interests of balance, my initial foray into Lean Six Sigma and TQM (Total Quality Management) was generally welcomed by Leaders but it was roundly rejected by employees!
Employees didn’t see these techniques as helping them because they were initially used to downsize the workforce by of reducing cost and maintaining throughput, rather than focus on increased output through efficiency improvements with the same size of team.
Therefore, you can see why manufacturing embraced Lean Six Sigma and then went on to pioneer Kaizen (Change for the better), Kata (Process improvements) which led to an early derivatives of Flow – in the manufacturing space.
When Haydn and I first met, he was working with a FTSE100 company that had a dream of being more innovative and, of course, becoming more agile but like many large enterprises, the leadership lacked the cohesion, collaboration and (to be frank) the courage to go for it.
Test and learn on this scale can get CIO’s fired – as I know from my own experience!
I presented to Haydn and the FTSE100 leadership team a series of techniques in the IT space which I was working on called TotalFlow. This was a mixture of Lean, KanBan, Continuous Deployment, MicroServices and DevOps with a large serving of automation.
Remember that DevOps, MicroServices, Continuous Deployment, KanBan and the other Japanese terms for workflow and improvements (KanBan, Kaizen, Kata etc) all had bad names from the Business within my world, so I used a phrase that described an end to end process which used all these techniques but dropped all the other buzzwords. And TotalFlow was born (in late 2012).
I soon discovered through Haydn that my idea of end to end wasn’t broad enough. He introduced me to the wider world of innovation, the relentless focus on Customers and added a new bunch of visualisations to the ones which I was using.
Of course, I came to “flow principles” from a technical viewpoint (as do many others looking to advance agile ways of working) but I’m so glad that I met Haydn, as working through this together we quickly realised that Flow is more of a state of mind than a pure methodology and hence we began to see Flow as a philosophy with some method, just enough that people can start to co-create their own processes and visualisations.
We also debated using and copywriting the term TotalFlow. But we really wanted to “Open source” these concepts and allow others to improve upon our ideas & methods. Maybe we are giving away the chance to become very wealthy but in reality, we couldn’t allow Flow to become like today’s Agile. A bit too rigid, inflexible, jargonised etc.
I see Flow as a bit like a book on how to be healthy. Imagine if the health book only had one diet plan or prescribed marathon running as an exercise regime. That could exclude many people from using it and hence miss out on a better quality of life.
And whilst Flow is based on a number of existing techniques, our production line involves people’s thoughts, ideas, mind-sets and motivations, as well as the need to build things in an efficient manner with the highest standards of quality. It also encourages continuous education – for everyone.
Returning to the Academics, one of their main reason to criticise Flow was because it is too simple.
No sh*t! That’s the way we designed it….