In this six-part blog series, Shirley provides practical advice on adopting Agile Development methodologies.
Agile Development is a software development methodology based on incremental, data-driven development, where requirements and implementations evolve through collaborative, self-organizing, cross-functional teams. Agile Development promotes product delivery as a time-boxed series of functional and potentially shippable product increments that enables teams to rapidly respond and adapt to change.
Part IV – The Big Picture
As you continue to adapt to the Agile process and focus the team on getting stories and tasks to ‘Done’, it’s equally important look at the ‘big picture’. This will help identify issues early (possibly even before the team knows themselves) and help you to steer the sprint and the team to success.
Swarming
Once Sprint Planning and Task Breakdown are completed and the post-its are on the Scrum board, it’s time to start the Sprint.
In my experience, Engineers want to work on the ‘next new thing’ and a fresh Scrum Board full of untouched stories can look like fertile ground. This is where you need to follow some simple rules:
-
Swarm. Encourage the team to assign as many developers, designers and QA to each story as is reasonable (based on how well the work can be parallelized).
-
Put stories on the board in priority order and make sure your team knows to open stories top down – not cherry pick their ‘favorite’ stories.
-
Never open more stories than you have developers on the team. In fact, encourage the team to allocate at least 2 developers per story so that they can collaborate, pair program and solve problems together to expedite story completion.
Sprint Health
Since the goal of a Sprint is to deliver a potentially-shippable product increment, it’s important that stories are completed prior to the Sprint Review.
An early indicator of the wellbeing of a sprint is how the Scrum Board looks overall. While it’s important to track the progress of each story, it’s equally important to take a moment every day to step back and look at the board in its entirety.
A healthy sprint will show some subset of stories Done (or on their way to Done), some that are In Progress and others that are not yet open. Since the progress should reflect the priority of the stories, the general trend should be in the form of a diagonal line across the board (see Fig 1). An unhealthy sprint will have all (or the bulk) of the stories open and in a partially complete state (see Fig 2)
Entering the final week of a sprint with too many stories open will necessarily prevent the team from getting to ‘Done’. It will lead to QA or code debt being carried forward to a future sprint and will impact the team’s ability to take on new stories.
Closely manage the team’s opening of stories. If your scrum board begins to look like Fig 2, pull the team together immediately and strategize on ways to get back on track. These could include backing out committed code (that cannot be QAed prior to the end of the Sprint), halting progress on lower priority stories and/or seeking assistance from another Agile team.
Fig 1: Healthy Sprint Scrum Board (diagonal line indicates overall progress)
Fig 2: Unhealthy Sprint Scrum Board (vertical line indicates too many open stories)
Continuous Integration and Unit Testing
It’s never too early to start investing in unit testing. Identifying and fixing bugs at the most fundamental (unit) level will pay huge dividends in overall product quality. ‘Building it right the first time’ (with unit tests) will enable your teams to focus their creative energy on delivering new features, not fixing old code. In a nutshell, they will be able to constantly take on new challenges and have more fun.
Of course, it’s unlikely that you (or any company) can afford to stop all development to go back and write unit tests for their existing code base. Instead, make a commitment that 100% of new and modified code will have unit tests and make it part of your process.
First, choose one or more unit testing frameworks (e.g. JUnit, PHPUnit, xUnit) depending on your code base. Create and prioritize one or more ‘developer’ stories (As a developer, I would like to…) to deliver a working framework and a set of illustrative unit tests that can be used as a reference by other developers. Work with your team to identify two developers to lead the unit testing effort (ideally, they will have a passion for or experience with test driven development) and time box the first deliverables to a single sprint. Ask the developers to pair program the framework and the initial tests. Like feature development, this approach will yield a higher quality result and will uncover issues that may be overlooked by a single developer. It will also create the inertia needed to get things off the ground.
Have the Unit Test leads host a brownbag to walk peer developers through unit testing (why, how and when) and review the framework and existing tests.
Add a column to your scrum board between ‘In Progress’ and ‘Ready for QA’ that is ‘Unit Test Dev”. Tasks should not move to QA until the associated unit tests have been written or modified to reflect the new functionality.
Note: Keep a close eye on unit tests that are commented out or disabled. If a unit test breaks when code is committed, it’s a pretty good sign that the check-in has broken something fundamental. Developers must modify the code and/or the unit test until the unit tests run successfully – and not be allowed to disable failing tests.
Continuous Integration (CI)
Building unit tests without a continuous integration (CI) tool will likely cause your unit testing investments to fail. Establishing a CI tool that runs every unit test against (at least daily) builds will reinforce the value of the investment and avoid unit test atrophy.
Select and implement a CI tool ( popular tools include Bamboo, Hudson, and CruiseControl). Identify someone in the Engineering team (ideally, they will self-select) to take responsibility for ‘Build and Release’ tools.
Setup your CI tool to execute the full suite of unit tests after every commit/build, or at least once daily. Report build and test failures to the team and list recent check-ins to help identify which one is responsible for the failure. Make it the team’s priority to ‘fix the build’ before continuing to work on open stories or tasks.
Measure your progress
While code coverage is a useful metric, it can be disconcerting for a team starting out when few, if any unit tests exist (i.e. starting at 2.7% code coverage can make it feel like a steep climb ahead). Instead, begin by measuring and reporting the total number of unit tests – and assess progress based on %increase each sprint.
However, don’t rely solely on the numbers. Using a strictly quantitative assessment, can incent the wrong behavior, with developers creating unit tests to achieve the metric rather than creating effective tests.
It’s important to combine the quantitative unit test metric with a qualitative assessment by a peer developer. I recommend having developers pair program their first few unit tests with the Unit Test lead(s) and performing regular code reviews on unit tests.
Every team has to start somewhere and, by making unit testing a priority, you will reinforce the value and begin to see the investment pay off in higher quality code.
Shirley Foster's Agile Blog 