I have a new year tradition: each year, I take an evening to call an old friend, Carlos, who was my boss almost a decade ago. But even if we don’t work together anymore, we’ve become very good friends, even if our schedules rarely align.
The other day I got an unexpected call from Carlos, rather unusual since he’s typically swamped at work. This time it wasn’t a casual call, he wanted to ask me if I knew about something called “Agile methodology”.
This is the point in the story where a narrator would say something like: “little did Carlos know that agile methodology is one of the most famous and important approaches to software development in the last 20 years”.
I said “yes”, eager to know where this was going. It turns out that Carlos owns a startup and they’re looking for new ways to expand and optimize their business, and a consultant offered to revolutionize the sales department by implementing an agile philosophy to their sales force.
I have to be honest, this didn’t sit well with me at first. I tried to wrap my head around the idea of a sales force implementing scrum (yes, Carlos specifically mentioned scrum), organizing sprints, embracing iterative development, and the rest. At the time, I just couldn’t.
“Can it be done?”, I wondered. Can Agile be used in other areas, can the principles enhance our work, even if it has nothing to do with engineering?
The Origins of Agile
To answer that question, I think that we have to understand what agile means at its core. Beyond the techniques, agile is a philosophy, a set of principles that underlies an approach to project management in software development and engineering.
Agile, like most revolutionary ideas, is a product of frustration. More accurately, it was the brainchild of a group of developers who were keenly aware of the many issues waterfall methodology brought to software development.
To them, it didn’t make sense to take such a rigid approach to their work. Their projects demanded more flexibility, more interaction with the end-user, less reliance on methods, and more focus on results.
The first approach to agile at the turn of the century had two goals in mind:
- To deliver as fast as possible to shorten the delay of benefits to users, and avoid the development graveyard problem.
- To get quick feedback from the user’s experience to improve on the project accordingly.
In the end, these developers wrote a manifesto with four simple guiding principles that are the essence of the Agile approach:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Agile in Practice
The first principle covers two important areas of project development: the relations with our coworkers and the relation with our users. The idea is to break away from methodology and to understand the value of human interactions.
Don’t focus on the tools of your trade or on whatever method you believe is right, but rather, talk with your fellow developers, engage with your client. Your shared experience is a better assessment of what needs to be done, in contrast to a generic and decontextualized process.
This doesn’t mean that you should discard methodologies altogether, instead, they’re there to provide perspective rather than dogma. Artists use techniques to create their work, but their process is guided by intuition rather than reliance on a method. So too does the developer.
This principle is rather simple to export to other areas, we often over-rely on practices without regard to what’s actually happening around us.
A manager measures success in terms of following a process instead of outcomes, The salesperson is worried about using a technique and stops listening to their clients. In both cases, the process has triumphed over human interactions.
The second principle can be summarized as “focus on the product”. Instead of writing hundreds of pages of documentation for every corner case scenario, create self-explanatory software. Excessive documentation is time wasted, for both the developer and the user.
Products are meant to be used by others, and as such, shouldn’t be cumbersome, nor shaped to our personal preference without regard to the reality of the end-user.
For example, most air booking softwares are console-based, travel agents have to learn dozens of codes and inputs to make reservations. If they forget something, that’s what the documentation is for. Perfectly fine if you are a programmer, but travel agents are nothing of the sort.
If I were to export this idea to other areas I would probably focus on fast deliveries and user experience. We all have to deal with clients, and most of us often forget that these clients don’t have our frame of reference. So, it’s our job to ease them into our worldview.
For example, a salesperson should focus on presenting their product in terms that their audience will understand, instead of reading a data sheet. Focus on prices if you’re talking with acquisitions, focus on long-term usefulness when talking with the decision-maker, and so on.
As for the third principle, one of the core issues with waterfall is that the user is almost a non-presence. During the early stages, they provide a list of requirements and at the end, they give feedback. 90% of the time, they’re just sitting idly waiting for a final product.
Users aren’t sources of income, they should be seen as an integral part of the development process. And yes, this is true in every other area of any business, speak with your client or user, engage with their needs and desires.
We should walk away from the idea of the expert. We have knowledge that our client might not have, but that’s a street that goes both ways. The user or client knows things that we don’t, about their business, about their market, and about their needs.
The last principle is self-explanatory, we live in a world that demands quick deliveries, the market is changing by the minute, and every moment we wait we’re being left behind. In this context adaptability is key.
As much as we would love to predict the future and follow a plan for the desired outcome, the truth is that reality is messy. As a friend likes to say, when we go into production, we shouldn’t ask ourselves if the project is going to explode, we should ask about the color of the explosion.
Things go wrong, markets change, and we need to have the resilience and adaptability to adjust on the fly. The more malleable our approach, the more likely we are to navigate successfully through whatever life throws at us.
Plans are important, they provide structure and direction, but they aren’t blueprints. A plan is like a compass, it shows us where the north is. But we get to decide how to navigate in that direction.
Beyond the Methodology
My initial apprehension towards exporting agile was because I was too focused on the techniques and not on the principles. But in a true agile fashion, we shouldn’t just blindly grab a sales team and have a Scrum. Rather, based on these principles we can start to develop new approaches that are designed for the particular needs of each area.
So, in essence, yes, Agile can be exported, perhaps not the methods, but the principles are as relevant to other areas as they are to software development.
