De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”

“NEW COMPUTER SYSTEM!”

Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.

Advertisement

Working exactly to spec

Well done roadworkers in Spalding, told to “repaint the bits you dig up” they did EXACTLY that
(via @Voice_Nigel) pic.twitter.com/xcDBeGLWak

— Jeremy Vine (@theJeremyVine) April 8, 2016

Is there a problem?

• The work was completed to spec.
• Any additional work was likely to break the time and cost estimates.
• The work meets the current standards. To bring the remaining paintwork up to standard would require removing and re-implementing the solution, further risking budgets and blocking higher priority work.
• The only available colours do not provide the legacy appearance required to match the existing lines.
• The blue lines were not part of the original specification and therefore no knowledge is available on their purpose and whether they should be extended or removed.
• The disjointed yellow line on the right-hand side would require straightening, which would cause confusion to existing users. There are multiple consistent configurations and the workers have no means to evaluate which of these minimises confusion.
• The user who raised the bug report is unaware of the timetable detailing the repainting plan and the agreed extent of the lines.
• The user who raised the bug report is unaware of future proposed fixes that will require additional upheaval. Any attempt to fix other line issues now will result in unnecessary rework.
• The existing pattern does not cover the required scope (see the far side), and any additional work would lead to scope creep to correct this error.

The Father Dougal trap

Every day we work with a codebase we get smarter, we learn more, we have more context, we refactor, we compromise and we understand.

Every day we work with a codebase, our estimates improve.

But some days we get asked to estimate “everything on the backlog”, with a large dose of yesterdays weather, and a divination ceremony that uses numbers and maybe spreadsheets to make it look like engineering.

And the tasks we tackle the following day or the next sprint, or the sprint thereafter are mostly going to match the estimates, except for the knotty ones that don’t. And the ones further away will match less because by then we’ll know more. And we know we’ll no more, and we chose, or are advised, not to do them yet.

Those are the indistinct shapes in the fog. The ones that look bigger than what you’re doing now but definitely a lot smaller than those big problems we’ve tackled in the past.

Or are you fooling yourself? Do they only look small because they’re far away?

When you get close, will you find that even your best tools aren’t up to tackling this monster, and you’ll need to invent some new ones? And that will take time, and rework.

How far ahead are you estimating, how soon will you get there, and how confident are you that size isn’t an illusion?

You have permission to change

Agile is a method of managing change by embracing it. It’s not a process, but there are lots of processes that help people deal with their particular change or their particular pain.

We talk about agile a lot as a method of developing code, and how the code needs to be flexible, reviewed, refactored, tested and changed to meet new requirements.

We talk a lot less about the processes around them. Yes, Continuous Integration and deployment are recommended, as are short sprints, and retrospectives should be about making all those better. But there’s too often a disconnect between the people and the processes they create. The processes may get reviewed, but often go without refactoring, testing or changing, so they slowly decay into legacy processes, and procedural debt, that are no longer fit for purpose.

So people work around them and suddenly there’s manual steps in production because a requirement to deal with secure data properly in production didn’t lead to the right refactoring of the CI/CD process.

So what’s your cycle for refactoring, testing, changing and reviewing your processes? Do they live in your code, and subject to the same cycle? Are they accessible and editable by all? Who needs to review them before they change? How do you know they’re failing the test?

Sugar coated icebergs

Prototypes are great. They let the user see and feel what the final product will look like, either in printed or in online form.

They suck when the customer wants it next week because “it’s just a bit of wiring up to get it working”

And they can be dangerous. Ship that button without properly tested, or incomplete, code behind it and your software could crash and sink without trace.

If you want to always be finished, you need everything that the user can interact with to meet your quality standards. No unguarded exceptions, no raw data, no untested code. And if that means leaving that button out until it’s ready, do it. Or put in a bulletproof, well tested placeholder, like an email subscription to find your beta testers.

The user doesn’t know or care about all the mass under the surface that they can’t see, so don’t expose them to it. Keep the interface clean, simple and error free. Build up behind the scenes, behind feature toggles, and off production until you’re sure it’s safe.

The one thing worse than a missing feature is a horribly broken one. A user missing a feature may come back when the feature is ready. A user who’s experienced a broken feature won’t come back until they trust it.

Don’t lose your users’ trust.

The importance of feedback

When I first became a tech lead, I realised that feedback from my team was essential. A lot of things had gone wrong and I needed to know why, and how to fix them. What I failed to appreciate right away, until it was pointed out to me, was how important feedback to the team is too.

We did our regular retrospectives, and ad-hoc post mortems as required. We gathered a list of actions. I got on with some and others had lower priority. And at the next meeting we’d have a new list of actions.

And the team got frustrated because they thought the meetings were a waste of time. And it was only when one of the team members expressed that frustration that I realised that the frustration stemmed from my lack of feedback to them.

If an action isn’t fed back, did it really happen?

I’d done the first part, action. Making sure the tasks that were generated weren’t all impotent, but I missed the importance of the second step. Without that feedback from me, the feedback from the team dried up, frustration increased and problems went unvoiced and unfixed.

So I made a point of regular updates. Both in stand-ups and as a written report, as I felt that suited the distributed team better. And I reported successes and failures, giving reasons as best I could.

And suddenly I found that some of the actions I had de-prioritised were very important to someone else, who then asked for permission to fix it. And mostly, I let them. And the team weren’t just fixing customer problems, they were fixing their own frustrations too.

And I reported them all. Here’s what we reported, here’s what we fixed. And I reported it to make sure those who weren’t at the coalface could see what was happening, so we had a record we could review when we wanted to know why a decision was made.

It wasn’t perfect but it had a massive impact on the motivation and the success of the team.

Make Actions Work

Don’t let actions be impotent.

Don’t let actions out of meetings be empty. Record them. Assign them. Report on them.

It sounds obvious, but as a tech lead, that should be your priority. If the team doesn’t get feedback, they won’t be motivated.