Introduction
Agile is the preferred solution for modern project delivery and iterative development. The focus is naturally on Agile frameworks such as Scrum or Kanban.
But how many people can say they have referred to the Agile manifesto before their first Agile project?
This article looks at the wider view of what Agile is, and why it can fail.
The Agile Manifesto
Back to basics. Agile is about delivering customer value and putting customer satisfaction first. It’s founded on 12 principles which support the manifesto.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximizing the amount of work not done — is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
What is Horizontally Agile?
Frameworks such as Scum and Kanban are examples of delivery models based on Agile principles and achieves most of these listed above.
This helps teams react to change, in working through prioritisation, for self-improvement, to feed the team with work, and also in promoting face-to-face communication.
What these delivery models won’t do is drive how you architect for Agile, or how you should structure an organisation to facilitate Agile. That’s on you.
Ignoring these parts of Agile, is what I call being “Horizontally Agile”.
This is because your organisation is still probably shaped horizontally into departments and silos. This makes it harder to achieve some of the principles of Agile, and why Agile might fail.
In some cases, being Horizontally Agile might be the best compromise when compared to other alternatives. It will solve some delivery and planning problems, but it will restrict agility and therefore your ability to compete.
The point is that an Agile delivery framework or process alone does not allow you to fulfill all 12 Agile principles.
Be True Agile
To fully implement Agile, there are a few missing pieces beyond the delivery model you adopt. It may require the transformation of an organisation. Alternatively for startups, it requires building an organisational structure to support Agile from the start.
Let’s refer back to the Agile principles and explore some of these.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Through Agile delivery models, you can certainly shape the way requirements are fed into a team and work iteratively in small chunks to develop products with value. But how do you reliably and frequently deliver this value to customers?
If the answer is a separate operations team who manage the infrastructure and release process across the organisation, then that’s a constraint on the team. It can also cause issues with hand-offs and it takes away control from an otherwise business focused team.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
How much does release frequency impact your ability to learn about your customer needs? You can only release as frequently as an operations team can support, and your project may not be their sole focus. An operations department limits your technology options and the tooling to support it. It puts development teams in a box.
That brings me to:
The best architectures, requirements, and designs emerge from self-organizing teams.
If the team is not able to choose their architecture and tooling, then the best architecture for the product is constrained and can’t easily evolve with changing requirements.
This is true whether you call your operations team DevOps, or if you sit your departmental operations guy in the team and call it DevOps. Please don’t do either.
DevOps is a culture that complements Agile and helps address these particular issues. It requires silos to be completely removed so operations and development can work seamlessly as one.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
If another department is making the architectural decisions based on the perceived needs of the organisation, or is too detached from the business, then key agility is lost.
An Agile team should have all of the skills needed to support the product requirements. They should be capable and able to deliver working software into production as frequently as needed. It facilitates a simplistic Lean approach that also complements Agile. It also keeps technology solutions as simple as needed to fulfill a specific business purpose.
Simplicity — the art of maximizing the amount of work not done — is essential.
Through departmental silos, communication overheads are increased and face-to-face communication is more challenging.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The same is true of governance processes such as external technical review boards that dedicate control, or architectural teams that serve the needs of an organisation. Instead, build the capabilities within the single team that supports the product and keep them autonomous.
Great leaders know when to step aside.” — Tara Jaye Frank
The more an organisation supports disciplines which collaborate horizontally across the business, the more it dilutes collaboration where it’s needed and limits the ability to react to change.
Many companies do this because they lack trust outside of those traditional structures, and it’s hard to break free of that mindset.
Agile Delivery as Horizontally Agile vs True Agile
Summary
Agile principles are more than a delivery process. They require a fundamental change in mindset and approach. It therefore requires an organisational structure and cultural mindset to support it. A DevOps culture together with Lean principles will help shape a full complement of Agile principles.
The benefit in achieving all Agile principles is high agility for both the business and the team. It allows rapid reaction to change and facilitates a competitive edge.
If an organisation attempts Agile methodology without the necessary organisational support, then it’s “Horizontally Agile” and cannot fulfill the full 12 principles of Agile. In this case, the constraints of siloed teams or departmental agendas will limit an Agile team at best. At worse it will result in failure.
Strong leadership is about stepping aside to entrust, nurture and empower others towards a common vision. It’s a brave step to relinquish control and governance across an organisation, but it can be tried & tested on a small scale.
With a good team, the upward shift in business and customer satisfaction should be self-evident. All that’s required is free-reign within a team to self-organise and be fully autonomous.
A broader cultural shift across an organisation is much harder to adopt, but starting small and growing out the idea based on early results can facilitate change. John Hagel coined this approach “Scaling Edges”. It can’t be done without strong leadership and a willingness to be brave.
