Collaboration over segregation
Software development. The magical translation of business requirements into deployable code.
As a business, you have to have a grip on your processes to understand when you will see value from an investment you’ve made in either time or budget. And while leadership in most businesses understand how to drive their finances, hiring, and marketing departments successfully (and on the budget). The world is, however, filled with so many views on “business & IT alignment” as agile frameworks that it seems we still struggle with getting a grip on tech.
But how come those deadlines are always slipping? Is it because those tech departments just being notoriously bad planners? Or is it that it’s tech finding it increasingly difficult to grasp the actual business?
Mowing the lawn
To make any process manageable in our lives, two properties are crucial:
We must understand the properties which make something controllable and which properties don’t.
It has to be something we’ve done before.
When we’ve done something before, we often think we know the properties to make it reproducible in another situation the next time. It’s just that we often confuse skills and tools with the problem that must be solved.
In reality, the programming skills of your development team, just like the languages and frameworks chosen, are just tools. Tools which can give an advantage in expressiveness and execution – but like shown with every technical transformation – completely replaceable and exchangeable from a higher-level view.
Alberto Brandolini describes that; “Software development is a learning process; working code is (just) a side effect”. Development teams' skills and tools inevitably commit to this side effect's outcome. But it’s the interest and capabilities of software developers in problem-solving and critical thinking which can separate well-thought-out solutions from generated code.
Say you’re planning to mow the lawn of your – just-acquired – house. The first time takes the longest. You have to figure out where your best power outlet is; maybe you have some tricky corners; perhaps you’re just distracted while talking to your neighbour. But after doing it several times over the months, you will get a good idea of how long it usually takes you to finish your job. You’ll probably even get quicker every single time. You’ve mastered your skills, and you understand the features of your garden which take the longest.
Now say, you have to mow my garden. It’s half of the size of your garden. Will you finish the process in half the time you usually do your garden? Probably not. Even while the process is the same, the skills are the same, and the tools are the same. The distinct difference of all plants, corners and other attributes of my garden will ensure it will probably even take you longer than your – twice as large – garden. Doing familiar work in a different context is a learning process, a freshly mowed lawn is the side effect.
Connecting your problem and solution development
A business heading in new directions must understand and embrace novelty. When business drivers are translated into high-level requirements and epics and your development team as an isolated deadline-driven implementor, you’re pushing your development teams into the seat of a business analyst, risk assessor and financial controller – without telling them. When the development teams were not part of understanding and navigating the problem domain (you have your analysts, architects and POs for that, right?), their solution will not only severely reflect your intentions, but they will also never meet that deadline.
Our experience shows a better fix for this segregation than additional layers of project management: make everyone in your organisation part of the problem and the solution. When navigating your business on new goals and requirements, use the critical minds of your developers not only to build the answer but to collaborate in crunching the problem. Within your development cycles, make every suitable layer of your business part of the progress by actively testing and validating if the model for the solution fits the problem.
True, honest collaboration fixes any misunderstanding between IT and the rest of your organisation. It also ensures the knowledge of your system is embedded throughout your organisation. Sure, it will take additional time and dedication from everyone, which might seem like too much overhead. But some extra overhead is undoubtedly better than not meeting your goals on time.