When work is invisible, a spiral of death builds up. How can we break that cycle?
Apps. Websites. E-commerce platforms. We talk about these things all the time. They're having a very real impact on our world. Yet they're all scarily intangible.
Like icebergs, you see only the small percentage that's on the surface. There's a lot going on deeper down. Code, libraries, schema, configuration scripts, layer upon layer of infrastructure – all largely invisible.
This hits us in the development cycle, when we're producing these things. It can be hard to get a handle on what's really going on in our development teams when so much of what they do results in intangible outputs.
Despite the analogies to engineering, it's not like building a bridge: you don't see new beams going up every day.
The same is true in our operations. Web teams create a lot of stuff in order to make the surface elements look good. They spend a lot of time adjusting things that most people only note subconsciously.
Fonts, tone of voice, small shifts of layout: they have a big impact on perceived quality, but many people don't notice them in their own right, so can't relate to the effort that goes into making them work.
This invisibility leads to a dynamic I see a lot.
A spiral of death builds up along the following lines:
- People can't really see or understand what's going on in the web or dev team.
- This lowers their confidence that the team is delivering effectively. (That confidence may already be low, due to past experiences. But even without that handicap, lack of visibility nearly always damages confidence).
- So they ask for status reports, meetings and suchlike, to try to get a feel for what is going on.
- They also increase the amount of work queued up for the team. Because they don't feel confident about what or when the team is going to deliver, they figure they'd better err on the side of putting more of their requirements into the pot.
- Both (3) and (4) create more work for the team. They have to write reports, attend meetings, regularly re-prioritise a large backlog of requests, get their head around a large bundle of requirements, and so on.
Above all, they have to manage all the duplication, overlap and conflicts that naturally arise in such a bundle of requirements.
- This all creates delays in the system. So requests take a long time to handle. By the time they're delivered, the situation has changed and they need to be reworked. Analysis gets out of date and needs to be redone. This creates even more work for the team.
- So the team's capacity to deliver useful work is diverted onto other tasks. Their pace of delivery declines. This lowers people's confidence in them.
And so we get a spiral of decline, lack of confidence leads to actions that further reduce confidence. This dynamic is incredibly common within some of my clients.
How do you break such a spiral? (Hint: getting the web team to go around saying "Trust Us" doesn't work).
I think there are some useful clues in the work going on in the Kaban community right now. Three of the things that Kanban emphasises: making work visible, managing work-in-progress, and continuous improvement – can do a lot to break the above dynamic.
Big, visible boards with post-it notes representing the tasks we're working on make it clearer just how much is going on. People can get a sense of progress by tracking the way tasks shift from "Ready" to "Doing" to "Done".
It's easier to keep track of dependencies between tasks when everything is so visible; easier to find and eliminate duplicates. With this in place, we can begin to argue that there's less need to produce extraneous reports and other add-ons.
The next clue is in Kanban's emphasis on limiting Work-in-Progress (WIP). It's a case of doing less in order to do more. Most of us have far too much on our plates at any one time. So we fragment our resources.
We waste effort on context switches. We lengthen feedback loops, making it harder to ensure we're producing just what's needed. Trying to juggle too many balls exacerbates many of the problems in the spiral of death.
And then there's the emphasis on continuous improvement – using the visibility of work flowing across a kanban board to identify glitches and bottlenecks, then taking action to eliminate these glitches.
My experience is that teams really do take this message on board when everything is so visible. Years of exhortations to Total Quality and suchlike may have had little effect, but a bunch of post-its on a board seems to enable real change.
It's a little ironic that we need physical post-its to manage our ethereal, digital stuff, but their tangibility and ease of movement makes them very powerful.
When we make the work visible, we really do make it easier to manage.
Graham Oakes helps people untangle complex technology, processes, relationships and governance. He is a guest blogger on Econsultancy.
No hay comentarios:
Publicar un comentario