How to describe Agile to an alien and other words of wisdom from David Sabine
Date Posted: May 29, 2016
Back in January, we spent two jam-packed days with Scrum trainer and consultant David Sabine learning how to be more agile—and we don’t mean our yoga moves. (Though if we’d said we wanted to learn about high performing teams while doing downward dog it’s a sure bet he would’ve worked it into the agenda, probably using it as a way to teach us that multi-tasking is a myth).
It was hands-down the best training some of us had ever attended, so it’s no surprise that when it came time to write our first post on Agile, we asked David for an interview. We caught up with him by phone as he was riding his bike to a nearby park. (If you want to connect with him, you’ll find him on LinkedIn or at berteig.com.)
Advice from David Sabine on Agile basics, from why businesses care to what to look for in an Agile agency.
ME: HOW WOULD YOU DESCRIBE AGILE TO AN ALIEN?
DAVID: Presuming this alien has been studying us for a while, it’s probably very confused about our business world. We use words like “productivity” and “efficiency” all the time, then turn around and create barriers to people getting things done. We’ve created bureaucratic systems with centralized decision-making that use an inflexible plan-execute-deliver approach. The alien’s going to think that’s pretty odd. Human systems are inherently productive. People are fast learners and have rich ways of communicating with each other. Agile methods eliminate the typical business pitfalls that prevent our natural productivity from flourishing and nurture what comes naturally to us.
ME: WHY DO BUSINESSES CARE ABOUT BEING AGILE?
DAVID: Because the marketplace is changing so rapidly. During the industrial revolution and early part of the 20th century, markets were slow to change and it was beneficial for organizations to be rigid—that’s how they could withstand temporary fluctuations. Our marketplace is now fundamentally different. Technology and customer expectations are continually changing. Agility is a requirement of any business that wants to be successful today—businesses can’t resist change, they have to embrace it.
ME: NOW WHAT IF I PUT AN UPPERCASE ‘A’ ON AGILE? WOULD YOUR ANSWER BE DIFFERENT?
DAVID: Okay, if we restate the question with a capital ‘A’ on Agile, we’re talking about the Manifesto for Agile Software Development, which grew out of a conflict between creative knowledge work and the bureaucratic industrial mindset. Continuous innovation is best served by iterative and incremental development by self-organizing teams. Unfortunately, the legacy of the industrial revolution is organizations with traditional management behaviours—the command-and-control, carrot-and-stick bureaucracy—which stifles innovation. Businesses care about being Agile—uppercase ‘A’—because a combination of disciplined execution and continuous innovation is what today’s markets demand, and Agile companies can achieve both.
ME: LEAN, SIX SIGMA, TQM, AGILE…IT’S A LITTLE CONFUSING. WHAT’S IMPORTANT TO KNOW ABOUT THE SIMILARITIES OR DIFFERENCES?
DAVID: Lean practices like TQM and Six Sigma have helped businesses reduce waste and achieve just-in-time production with high quality outputs. They’re fundamentally about process optimization. In contrast, the Agile Manifesto reminds us to value individuals and interactions over processes and tools—processes and tools serve the people who are doing the work, not the other way around.
Lean methods came out of manufacturing, where there is a high cost of change and high predictability about the desired results. Agile methods came out of software development, where there’s a very low cost to change and very low predictability—every time we deliver a piece of software to market, the conditions have changed in unforeseeable ways.
In other ways Agile and Lean are very similar. They both focus on systems thinking, waste management, technical excellence and evidence-based decision making.
ME: WHAT DOES AN ORGANIZATION NEED TO HAVE IN PLACE BEFORE IT “GOES AGILE”?
DAVID: I’d say “becomes Agile,” not “goes Agile.” There’s a lot of discussion in the community about “going,” “being” and “doing” Agile but there’s consensus that what’s written in the Manifesto is a philosophy—it’s not just a set of practices we apply, it’s a description we identify with on a personal level. It isn’t an end state or a destination. It’s an evolution. Can you “go healthy”? No. It’s a philosophical approach to a way of living. It’s a set of values and principles.
So back to the question. Before an organization can become Agile, everyone in the organization must have read the Manifesto so they understand the document that created that proper noun “Agile.” Then comes some soul searching to decide whether those 16 sentences describe a way of working that everyone would want, not just concede or consent to.
ME: WHERE DO AGILE ORGANIZATIONS TYPICALLY STRUGGLE?
DAVID: There are a few principles in the Manifesto that organizations often struggle with. The first that comes to mind is the principle that says, “The best architectures, requirements, and designs emerge from self-organizing teams.” That’s a hard one for most organizations that historically have held high regard for the work of highly specialized—and often segregated—individuals rather than a cross-functional team.
The other one that requires a big shift is, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” There’s been a long history of centralized decision making in organizations. Agility requires decentralization so that teams can make the best decisions possible based on their market, their users and their skills. It’s hard for organizations to give up centralized control and trust the wisdom of teams.
The third challenge is around communication. The Manifesto is clear that business people and development teams should work together daily throughout the project and that face-to-face communication is best. Not just better. Best. Phone meetings, working from home, outsourcing, offshoring—these are fundamentally at odds with Agile work.
ME: WHAT MUST A COMPANY DO TO ACHIEVE AGILITY?
DAVID: Focus on rapid time to market, customer satisfaction and uncompromised quality. If an organization focuses on those three things its people will naturally discover efficient and innovative ways of doing their work. The big ‘A’ Agile methods, like Scrum or XP, might be helpful and informative as the organization works towards greater agility but it’s greater agility that’s the goal, not Scrum. Lots of organizations are achieving that speed, satisfaction and quality triad. Amazon. Netflix. Spotify. Uber. Google. These are very large organizations. Their quality is just amazing and their ability to respond to the market is breathtaking.
ME: HOW DO YOU DEFINE QUALITY?
DAVID: There’s a principle in the Manifesto that says, “Continuous attention to technical excellence and good design enhances agility.” To me, quality means zero bugs and a satisfied customer.
ME: CAN YOU SHARE AN EXAMPLE OF A CLASSIC ROOKIE MISTAKE MADE BY AGILE AGENCIES?
DAVID: The real challenge for an agency is going to be related to contract negotiation. As a traditional agency, scope is written into the contract between you and your client all the time. That’s rigid. Contracts like those are intended to lock both parties into what’s going to be delivered. The flaw in that approach is that software development, marketing and service delivery—the typical work of agencies—is creative work, not predictable industrial work, and so it’s very difficult to know in advance what ought to be in or out of scope.
The Agile Manifesto provides us guidance on this topic. It says, “We value customer collaboration over contract negotiation.” Let’s agree at the point of contract negotiation that we don’t know the right thing to bring to market because the target might move and the market might change. We’re going to collaborate with the client to determine what we’re delivering, and it’ll change throughout the process. Whatever scope we can imagine at the point of contract negotiation will have been imagined within the realm of conjecture rather than fact. Conjecture is risky in a dynamic marketplace.
Let’s instead agree that what ought to be discussed in the contract is quality, because a quality standard is how we mitigate risk. What’s the quality standard that we should achieve? What does “done” mean? The agency and client should agree on those things in the contract and keep scope flexible. That is the hardest thing for agencies.
ME: YOU’RE RIGHT—THAT’S A BIG CHANGE FROM BUSINESS AS USUAL FOR AGENCIES. WHAT DOES A QUALITY-ORIENTED CONTRACT LOOK LIKE?
DAVID: There will be some statements about the team, their capabilities, their commitment to the customer’s business goal, and clarity around what “done” means. For example, “As this team is delivering product for Client X we recognize that the system should always be in a ready state and delivered in increments.”
I have written and seen many contracts that focus on quality, system integrity, and security and accessibility standards rather than scope. For example, a client and their team may agree that some analysis is required for each item in the product backlog; code must be written and peer-reviewed; system integrity will be verified with automated tests during and after every adjustment (which means multiple times per day); and performance standards are frequently met and tested with regard to user interface (UI) load time and number of concurrent users (again, multiple times a day). As well, the client and team might reach agreement that the system shall never be lacking more than one known security patch; all UI design decisions will include testing for WCAG Level-A accessibility on specific screen sizes and devices; and that the team will have effective rollback strategies to capture and prevent defects from ever reaching production environments.
These criteria apply every day to every single thing the team implements—this is their level of done-ness, and it’s written into the contract. An agreement like that between the agency and the client allows the scope to be flexible. The client develops trust in the output of the team because they know the desired quality standards will always be achieved.
ME: HOW IS THE EXPERIENCE OF WORKING WITH AN AGILE AGENCY DIFFERENT FOR A CLIENT?
DAVID: Clients of an Agile agency will experience a relationship with an intensely focused team that is capable of receiving frequent and rich feedback from both the client and the client’s marketplace. That means clients must be available to the team. The product will benefit most if the client has frequent dialogue with the team and perhaps even embeds themselves with the team to allow for day-to-day interaction.
Some clients can’t handle that much involvement. Some think of an agency as a way of outsourcing the problem—“Here are our requirements. Show it to us when it’s done.” Clients like that will have a hard time working with an Agile agency.
The job of the client is to bring their business goals to the team, rather than prescribing the end product. I’m sure agencies see it all the time—a client who says, “We want a website” and when you ask them their business goal it’s something that can’t easily be achieved by a website, like shortening their sales cycle or improving customer retention. When clients bring their goals to the team rather than their requirements, it sets the stage for real collaboration.
ME: IF YOU WERE LOOKING FOR AN AGILE AGENCY TO WORK WITH, WHAT WOULD YOU ASK THEM TO FIND OUT IF THEY WERE REALLY WALKING THEIR TALK?
DAVID: Funny you should ask that, because BERTEIG is actually involved in that process right now for some work we need done. The first thing we’ll ask is, “Can we hire a cross-functional team?” Then we’ll want to interview that team so we can see who they are, discover how long they’ve been working together, determine whether they have the skills to deliver on our business objectives, observe how they talk about quality, and find out about work they’ve done together. What have they learned from? Do they share pride in their work? Without an effective cross-functional team, agility is impossible.