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;
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.