In a business world obsessed with speed, output and disruptive innovation, it is no surprise that there is a newfound obsession with ‘agility’. From startups to tech juggernauts, it is now trendy to be seen as agile, nimble and able to pivot quickly. In the complex world of software development, however, agility is far more than a buzzword. It is a necessity. As a result, for managers and developers within a software company, agility has very real and tangible implications for how work is approached.
To draw on a very simple comparison, let’s look at the construction industry – and the planning that goes into constructing a building. The developer/architect will present the blueprint, and from there, things like costs, timelines, and resources will be planned accordingly. For the software developer, however, the blueprint is based on the information available at the time, which is very often incomplete, and worse still, misaligned with the realities of the day to day operations of the business. This due to the inherent complexities of a living, fast moving company. So, the resultant developed system may fall short of what was initially envisioned, or worse still, turns out to be a poor solution to the initial problem or brief.
No ad to show here.
Short Bursts of Genius
While a blueprint is needed in order to provide business with the expected costs, time lines and scope of the project, we can’t keep all these parameters fixed unless we know every little detail of the requirement upfront. Through experience, we’ve learnt that only 20% of functionality stated in the blueprint is used 80% of the time. Even if the blueprint only focused on the most crucial aspects of a system, in our experience there will still be an adjustment in scope.
So how do we manage the inevitable change to what was planned initially?
We follow a structured but lean approach to software development. We develop software in small increments, delivering value early, and engaging the client in all aspects of our process. Value is shown through working software allowing us to continually adjust the direction of the project based on the outcomes of client reviews.
As with any system, the Agile approach still has its challenges and pitfalls for both sides. For the client, having to work so closely – and frequently – with developers can feel like a headache, and draw resources away from other matters. Yet we have found that over time, clients begin to enjoy the process and take more ownership of the output – which ultimately leads to better results. This way of working is also conducive to a more open and transparent working relationship – leading to long and successful partnerships.
Scaling
How can we still be productive in such a dynamic environment, especially on projects where multiple teams are involved?
Team structures are crucial. A delivery team must have all the roles required to make them self sufficient and self managing. They become like a small business unit, being responsible for the tasks they committed to, with authority to execute on their obligations and accountable for their performance.
Once the team structures are defined, processes can be applied to ensure a predictable and repeatable approach to doing things. We subscribe to the tenets of the SAFE framework, which provides the governance around using Agile development on these enterprise-wide engagements.
All this results in a decentralised management structure, where decisions can be made by people who are closest to the problem. This allows us to scale from two teams to 20 teams – with minimal change in approach.
