I had an idea for a story. A kind of “geek tragedy,” based on the idea that the very things that the team are most proud of, might also be the seeds of their DOOM.
I thought I would play with an outline here and see if the story comes to anything.
Idea one – a theoretical team of techies
Let’s say we have an agile teams that wants to continually focus on technical excellence. In fact excelling technically is something that is very dear to them.
They are a small team that works on a stand alone product.
Things are hard to start with but they learn continually and become technically awesome.
I think this is a plausible outcome for the story because it aligns with two principles that I hold to be true:
- From the agile manifesto – Continuous attention to technical excellence and good design enhances agility. The team’s product can grow more successfully and adapt more quickly
- Forgetting about good craftsmanship will constrain and ultimately imperil agile adoption.
Plausible maybe, but a bit dull. It is almost as though adopting good agile practices takes the drama out of getting work done. Maybe I could add a twist where they forget about technical debt, then realise and fix it.
No, still too boring.
I could add a murder or maybe have the product owner disappear for several weeks and nobody knows where she is or what she wants from the team. A bit unlikely, I guess, but it adds a little drama.
Maybe I will have an evil Scrum Master instead and they keep promising crazy things on behalf of their team, even though that is not their role. Then they force the team into endless meetings which just annoy the team when they want to get back to work.
No, that is both unlikely and dull.
More geek tragedy, less scrummy
Ah but I have and idea – let me tweak things a little.
Instead of being a stand-alone product, the product that the team works on is highly technical, hidden in the backend of the IT shop and deeply integrated into a complex technical ecosystem. That could definitely happen.
The team are really passionate and really talented and yet there is going to be a sense of foreboding, or even INEVITABLE DOOM. If we can pull that off then we will have a geek tragedy.
But how?
The thing the team members hold most dear is their ability to come together to build a technically awesome product. So their strength and potential downfall is their technical ability and their ability to focus on technical excellence as a team.
Now we have something that we can use as the seed for their INEVITABLE DOOM.
Next we need some early warning signs that we can see from the outside but that, tragically remain invisible to the team. I can do this by adding a character named Kassandra.
Kassandra is an experienced developer who joins the team but is a bit pessimistic. She keeps telling the team that they are doomed, but of course nobody believes her. Somehow she has come to believe that their technical goodness will also be their INEVITABLE DOOM, if that could indeed happen.
Well, whatever. Things start slowly and over drinks Kassandra starts trying to warn the team that she had a dream where they were doomed. Sadly she is a female developer with a background in Ruby on Rails, so naturally nobody listens to her.
Well, nobody in the team listens to her, we as the readers hear her STRANGE PROPHESY of the team’s INEVITABLE DOOM several times in the early part of the story.
The greater the technical expertise of the team, the greater the likelihood that the organisation will make bad technical decisions.
Kassandra
So I have introduced some ominous claims from a developer but I think we will need to add a little more meat to the story before we can pull off a claim like that.
Maybe I can set the scene by showing that the team are great problem solvers. They encounter highly paid subscription software that is burning the companies budget and they download some open source replacements that save money or they catch an evil hacker trying to get into the system, or something like that.
OK – next I can establish that the team are part of a wider ecosystem as I show them them building their solution.
Early in the story the team struggle to get on top of their complex technology, integrating GO with a restful, peace loving API. This sounds easy but we somehow need to make it seem challenging, possibly through the addition of a few acronyms.
Then we can throw in some tight deadlines, a sales team who have already sold the product and some random new government legislation about privacy or something. These seem like things that could really happen and they would add some drama.
With each technical challenge the team doubt themselves and then come good. With each challenge the business people are worried and under pressure but they work with the team and see them struggle. With each challenge, the team come out stronger and their focus on technical mastery starts to really pay dividends.
Things start to hum and we have a montage of people doing successful releases into production. Customers, other teams and management learn to appreciate the expertise of the team, even if things do seem to happen much more slowly than predicted.
People continue to complain about how slow the team is but actually have a grudging respect there. From the team’s perspective some complaints about being slow when they are actually have good momentum is a long way from INEVITABLE DOOM.
After all, the team has defeated the complexity of their product and found an equilibrium. Production outages are but a distant memory, value is being delivered, even if only to internal stakeholders.
They go to see a super hero movie together (wearing masks if there is a world wide pandemic at the time) and they talk about how they really are on top of their game. In fact, they even note that they are increasing agility, just as the ancient texts of the manifesto predicted.
But in fact, DOOM awaits them and trouble is already brewing.
“Slow then fast,” mutters Kassandra, as they catch some food after the movie.
Someone asks if she means their velocity, which is increasing nicely, but Kassandra seems surprised by the question.
“Technical problems always start slowly, barely noticed by the team, then suddenly they accelerate into a flood of terror,context switching and random meetings that hold no meaning for the team whatsoever”.
Kassandra, just before things start to unwind
The team laugh these random comments off, since their system is actually very robust.
Their confidence is reinforced the next day as we see that, as a result of all the good design and disciplined coding, the team can get on with their jobs without impediments.
In fact, the team’s stakeholders (other technical teams and business people) have stopped harassing the team because they know that there have no need to disturb them.
Stakeholders simply ask for something, wait “way longer than they should have to” and then get what they need from the team. Some stakeholders find that when their own planning comes short, they can ambush the team with unexpected requests and still get what they want. It’s annoying, but manageable.
It’s annoying to hear people half-joking talk about being slow when the team’s product is more a nuclear reactor than a Lego model. But that is a long way from INEVITABLE DOOM.
Meanwhile though, there are, of course, issues across the wider ecosystem. As a result, other people start talking about how to fix these problems and there is constant activity that the team hear about, but do not need to worry about.
Management, though, are worried. They are worried about costs and an unexpected slowness across the portfolio.
Other technical teams are worried too. Some are now complaining that they suddenly found out their systems had become legacy systems while they weren’t watching.
Not a problem for our team, but they notice the unrest anyway.
Next, some outside consultants offer a cool sounding product, but they neglect to explain that that the outside system still needs to integrate into the organisation’s overall ecosystem, including the newly discovered legacy systems. They talk about how their system will be awesome, as long as some foundation work is done to clean up any legacy issues that might exist.
Nobody is foolish enough to just believe outside consultants though and so of course everyone speaks to the technical teams about what will happen if the vendors system suddenly appeared in technical mix.
Some of the other teams are a little hesitant in committing to a recommendation but our team is fearless. Given their sound understanding of their system, along with a general understanding of the wider technical landscape, they are well placed to offer a view.
When they assess the proposed solution, our technical experts hear some pretty dumb ideas about an out of the box system that automatically integrates and cleanses data as it extends its tendrils into the ecosystem.
Since these ideas are clearly unworkable, the technical team send a long email and present their findings in a meeting. Problem solved.
Then they hear about a really bad attempt at an implementation of the same solution in another company and, just for good measure, they forward links to various decision makers, with some appropriately dismissive comments about dodging a bullet.
Our team hear that the vendor wants another meeting, but they know it is pointless now that the issue has been put to bed.
We do see Kassandra updating her resume though and she asks if the team would give her references if they all had to leave after the INEVITABLE DOOM that is coming.
People are polite and say yes, because she is actually a good developer and her knowledge of the backstories in the Cobra Kai tv series is very well respected, adding great value to the team.
Since the team give a quick, not too detailed reply, the vendors see this as a typical team protecting their patch. They decide to ignore the team and keep catching up with some management types.
Nothing much comes of it, but then there is a twist. Someone who has used their products before (on the periphery admittedly) comes to work in the company. They start telling the CFO how surprised they are that development here is so slow. At the old firm people punched out entire new planetary systems each month.
We leave that there as not much is happening.
We come back to the team.
Since the system they build is working really well, people don’t come and talk to the team much but they are in a bunch of technical forums where they share their philosophy ubiquitous presencing an how it is really going to limit the emergence of AI.
In those forums the team hear the ongoing complaints about “legacy applications” and then they hear that the new Billing systems called “The Borg” seems a little troublesome.
The team also hear rumours of a demo or a presentation related to the vendor monstrosity, which they ignore, because they have already tackled the issue – vendors are always so hungry and so ignorant.
Anyway, our team could probably create a similar app with open source in 3 months.
Meanwhile one of the troublesome legacy systems is having some real problems and desperately and needs some kind of fix. The technical debt in the old billing system is getting out of hand and it is taking the general ledger down with it faster than the new Borg system can assimilate it.
Its almost too hard to fix, but one of the debt infested team hears about a new framework and some particularly peaceful and relaxed API’s and they start to build some solutions on top of their system. Building some API’s seems easy to the legacy team, although they are not entirely sure about how the APIs will integrate with some of the other systems.
Our team of technical experts offer to help. They soon see the folly of what is going on and direct the debt infested teams to an existing solution that is already in place in the organisation, rather than a half baked new app.
A job well done they decide, but they are feeling a little uneasy.
Unfortunately the debt infested team are too tired to think straight and don’t really have time to follow through on the lead, so they keep building and they are confident that they are nearly there, wherever that is.
Things do not work out well and the debt ridden team escalate to management. They cannot support this newly finished solution (well, nearly finished) and also meet their other obligations, so they will need to hand the new solution over to someone else.
Meanwhile an agile coach starts with the company. He used to work somewhere that used splunk with BDD and a HAL based AI. Although he is not entirely clear on what all this means, he shares his experience with the management team and some of the business people.
The coach describes a utopia of continuous integration, happy clients and rapidly growing profits. He suggests that the organisation could probably impose a strangler tree pattern of test utopia on the old billing system and also accelerate the progress of the borg project.
The agile coach tells the technical team, who dismiss these stories for what they are – ill formed thoughts about a system that existed in a different organisation at a point in time in a different context and never actually went live.
The agile coach calls a big workshop, as coaches are want to do. The team go along, ready to explain flaws in the solution, and then they find out that it is even worse than they feared.
There is talk of recycling some underutilised Tolkein ring networks, but the team know for certain that Tolkein rings don’t even exist in a .Net environment. They are are able to prove this and gain agreement about the futility of pursuing this half-linked solution any further.
Being technically gifted, our team are able to shoot the coach down and send him packing. They won’t hear from him again and he heads off to run some workshop for the CFO.
“Good,” the team think – the agile coach and the CFO can distract each other, leaving everyone else to get on with their work.
Then one day there is a meeting and the highly technical team attend, hoping for donuts and maybe muffins.
Unfortunately there is no catering. Worse, there is some disturbing news.
Three new technical solutions have been rolled out in the organisation, they are all about 90% finished but the teams working on them are either flat out or moving on.
Apparently it is going to fall to our highly technical team to make the final tweaks, support these systems in production and bring home the substantial business benefits that have been all but realised now.
However when the technical team look at what they have inherited, it is not at all good. They use phrases like “ball of mud,” “Franken-system” and “no chance in hell.”
Kassandra is sitting at her desk, working on something in the background. She seems as pessimistic as always yet somehow looks more at peace.
The team ask for technical documentation to support their new monster babies, but apparently it is hard to find. At least the teams handing over to them will “help out when they can”. They promise to make time for our team but “just not today”.
Then I guess we wrap things up by bringing on some INEVITABLE DOOM.
Well, that was fun, but it’s not quite working is it?
I was hoping to weave in the futility of technical excellence if you are out of synch with the people around you. Maybe to even show how quickly bad ideas can spread through an organisation that is not paying attention.
I had hoped to somehow show that the better the team did, the less help they needed help and the more people let them just get on with the job, which then led to them contributing to the INEVITABLE DOOM.
I guess the problem is not really technical expertise, but maybe it is that conversations are happening without an understanding of context, while the people who understand the context don’t bother to spend time on what they know will never come to fruition.
The reason the technical expertise contributes to this problem is that excellence breeds complacency. The more you know the less you question and the less you notice, or something like that.
A good goal I guess, but I don’t think it is working. I guess, the whole story is just not realistic.
Ah well, thanks for following my journey, sorry the story is so implausible. Of course a continual focus on technical excellence could never be the downfall of the team. It’s all just a bit too silly.
Maybe if I did a story on how providing the customer with early and continuous value by giving them everything they ask for could lead to INEVITABLE DOOM if there is no plan for resilience in the face of change.
No – not realistic either? I guess I am all out of ideas, so there won’t be any geek tragedy with INEVITABLE DOOM involved in it this week.
There probably won’t be any next week either.
James King 