Have you ever worked in an 'agile shop' that actually feels more like waterfall development? Raises hand – I have and it's pretty terrible.
Is your process from the Agile region of France or is it just a sparking waterfall?
With the term lost all of its meaning, applying to a new job can feel like playing Russian roulette with the development process.
In my experience, Agile software development teams tend to fall into one of three patterns. Each is defined by how it receives user feedback and adapts to requirement changes. Because software systems are living entities – and because 'Agile' has been thoroughly co-opted and rendered meaningless – they are named after living things.
These patterns help me find out where my software development process really lies, and advocate for a better fit if the current one is not working out.
The Boar
_Look how agile I am!
_
The boar charges forward. It moves fast and breaks things. To the boar, velocity is king and its skin is too thick to feel customer feedback. The boar finds a shiny thing far on the horizon – usually about 3 months out – estimates how fast it can run, and sprints forward.
The boar thinks it's agile. Look at how fast it runs and how far it goes! Sometimes the boar hits a snag or gets lost, but the setbacks only enrage the boar to move even faster to catch up.
The saddest type of boar is the Babirusa, a type of wild pig native to Indonesia. They have long fearsome front tusks that are a sight to behold. Unfortunately for the babirusa, those front teeth have the habit of arching back and eventually growing into their skulls.
_What happens when tech debt is never paid.
_
This mirrors my experience working on a team that chases feature velocity at all costs. When velocity inadvertently drops due to past design decisions and tech debt, the result is usually adding additional developers – causing the tusks to grow even faster. A better solution I have seen is some sort of specification gathering process improvement. Better spec helps, but it's not a replacement for refactoring.
It's not always bad to be the boar. It's useful when you are working out an MVP in order to start receiving consumer feedback or working on a proof of concept when technical feasibility cannot be determined. It's only a problem when you care about customer feedback – not a guarantee at large enterprise companies or startups with more VC money than sense.
The Lobster
O Hai!
Lobsters are not just delicious, they are also long-lived. They can live for up to 72 years – which compares favorably to the boar's 10-year average lifespan. Lobsters have a hard exoskeleton – aka shell – made out of chiton. Because of this, they must periodically molt in order to keep on growing.
Molting is more about hiding in a cave than a walk in the park. The lobster is extremely vulnerable after molting and an estimated 10 percent of lobsters die after each molting process. But they must molt or their shell will stop them from growing.
While the only hard exoskeletons I encounter at my job are the plastic caps on my keyboard, past design decisions form the exoskeleton of our codebase. And unless we have built the same exact software system before – in which case just cp -r it – we are bound to make incorrect design decisions. And whereas the boar keeps on charging forward even as its tusks are growing inward, the lobster knows when it is time to molt. Software molting takes the form of either a refactoring/hardening period or a rewrite.
A portrait of the author refactoring a data table component.
While a younger lobster may molt multiple times a year, a major one tends to only molt once a year or once every two years. A piece of long-live software tends to have a trashing rebellious period of rewrites before settling down to a refactoring rhyme.
Other than correcting bad design decisions, the refactoring phase has other major benefits:
- You can incorporate new customer feedback into your design decisions, making future features faster to build.
- You can drop support for the less-than-useful features, a major Semver upgrade is a good opportunity to introduce these breaking changes.
- You are encoding your new – and hopefully data-backed -- design decisions into the codebase.
The lobster grows more slowly than the boar, but it wins out in the medium to long run. Although management's aversion to refactoring makes up a large portion of the molting casualties, I have seen Agile teams successfully adopt a 'one refactor sprint out of every four sprints' approach. It's a natural fit for the Spiral Model of Software Development. The lobster works well with periodic customer feedback, say at a consulting shop that works on a prototype and revision workflow, or if the user feedback cycle is long because they are done in phases and require manual data gathering.
The Juniper
As a Colorado resident, few sights are more beautiful than a single Utha juniper tree growing on a dry and rocky mountain top. While its pine tree cousins look like they were copied and pasted out of some digital assets library, each juniper tree perfectly adopts to its location.
Because they are often found on mountain tops, the juniper has trunks that twist as they grow. This allows them to take on shapes dictated by the wind patterns of their particular locations. An upright tree would be uprooted long ago. You also find junipers in extremely arid regions where droughts are common and nutrition scant. Juniper has the ability to shut off some branches in order to conserve water, so the entire tree may survive.
The juniper teams I was a part of on are likewise continuously looking for customer feedback and updating roadmaps to fold in better designs. They understand the Moltke quote: 'no plan survives first contact with the enemy'.
You may be thinking 'this sounds like the agile manifesto', and you would be correct. Especially the lines:
Customer collaboration over contract negotiation
Responding to change over following a plan
Customer collaboration is as important to the development process as the wind pattern is in determining the Juniper tree's shape. It must be continuous, and it will naturally guide software development. When a new piece of custom feedback leads to a better design, the boar charges forward with the original plan, the lobster waits for the next molting, and the juniper will grow into the change even if it means it must kill an existing branch.
A well-adapted juniper tree
The strength of the juniper pattern is its ability to always match users' needs, with the side effect that developers' morale is high because their work is directly connected to user feedback.
The pattern is not a good fit for every team. The juniper does not work when there are too many layers of individuals between end-users and developers, nor when management is not willing to tolerate waking up one day and chopping off half of the features list. This is the wrong development pattern for software that monitors airplane engines or controls robotic arms with very specific safety standards.
Takeaways
These are the three patterns of Agile development I've encountered in my software development journey, each pattern has its place in a well-rounded team's toolkit.
Following the juniper pattern before an MVP is created can lead to a lot of churns based on hypothetical consumer needs and wasted cycles.
Following the boar pattern when the software is already mature and you end up with a team of burnt-out developers.
Fellow Agile developers, which of the three patterns describe your team?
If you liked this post, you may also be interested in how a Code Review Comments Hierarchy can speed up your delivery or how the "Disagree and Commit" principle improves team morale.
Top comments (0)