According to Forbes, Agile has been eating the world for some time now. Moreover, what many New York best sellers on progressive leadership pushes has its origins in Agile. Sometimes it's disguised as “startup culture” or just making the work fun or meaningful. But when done in earnest, it engages employees and customers. I've done several Agile transformations and seen night-and-day differences in productivity. But many still dismiss Agile as a “software thing”. Some are confused about what it is. Others just need help seeing how to apply it elsewhere.
What Agile Really Is
There are many implementations of Agile, most notably Scrum and Kanban, but Agile is a bold philosophy of work. In my interpretation, that philosophy is comprised of four essential themes:
- Being people-centric
- Being customer-centric
- Responding to change
- Developing a “product” through iterations
And I’ve listed them here by the order in which — in my experience shepherding these changes, people find them controversial. So let's start with the one that is most difficult to reject.
Agile is People-Centric
Software development is not a technology problem; it is a people problem. The technology side of the problem is solved when you learn to identify and hire competent people. The real issue is how to get technically competent people to build what the business needs.
To develop software, you need to be highly adept at introverted thinking, making sense of things in a logical manner.
But for most developers, this is the primary way in which they make sense of the world around them. This can make it difficult to identify and prioritise the needs of the business. Consequently, developers can often misinterpret resistance to their ideas. Sometimes we see ambivalence towards what others deem detail, as failure to address a major problem.
But introverted thinking is central to most technical fields including law, science, and engineering. Often teams succeed in finding ingenious technical solutions, but miss the mark from a business perspective.
Putting People Above Process First
The most visible symptom of an exclusive focus on this way of thinking is an obsession with process and tooling. The Agile Manifesto, written in 2001, states:
Individuals and interactions over processes and tools
Agile Manifesto
By making this its primary mantra, Agile re-balances the team towards other ways of thinking.
It is no wonder that Agile practitioners obsess about culture. By doing so, they lead the way in individual empowerment, physiological safety, and the construction of self-organising teams. These strategies can be applied to almost any business with multiple employees. There is clearly nothing here unique to software, or any other sector or department.
Agile is Customer-Centric
Many of today's billion dollar tech companies had no clear initial path to profitability. Their initial product didn't meet the needs of its intended market. They saw this and made a fundamental business change. They succeeded through “pivoting”.
If I had asked people what they wanted, they would have said faster horses
Henry Ford (maybe)
Often it’s a chick and egg problem. Customers don’t necessarily know what they want until they see it. No one really knows what is or is not possible until someone tries.
Agile places a central role on gathering feedback from the customer as early and often as possible. They make sure the conversation is in the context of the product, no matter how unfinished.
Perhaps your knowledge of customer-needs is imperfect, or your business requires innovation in its products or services to wow customers. If so, you could probably benefit from this was of thinking. It can minimise the time or resources suck into something ultimately infeasible, or undesirable to the customer.
Agile is Responding to Change
Before Agile, software projects would undergo several months of planning. This meant months of effort was sunk into a project before any code was ever written. The idea was that you could avoid making ruinous mistakes by meticulously planning the project upfront. But the devil is always in the details. Until someone actually gets their hands into the problem, those details remained unknown.
In the long run we are all dead. Economists set themselves too easy_, too_ useless a task, if in tempestuous seasons they can only tell us, that when the storm is long past, the ocean is flat again.
John Maynard Keynes, A Tract on Monetary Reform
Keynes was trying to warn economists of his time. You shouldn’t overestimate your ability to accurately analyse and forecast something so complex so far into the future. At best, it’s a waste of time and delays the oh-so-important feedback from the customer we discussed above. At worst, people continue to follow the plan rather than responding to new information and unforeseen change.
This too is broadly applicable to any sort of knowledge-work. When engaging in planning, remember that you do not have a crystal ball. Take note of all the assumptions you are making. Think about how you can test each of these assumption as quickly as possible. The level of accuracy you need is the minimum to drive decisions. Most importantly, establish a culture of regularly revising plans and driving them as a cycle of testing and learning.
Agile is Iterative Development
We learn lessons from experience — not simply the passage of time. One must actively reflect and examine the outcomes and their causes. Imagine an intense 1-year project attempting to deliver a novel, innovative product for its customers. Let’s say it ramps up in the Spring. The major technical challenges are surmounted in the Summer. Customers test it in the Autumn, and it is rolled out in the Winter. Time is taken at the end of each phase to learn how some future project might be better undertaken.
The Waterfall Problem
Often some architectural oversights is discovered during the testing or in the roll out. The project now faces an altogether different set of technical challenges. Did the customers’ needs got lost in translation to the development team? Or Maybe, the customers don’t really need or want the features of the product that consumed the most development resources. Perhaps your testing was flawed, and you delivered only a semi-functioning product. The worst you discover your team doesn't have the right skills to deliver what you should have built.
The Agile Solution
Now imagine that instead of a single 1-year project, you ran 4 consecutive 3-month projects over the same period of time — after each, stopping to learn lessons from the previous project. For each project, you would need to go through the same phases as the 1-year project described above. Each project would need a narrow, clearly defined scope at its inception to be able to deliver something meaningful to its customers in such a constrained period of time.
The first of these 3-month projects is certain to encounter similar issues as the 1-year project described above, but the subsequent projects could adjust. Now imagine doing 26 consecutive 2-week projects for the year!
Clearly this approach provides some additional constraints, but mitigates risks from organisational failures. Which approach allows for greater risk taking? Which approach provides the most opportunity to get better at learning from your mistakes?
Where is iterative development well-suited?
In Software — Obviously this is where Agile comes from, but is it really obvious why software is particularly well suited? Iterative development helps avoid overly engineered solutions, mitigates damage caused by miscommunications, and prevents procrastination around testing and deployment.
In Sales & Marketing — Iterating your marketing efforts helps you build your brand while learning your market and capitalising on unexpected opportunities. I recommend the book, Lean Agile Marketing, if you wish to learn more.
In R&D — Research is easily the ripest area for iterative development. It’s impossible to forecast breakthroughs and you always learn something along the way that shifts what you believe to be feasible — or even possible.
Some Places to be Cautious
Here are some places where iterative development is tricky or just ill-suited:
Compliance — Sometimes you just don’t have the freedom to be flexible. This can happen in a highly regulated environment. Sometimes you must submit detailed plans and are not allowed to deviate without going through a laborious change control process.
Security — I wouldn’t advise gathering “customer” feedback from malicious intruders. Once you have a security breach, it’s already far too costly to start thinking about security. If you want to have iterative development here, you need to actively test security at each iteration. I’d advise finding a third-party to do so and foster a strong-relationship with your development team.
Finance — Although Oracle has had success developing an Agile model for fiance(whitepaper here), this is typically a hard sell culturally.
In general, areas that constrained or well-understood process without room for innovation may not benefit from Agile.
Where to start?
I always advise to start by holding Agile retrospectives (how to guide here) immediately. This will allow you to gather meaningful feedback from your team---regularly check their temperature as you undergo change. The most important thing is that you action the items raised without delay (as discussed here).
While you doing this learn more about Agile and why sometimes Agile transformations fail. Spoiler: Organisations often try to go it alone without reaching out to an expert for advise and training.
If you have any questions, comments, impassioned speeches, or heated denunciations, reach our on social media or comment below.