Moving Gradually to Agile Development and Scrum

Stage 3: Improve Team Collaboration and Software Quality

The team now knows what high priority business requirements they should work on and the pressure of meeting an unrealistic project plan; which doesn’t accommodate for unforeseen issues and changing requirements, has been removed. They should already be feeling happier – so now is the time to get them working together more closely to help improve productivity.

Ideally the team should already be co-located, including Business Analysts, Testers and Developers. It is now time to introduce the ‘daily stand-up’, and the sprint retrospective to enable the team to talk about what they did well and where they can improve.

In the first stage, developers started committing to their own estimated tasks at the beginning of each sprint. Once that is working well, you can enable team members to select their own tasks from the planning board during the sprint. At the beginning of a sprint, rather than committing to individual tasks, they will be committing as a team to complete all of the user stories, which encourages self-management. The developers should help each other solve issues and collaborate on the best approach for design using pair programming where it makes sense.

Not only must the developers communicate more with each other, but the communication must spread to the Testers and Business Analysts as well. This is the only way we can define what should be built and tested.

When I first started coaching one team, someone told me that he felt like software testing was like going into an exam where they had no idea what to study since they weren’t sure what would be covered. This was because testers were ‘being creative’ and coming up with ‘new and crazy’ scenarios to test. There were so many ‘defects’ that every few weeks there would be a long defect prioritization session. This type of defect prioritization should never be required.

Instead, everyone should be very clear before development begins what will be tested so that the developers can write code that meets the requirements and defects are therefore minimized.

If the goal is high quality software or zero defects by the end of the release. The only way to accomplish this is to ensure that defects raised are ‘real defects’ i.e. there is a business requirement (or acceptance test) that is not currently being met. To ensure defects are ‘real’, testers must communicate regularly with the testers and developers. If in doubt, BEFORE raising a defect the tester must clarify that the issue they are raising really is a defect. If it is a new feature, it is instead added to the product backlog.

Scrum features introduced at this stage

The team now takes part in a daily standup for fifteen minutes or less at the same time every day. They are sharing tasks and becoming more cross-functional, working together to identify how they can improve through the introduction of sprint retrospectives.

The team is using acceptance tests to more clearly state the ‘definition of done’ so that both developers and testers know exactly what is expected. Software can be released to testing throughout the sprint rather than at the end of the sprint and defects should always be given top priority over new features.

Issues overcome at this stage

At this stage the team must overcome people issues. I’ve worked with teams where there were team members that either did not have the skills or the personality to work on a Scrum team. If they don’t have the skills, that is apparent very early on because they are not able to deliver the software within the sprint. Issues with personality I’ve seen include failure to communicate with the testers and business analysts due to the need to work independently. That doesn’t work with Scrum.

I have worked with a team that didn’t have any Business Analysts – just a Product Owner who was not available the majority of the time. In this case, we attempted to have the testers and developers write acceptance tests together at the beginning of a sprint. This was very difficult and productivity improved dramatically when Business Analysts were added to the team.

Benefits gained at this stage

Developers, testers and business analysts are all working towards the sam objectives in each sprint which will enable you to reach the goal of zero defects at the end of each release (and hopefully each sprint). This high-quality software will be provided more quickly due to increased team velocity due to sharing tasks and increased communication.