As an agency committed to Agile, we’ve noticed that some of the demands of Agile working – conversation, sharing, collaboration – seem to run counter to the preferences that many developers would have for their work environment. They like it to be quiet. They want it to be free of interruptions. They want to be able to concentrate. That’s not just our experience here at Siteset, but our observation of many dev teams in organisations we’ve worked in or dealt with. We, who are not developers, would say that developers themselves are often that way inclined as personalities. But we were interested in exploring the question of how it feels to work Agile when one’s preference as a developer might be to work in silence and alone?
We gathered together our dev team to explore this seeming conflict of styles to see what challenges, if any, Agile places upon them and the way they might like to work, and what the benefits and advantages of Agile working are for developers.
Before we got into the meat of the question, the first casualty of the discussion was any idea of a ‘typical developer’. Siteset’s dev team were strongly of the view that developers vary hugely in type. They argued, convincingly, that one of the reasons the ‘quiet developer’ stereotype arises is as a by-product of what the job needs. To be productive, a developer who’s deep in trying to fathom code development or fixes must have an uninterrupted environment allowing for profound concentration. One of the senior guys in the discussion pointed to a pile of post-it note blocks on the table and explained it this way: “I’m down at level 6 in this pile of a dozen note blocks. I’m in the zone. It’s taken me ages to get there. Interrupt me, and you drag me back to the top. Then I have to remember the path I took to get down to level 6 all over again.” All that said, compared with others in the company, the development team is unquestionably the quiet end of the room, but to be fair, we also hear them having lively discussion, banter and laughter. It’s all about context.
Bringing the conversation around to the question at hand, the dev team began by looking back to the past, to a time when waterfall development was the way of working, or as one of our team put it, “going off for a few uninterrupted weeks to work on something”. But all the dev team agreed that, appealing as that way of working is to someone who believes themselves to be most productive away from it all, it just isn’t feasible. No developer can be an island; they must work as part of a closely connected team. They all know the wider downsides of working waterfall and the upsides of working Agile, seen from a commercial and usability perspective. Also, they said, live issues need to be addressed and they have to be able to drop tasks and deal with those.
What aspects of Agile did the team find challenging?
First, the ‘hiding away in the developer cave’ thing. “Though the thought of isolating oneself to work solo is appealing, it isn’t Agile,” they agreed. “It [working solo away from others] feels more comfortable in the short term,” they said, “but we have realised we achieve more as a team working Agile.”
They did acknowledge that Agile takes them out of their comfort zone. They said that a typical developer, as far as that notion is true, is more comfortable with machines, with email or messaging rather than conversation. They are usually not forceful but contribute reflectively and thoughtfully. The good thing about Agile is that successful collaboration can take this quiet form – being a productive team doesn’t mean an extrovert discussion with participants vying for air time and loud debate. The main challenge that we have noticed at Siteset though is that without an extrovert to start the conversation, silence can often fall without anyone wishing to be the first to throw their hat in the ring. Then it is a case of motivating and chivvying the conversation along rather than it necessarily being free flowing.
They found the fast-changing nature of Agile challenging. With two-week sprints and regular updates, Agile means that a developer has to become accustomed to change. “Agile is different because it is about change. Change is difficult,” said one mid-level developer. “But you get used to it.”
The need to work collaboratively, not just with dev colleagues but those in other teams, is also demanding: “There is more noise, more interruption and more distraction working collaboratively,” one said. “But we have found ways to minimise interruptions,” said another, meaning that ‘headphones in’ is the ‘do not interrupt’ sign around here.
What did our dev team agree on about Agile?
In essence, they all agreed that Agile brings a level of collaboration which is beneficial to each of them and builds great team relationships, as well as getting the work done well and giving clients a fair and predictable way of structuring the workflow.
They saw major benefits in Agile, because of the collaborative nature of it, such as in the stand ups. Agile enables problems, difficulties and challenges to be shared and worked on; progress and achievement to be recognised; and good forecasting and planning to be done. “It’s easier to get the work done if we communicate,” said one. “It takes some getting used to, but once you see the benefits, it gets much easier,” said another. One of the younger developers said that he soon realised that he had to think in advance about what he would contribute and how to express it. He’s seen that as a really positive development personally.
They also saw Agile as equitable: our team have been trained by our MD, Peter Sheppard, to run their Agile meetings in a way that encourages each developer to contribute so they feel they have a voice and are also supported by the rest of the dev team. “There is no controlling mind in our Agile forums but a genuine hive environment”, explained one of the long-standing developers. However, an interesting reflection that emerged during this part of the discussion was that when one of the product owners joins them in sessions, the dynamic changes: “We’re quieter with a PO there,” one said. “That change is understandable, given that we are a close team and the PO is ‘an outsider’ even though they’re a close colleague.”
One of the developers made the interesting point that Agile working methods support a developer-like environment, because Agile (or Scrum at least) is highly structured. But Agile also requires its participants to behave in particular ways, which are around working together in a team. Agile is an interesting conjunction of ways of working, they realised.
So the answer to the question we began with was an overall thumbs up for Agile, in the context of a commercially successful, productive and positive working environment.
Finally, if you’re a developer about to interview to work in an Agile agency, this is what our developers say is needed: you must be comfortable communicating; you must be willing and able to collaborate; and you must be a contributor not just a listener. And give it time: even though it doesn’t come easy to start with, you’ll see why it’s better in the end.