A growing number of Dialog’s clients are discovering the benefits of an Agile software development approach and the co-operative team dynamics supported by the Scrum management discipline that can deliver a win-win result for all stakeholders.
This paper will focus on how Dialog has implemented Agile to manage software development projects and touch on some of the lessons learned.
Agile is flexible
Agile software development delivers working software components in an iterative manner by “time-boxing” the development. It is adaptable, focused on delivering working software iteratively and it encourages client feedback and change to occur during the project. At the end of the project, the client has a system that supports its current business requirements, not necessarily the original business requirements. There are many specific agile development methods and most promote teamwork, collaboration, and process adaptability throughout the lifecycle of the project.
This is different to the traditional “waterfall” approach where the client has to document and approve all of their requirements before the various product development phases can occur (e.g. analysis, design, development, system testing, user acceptance testing, training and deployment phases) in a strict sequence. Projects where the requirements don’t change, such as those based upon legislature, are usually good waterfall candidates.
Scrum framework
Scrum provides a framework for managing the agile development processes and techniques. The term “scrum” comes from the idea of a rugby team made up of players supporting each other, working together to achieve a goal (i.e. getting the ball over the try line as many times as possible in a set period of time). In Agile software development, the team scores each time it completes an iteration successfully and delivers working software components to the client.
There are many books and internet sites that can be used to find out more about Agile and Scrum. There is no “right way” to implement Scrum; this paper describes how Dialog has implemented it successfully for a number of client projects.
The next sections provide the guidelines, Dialog uses in its Agile approach.
Sprint Planning
Agree on the length of the sprint (2 – 4 weeks). Any shorter duration and the team will be under too much pressure; any longer and you start to lose the tight client feedback loop and the ability to adapt to changes in requirements or priorities. It is best to keep all sprints the same length as this allows the team to set a “heartbeat” to enable consistent production of working software.
Work out the capacity of the team for the sprint based upon an agreed level of productive hours each day. Non-productive time allows for any administrative type work, code reviews, getting clarification from the client, etc. It is important to gauge the productivity of the team as early as possible but sometimes it can take 2 to 4 iterations. On some projects we have used productivity of 60% when first planning and then used the velocity once it stabilises. Make sure you make an allowance for rework from the previous sprint.
Review the client’s prioritised requirements (i.e. the product backlog items) with the client’s key representatives and estimate using Planning Poker Cards in two phases. First, estimate the complexity of each requirement and analyse the variances in team member perspectives. The aim is to ensure all team members understand the requirement and its complexity. Second, estimate the development hours for the requirement. Again, analyse the variances in the team in order to ensure that everyone has a common understanding. We estimate in development hours, not user stories or points. We have found it easier for developers to think this way. Using Planning Poker Cards ensures everybody participates and at the end, everybody commits to the estimates. The product backlog items that the team commits to become the sprint backlog items.
Do not over-analyse the requirements and do not break them down to tasks that are too granular. The fat that is naturally built into estimates by developers can quickly make your project look twice as big as it really is. It is also important that the requirements are only business requirements. Technical requirements must not be included at this stage as we want to ensure that the business can prioritise. They can’t do this when we add requirements such as ‘code must create log files, alerts must be raised in error situations’. There is a dilemma here – how then are the ‘technical’ requirements captured and prioritised? One approach is to appoint an IT ‘business’ owner for these types of requirements (e.g. someone from Application Support). The trick is then to educate the business on the importance of these tasks and to make some of them compulsory parts of the development approach.
Do not forget to estimate for testing as well (e.g. creation of test scripts, execution of test scripts, and any rework).
Only commit to what the whole team is capable of. If you over-commit, the team feels pressured and morale can take a beating if you do it for every sprint. It is better for the team to recognise that extra hours need to be worked than them being told that they will do it.
Daily Stand-Up
Even though the team is in the same location and talk openly each day, this is the key meeting where the project team members report on their progress and the issues that are holding them up.
Make sure the meeting starts at the same time each day and starts on time and that everybody is ready to contribute.
Make sure team members have updated the sprint backlog items with the latest remaining hours. If this is done in advance of the meeting, the scrum master can produce the Sprint Burn-down Chart which can then be discussed at the meeting. The team will then know exactly where they stand in terms of the planned sprint burn-down.
Use a “talking stick” to pass around so everybody knows who they should be listening to. We use a stress ball. It might feel silly for the first couple of stand-ups but you will quickly get used to it.
The three questions (What did I do yesterday? What will I do today? What issues do I have?) give all team members a structured way to contribute.
Do not try to solve issues in the meeting. Identify who is responsible and who can help and take the issue offline.
Sprint Review
Demonstrate the sprint deliverables to the client using business scenarios, or use cases, not technical jargon. They are interested in what the system does, not how you managed to get it to do it that way.
Tell the client what did not get completed.
Tell the client what issues or software bugs are still outstanding.
Sprint Retrospective
The project team should openly discuss what went well, what did not go well and what changes they will make in the next sprint in order to improve quality, productivity and morale.
Do not try to fix all things in the next sprint. Too much change can lead to confusion. However do try to aim for a team ethic of continuous improvement.
Tools to support Scrum
There are plenty of software tools that support scrum (e.g. VersionOne, ScrumWorks, Scrum for Team System, Excel spreadsheets). On our .NET projects we have used Microsoft Team Foundation Server (TFS) which has a scrum template. On Java projects we are using JIRA which supports agile development and scrum as well.
Even though we have software tools to track our sprint backlog items we also employ a big visual Task Board. The developers are responsible for ensuring it is up-to-date and it needs to be checked regularly by the Scrum Master. At Dialog we stand in front of the Task Board for our daily stand-up meetings.
We use coloured Post-It notes to group tasks within each backlog item so that it is visually easy to see the status of each item. All of a backlog item’s tasks need to be ready before they move into test as a single deliverable.
“Ready” means that all unit testing has successfully been passed by the developer and a peer code review has also passed.
“Done” means it’s ready to be demonstrated to the client and shipped to the client for user acceptance testing.
Lessons learned
The most important lessons learned are:
- Team dynamics are critical to achieving the productivity gains of agile and scrum. Once you have a team established and working smoothly together, try not to break it up.
- Agile software development is a discipline. It is not a buffet where you can pick and choose the techniques that you like and leave the harder stuff; you need a good balance. You cannot have the freedom of minimal documentation without having the accountability of code reviews; you cannot have the business co-located with you without having some kind of governance to manage any changes as well.
Dialog has been delivering high quality systems for its clients for over 30 years. Agile software development delivers working software components to the client quickly and is able to adapt to changing circumstances. Dialog has many experienced consultants who actively use agile techniques and the scrum approach to manage the development effort.
For more information contact dialogit@dialog.com.au
