What does an agile software development team look like?
Many software development teams claim to be “agile”. These days it’s all the rage. But how can a business know if their software development team is in fact agile? And why is being agile so important?
At core, software engineers turn ideas into results. Of course we are not the only ones with this job description. We share it with many other creative professions. Writers, for example, turn ideas into words that inspire, educate and inform. That’s pretty much what we do too: we turn ideas into words that instruct a computer system to perform a desired behaviour.
Focusing on writers for a moment… there are a wide range of writing environments and styles. On one side of the spectrum are novelists who secret themselves away into a quiet room, where they can find the time and space to breathe life into their intricate vision. On the other are journalists on the newsroom floor, sampling from an avalanche of information, responding quickly to what’s new and what’s important.
At Pivotal Labs, we work with many fast-moving companies, helping them to fashion the software engineering capability they need to succeed. Our approach is to create an environment that resembles a newsroom more than a writer’s hide away. This is what we mean when we say “#8220;agile”.
This newsroom style is the key to success within a business that is constantly buffeted by a changing environment, leaping to seize new opportunities, and reacting to the actions of competitors. Like journalists, our objective must be to deliver each new story – each requested systems change – with speed and craftsmanship. This is what we mean when we say that we strive to be agile.
When non-developers come over to where we work they are often surprised. We don’t conform to the movie image of a coder: the young man surrounded by screens of mysterious symbols, clad in headphones, fingers flying across the keyboard. Of course there are coders who work that way. In fact, many software engineers enjoy this kind of novelist-style coding in our non-work time. But this type of isolation is problematic within a company.
What you’ll find is people conversing – listening and talking. We are talking through ideas, debating approaches and double-checking our results. We do this at every level: each line of code involves conversation, as does each software feature, as does each longer-term objective.
Why are we talking so much?
Our first challenge is to make sure we are always working on the top priority; anything else is wasteful. We avoid spending months or even weeks working on the software equivalent of a novel. Instead we break our work down into discrete units that we can complete in a day or two at most. This increases our responsiveness by creating opportunities for us to realign with shifting priorities. Like journalists in the newsroom, this practice enables us to embrace new ideas and shifting priorities.
Our second challenge is quality. The instructions we write, the behaviour we define, the software we create sits at the core of the business. If the system breaks, the business screeches to a halt. If it misses the mark then the business misfires. So we put considerable effort into checking and re-checking everything we write. We do this checking continuously by working in pairs, and automatically using a continuous integration server. Quality is a team responsibility, so we broadcast the results on a build monitor (the green/red screens you’ll see above our desks) so that we all know when there is a problem. We aim for quality at every moment so that changing direction in response to new ideas does not undermine the total quality of our systems.
Our third challenge is efficiency. As we grow the system, we introduce complexity that can make change more difficult. But with vigilance we can keep this sclerosis in check. We are always on the lookout for more efficient ways of operating. We are always refactoring the code: reorganising it for clarity, simplicity and flexibility. We also invest our time in automation, letting the computers perform tasks we know we’ll have to repeat. This might slow us down a bit in the short term but has significant pay off over the long term.
Helping us to bring all of this together is our product owner (aka product manager). Similar to a newsroom editor, they scan the horizon for new priorities. They sort through new ideas to define our daily agenda. It is their job to ensure that the needs and concerns of the larger organisation are present in our conversation.
Working on a software engineering team in a fast-moving business is exhilarating and challenging. There is a buzz of conversation in the room. The team shares the pride of creating a system that is ready for whatever turn the business may take. And the team embraces each new idea, each changing priority, as an opportunity to deliver results.
This is what an agile software development team looks like.
About the Author
