The 12 Agile Monkeys - Decyphering the 12 Principles Behind the Agile Manifesto

We talk a lot about the Agile Manifesto, but not about the 12 principles that back it and I think that's a shame. In this article, I do a little musing about how these principles have been misinterpreted or ignored and how we might better use them to our advantage to deliver effectively.

Introduction

If anything is worth doing, it's worth obsessing over, and Agile is no exception to this rule. So bit by bit, I'm pulling apart our Agile ancestry to figure out which parts need to change and which bits we're just doing wrong. In general, I tend to treat the work of the people involved in this manifesto with some reverence. This is not because I'm star-struck, but because they're definitely more experienced than I am, and almost certainly smarter.

In this part, I'm going to look at the 12 principles of the Agile Manifesto, which seem to be taking a back seat to the main manifesto itself (maybe because it means clicking beyond the home page, who knows). The thing with principles is that we all need them, but to make them effective, we firstly need to understand them, and then secondly stick to them (if we decide we agree with them). That is a lot to ask of fools in a hurry, i.e. all of us delivering to tight deadlines (it's a legal term, and we've all been there, this isn't a blame game).

I think that one of the fundamental problems with implementing Agile is how our brains are wired. We will greedily take that serotonin hit that comes from approval, not thinking about the future. We want that satisfaction right now and are willing to sacrifice our principles for it. This is clearly not the right way to go about our business, despite our ego craving it...

These are my principles. If you don't like them I have others. -- Groucho Marx

With that in mind, let's have a look at these 12 wise monkeys, the 12 things that our hallowed ancestors set out. These are in the order presented on the Agile Manifesto site and I wouldn't like to say what priority order they belong in, aside from the first one, which mentions it directly.

#1 - “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”

This is true, but we have to understand what satisfaction really is. You will be satisfied driving a shiny new vehicle out of the showroom, but less so if it breaks down a mile later in a smoking heap. Satisfaction is a funny thing, it's temporal and fickle, just as dissatisfaction can be. I'd take a bit of a beating from a client in the short-term for a long-term win.

In my opinion, we should favour long-term satisfaction through good engineering and delivering software when it’s really done (see “Definition of Done”). Delivering too early is a false start, it’s a cheap fix with no lasting power. Do not engage in “smoke and mirrors delivery” as you will fail.

I genuinely conflated the 12 Monkeys and The Fifth Element for about ten minutes. Please don't hate me.

