Stand-ups, sprints and post-it notes: The world of agile development
Former technical project manager, BBC Academy
At 9.15am our phones and laptops start to buzz and chime. We stand up with the uniformity of a synchronised swimming team and gather around an ominous looking wall covered in sticky notes.
For many technology teams this will sound familiar. For everyone else, this is how modern development teams communicate - not through email or reports but by reviewing a wall of sticky notes containing the actions and objectives a team has to work through. We call this get-together the daily ‘stand-up’ and the wall our ‘sprint board’, a sprint being a fixed length of time, say two weeks, during which a team will work together to progress the project aims.
The method enables teams to monitor progress towards hitting milestones, reviewing progressing and taking stock of what they’re trying to achieve. These might sound like obvious points for any project team to be tracking but the post mortem after many a failed project is traced back to one of these areas.
‘Sprint’ is fairly self-explanatory, but it’s part of a bigger idea: ‘agile development’. So what’s that all about?
Well, the agile approach is a set of principles which prioritises traits such as flexibility and responsiveness to customer needs. These and ten other principles form the agile manifesto, which was established as an alternative to more traditional software development methodologies. Agile sparked a new approach to delivering software that made start-ups like Facebook, Twitter and Instagram possible.
I think there’s enormous opportunity for teams outside of the world of technology development to apply and benefit from agile principles. What aspects of agile could be used to develop a new concept for a reality TV show? Or the script for the next episode of EastEnders? What about agile in the newsroom? What if you started to apply the principles to personal goals such as hunting for your next job?
But back to our morning stand-up. In turn, we each refer to the sticky notes on the wall and give our update using a format that we rarely deviate from. Each person shares with the team what they did the previous day, what they plan to do today and whether they see any obstacles to achieving their goal.
Some agile teams will have dedicated roles like a ‘scrum master’ - a term inspired from the world of rugby, signifying a team working together to move forward. The primary purpose of the scrum master is to ensure that nothing prevents the team from making progress. In other lines of work, you might call them a fixer: they will go to the ends of the earth to ensure the team has what it needs to make progress. There’s no question as to the value they’ve brought to the projects I’ve worked on.
The modern approach to delivering technology has given rise to new tools and services which try to move us away from our addiction to email. Commercial tools like Atlassian’s JIRA are commonplace amongst agile technology teams as they provide features which support the agile principles - such as a digital sprint board, one place to store all your attachments, bugs and conversations about the features being worked on.
Digital sticky notes allow you and other team members to add updates which are visible to the whole team. This is a level of transparency and access that email was never designed for, and that’s why email has no place in a modern development team.
As a result, team communication is improved and visibility of progress and problems are immediately surfaced: sprint boards have a column labelled ‘Blocked’ to represent the items that can’t be progressed. If problems are made highly visible, they aren’t forgotten and can’t be ignored. Solutions are invited from the team, because a problem shared is a problem halved.
Next time you’re in a bookshop, pick up any management book from the last few years and it will inevitably tell you that meetings are toxic to your team’s productivity.
The agile approach rejects the idea of regular formal meetings where detailed agendas are set and minutes are taken. Instead, the agile principle encourages informal, impromptu discussions as and when they are needed to minimise overhead and to allow teams to progress without unnecessary delay. This makes sense when you’re on a tight schedule and can’t wait for a 30-minute slot in someone’s calendar to become available.
We use to-do lists in our everyday lives, whether for the weekly grocery shop or daily errands. This same concept is applied in agile where your entire project becomes one big to-do list called the ‘product backlog’. Each item on the list is represented as a sticky note on the sprint board. We pick them off one at a time, sprint-by-sprint until they’re all done. This allows the team to tackle a small chunk of functionality and focus entirely on completing it before moving on to the next one.
The backlog is prioritised and re-prioritised regularly by the team. That way, the most important items and those that it makes sense to tackle first are given priority.
Unlike other methods of delivering technology, agile allows teams to self-organise and adjust their plans on the fly without huge overhead like updating and agreeing project plans. This increased flexibility is one of the powerful features of being agile: you don’t have to stubbornly execute a plan that can’t adapt to a changing environment and that a team collectively doesn’t agree with.
Successful agile teams I’ve worked with involve their customer in the process right from the start by giving them the title ‘product owner’. The product owner represents the end users of the technology and they help the development team to understand what features are important, providing critical feedback and clarification. Referring back to our communication principles, again we do this in an informal manner and capture the results in our collaboration tool.
A slightly more formal session, often called a ‘show and tell’ or ‘demo day’, is arranged at the end of a sprint cycle. This is a chance to collectively review the work that has been done so far by demonstrating the output from the team. It’s a further opportunity for the product owner and other stakeholders to provide input and feedback to the team.
All of this feedback is captured and reviewed before the team collectively decides which features to take forward - and where they belong in the product backlog. In practice, it doesn’t necessarily mean that every new feature or suggestion gets implemented but it is captured for consideration.
So what have I learned?
Your best chance of succeeding in using agile is if you understand the principles before attempting to implement the methods. With so many possible methods and approaches, making a choice informed by your understanding of agile principles will significantly increase your chances of success.
Problems are infinitely more manageable when they can be surfaced and discussed in the open. Gone are the days where a project manager has to shoulder the weight of the world. Not all problems will go away, but rather than allow them to linger, the agile approach encourages the team to decide the best course of action. When problems hit a dead-end, the team can collectively come to a decision on next steps and move on without further delay.
Whether you call your next project agile or not, I believe there’s a huge amount of value to be gained from getting into the mind-set without getting caught up with the buzzwords. If you try to apply the principles as though there’s only one way to be agile, ironically, that can mean becoming less agile because you’re simply following a process. Agile isn’t the silver bullet for all projects, but it’s established itself strongly as a set of principles to guide how we work.