Agile: Just a way to write code?

Agile is a bit of a buzz word in software development these days and is often used without a full understanding of what it means. I think of agile as an end-to-end software development process that minimises wasted effort by getting customer feedback as often as possible, but agile methodologies can also be applied in day-to-day business as much as software development. When used properly, agile helps you achieve your goals quickly and efficiently. 

Making tough choices

To deliver new software or changes to an existing system, your agile process needs to consider the entire release pipeline. There is always more going in than can come out the other end, so prioritisation is key. Some things are more important than others. No software will be 100% bug-free and there is not enough time to build every feature or meet all aspirations of your software architect. You must make tough choices to ensure the high-value items get done. 

Good issue tracking software such as JIRA or Visual Studio Team Services is needed. Each request can then be captured and the prioritised items will form what is referred to as the "product backlog". Each item captures enough detail to enable any member of the development team to understand what needs to be built. If further information is needed, the product owner (a person responsible for shaping the product requirements) is consulted and the customer involved if needed. It is important that additional information is captured against the item in the tracking software.

Sizing with planning poker

The development team must review the top items on the backlog, and assign a high-level estimate in "story points" to each one. They do this by playing "planning poker", with each developer holding a set of playing cards containing values 0, .5, 1, 2, 3, 5, 8, 13, 20, 40, 100, "?" and ∞. After discussing each item, they each reveal their story point estimate, with the consensus being assigned to the item. Story points are not time-related but are a measure relating to size and complexity only.

Breaking down to manageable chunks

Development work to build and test each issue is carried out in iterations of a fixed length. I like 1-week iterations, as the team remains focussed on frequent small deliveries, but the length will vary from team to team. 37Signals, the team behind Basecamp.com, operate 6-week iterations and Jason Fried, their founder, has written a very good article discussing this.

With the most important items on the backlog sized, the team must try to commit to delivering a suitable number of them within an iteration. By monitoring the committed story points versus those delivered (in each iteration), the team can learn and commit more accurately over time.

Before coding can begin the team must break down each request into a series of small steps or sub-tasks. I advocate each sub-task should amount to either 30 mins, 1 hr, 2 hrs or 4 hrs of work. This time estimate is recorded against each sub-task in the tracking software and coding can begin.

As each sub-task is a small item of work with a time estimate assigned, progress occurs at a predictable rate. In an environment where developers are crafting complex code solutions, this level of breakdown is essential for realistic targets. Without this, it is very easy for developers to get lost down a rabbit hole of code and burn many hours for little value. Throughout the coding process, each sub-task is updated with the amount of work remaining until it is done. 

Tracking progress transparently  

A key element of the tracking software is the ability to observe the team's progress during an iteration, visually on a Kanban board. 

From left to right, my board would show columns named "to-do", "in progress" and "done". Work items and sub-tasks are shown on the board as tiles. At the start of an iteration, all sub-tasks are on the left in the "to-do" column. As developers start work on a sub-task, they drag the tile representing it, right, to the "in progress" column. Once done, they drag the tile right again, to the "done" column. This Kanban board is a valuable, transparent way for all involved to see progress being made towards the goal - having all tiles in the "done" column at the end of an iteration.

A burndown chart (a graph plotting time remaining and time spent) helps to track progress against the iteration goal. In a perfect burndown chart, 100 hours of work estimated for a 5-day iteration requires the team to complete 20 hours each day. Work remaining should fall to 0 and time spent should increase to 100 over the week with the burndown chart enabling the team to see quickly if they are on track. If the team is ahead of schedule they may pull more work into the iteration; if they are behind they may de-scope certain items or sub-tasks to ensure the key things are delivered in time.

Feeding back into the process

At the end of the iteration, the team must review what went well and what they want to improve on next time, in a retrospective meeting. I also like to see a demo or even an actual delivery of the software being worked on. This is most likely to be given to the product owner or customer to test, so the team can quickly gain real-world feedback. Any changes requested will then be prioritised alongside those already waiting in the product backlog, and so the cycle begins again.

Keeping it lightweight

It is important to concentrate on keeping the overhead of the agile process to a suitable level. The process forces up front consideration before coding, but you don't want the team spending too long, as can happen if they prepare too many items for an iteration, or don't keep their eyes on the prize (of finishing all work in the iteration). I find it useful to impose a “time-box” to the preparation so that I know by a given time each iteration, coding will have started.

There is lots more that I could write about agile. I haven't even covered stand-up meetings, but I have found that an agile process like this works well and allows the development team to get into a rhythm that makes them feel good. I wouldn't advocate building software any other way! 

I’m keen to discover your views and experiences with agile, and what you think an agile software process should look like. Feel free to add your comments or drop me a private message. Thanks for reading!