Agile is everywhere. Top consulting firms like McKinsey & Company and Boston Consulting Group are helping some of the biggest companies in the world go through agile transformations. The fastest-growing startups out there are using agile to build their software platforms and run their business. Forbes, Fast Company, and Harvard Business Review are writing about agile and publishing case studies about agile companies almost every month.
But what is agile, exactly? Some say it’s a philosophy. Others call it a mindset. It’s sometimes referred to as a methodology. Or even as a Software Development Life Cycle (SDLC). With all that’s being said and written about agile, you’d think that the agile community has at least set the definition of “agile” straight.
So, is agile a framework or a methodology?
Agile is neither a framework or methodology. It’s a mindset that you can practice by adopting the 4 values and 12 principles from the agile manifesto. Agile frameworks like Scrum give structure, usually in the form of roles, events, and artifacts, which individuals and teams can use to work in agile ways. Agile methodologies like Extreme Programming (“XP”) define the best practices for how this can be done.
Some of you are probably asking, what’s the difference?
- An agile mindset is a set of values and principles that influence your approach to work
- An agile framework gives you a basic structure that helps you work in agile ways
- A methodology shows you how to work in an agile way using specific practices
This is why Scrum is closer to being an agile framework and Extreme Programming (“XP”) is closer to being a software development methodology. Scrum defines the roles, events, and artifacts that an agile team can use to work in agile ways.
XP, on the other hand, gives specific practices (called “simple rules”) that help an agile team figure out how to work in agile ways. These practices include choosing a system metaphor, using Class, Responsibilities, and Collaboration (“CRC”) cards to design software systems, having unit tests, and writing unit tests before writing code.
When a framework defines not only the “what,” but also the “how,” it can also become a methodology. Often, it’s hard to draw the line between what defines a framework and what defines a methodology. Which is why some agile practitioners use the terms interchangeably.
The Agile Mindset Explained
The best solutions come from capable individuals who work in self-organized teams and are given the time and materials to solve high-value problems in an iterative (work is done in short cycles) and incremental (each cycle contributes to or builds on top of the others) way of work.
In 2001, 17 software development thought leaders gathered up on a ski retreat in Snowbird, Utah. Getting snowed in by a blizzard, they began discussing how they built software and how they worked with their clients. Finding many similarities in their ways of work, they wrote them down on a whiteboard and created the agile manifesto, which started the agile movement.
Agile is based on four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Here’s one way to interpret each of them.
Individuals and Interactions Over Processes and Tools
Agile practitioners value individuals and interactions over processes and tools. This doesn’t mean an agile team doesn’t keep any documentation whatsoever or uses whatever tools they want. Many agile teams work in an enterprise setting where adhering to standards and using certain tool chains is a must. They acknowledge that processes and tools will only get them this far.
Humans have a natural tendency to avoid making difficult decisions and having hard conversations. Which is why most of us are surprisingly good at coming up with creative ways to avoid making decisions and having conversations altogether. Sometimes, a team can spend hours discussing how they will solve a problem, without spending a minute talking about the problem itself.
On a team and company level, this manifests itself in processes and tools. People often spend endless hours creating and talking about documents, diagrams, and slide decks — when they can just get together, sketch things out on a whiteboard, and agree on what needs to be done and how to do it to the best of their knowledge and abilities.
Even agile teams do this early in their journey. I’ve seen Scrum Teams spend their entire Retrospectives arguing about how long their standups should be or how strictly they should follow the user story template, even when they could be using them to agree on how to put out the next burning fire on production or make better trade-offs while under a lot of pressure.
At the end of the day, software is built by people, for people (at least until AI takes over). Most problems agile teams face can be solved through conversation between them or with their stakeholders. Above all, they are solved through thought and collaboration. Processes and tools are there to facilitate, and not constrain, that.
Working Software Over Comprehensive Documentation
Which is more valuable? 20 pages of documentation that describe how a screen on a mobile app will work, or the screen itself working? Agile practitioners understand that working software (not its substitutes) delivers value. So they set out to ship working software early and often.
You paint a portrait of someone. It will show them in a given setting, but never reveal them in their true light. Software is not that different. As much as you describe how a piece of software will work, your documentation will never be able to describe how exactly its users are going to interact with it.
The agile mindset is based on empiricism, a philosophical school of thought that says knowledge comes first and foremost from experience. The agile way to build software, then, is to start with an idea (a hypothesis) and deliver just enough of it to seek out feedback (Minimum Viable Product), allowing you to draw conclusions, learn lessons, and course-correct (pivot) along the way.
Simply said, you never know if a product, feature, or enhancement will deliver value until you build it, ship it, and measure it. You can only hypothesize about it and identify the minimum effort needed to help you get to the answer. By working in short iterations and shipping in small increments, you make calculated bets, minimize the cost of change, and maximize the amount of insight.
Documentation is useful until you overdo it. This is why one of my all-time favorite agile practices is to keep “just enough documentation.” While each team tends to have different needs for documentation, here’s a good rule of thumb to help you get started:
- Keep your user stories simple
- Keep your solution diagrams clean
- Make meeting minutes and task lists only if needed
- Send out your release notes in plain English
The most successful software development project I’ve participated in started with a vision statement confined to one page. The one-pager contained:
- The vision for the software product;
- The agile framework to be used (Scrum);
- The name and role for each member of the Scrum Team;
- The architectural patterns to be used (citing specific books, pages, and patterns);
- The development and testing practices to be used (unit testing, TDD).
The one-pager said at the end that all requirements, functional and non-functional, will be kept on the product backlog starting from Sprint 1.
How do you and your team approach documentation? What are your secrets to applying this agile value? Let the rest of this post’s readers know by leaving a comment in the form below.
Customer Collaboration Over Contract Negotiation
I used to work in IT outsourcing. I had the chance to work with leading companies across geographies and sectors, experiencing first-hand how they built and ran their business-critical software systems. Yet there’s one thing about buyer/supplier relationships that I never came to like: negotiating contracts.
My lack of love for contract negotiation didn’t really change when I started working in Fortune 500 companies and kept on working with IT outsourcing companies. I could spend weeks or months detailing the terms and clauses on a contract… but it was the way that my teams collaborated with the vendors that made the partnerships work.
A contract helps you set the terms of a buyer/supplier relationship. But it’s the collaboration that makes it work (or the lack of it that breaks it). You can have a support contract with the best-defined SLAs, SLOs, and SLIs in the world. But if a critical production incident happens and the teams don’t work well together to resolve it, the contract will be useless.
So make simple contracts. Make sure they cover the legal basics needed to protect each side in case of conflict that you can’t resolve in any other way. Then sign the contract and forget about it. When problems come up, storm on solving the problems, not discussing who needs to solve what problem under what circumstance according to which clause.
When the collaboration is systematically not working, forget about political back-and-forths between Business Sponsors and Key Account Managers. Get the people doing the work on both sides together and facilitate a conversation about how to do things in a better way.
When you feel like the customer or an employee of the vendor simply doesn’t get it, have a 1:1 call with them and talk it through. As you adopt the agile mindset, you will be surprised by how many problems can be solved through conversation and collaboration.
Responding to Change Over Following a Plan
Last but not least, agile is about responding to change over following a plan. One of the few certain things in life is that plans change. If that’s the case, then why do we have such a tendency to want to make and stick to plans?
Because change is scary. It means that we were wrong. Or that we could be wrong. Change challenges the assumptions and notions we approach life with. It causes our lizard brains to be afraid. Change is also necessary. And beneficial.
Modern business history has plenty of examples of companies that failed to embrace change and projects that failed to course-correct. Kodak invented, but buried the digital camera until their film business got sweaped by competitors who launched theirs. Lidl embarked on a gigantic project to roll out SAP, only to cancel it €500 million later. Change forces us to stop, rethink, adapt, improve.
Agile is all about harnessing change for the customer’s (or for your organization’s) competitive advantage. Individuals, teams, and companies have the natural tendency to resist change. The agile approach allows them to stay flexible by working in short cycles, delivering frequently, and seeking out feedback through conversation and/or getting insights through measurement along the way.
Some agile teams keep product roadmaps, which allow them to visualize their plans while staying flexible. Basecamp, one of the companies that are more proficient at using agile, works in six-week cycles called bets, keeping only options for what to do next but making no commitments whatsoever.
To a large extent, how much a team can practice the fourth agile value depends on the organization that sponsors it. Ironically, senior management in large companies is reluctant to sponsor projects and products that don’t make (and follow) one-year plans, even if this is what gives them sustained competitive advantage.
