Return to site

FLOW: Agile Wild West or Common Sense?

· FLOW processes

By Fin Goulding

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. Since the World Wide Web was widely commercialised we have never stood still. Many organisations still can’t get used to this idea. They talk about continuous change as if it were today’s big challenge. Sorry, we’ve been forced to reinvent and redesign for twenty years now.

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 now 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 the opportunity to change quickly, even daily, so in a sense the processes don’t perform like processes used to. They are not anchor points like they used to be. You can’t afford that many anchors because anchors drag you back. Today’s processes consist of signposts, a clue that you may be onto something good 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, reflected ‘real-time’ on how the goalpost of what is edgy or good keeps moving.

It occurred to me that the reasons new techniques often hit the rocks is that leaders (and that includes me) have a hard time admitting sometimes that we don’t understand something. We try things out and pretend it is part of a great new wave. 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 of the market right now and then adapt accordingly. A method should be abstracted into a philosophy, a guidebook, a primer on good culture.

Back in the day, some leaders rejected Agile because they didn’t understand it. They didn’t know the lexicon, they were not included in the ceremonies (backlog 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. You don’t need to master Agile, Go straight to flow.

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 reducing cost and maintaining throughput, rather than focusing 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.

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. Since the World Wide Web was widely commercialised we have never stood still. Many organisations still can’t get used to this idea. They talk about continuous change as if it were today’s big challenge. Sorry, we’ve been forced to reinvent and redesign for twenty years now.

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 now 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 the opportunity to change quickly, even daily, so in a sense the processes don’t perform like processes used to. They are not anchor points like they used to be. You can’t afford that many anchors because anchors drag you back. Today’s processes consist of signposts, a clue that you may be onto something good 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, reflected ‘real-time’ on how the goalpost of what is edgy or good keeps moving.

It occurred to me that the reasons new techniques often hit the rocks is that leaders (and that includes me) have a hard time admitting sometimes that we don’t understand something. We try things out and pretend it is part of a great new wave. 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 of the market right now and then adapt accordingly. A method should be abstracted into a philosophy, a guidebook, a primer on good culture.

Back in the day, some leaders rejected Agile because they didn’t understand it. They didn’t know the lexicon, they were not included in the ceremonies (backlog 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. You don’t need to master Agile, Go straight to flow.

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 reducing cost and maintaining throughput, rather than focusing 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 inside 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….

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly