The number of articles here on Agile Fixer is growing all the time. This article is designed to help you navigate to those that may be of particular interest.

Once upon a time, in a wonderful far-off land called “Agile”, there lived a man, who told a tale…

“So I work in a biggish company, and we have quite a few software teams. I know some of the tech guys personally, and it’s my job to know how much they collectively cost – and it is a lot. We’ve had a patchy history of building apps and websites in this organisation. Software development seems very hard to do well, with many teams struggling with their processes, and unable to give convincing answers to even the most basic questions about how much work something involves and when it will be done.

In the last few years a lot of our teams have started doing a thing called ‘Agile’, which apparently is a better way than whatever they did before. But it’s certainly no magic bullet – it seems to introduce a lot of confusing jargon; for example, some of these teams now say ‘when something will be done’ using a made-up unit called ‘Story Points’, which doesn’t seem to be any real improvement if I’m honest. Perhaps part of the problem is all the big, long meetings these expensive techie people spend their time in (many of the developers actually complain bitterly about this) – I sure hope they’re using this time wisely.

Actually these techies have one meeting that seems a bit different from the others – it’s a quick one in the morning that is often held in an open space, with a lot of people standing up. You only see the techies doing this, nobody else in the organisation; it’s a bit odd, really.

When you watch them in these morning meets nobody seems to take notes, and they’re almost always gathered around a whiteboard, or a big TV screen. Apparently they put a visualisation of the team’s work up on that screen; some teams reckon this visualisation is really critical and think carefully about how to do it well, while others seem to be much more slapdash about it. One of the senior tech managers told me that the teams that take these visualisations more seriously seem to work much better than the rest, both internally and with the rest of the organisation. I wondered why they don’t just make all the teams follow best practice, but there seems to be an ideological reason behind these very different attitudes.

Curious, I chatted to a guy from one of these ‘better’ teams. He gave me a run-through of what’s on their big screen, which is called an ‘Agile Board’. It’s a 2-dimensional grid, basically. There’s a whole bunch of columns, which show you how work is progressing. I asked how they choose the columns, and was told it varies from team-to-team, but that one way to think about it is you first need the steps to get work ready for the developers to start, and then you need the steps for the coding itself, and the testing, until it’s all delivered to the customer. Makes sense.

I told them that in our business unit we don’t have any of that. But perhaps we should – we’re often in a bit of a mess ourselves, truth be told. Our managers try to prioritise our work, but it just seems to create more noise rather than helping. “That’s why we use these Agile Boards – to make it really clear what everyone should be working on” said my tech friend.

So I went and had a closer look at these boards. They’re not just divided into columns, they have rows (called ‘swimlanes’) as well – this seems to be a key part of how they sort out what their real priorities are. One of their key concerns is to make sure people get stuff properly finished before picking up something new (they have some some techniques to help this) – a bit of that discipline would help in my area for sure.

I’m not saying we’re bad or lazy workers, mind – often it’s our bosses’ fault, since they cancel or change work after we’ve already started on it, wasting a ton of time. We should be a lot stricter about what work gets started and what doesn’t. My tech friend said his team have an excellent way of doing exactly this, which they call a ‘triaging process’.

The more we talked about these boards, the more interesting they seemed. The tech guys reckon that work spends most of its life just sitting around, waiting, rather than being acted upon, and if you highlight and clamp down on these waiting periods, you become a more effective team overnight. This really is starting to sound like “working smarter, not harder”.

I’m gonna have to have a think about how to apply some of this thinking to my own team. Apparently recruitment are using a similar system to track the state of their hires, so it’s definitely not just for techies!”

To be continued (as more articles are added)…