The truth about Agile

Agility is about leadership. Human nature says it’s easier to follow a process, which can be referred to in times of trouble with a weak ‘I did my bit’ or ‘I used best practice’. Leadership is the missing ingredient.

Sadly, Agile practice in the technology world has become purely following the method, largely academic and belief led, religious even. It’s become the study of the writings of Ken Schwaber, rote learning and certifications. As with religious theology, the acceptance of the spirit, intention and principles of Agile, rather than the rules of the method, are where its true value becomes evident. We've lost that.

If there is a single learning that is obvious over years of Agile implementations, successes and failures, it is that there is no one size fits all.

Just as there are many kinds of good leadership, there are many kinds of agile approaches. As an Agile leader you must do what works for you, your organisation and your team. If Agile dogma is followed, then waste results as conflict ensues, and that is exactly what is happening out there right now.

We need to move away from these methodology wars. Commentary used to be confined to Agile v Waterfall methods, but now that the majority of technology developers and leaders have accepted that Agile is a valid approach and can co-exist with waterfall techniques across a delivery portfolio, the Agile ‘community’ is turning on itself with constant infighting about which framework is best - such as Scrum, Kanban, Crystal, Dynamic Systems Development Method, and Feature-Driven Development etc.

What makes Agile effective is strong leadership, adaptive planning, constant learning and transparent communications in all directions. In scaling agile, we are looking to replicate the successes of a single team and make an entire programme or organisation successful.

But scaling Agile is not a process scaling activity. It’s a behaviour scaling activity. We need servant leaders as Scrum Masters, and we need to develop and replicate them. At scale, scrum masters exist at the intersection of two teams, the team they lead and the team of leaders that they are also a part of. What is important is finding or developing and entrusting the right leaders, ensuring good planning and good communications, and cultivating a great execution context.

Execution context means trust, collaboration and, crucially, enough resources. Too many times Agile fails or is blamed when there has not been enough previous investment in behavioural change, in development environments, where their are too many constraints on desk and meeting space, or when technical debt has become unmanageable - un-paydownable even.

So what is agile leadership? It is servant leadership, a coaching style, a desire for team success and team accountability. The team is the single entity. Pushing back against shared accountability criticisms is no weakness - for the self-directing team the buck stops with the team. This accountability, honesty and transparency needs to run through to the top of the organisation.

Agile simply cannot work without the right kind of leadership working relentlessly in building the right context. All the techniques and processes in the world amount to pretty diagrams without it. Too many frameworks mentioned earlier aim to control and are prescriptive, when the reality is that every problem or scaling challenge is very different. Out-of-the-box Agile frameworks and personal certification may be a starting place, but without good leadership the risk of falling back into prescriptive, top-down practices is always there. No certification exam can replicate the deep insights and intuition required to make a team successful,

Agile Success Principles

The following is a list of ingredients, by no means comprehensive, that get us towards successful Agile.

Stick to the Agile Manifesto principles. Even when scaling, they are still relevant. Study Agile techniques and learn how and when to use them.
Persistence. Often there is a good reason, usually context related, why Agile principles are hard to achieve. So, if you’re not seeing results after moderate perseverance, recognise the constraint and change the approach.
Be honest about status, challenges, strengths and weaknesses. Teams need to face some hard truths at times, so this honesty needs to be internally focused at times.
Empower the team to be autonomous and self-directing, and be a servant leader.
Ensure that the roadmap is well understood across all teams, and evolves with the domain knowledge in the dogged pursuit of achieving the goal in as simple a way as possible, and nothing else.
Ensure that information flows through and between teams. Don’t rely on timetabled meetings. If things are going awry at the scheduled ‘information sharing’ meetings, it’s because information isn’t flowing to the right people at the right time. Communication needs to happen when it needs to happen, communicating something at the wrong time, at the wrong level of detail, or to the wrong people is poor communication.
Visualise the work and the challenges likley to arise, and be ready for them.
Have a fixation with identifying and removing waste.
Accept that your team or engineering function as a whole has blind spots, and get help to identify and remove them, so that you can build capability in these areas.

Agile is about leadership, and leadership is about change. Don’t adopt frameworks blindly, think critically and test the theories to find what works. Keep moving, changing and evolving towards success. Allow your people to figure out what they need to do to deliver results - then you may begin to see your success.