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 of working and the realisation that a lot of teams face many blockers. Blockers being those 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:
- Individuals and Interactions over processes and tools
- Working Software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to Change over following a plan
As for agile software development, Wikipedia has this to say:
- Agile Software Development advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change
I’m sorry but today’s agile world has done very little to address these principles. Instead many agile practitioners have been led down the path of conformity, formal methods, certifications, ceremonies, metrics, scaled frameworks and so on. These represent rules-bound ways of working when what we need is creativity and decision-making in the moment.
Some people have called for the Agile Manifesto to be updated. However, from my point of view, the 2001 principles still hold true. We have lost sight of the need to have teams continually improve our ways of working. Those very same teams are getting bogged down in repetitive processes, leading to disengaged, de-motivated individuals.
Haydn and I believe that Flow Agile unleashes individuals and teams from this procession into corporate formality. And whilst building belief in a leader, team-members or indeed a single purpose, can be a difficult proposition, one needs to start somewhere.
In my opinion, when it comes to making teams more effective and helping them to become true Flow teams, there are three main ingredients which leaders must demonstrate:
1. Trust – Creating a high trust environment is fundamental to drive innovation. Experimenting, testing & learning or pivoting quickly without blame or retribution, starts the team towards a journey of feeling safe and gives them the confidence to be bold & brave. However, leaders need to communicate, communicate and communicate. Everyone needs to be in the know and the team members need to have an effective feedback loop. So, debriefing after each major milestone, non-blame retrospectives and celebrating bold experiments are key. In Flow Agile we do that through visualisations that act as a place to congregate around.
2. Permission – Working outside the margins has always been my mantra. Rules are there to be followed but if they don’t make sense, they need to be challenged and broken. In the case of teams, we want people to work outside of their job descriptions. High performing DevOps teams do this by everyone sharing each other’s jobs. Especially if demand outstrips the available people with the appropriate job description. In Flow, we want everyone to work in each other’s shoes. Let’s all code, test, deploy, harness customer feedback and stuff the job description. Not enough has been done to extol the virtues of T-Shaped skills but this will change over time.
3. Unblocking – As a leader, your main purpose is to get out of the way of the team, no micro-management, no insistence on status reports that no one reads and no over-governance. Your job is to remove blockers and protect your team members from the incessant BS that’s all around them. Removing the blockers ensures an effective flow of value and ironically it increases the trust.
Even if you don’t subscribe to the Flow way of working, you must be able to see that today’s business world is drowning in systems of distrust, effort wasted on not delivering value and an obsession with changing culture or mindsets without a plan for what should be different or how to get there.
Worse the real emphasis is on creating a new set of rules, sometimes just as stifling as the set we are trying to get away from. Flow is an absolute minimalist framework for agile and is the reason why we need to trust each other whilst also trusting in the good sense of teams to find good ways to work. No slave drivers, bad scrum masters or blockers, please.
FLOW the book is available from our website here: http://www.flow-academy.net/the-book