Software Development: IJYI
I smiled when the subject of this issue was announced as “Agile”. It’s a principle we’ve built IJYI on, both in the way we operate and how we deliver software. Agile is a software delivery methodology dating back to a famous meeting in 2001, when 17 developers discussed lightweight development methods. They left that meeting with the ‘Agile Manifesto’ – a set of values that shape how many modern development teams work together.
My favourite part of this manifesto is the statement “Responding to change over following a plan”. It acknowledges that software is a tricky and complex thing to develop, and that new features, problems, dependencies and ideas will come to light as that process takes place. It’s almost impossible to plan for all eventualities. So although there’s value in having a plan, you have also to accept that change will happen. Accept and even embrace change. Be Agile.
This is apt given what’s happened to businesses over recent months. Directors in most organisations would have had various degrees of planning in place, such as working from home policies, business continuity and disaster recovery plans. Some may have even had planning in place for country-wide or even global disruption. But how many businesses had planned for something of this scale? I know many IT departments that were scrambling to get infrastructure in place to support home working, assigning laptops and licences to ensure that staff could remain productive. And do you know what?
From what I’ve seen, in most cases, people adapted. Employees adopted new ways of working through new tooling (honourable mention to Microsoft Teams and Zoom!) and achieved rollouts in record time. People were Agile and deserved credit for being so responsive.
I like to describe the way we build software to ordering a sandwich at Subway. The person making your lunch (known as a sandwich artist) needs to know the big picture – namely the size (footlong or 6-inch), your choice of bread and the major fillings (i.e. Meatball marinara, melt, chicken and bacon etc…). You get total transparency as you can watch the sandwich take shape. You’ll be asked many questions (“cheese and toasted?”, “what salad?”, “any sauce?”, “would you like it cut in half?”) and if you see chillies added that you’d rather not have before an important client meeting, you can interrupt and make the change.
We build software with a customer “product owner” as a vital member of the team. We know the overall big picture, the risks, dependencies and other chunky requirements, and we run 2-week “sprints” where development takes place. At the end of each sprint, we’ll demo what’s been built so far. This is an opportunity for all stakeholders to see if things are developing the way they would like, tweak things where appropriate and help form the product as it takes shape. We’ve even had customers invite their customers to show them how a new feature is looking and build excitement for the next release! We often find that what customers thought was essential at the beginning of a delivery, is less important as they see something develop and new ideas start to flourish.
So have a plan; know the big picture and how it relates to what you’re doing, but be Agile, accepting and embracing change. You’ll end up with something far closer to what you need.