Learn to embrace the word "no" and the realisation that in the short term, you may not get the reaction you want... and here's the kicker, the reason we do it incorrectly is because we mistake our satisfaction for the client's. We are approval junkies, we love the pat on the back and the gold watch (to quote Guy Ritchie's brilliant Revolver). Sometimes you've got to take it on the chin for a long-term gain.

#2 - “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”

We welcome changing requirements but not changing fundamentals, project goals or values. Architecture and fundamentals are de-risked early. Complete architectural or outcome 180 turns are not as welcome as you will have to waste a lot of work. Every change is welcome after a fashion, but they all come at a cost. We harness change, it doesn't mean we absorb it transparently. Have a think about that one when you try to 1:1 swap stories out and for some reason it fails. There's a cost for course shifting, it doesn't mean it's unwelcome. Just like Champagne is welcome at a party, it's not free! Get good at sizing up and analysing the impact of change and how you can fit it into your process. Get even better at trying to persuade the client to deal with the big things first (like architectural changes), then you just have to deal with the smaller change.

#3 - “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Firstly, I'd say it's definitely not “a couple of months”, 17 years have passed since this was written and it has been noted by the members of the agile alliance that Sprint lengths are dropping. So take the timescales in this principle with a modern pinch of non-msg, reduced sodium flavour enhancer!

This drop in sprint lengths is for good reason; it works and it is trackable! So think more on the scale of one to two weeks and we're in the right ball-park. Also, when we say working software, this could be a working unit in a harness as long as the unit meets the definition of done. Again, do not engage in smoke and mirrors demos, do not deliver non-working software in an attempt to appease the short-timescale gods.

There are three major reasons for not engaging in smoke and mirrors delivery

1. You will be found out almost immediately when the demo goes off-piste
2. You will be found out shortly after when the delivery suddenly drops off a cliff as you try to fix your botched software
3. You will not sleep at night wondering when #2 is going to happen or if it's the night before the demo, if #1 is going to happen

Where there's no crime, there's no guilty conscience.

#4 - “Business people and developers must work together daily throughout the project.”

Again, this is a fundamental part of Agile delivery, however this means genuinely “together” in a partnership, but there is and always should be a segregation. The business does not have the right to tell technology what corners to cut and technology do not have the right to tell the business what they should be doing (unless you’re a purely tech company). This is a peer relationship, not dom/sub scene.

The accounts department of a company works in partnership with the rest of the company as part of a team, but the department of colouring in screens can't walk up to accounts and tell them to stop this double-entry book-keeping stuff. There's a difference between working together and trying to destroy what each role is supposed to do and the level of professionalism they're supposed to deliver it at.

So in summary, don't let people tell you to be unprofessional. It's unprofessional to listen to or act upon that. Did I mention unprofessional? This goes back to my conscience point above.

#5 - “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

I’m not sure where we missed the memo on this. I’d go further and say “and involve as few talkers as possible”, let the do’ers do. Harness the power of a few great tech leads and let the project deliver itself.

When it comes to making commitments, I'd always involve the do-ers. Do not re-plan or commit to new dates without doing so. Firstly, you may miss the new dates and secondly, your do-ers won't buy in to something they haven't agreed.

The key to your motivated individuals is motivated technical leads. You only need a few, hand-picked shining examples to seed the teams and you are away. Do not try to lead technical teams with people who aren't inspiring technical leaders. Unless, of course, you enjoy the sound of eyes rolling in their sockets.

#6 - “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This principle is an interesting one, as it's true, but only after a fashion. It's true as long as this is a proper pigs and chickens style engagement and you can get the chickens to shut their beaks. Those who are merely “involved” should butt out, those who are committed should have the right kinds of conversation. The conversation should happen once and once only, as anything beyond that is waste, hence the need for “necessary and sufficient” documentation.

Having the team all within earshot on the same bank of desks in the same building on the same continent strangely really helps with this.

Good team communication is based on:

• Accuracy
• Completeness
• Timeliness
• Waste reduction

Cut your lines of communication and the number of times you do it and you make your project efficient. I keep repeating this point, but it does seem to need repeating. Which is ironic, as I recommended only communicating something once. Sue me.

#7 - “Working software is the primary measure of progress.”

This principle is a bit too simplistic for us mortals to understand without some expansion as "working" in some cases means "it compiles" or worse. Working, quality, tested, deployable, fully automated software is a genuine measure of progress. Software that “works” if you squint at it and ignore the lumpy bits isn’t really working software. Do not try to cheat progress, as again, you will be found out. Let's work on your approval addiction and what real satisfaction means, shall we?

I'd go further an map out some basic metrics for this progress so you can show the team. For all I've been critical about the modern delivery process, we should celebrate what we have delivered, especially if it meets a sensible quality bar. The measure of progress isn't just for the client, it's for the team too. Genuine victories are savoured by engineers, do not hide your light under a bushel.

#8 - “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

This does not mean buy your team lots of coffee, or that nobody should work overtime, ever. There is no such thing as “constant pace” otherwise you wouldn’t have lunch for fear of that dropping your pace. This just means that smoothed out over a week/sprint/month, you definitely shouldn’t be killing yourself. This principle mostly boils down to having a realistic number of story points per sprint, where that number is adjusted to match point delivery. There will be some courage required when the chips are down though. It's ok to have a push to finish something, but not to enter full flapping mode to try to rescue something desperately broken. Sometimes it's better to call a time-out on a project to have a restructure of things to increase productivity. Also, if a problem is interesting, people may actually want to work extra on it, good on them. I'm a big believer in flow; do not break somebody's flow because it's late/early/other stuff needs to happen.

#9 - “Continuous attention to technical excellence and good design enhances agility”

And this is where Agile, as implemented in many organisation, comes crashing to the ground.

• It’s slow to do quality… at first.
• It’s slow to put the fundamentals in… at first.
• It’s slow to get the right team in place, with the right kind of environments and processes in place… at first.

What I’m trying to say is that “agility enhancement” means sometimes you have to play the long game. I’d favour enabling technology over functional development, as the former speeds up the latter. Basically, it's the classic parable "do not confuse haste with speed", only in the Agile world, as if you ignore this, you will get hurt. Also, every single time I’ve compromised or kicked something into the long grass, it has bitten me personally, so I’d advise you not to. Keep your builds fast and green, and your SonarQube nice and clean. If you don't compromise, there can be no poor light held up to your project.

This means, as a technical lead, you'll need to spend some time defending your engineers. We're paid to think, not to roll over like a good puppy. Technical excellence isn't an accident, it's by the designs of the technical lead. Some will grumble at first, but again, that deferral of your own approval will pay dividends in the long-run.

#10 - “Simplicity--the art of maximizing the amount of work not done - is essential.”

Architects love code, they love designing systems, adding new stuff. We all want to leave a box of Terry's All Gold by the bedside of AWS to wake up to. Unfortunately, working systems don't care about how great your code is or its impressive volume. I know this is painful, but consider just avoiding doing things that don't need to be done.

Here's a checklist for you, if you're unsure if it needs doing:

• Is it architecturally risky?
• Is it part of the MVP?
• Is the lack of it going to cause development to be impeded?
• Is it trivial but carries huge benefit?

If the answer is no to all of the above, I'd just consider chucking it into the oubliette that is the backlog; it'll get forgotten about, and someday you'll be glad you didn't bother wasting your weekend on it. Further to that, here's a checklist you could use, if you're unsure it needs doing by you:

• Could you just use an open-source library?
• Could you buy something inexpensively?
• Could you reuse it from another team?
• Is it a really well solved problem/design pattern?

If the answer is yes to any of the above, don't hand-roll it, why would you design or write something to do this, beyond massaging your own ego? You know the answer to this; you wouldn't.

#11 - “The best architectures, requirements, and designs emerge from self-organizing teams.”

This is good advice, unless you’re working in a large federation of several teams to deliver a large-scale system. Then you need to have a harder think about things. Self-organisation still matters, but you’ll need to consider how you do that across several cells.

I’d personally have a high-level architecture and design that prevents a polyglot programming petting zoo, and provides guiding principles, rather than trying to waterfall the architecture.

Let design emerge as required, consolodating patterns and allowing for reuse by keeping good lines of communication. Do not end up in a fantasy land of diagrams that do not match reality as the only reality is delivered code. Use consistent tooling to do any design, but keep it lightweight.

My advice would also be to keep each cell technically led and let those technical leaders self-organise. Keep traditional architecture as a review and advisory role as much as you can and let them bounce ideas off you.

#12 - “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”

Unfortunately, we do the reflection bit quite well, but not the adjustment. Sometimes, this adjustment is hard and requires tracking. I’d log all retrospective items as tickets and track them. If there’s no progress, the project isn’t moving on or improving and if you don’t make changes, what is the point of a retrospective? It just becomes an ineffectual support group and you could better spend your time elsewhere. Commit time to making changes, otherwise you can expect your situation to remain the same, this fact should come as no surprise to anybody, yet for some reason it does!

You may find some unpleasant truths in these retrospectives, maybe have to report them to the programme team and prepare for a bit of a kicking. However, I refer you back to the long-term satisfaction argument.

Conclusion

Thank you for reading another one of my streams of consciousness. I really do appreciate it and I hope that some of it resonates. We have thought about many things today, some interesting others scary but none of them fundamentally change the 12 principles, but I hope they have expanded your thoughts upon them.

I do not claim to be right or to have some higher insight, but I suggest to you, that these principles do require extra thought, interpretation and expansion. Some of it may contradict what I have said today, but if I have made you think, then I feel like it has been worthwhile.

My closing message though, is this... Stop being an approval junkie and start investing in the long-game. Trust me, you'll win.