The Gift of Agile

Software development has undergone a quiet revolution over the past 15-20 years. What many outside the industry, and even outside the engineering organization within the same company, might regard as a simple change in the engineering process, is actually a cultural transformation that fundamentally changes the way people work. If you’re on the inside, you already know what I’m talking about because you live and breathe it every day. If you’re outside, you’ve no-doubt heard the engineering folks extol its virtues with near religious fervour but have mistakenly disregarded it as not relevant to you. What is it? Agile.

Prior to Agile, most software projects followed a standard pattern, often referred to as the Waterfall methodology: Requirements were gathered, planning was done up front by a select few behind closed doors, something got built according to that plan, and then that thing was delivered to the customer. Those projects could take anything from a few weeks to – more often – many months or even years to complete. 

Everyone was fine with this approach until someone spotted that it wasn’t until the very end, when the deliverable reached the customer, that you found out whether you got the requirements and planning right. Were you actually building the right thing? Worse, by the time you built it, the requirements might have changed anyway, so even if you did get it right at the beginning, you were still wrong by the end. 

You didn’t have to dig very deep to spot lots of other issues. For example, since everyone wasn’t involved in the planning process, they didn’t buy-in to the vision causing individual accountability to suffer. Or the amount of effort to build it was very different to what the planners had assumed, so the delivery dates were always slipping, and features were being cut. 

Does any of this sound familiar yet? Most projects outside of engineering still follow the Waterfall model, and as a result, they still suffer the same issues. Yet an Agile approach will work just as well for a Marketing project, or a Finance initiative. It will work for your projects.

Agile works because it follows a few basic principles:

1. Everyone is involved in the planning process, so they understand why they’re doing the work, and can contribute to things like estimating the effort to do it. This establishes a sense of ownership.
2. Work is done in small increments, typically lasting two weeks, where each team member volunteers for work items, reports progress on a daily basis, and asks for help when they hit an impediment to progress. This fosters collaboration and accountability.
3. After each iteration, everyone on the project comes together to see if they managed to deliver what they thought they’d deliver, and to understand what got in the way when they didn’t. This leads to continuous improvement, so the team is always getting better.
4. After each increment, the customer (or internal stakeholder) gets a demo, so they can tell you if what you’re delivering is what they really want, and if not, you can change the plan rather than deliver the wrong thing.

Analysis of our aggregated Whole-Mind Manager data, and the feedback we get on the assessment terminology, would suggest that Agile adoption is still very much siloed inside engineering. As a manager, regardless of your function, you’re hopefully now starting to see that Agile is a gift – addressing many of the challenges you face in building a high-performing team.