Agile Software Development

What does it mean to be Agile?

There are a number of strategies and working practices available for Agile software development, I have included the process that works for me; this is based on my real life experiences working with stakeholders (more about these in a moment), developers and testers.

Scrum

What is Scrum? During a project the customers can change their minds about what they want and need (also called churn) these challenges cannot be addressed in a planned manner. Scrum uses a pragmatic approach, in most instances these problems cannot be fully understood therefore a focus on capitalising on the team's ability to delivery quickly and respond to emerging requirements.

Daily Scrum

A stand up meeting called a Daily Scrum takes place at precisely the same time every day - 10 am is a good time as the team members have had the time to know what they are doing by this point. If your team is distributed then use a video conferencing tool (e.g. Skype).

There are three roles in a Daily Scrum:

On the officials in the 2007 Tech-Texas game in Austin:

"It's a little like breakfast; you eat ham and eggs. As coaches and players, we're like the ham. You see, the chicken's involved but the pig's committed. We're like the pig, they're like the chicken. They're involved, but everything we have rides on this."

Pigs

The developers and testers play the part of Pigs, they have no longer than one minute to describe what they did since the last Daily Scrum, what they are doing today and what blockers they think they may have to do today's tasks.

If anyone has an questions or comments they should take place outside of the Daily Scrum.

Chickens

The stakeholders (customers) play the role of chickens - they can listen but not speak. If they have any questions they should go through the Scrum Master outside of the Daily Scrum meeting.

Scrum Master

The senior member of the software team usual a Team Leader will take the role of Scrum Master, they ensure the Daily Scrum starts on time and that everyone takes turns to speak. The Scrum Master can also be a Pig.

Sprint

Sprints are a part of the Scrum methodology.

Sprint planning meeting

A sprint cycle lasts for two weeks.

Select the work to be done

User Stories

The Scrum Master meets with all the Stakeholders in a single meeting to gather the user stories.

In order to process the user stories quickly cards should be used to write a short sentence that describes the functionality in the form:

As a [role] I want [requirement] so that [business need].

The Stakeholder writes the card and passes it back to the Scrum Master, only one card is completed at a time after being discussed with the other Stakeholders.

The number of User Stories gathered in the Sprint Planning Meeting will vary depending on the size of the team for a small team of four developers, ten User Stories would be a fair number.

Each User Story will have a number of scenarios written on the back; these will form the tests.

Story Points and Planning Poker

After the User Stories are gathered the Software Developers and Testers go through each User Story and assign it a number of Story Points.

The highest number is the most complex and time consuming, the lowest is the simplest and shortest: 0,1,2,3,5,8,13,20,100. 100 alerts you to the fact that you have an Epic Story which should be split in to multiple stories.

A game of Planner Poker should be played, this can be done with Planning Poker cards or if your team are distributed - this can be done over an IM - The Scrum Master asks everyone to get their numbers ready and all hit Enter at the same time.

The Scrum Master records the Story Points against each User Story, no more than 5 minutes should be spent on each User Story.

Prioritisation

The User Stories with Story Points should be reported to the Stakeholders in person, they then order the cards by relative priority.

Tasks and durations

The Scrum Master asks each of the Developers if they have any holiday booked for the next two weeks, this is subtracted from the number of hours in the Sprint.

A Sprint is always two weeks long, due to outside forces, answering emails, meetings, urgent issues (real life) I allow for six hours per day on a Sprint. So if a Developer is in then they are available for sixty hours for the two weeks. I recommend using Pair Programming so this will be the hours shared between your developers (i.e. sixty hours for two Developers).

Get the Developers and Testers together, take each User Story ordered by highest priority first, split in to Tasks i.e. Analysis, Design, Database schema changes, Development, Testing, Deployment. Speak directly to the individuals most likely to implement the User Story (Developers and Testers should work on a single User Story rather than a single Task), ask them to say how long they think the Tasks will take. The other Developers and Testers can verify this.

Create a table in a spreadsheet with sixty at the top and subtract the hours for each User Story from the Developers available hours, eventually this will get to less than zero, all User Stories in positive numbers will be what the team can commit to.

The Scrum Master meets with the Stakeholders and provides them with the list of User Stories that can be committed to in the two week Sprint.

Story board

A Story board is created for each Sprint, User Stories have a state during the Sprint:

Backlog > In progress > Code ready for review > Code reviewed > QA Ready > [QA Passed][QA Failed] > Deployed

There is another state called Waste, this is used for any duplicate or erroneous User Stories.

The Developers are encouraged to move their User Story to the next Sprint, this should be viewable by the Stakeholders, web based story boards are available this is useful for distributed teams.

Sprint review meeting

Once the two week Sprint is completed, the Developers and Testers meet with the Stakeholders to review the work that was completed and not completed. A demonstration of the completed work is shown to the Stakeholders. There should be a four hour limit to this meeting.

Any User Stories not completed in the Sprint go in to the Sprint Backlog.

Velocity

The number of Story Points completed in the Sprint gets recorded against the User Story, this becomes the velocity of the team.

After three Sprints the velocity will start to even out and give the Stakeholders an idea of the amount of work that can be done in a Sprint.

Charts

There are two charts I have found useful, the first is a Daily Burndown Chart, this is where the number of hours the Developers spent on the Sprint each day is recorded against the number of available hours.

The second is the Release Burndown Chart, this shows the estimated number of Story Points in the Sprint against the actual Story Points completed, this chart can be extended to also include the velocity.

Sprint retrospective

This meeting is attended by the Developers and Testers, all team members reflect on the past Sprint, make continuous process improvements , what went well and what can be improved, there should be a three hour limit to this meeting.

Extreme Programming (XP)

There are a number of XP elements, the one I find most useful is Pair programming. Software developers sit at a single Development workstation they take it in turns to be at the keyboard - known as the Driver, as a Developer types they describe what they are doing to the Observer. The Observer reviews the code as it is being typed, therefore code reviews do not need to be done after a task is completed and the quality of the code is far superior than if done on their own.

One common issue is one of swapping, if this does not feel natural then switching every thirty minutes is a good compromise. Other benefits include a lack of fatigue, knowledge sharing, a boost in morale, not skipping unit tests. New Developers can pick up the workings of the team quickly and people are less likely to interrupt a pair of programmers.

Other distractions can be email, one solution to this is to have a separate PC that individuals can use to read their email.

Summary

By employing these Agile Software Development methods my team are able to work in a more efficient way, there is little or no context switching between tasks, the quality of work has improved and the implementation matches the requirements closely. The Stakeholders feel engaged with the development process and see results more frequently than through the waterfall model.