I’ve worked in and with teams who would identify as agile for many years. I’ve written about how I think the most interesting part of the agile manifesto is the “uncovering better ways” mindset.
With this in mind, I’ve been pondering how the principles in the agile manifesto have aged. Where do (and don’t) I share the same principles.
Given the “better ways” of developing software we’ve uncovered, can we “turn up the dials” on the principles as well as the ways of working?
Principles tend to stand the test of time better than specifics. The agile manifesto still reads as an aspirational document today, but I think there’s room for improvement.
Here’s my take on things I’d tweak in each principle; hopefully staying true to the values.
Bettering Ourselves
Building working software is a powerful tool to achieve our ends. However, I wouldn’t consider it the highest priority of a team. If we can achieve our goals without software (which can be a liability) that’s even better.
Moreover, if the software we’re asked to build is harmful for humanity, or counter to our organisational/personal values; avoiding that comes before satisfying the customer. The negative impact software can have on society is increasingly evident as more of our society is controlled by software.
“Bettering ourselves” (optimise for learning) is at the heart of agile to me. To borrow from Captain Picard, I’d state our highest priority as:
Our highest priority is to better ourselves, our organisation, and the rest of humanity. Continuous delivery of software is our tool to achieve this.
Learning we’re Wrong
We’re not passively waiting for requirements. We can take more ownership over our goals and understand customer needs ourselves. We’ve shifted from requirements to forming our own hypotheses of what customers need.
It’s not that requirements change, it’s our understanding that improves. We learn how we were wrong and adapt our goals in response.
We don’t need to build for a customer-proxy (stakeholder who wants the software). We’re can build products for people; they are our customers. By meeting customer needs, we build a competitive advantage for ourselves.
We welcome learning that we’re wrong, even late in development. Changing our software in response to what we learn helps us meet customer needs and gives us a competitive advantage.
Continuous Delivery
The only thing worth changing in the continuous delivery principle, is that our tooling and platforms are so much better now than 20 years ago. We can deliver considerably faster and smaller.
A team can feasibly ship multiple times a day—given a good continuous delivery pipeline, reliable & fast tests, production safety net from canary deploys, and production observability. We’re no longer having to burn CDs with software builds.
Deliver increments to working software frequently, from a couple of hours to a couple of weeks, with a preference to the shorter timescale.
All the Brilliant People
I’d replace project with product; due to the temporary-team fixed time/budget/requirements connotations of project.
I think longer lived product teams are more effective. I appreciate this won’t be for folks working in a project/consultancy context but I avoid those ;)
I’d also expand to “all the brilliant people” as per Woody Zuill’s description of mob programming. Get everyone needed to achieve the goals together into the team, collaborating together every day. Minimising dependencies and handoffs.
All the brilliant people work together daily on the product. Developers, businesspeople, customers, designers, testers, ux, data scientists …
Product Teams over Individuals on Projects
As per above, I prefer sustained investment in stable product teams over the project model.
Teams of motivated individuals build products. Give them the environment and support they need, and trust them to get the job done.
Communication Quality over Efficiency
This is the only principle I feel like I’m watering down rather than turning up.
I think face to face conversation is still the highest bandwidth communication method. However, face to face communication is not always feasible for practical & inclusion reasons. Reasons such as geographic location, neurodiversity, family commitments, carbon footprints, and global pandemics!
If face to face communication is infeasible then it’s not the most effective method of communication; even if it would be the highest bandwidth method.
I think the general principle is it’s better to trade off efficiency for quality of communication. Be willing to sacrifice time for better communication. You’ll save time in the long run. Prefer the highest bandwidth communication you can enable, even if it feels inefficient.
Prioritise communication quality over time efficiency. Learn the most effective method of conveying information to and within your team, for your context and each other’s individual needs.
Results are the primary measure of progress
I don’t see working software as the primary measure of progress. We can ship oodles of working software every day and benefit nobody.
How are people’s lives enriched by our toil? How are our organisational goals furthered by our software? How is society better?
Have we achieved what we set out to? What have we learned from our experiments?
The less software needed the better!
The results of working software in production is the primary measure of progress. Get software into production early, starting with a walking skeleton.
Sustainability
I’d make the call for sustainbility more imperative. We don’t rely on static processes to keep development sustainable. It requires active effort and adaptation to combat the natural incentives in play.
We don’t go fast now at the expense of tomorrow. We strive to keep the cost of change curve low.
Prioritise sustainable development over speed. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Technical Excellence
I find myself avoiding the words agile and agility since “agile” has become so semantically diffused it can create confusion.
Continuous attention to technical excellence and good design keeps cost of change low and lets us learn and adapt swiftly.
Simplicity
The principle of simplicity is timeless.
Diverse Teams
I’d add diversity to the description of teams that produce the best results. Self-organising teams with a monoculture are not going to produce the best ideas; there’ll be shared blind spots.
I think it can also be useful to expound on some of the things teams need to self-organise effectively.
The best architectures, requirements, and designs emerge from diverse teams that can self organise. Having the skills needed, clarity on their goals, with a high level of psychological safety.
Double-loop Learning
I’d just add adjusting goals, in addition to tuning team behaviours. The most effective teams benefit from double loop learning. Learning-through-doing that our goals are wrong, or our assumptions when choosing our goals were wrong.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly, reviewing their goals based on what they have learned.
Your Team’s Principles
How do your principles differ? I’ve only thought about things I’d tweak from the manifesto principles above, not what I’d add. What would you add?