Sometimes you just don’t have the right tool for the job.
Back when I was a young whipper snapper I’d often work on some project in my father’s shed. By project I mean some kind of adaption to my car like grafting a couple of Webbers to the engine. Dad had better tools than I did, so I’d often save a particularly nasty job for the university holidays.
Of course at some point something would go wrong, and a stream of profanities would issue out from under the hood of my car. Dad would wander over and look at the rounded nut, or stripped thread or whatever problem I’d created and say, in his laconic bush drawl, “I dunno, maybe you could try XXX”. Invariably XXX would be something odd-ball like patching a cracked oil sump with epoxy, or using a pipe wrench to undo a nut. Something I’d never have thought of, but it would usually work.
Dad’s solutions were resourceful and creative, he’d developed those skills through years of farming, and growing up during the war when everything was scarce. Sometimes he just didn’t have the right tool and had to make do.
And, when you’re part of a large development organisation you need to develop that kind of mentality as well. There will be things beyond your control, and mandates you will have no choice but to comply with. On some issues it may be worth campaigning for organisational change, but for some it won’t and you have to pick your battles.
For example my last employer had an internal all-of-company bug tracking system. Now while this was not the most cutting edge or fully featured system, it worked. And, when there’s a lot of inter product integration and dependency, it makes a lot of sense to have all the development teams on the same system.
So what happens in that situation when you’re evaluating an Agile tool that has bug tracking built in but you’ve already got one. There’s three options;
- Buy the tool and don’t use the feature. This causes an awkward workflow and potential confusion. Not to mention loss of value.
- Use the feature and write integration to the existing system. This could be a lot of work.
- Limit yourself to tools that don’t include bug tracking. This reduces your choice.
This is just one example. And if you’re trying to implement agile within an organisation that already has processes, policies and procedures governing development you will be coming up against this kind of thing all the time.
One of the smartest things that an old boss of mine did was assign one of our junior Indian developers the job of tool automation. At the time his organisation probably had around a hundred engineers and there were twelve to fourteen sprints running across a number of products.
All that engineer did was write tools and scripts that integrated various systems like bug tracking, sprint management, wiki’s etc. His work allowed the tool we used for managing our sprints to smoothly mesh with the overall development process that was never designed for scrum. Sometimes he used API’s the tools exposed, and sometimes he had to query directly against a tool’s database.
Like the pipe wrench on the nut, many of the integrations were a hack but they got the job done.
So before you decide on using that all singing all dancing cloud based tool consider the kinds of integrations you might have to do. Then ask yourself how, or even if, they’d be possible using just the API’s they provide.
To return to the car analogy, if the hood of your car is welded shut there’s no way you’ll be able to bolt those Webbers on. And my car so needed those Webbers.
Trusting a yellow sticky? Good luck with that.
At one point as our group dived into our particular miss-implementation of scrum we had, as you would expect, one wall of a meeting room covered in yellow sticky notes. And we’re not talking here about a poky little phone room. This was the room we used for “all hands” meetings and for team pizza lunches. You could fit a good twenty pizzas on that meeting table and still have room for drinks and garlic bread.
That wall and those post-it’s managed the work of twenty five developers. And as I was shortly to discover, it was the bane of our scrum master’s life.
One day I wandered in to see what my developers were up to. I only managed one of the four teams at that point in time and the wall was great to see what my guys were doing. M (I’ve abbreviated her name to protect her right to anonymity) was sitting at the table, and even my stunted geek emotional radar could tell that she was seconds away from bursting into tears.
She was in the process of reconciling the wall with the bug tracking system and the escalation system. This took an inordinate part of her day and to add insult to injury she’d just discovered fluttering around under the table like autumn leaves, a whole pile of orphan post-it’s.
So I grabbed my laptop, sat down and helped her sort through the mess. Then for the next few weeks we would spend a good hour each day keeping on top of everything. It was the end of the release and our director and his peers needed the bug and escalation systems to be correct.
Now you would have thought that we should have been able to rely on the developers and the QA’s to keep all the systems updated. But when, as a manger, you’ve got processes that require your developers to update three different systems when they fix a bug, you have to take some of the blame for the inevitable mistakes and oversights. Hence I was helping keep everything straight.
Not long after that we abandoned the wall and it’s plethora of fluttering yellow notes. And eventually we managed to merge the escalation and bug tracking systems as well. As a learning experience it taught me not only to choose my tools more carefully, but also not to blindly trust the crowd. At the time the web was abound with people waxing lyrically at how post-it’s had transformed their development processes and we’d bought into that.
To be fair, if you have no formal development process, no bug tracking system and no feature management system then post-it’s would be an improvement. But when you do have existing systems, introducing a new manual system that has no potential for integration with your existing systems doesn’t really make sense.
In an enterprise it’s important to be able to back up your assertions with hard numbers. VP’s like spreadsheets. During planning you need to be able to say things like;
“Based on the last three months of development my sprint team consumes an average of 23 story points per sprint, with a minimum of 18 and a maximum of 27. Feature ABC is 100 story points in total so it will take at least 4 sprints.”
That can be used in a planning exercise. Saying instead;
“I think ABC will take about two months.”
Is just inviting your VP to order you to do it in one.
When your data is in a structured system that keeps history around the epic user stories, the stories they were broken down into, the tasks they became, and the estimates at each step of the way, you have a corpus of data that cannot be argued with.
So what happens instead in the above scenario is that the conversation you have with the VP is directed to the feature set and what can be trimmed from that if a one month deliverable is a hard requirement for feature ABC. That is a more constructive outcome for everyone.
From previous posts you, dear reader, will have gleaned that I’m not an advocate of post-it based task boards. As a visual aid, and to motivate teams and provide accountability and visibility within the team they are great. But they are a one trick pony. You can’t usefully distill data from them for other purposes. You can’t integrate them with other systems, and you can’t see them unless you’re in the room.
Not to mention that post-it’s fall off the wall and get lost under the table.
