As a software company, we’ve naturally integrated some Agile practices, though we’re not religious about it. More importantly, we extend its principles through our entire working process. At this stage, other developers are probably thinking ‘Obviously. We do too.’ While non-developers are thinking ‘What are they talking about?’ and ‘I must stop reading at once and find something better to do.’ If you’re in the second category, give us 5 minutes, and we’ll not only give you a quick and dirty explanation of how we’ve made some of the core tenets of Agile work for us, we’ll also tell you why we love them, and why you might want to implement them in your own organisation too.
Agile in a nutshell
Agile practices were specifically designed to help development and software companies cope with the vast amounts of quick-turnaround/high-quality work that are their bread and butter. Agile allows large groups of people, often working remotely, to plan and deliver high quality work, within a set time frame (which is pretty much what any company wants to do). The essential elements include:
- Continuous progress on iterative development — during each ‘sprint’ (explained below), significant steps are taken, which contribute to the greater whole.
- Self organising and cross functional teams — each team undertakes to deliver a certain amount of work by the deadline, so that other teams will not be delayed.
- Flexible working environments — within the confines of the deadline, individuals can choose when and where to work, for maximum personal autonomy.
- Online communication and collaboration tools — teams can share information and discuss issues in real time with a host of online tools such as Skype, Slack, Google docs, and Trello.
- High quality final product — quality control is maintained through predetermined criteria that ascertain whether a product is ready to go, or goes back to the drawing board.
There is a plethora of literature about the technicalities of Agile (which make for very informative reading when you have a couple of hours), but for this article, we’ll focus on the sprint.
What’s a ‘sprint’?
First, it is not getting your whole team out to perform track exercises during lunchtime. However, it is to do with quick, high-impact performance. Think of a sprint as a To Do list tailored to each team, with a set amount of time in which to complete all the tasks (usually 2 weeks to a month), and a set of criteria for evaluating the work. A typical sprint looks like this:
- Team meeting where the product owner (the person requesting the work), and the developer (the person/team producing the work) get together to plan the sprint. The developer always has the final say on how much work gets put into the sprint (this makes sense, as they’re most likely to know how much time things realistically take). The product owner has final say on what criteria will be used to judge the work.
- The duration of the sprint is agreed upon (we generally run weekly Tuesday — Tuesday sprints, for reasons we’ll explain below).
- When work begins, the developer team holds daily standup meetings. These are usually 15 minute get-togethers to cover progress, plan the work for the day, and identify blockers for problem solving.
- During the standups, the product owner generally minimises his or her involvement, except to answer questions. The idea is to let the people doing the work get on with the work, with minimal interference.
- At the end of the sprint period, the team leaders will present the work. The product owner will then use the predetermined criteria to accept, or reject the work. Work that is rejected will likely form part of the next sprint.
- Rinse and repeat.
Sprints give organisations a defined system within which work gets planned, done, and signed off, all in the requisite time. And here’s why we love them.
Sprints are less stressful than weekly work plans
Monday mornings are horrible times to run meetings — they inevitably force Sunday evening planning, which makes everyone miserable. Friday afternoons are lovely times, but not for meetings. That’s why we like to run weekly Tuesday — Tuesday sprints. This allows people a working day to finish last week’s sprint, and prepare for the next one. By the time we meet on Tuesday morning, everyone is ready to bring their A game. We see this as working around basic human nature, and setting our teams up for optimum efficiency.
Sprints break up humongous tasks into realistic achievables
Human beings have a tendency to become overwhelmed with giant projects. The very thought makes us cringe, and want to cuddle into something warm and bed-like. That’s why many motivational coaches counsel people undertaking big projects to start small. It’s the same principle for sprints. While the big overarching project is unlikely to get done in a week, you can break down its composite parts into manageable weekly sprints. Week after week, as each sprint is completed, more and more of the overall project starts taking shape, without anyone being overwhelmed by a Herculean task.
Sprints force you to prioritise
Everyone always wants everything done now. But regardless of how many superhumans you’ve got on the job, there are only so many hours in each day (and week). Sprint planning forces you to choose the most pressing tasks to deal with. If a task can’t be broken up into a manageable sprint size, it might mean that you haven’t done enough problem solving to really untangle the issue. And because the contents of the sprint are agreed to by the developers, you should never end up with an ‘everything but the kitchen sink’ scenario.
Sprints create real accountability
During sprint, each team undertakes to complete a certain number of tasks, with one team’s work impacting the work of others’. So, if there’s a delay somewhere along the process, it’s very easy to spot where the blockage occurred. This means there’s transparency in the workflow, and everyone can be held accountable.
Sprints highlight weaknesses in your work chain
There are only 3 types of issues: poor problems, poor managers, or poor team members. Sprints help with all 3. Breaking an issue up into bite-size chunks solves the first problem. If an issue can’t be broken up into manageable sprint-able chunks, it might be because you have the second problem. Perhaps your managers aren’t giving clear enough instructions, or don’t have a good enough grasp of the overarching problem to decide what the next step should be. If a problem is already in manageable chunks, but the work still isn’t being completed, then you might be looking at a problem with a member of the team, which might require training, coaching, or more drastic options. Wherever the bottleneck appears, you’ll have a good idea of where you need to focus some TLC in your organisation.
Sprints let you celebrate the small wins
While a big project could take months, if not years to complete, your team is human, and needs regular encouragement. Sprints give teams a constant sense of accomplishment, as at the end of the week, measurable results are seen and recorded. You should never underestimate the importance of these ‘small wins’, as purpose and a sense of contribution have been shown to be equally, if not more important, than money in giving people job satisfaction.
We promised you an informative 5 minutes, didn’t we? So, now that you have a basic understanding of Agile sprints, and why we love them, maybe you’ll want to adopt the practice yourself. And if you found this article helpful, why not check out some of our others? Like our tips for how to contract like a lawyer.