Agile Quickies: Customers & Change
Today may feel like déjà vu, but we’ll take a look from a different perspective. We’ll be learning about the first two Agile Principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
and
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
#1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
We’ll be focusing on the first part of the principle, as by taking care of that part, we’ll have a much more clear direction. I’ve written about the second part already when talking about the value of Working Software over Comprehensive Documentation.
What does it mean to satisfy the customer? I often like to think about satisfaction in contrast to gratification. Immediate gratification may be what we think we want, but what we, as humans (which our customers are), have a longing to be satisfied. Sometimes that means we need to deny the thing that seems urgent and shiny to really focus on what will ultimately get me to my goal. If you’re a parent, a person who has ever done a diet, or anyone that has ever worked to accomplish a goal, you will know what I mean. What this means is that we must have a long-game approach to everything we do, and not just shift with the momentary tides. Luckily, we work for a company that truly believes in this approach, as it’s how we’ve been able to grow as a business for over a century.
How do we embody this Principle?
- By keeping in mind the forest and the trees. What problems are our customers trying to solve? What is our strategy? How does what we’re working on right now influence the direction of that strategy or solution?
- Working closely with our customers to understand their needs, concerns, wants, etc. We need to understand the customer’s perspective, and utilize our expertise to guide them to innovative and effective solutions.
- Do as much learning and networking as you can
- Utilize user data to inform decisions and confirm assumptions.
- Work with customer service as our primary concern. Think of a time when you’ve had great customer service. It probably involved validating concerns, listening well and providing options. Don’t just tell the customer we’re out of the Prime Rib, offer them an alternative, and maybe go off menu.
Making it practical:
- As a developer this means that when we are building our projects, think of the architecture and components within. Try to build things in a way that things can be reused, and extended.
- Also as a developer, feel free to ask whether what we’re building will actually help solve a problem, or just put a band-aid on the cough.
- As a Business type person, you should be an expert on the scenarios the customer encounters as well as the challenges and opportunities within our tech stack and fulfillment process from request to delivery. Do as much learning and networking as you can.
- As a team, think about several solutions to the customer’s problem and don’t be afraid to build a quick Proof of Concept to help the customer decide. This also means that we need to provide the space to think creatively and build experiments.
- Being nice is a given for good customer service, but listening actively is more important. Actively listen to our customers to uncover the root causes of their problems. Maybe it’s beneath what they’re expressing. Then, let’s think of alternatives for them in the short-, medium-, and long-term and provide them that choice.
#2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Agile project structures > traditional PMO and project planning.
This is not a new revelation, as we’ve seen more and more companies implement Agile ways of working and enjoy greater success. The traditional model of the PMO works well for many applications where there are fewer uncertainties, such as building airplanes and buildings, but in software, we’ve (a collective We) have noticed that software does not operate in the same way. When we flatten the structures, eliminate overhead processes and develop smaller iterations and deliver more quickly, we have the advantage of being able to pivot more quickly to address any new insights we may gain. From the time we hear a customer’s needs, to the time we can actually deliver, we may have either missed the opportunity to provide a solution, or we may have frustrated the customer enough to have them look for a different provider that can move more quickly.
I’ll let Carrol Shelby (by way of Matt Damon) explain a bit more about why committee decision making and multiple layers of process before implementation of solutions can cause us to fall behind*.
Ford vs Ferrari (2019) — Shelby explains the loss at Le Mans to Ford — YouTube
How do we embody this Principle?
- We do our best to streamline processes as much as possible to narrow the gap between feedback and deployment.
- We don’t build 12 month plans, but rather build a solution, deliver, inspect and tweak.
- We build features in a way that allow for us to respond quickly and without insurmountable disruption.
Making it practical:
- Talk with business to align expectations. The traditional model of months of planning and requirements definition before implementation needs to shift.
- We should flatten structures to be able to respond quickly to requests. The closer to implementation we can have the business and customer desires and feedback, the quicker we can turn around and implement a solution.
- Only provide timelines once the team has sized the work. No dates or scope are set until then. If dates are crucial, then we negotiate the scope based on historical team performance.
- Break down stories and features into chunks that can be delivered independently and within a few sprints. Think incrementally, and not myopically or monolithically.
Further Reading:
Continuous Development Will Change Organizations as Much as Agile Did (hbr.org)
Business lessons from “Ford v. Ferrari” | MIT News | Massachusetts Institute of Technology
*For further reading, if you like the analogy — Business lessons from “Ford v. Ferrari” | MIT News | Massachusetts Institute of Technology
