In Flow Processes

One aspect of Flow Agile which I haven’t expanded too much on is Flow teams and how they work.

After presenting at a Leadership Forum last week, my mind is buzzing with the potential of new ways to work and the realisation that a lot of teams face many blockers. Blockers are any elements of behaviour that stop us all reaching our potential.

Blockers is a term we use a lot in software development. It often refers to something obvious, say a leader who is too full of his or her own self-importance so they won’t listen. That’s a blocker. Also, there are those inefficient hand-off’s which force a team to wait. That’s an unnecessary blocker.

So, in my work environments, I try to find ways in which we can remove these blockers so that we can enjoy work and become more productive. That’s part of how you create a good culture and it requires honesty. If I’m perfectly honest, and we said this in the book, leaders are often the problem. Somehow they believe that their position is centred on making sure that people follow the rules.

I’ve said this before and I’ll say it again, this is one area of behaviour that agile methods (not an agile philosophy) reinforce. Agile methods are too much focused on setting rules and having enforcers.

The best digital transformation comes via cultural transformation. And the latter is very difficult to pull off, especially in a company where years of hierarchical management have left their scars. Leaders are usually drawn towards the norms, they reduce change as that increases risk and they only venture into new areas if someone else has already trodden a successful path. In my mind, that is management. Controlling the known and stifling innovation.

I’m seeing this more and more within the traditional agile world and especially with systems aimed at promoting agile at scale.

Have we lost the ability to be imaginative? Can’t we create new methods and evolve them instead of following rules all the time? How can we continually improve if we are forced into mediocrity and lowest common denominator thinking?

Seems to me that many leaders are nervous of the unknown. Case in point is DevOps.

DevOps is not a method, toolset or person. It’s a way of working and a fine philosophy. But I often hear that leaders stop DevOps from getting established because it cuts across their outmoded organisational hierarchies and hence it threatens the turf of one or two managers. They will block DevOps simply because it threatens their empire – simple as that. And in some way, agile has suffered the same fate.

According to Wikipedia, the original agile manifesto had a simple set of principles:

Recent Posts
Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Fin Goulding