15 July 2015
Building software is something that your business needs to do well. You see more revenue moving through digital channels and you’re starting to realise that this trend will continue. Your company’s ability to remain competitive hinges on your use of technology. This same technology gives new competitors the ability to springboard their businesses and scale quickly. Your business needs to have software development as a core competency.
There is a proliferation of people, books and frameworks telling you how to manage your software teams, but it is hard to figure out what is really important. There are consultants knocking on your door trying to sell you Scaled Agile This and Distributed Agile That. I’m going to help you cut through the noise and focus on what being agile really means. I’m going to show you four attributes that will allow you to build a software capability that can respond quickly to a rapidly changing market.
The concept of agility relates to how quickly you can react to your environment. Pause for a moment and think about whether you care about feedback. Do you want to understand your customers and adapt your product or service accordingly?
The most important feedback you can get about software is from the people who use it. Get feedback from your customer. Get it early and often. There are a number of Experience Design techniques you can use to do this. If your decisions are being driven by something other than what your customers want, you’re responding to the wrong things.
Building the right feedback loops will help you to understand your environment. There are qualitative metrics such as asking customers ‘do you like this?’ There are also quantitative metrics you can put in place. These can help you answer questions like ‘is this profitable?’ and ‘how many people are using this?’
Once you have feedback about your customers and market, you must be able to do something about it. We sometimes forget that software is built by people. You need the right team with the right support.
In order for your software team to produce features rapidly, they need to use practices that allow them to pivot quickly as you discover things about what your customers want. It doesn’t matter whether they’re practicing Scrum or Kanban or XP. As long as they can react quickly to feedback and turn that into working software, you’ll be happy.
The people who build your software need to work together closely. Fragmented teams build fragmented software. (Have you heard of Conway’s law?) Work closely with the team so they understand your goals. Work closely with your customer so your team builds something your customers actually want.
Your team needs to be empowered. You and your organisation need to be helping, not hindering. Outdated change control and architectural structures slow teams down.
The bottom line is that your code should be an asset to your business when you want to seize opportunities. It should speed you up, not slow you down. We’ve been talking a lot about important activities that surround software development, but we have to remember that computer programming lies at the heart of this all. A focus on good design, testing and deployment practices is crucial to building code that is on your side.
You need confidence—confidence that your software is not being put at risk by new work, confidence that your customer’s experience (and your reputation) will remain intact. The way to achieve this is through automated testing. (Find out about Test Driven Development.)
Your code needs to be easy to work with to allow new features to be added rapidly. Your team should have a good eye for what a responsive code base looks like and be able to continuously keep the code maintainable as it grows.
Releasing your software needs to simple and reliable. Nothing your team builds has any value until it is in production. The way to achieve this is through automation. Automating the deployment of your application and the configuration of your infrastructure will prevent your infrastructure from becoming mysterious and unpredictable.
There’s no point in having a responsive team and code base if you’re using that capability to build the wrong things. Use the feedback you’re gathering to make informed decisions and take the right features to market first.
It’s like cleaning your house. Imagine you’ve just gotten a phone call that some guests are coming over in half an hour. You look around. The house is a mess. The bed’s unmade, there are unwashed dishes in the sink. The floor needs a good vacuum and there are socks lying on the living room couch. You’re facing the same problem that software teams around the world face all the time: no matter how much there is to do, you can’t create more time. Do the most important things first. People are definitely going to need to sit on the couch and picking up socks doesn’t take long, so do that first. Your guests will not be impressed by unwashed dishes, so get started on that and wash as much as you can before they arrive. If you happen to break your dishwashing personal best, you can give the lounge a quick sweep. You should be going through this prioritisation exercise continuously with the features you want to build.
You have a team and a code base that is equipped to react to feedback. You have the right feedback loops to find out what’s important to the success of your product or service. The last piece of the puzzle is making sure you’re using that feedback to decide what the right thing is to build next.
Note: this blog post was previously published on ThoughtWorks’ Insights blog.