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.
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:
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.
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.
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.
Product Teams over Individuals on Projects
As per above, I prefer sustained investment in stable product teams over the project model.
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.
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!
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.
I find myself avoiding the words agile and agility since “agile” has become so semantically diffused it can create confusion.
The principle of simplicity is timeless.
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.
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.
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?