.png)
In a couple of weeks’ time I’ll be speaking at CTO Craft Con. The panel discussion looks to explore whether the Agile Manifesto and its core principles still apply, or whether we should be seeking to move beyond it - and if so, how? As we are all pondering this question, I thought I'd share a few musings ahead of time.
Scrum by ceremony
When people tell me that their teams are running in two-week sprints my eyes usually glaze over. Yawn. (Sorry!)
Don’t get me wrong, I’m all for agility AND delivery, but I have yet to see a Scrum implementation that doesn’t fall victim to “Scrum-by-ceremonies” - teams blindly running planning meetings, holding retrospectives and perfecting their Jira boards without asking why and whether they derive value from these activities.
Story points, planning poker, velocity calculations - they all scream feature factory to me, of the feeble attempt to somehow tame the complex-emergent nature of software development to make it a predictable, repeatable activity.
Tell me this: if you have just implemented and tested a particular feature, why not release it then and there? Why batch it, make it linger and then release it with a bunch of other, possibly unrelated code changes? Why not ship as soon as you’re ready? If your answer is that it takes too long to get code out of the door, then that's a problem you should address. After all, you are only as agile as the process of getting code into Production.
Here are a few other questions worth pondering as you consider your processes and delivery approach:
How much time do you spend backlog grooming?
How many of your backlog tickets have been sitting in the backlog, perfectly groomed, for more than 6 months?
How much time do you spend planning multiple sprints in advance, creating pretty roadmaps of features you will be releasing several months from now?
Do your teams understand why they are implementing a certain feature? What it is supposed to enable customers to do and why?
How much time do you spend on creating perfect Jira tickets so that you can "rule by report"?
How many actionable, concrete ideas do your retrospectives generate - and, more importantly, how many of them get implemented?
How many of the features you deliver create a real-world impact, a change in behaviour of your underlying user base? And if they don’t, do you retreat to “It was delivered as requested/designed?”
Waterfall by another name
The Agile Manifesto was published over twenty years ago. Blimey. That’s six years before the first iPhone hit the market. Most software releases then were thick-client updates running on people’s desktops, often constrained by network bandwidth. Software development was akin to year-long endeavours generating ring binders (remember those?) full of documents in the process, all carefully crafted, with signatures and punitive commitments attached to them. Strict functional silos and carefully policed handovers sought to ensure that each stage of the process was carefully shepherded from one team of experts to the next - as if we were working on the next civil engineering masterpiece.
We all know how this ends: projects with an incredibly high abandonment rate, long delays, excessive costs and worst of all often delivering negligible value at the end because, guess what, the world changes as you’re planning your 2 year development project. So when back in 2001 the guys behind the Agile Manifesto took a break from skiing and got together to discuss better ways of doing things, the intention was to break out of that spiral of doom and pave the way for a world where individuals and interactions, working software, customer collaboration and responding to change were the paradigms to strive for, not processes and tools, comprehensive documentation, contract negotiation and following a plan. (Some teams take this to mean no processes, no documentation, no plan - which is not the point but that discussion is for another blog post another day).
Along came Scrum - or to be factually accurate, Scrum had technically been around since the mid-nineties - and it was embraced by many as the solution to their development crises. After all, it came with rules, accreditations and the excitement of being novel, cutting-edge. The Prince2 community was delighted and sat through 2-day classroom courses in their thousands to add ScrumMaster to their LinkedIn profile.
And for a while the industry was probably better off because of it. After all, we mostly moved away from annual big-bang releases and gradually improved our rate of delivery. But guess what, while fortnightly delivery was worth striving for 20 years ago, if this is all you’re accomplishing today then chances are you’re still trapped in waterfall processes; they’re just smaller waterfalls.
About ten years ago, news hit that Amazon was deploying code changes approximately every 11.6 seconds - as a big organisation with tens of thousands of engineers that obviously doesn’t translate to every team delivering with that frequency, but just let that number sink in. And then consider that this was news-worthy 10 years ago.
What's the right way to do it?
One of my very smart friends asked me this question not too long ago - and I was taken aback a little that he, who is a much better engineer than I am (if certainly less charming!), did not know. But I guess given the prevalence of “Scrum-by-ceremony”, “feature factories” and similar dysfunctional behaviour in organisations of all shapes and sizes, I shouldn’t be that surprised.
Naturally there is no one right way. Every organisation is different and operates in a different context, different competitive environment, different stages of the product lifecycle etc etc. So, within reason, each team should be allowed to adjust and tweak their processes so that it works for them and their domain. But to me there are a few underlying themes that matter and that should be reflected in your working practices if you want to be truly agile (lower case a!).
So here is what I think matters (not an ordered list!).
Velocity matters - but only insofar as it enables you to release, test ideas, learn and iterate quickly. Velocity as a goal in its own right tells me nothing about the value that is being delivered (or lack thereof).
Outcomes matter. Unless a feature is being developed in pursuit of a tangible outcome, something that will have an impact in the real world and change user behaviour in some desirable way, you may as well not bother.
Unfortunately there is no reference in the article that featured this chart on the left that could corroborate the findings (I would have loved to dig into the details...) but looking at the distribution, from experience, it’s probably about right.
Why is that? Because so many features are still dreamt up by people who aren’t the end user and don’t truly understand what delivers value from the customer’s point of view (though of course they think they do). And so features get developed by specification, not by the outcome they’re supposed to create.
Instead, why not have collaborative conversations about what we are trying to achieve and what behaviour we’re hoping to observe in our customers? Let’s admit that we have a few ideas as to how we may make this happen (a list of features we’d like to experiment with), but that we won’t know for sure whether they work until we’ve tried. From there we’re in it together. We will jointly seek the simplest solutions to learn as quickly as possible whether a particular feature set or approach resonates with customers - if it does, iterate and develop the full-blown solution, not before. If it doesn’t resonate, we try the next thing on the list. And we’ll keep going that way until we have achieved our outcome (for which we agreed measurable key results at the outset of course!), or have come close enough that diminishing returns suggest it’s time to move on. If you need a roadmap, make it an outcome-based one.
Collaboration matters. A product owner is not a replacement for real customer feedback. A written document and “organised handover” is not the same as cross-functional co-creation. Throwing something over the proverbial wall and expecting a (usually junior) support team to “deal with it”, is not the same as true end-to-end ownership and continuous, valuable feedback loops.
If you want to be truly successful and deliver fast and effectively, it’s time to rethink functional silos. The excellent book Team Topologies proposed a way forward, but it doesn’t go far enough in my view. It creates cross-functional teams but these teams are still entirely technical in nature. I think it’s time to go beyond that: true value comes from collaboration and teamwork across the organisation, involving whoever is needed to get the job done.
When reading The Innovator’s Dilemma by Clayton Christensen only recently, I was somewhat surprised when he introduced the idea of “heavy-weight teams” (which he himself is quoting from the 1992 publication “Revolutionizing Product Development”):
“[...] Organizational boundaries are often drawn to facilitate the operation of present processes. Those boundaries can impede the creation of new processes that cut across those boundaries. When new challenges require different people or groups to interact differently than they habitually have done [...] managers need to pull the relevant people out of the existing organization and draw a new boundary around a new group. New team boundaries enable or facilitate new patterns of working together that ultimately can coalesce as new processes - new capabilities for transforming inputs into outputs. Professors Steven C. Wheelwright and Kim B. Clark have called these structures heavyweight teams.”
30 years on and we still organise ourselves into “Technology”, “Finance”, “Marketing” etc. when we should be thinking about the customer we serve and assemble the right mix of skills needed to create value for that customer. I have written an entire series of articles on the subject of these value stream teams if you want to learn more.
Agile Manifesto 2.0?
So, is the Agile Manifesto and its principles still relevant today, or should we move beyond it?
Arguably, in order to move beyond somewhere or something, you have to prove that you arrived there in the first place. I’m not sure we can.
Let’s remind ourselves of the wording of the manifesto one last time:
Individuals and interactions over processes and tools
*
Working software over comprehensive documentation
*
Customer collaboration over contract negotiation
*
Responding to change over following a plan
Absolutely everything written there is just as applicable today as it was 22 years ago.
What about the underlying principles? There’s twelve of them in total:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Check.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Check.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Minor tweak but the underlying intention is spot on.
Business people and developers must work together daily throughout the project.
Check.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Check.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Partial check - but valid if you assume that includes video calls.
Working software is the primary measure of progress. ← yes and no; outcomes resulting from working software is the primary measure of progress
Check.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Check.
Continuous attention to technical excellence and good design enhances agility.
Check.
Simplicity--the art of maximizing the amount of work not done--is essential.
Check.
The best architectures, requirements, and designs emerge from self-organizing teams.
Check.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Check.
There you go. Two minor amendments are all that is needed to make these very sound principles just as relevant to software development practices in the 2020ies as they were in the 2000s. Have we universally implemented these principles today to warrant a discussion on "moving beyond"? I don't think so - but let's see what my fellow panelists think!
As always, if you’re on the path to making this a reality at your organisation - or you want this but don’t know how to start - get in touch for an informal chat.
Comments