How not to be an Igor

I recently wrote a somewhat tongue in cheek piece with a serious message. For agile - well, actually, any software development project - to succeed, business needs to be fully and intelligently engaged. Iterative delivery processes appear particularly sensitive to this (arguably, they just show it up sooner, but that’s another discussion).

So, how do you make sure that your software team(s) successfully deliver what’s needed? A very good question - and one with no definitive answer. But here are a few hints that should give you a better than average chance of success.

Firstly, and perhaps most importantly, is to recognise that “The Business” generally does not really understand the engineering discipine of software development. They might have an appreciation of it (at least, I hope they do!), but they don’t have skin in that particular game. They don’t cut code daily, so they don’t experience the trials and tribulations of producing the end product. So they don’t generally care about how many tests you have, or that you are using the latest whizzy ReacgularEmberAshSproutCabbageCarrotCore framework, nor do they care whether you are using continuous integration, containers, microservices or Tupperware. The business is usually only interested in one thing - the end game. Working, reliable software in front of the customer. And if they cannot see that, then they will be tempted to fall back on illusion of progress antipatterns as a proxy measure of progress, performance and value. For example, Number of Stories Delivered, Velocity Points Delivered, Accuracy of Estimates measures and so on (Hint: This is a Bad Thing(tm). None of these are productive. Quite the opposite, they are illusory).

Equally, “The Dev Team" don’t always understand the business. Since software development is a skilled, complex, creative endeavour, their focus needs to be on programming tools, techniques, patterns and paradigms. As a result, in the same way as business is disconnected from development pressures, they can miss important factors unrelated to their immediate engineering discipline. For example, time-to-market pressures, customer needs, visibility of real progress and so on.

I believe this situation is fine and good. It is rare to find teams that are so cross-skilled that developers and business representatives are interchangeable. Both disciplines require significant specialist personal investment of time and energy. But as a result, neither side can exist in isolation. Neither side is better than the other. Effective product delivery is a joint responsiblity. It has to be a symbiotic collaboration of the two sides, which requires communication and mutual respect. Frequent, effective, two-way, respectful communication. If this breaks down, then trust is lost, the illusory control mechanisms begin to appear, and both sides start an unproductive game of "blame whack-a-mole”. Business demands a meaningless progress metric, eg velocity points delivered. Dev team get metaphorically beaten up for “not delivering enough points”. Dev team learns how to game the metric to avoid pain. Software still doesn’t get delivered. Business demands another meaningless progress metric, which gets gamed…. and so the proverbial blame-moles get whacked.

So the first, most important rule of “Not being an Igor” is for Business and Development to communicate with each other openly, honestly, and with respect for each others’ needs and skillset. The rest follows on from here.

Once there is a meaningful, respectful dialogue between Business and Development, then both can openly and honestly discuss, challenge and align goals. For example, if the Business genuinely needs something working in time for, say, a key conference, then the thorny subject of how it can be delivered can be discussed. The Development team knows their subject, so they are the best people to ask. Equally if there is budgetary consideration, then perhaps Business are the best people to ask. Both sides have valuable input. However, both sides need to be alert for imagined terms. The needs of both side can be challenged (respectfully!) and discussed to see if they are real or based on flawed information or opinion. Eg. "What happens if we miss that date? Does the company go bankrupt?”, “Do we want this product so badly that budget isn’t really an issue? When does cost become a real issue?”.

There are facilitation techniques that can be used to ensure these discussions are effective and productive rather than damaging. This is a rich seam of material for other articles at some indeterminate time in the future - do get in touch if you need help with this.

Now the goals are aligned, actual development of software to satisfy them can start. More importantly, an ongoing, meaningful discussion of progress can begin. To be meaningful, progress needs to be directly measurable, and not abstract (story point burn is definitely out). The only measure is demonstrably working software. That is, software that you can give to the business and say “This is what it does now, compared to what it did last time”. No smoke, no mirrors, no voodoo SQL statements showing magic has happened. Plain old warts’n'all User Experience.

From visible progress, more meaningful discussion can take place. Does the software work? Does it look like we can deliver within budget/time? What are the unforeseen (unforeseeable!) problems stopping us? Are we likely to succeed? Is it worth continuing for another week/fortnight/month? The odds are, by making small, mutually agreed corrections early and frequently during delivery, the product becomes much more likely to succeed, and if not, significant budget, effort and stress saved by recognising this early.

Following these simple pieces of advice do not guarantee success. The supermarkets are sold out of silver bullets, and the world supply of magic project beans has had an unfortunate run-in with some weed killer. However, I do guarantee that by simply appreciating the skills others bring to the project, and having honest, sensible discussions with each other, you will be less Igor-like, and your project will stand a far better chance of succeeding.