How to Tell if Your Agile Project Changes are Slipping

By Mark C. Layton

Sometimes, you might feel like your agile project isn’t going as smoothly as it should. The following list of questions helps you see warning signs and provide ideas on what to do if problematic circumstances arise:

  • Are you doing “scrum, but …”?

“ScrumBut occurs when organizations partially adopt scrum. Some agile purists say that ScrumBut is unacceptable; other agile practitioners allow room for gradual growth into a new method. Having said that, beware of old practices that thwart agile principles, such as finishing sprints with incomplete functionality.

Scrum is three roles, three artifacts, and five events. If you find your team tweaking those basic framework components, ask why. Is scrum exposing something you’re not willing to inspect and adapt?

  • Are you still documenting and reporting in the old way?

If you’re still burning hours on hefty documentation and reporting, it’s a sign that the organization has not accepted agile approaches for conveying project status. Help managers understand how to use existing agile reporting artifacts and quit doing double work!

  • A team completing 50 story points in a sprint is better than another team doing 10, right?

No. Keep in mind that story points are relative and consistent within one scrum team, not across multiple scrum teams. Velocity isn’t a team comparison metric. It is simply a post-sprint fact that scrum teams use to help them in their own planning.

  • When will the stakeholders sign off on all the specifications?

If you’re waiting for sign-offs on comprehensive requirements to start developing, you’re not following agile practices. You can start development as soon as you have enough requirements for one sprint.

  • Are we using offshore to reduce costs?

Ideally, scrum teams are collocated. The ability for instant face-to-face communication saves more time and money and prevents more costly mistakes than the initial hourly savings you may see with some offshore teams.

If you do work with offshore teams, invest in good collaboration tools such as individual video cameras and persistent, virtual team rooms.

  • Are development team members asking for more time in a sprint to finish tasks?

The development team may not be working cross-functionally or swarming on priority requirements. Development team members can help one another finish tasks, even if those tasks are outside of a person’s core expertise.

This question can also indicate outside pressures to underestimate tasks and fit more work into a sprint than the development team can handle.

  • Are development team members asking what they should do next?

After a sprint is planned and development work is under way, if the developers are waiting for direction from the scrum master or product owner, they aren’t self-organizing. The development team should be telling the scrum master and the product owner what it’s doing next, not the other way round.

  • Are team members waiting until the end of the sprint to do testing?

Agile development teams should test every day in a sprint. All development team members are testers.

  • Are the stakeholders showing up for sprint reviews?

If the only people at sprint reviews are the scrum team members, it’s time to remind stakeholders of the value of frequent feedback loops. Let stakeholders know that they’re missing their chance to review working product functionality regularly, correct course early, and see firsthand how the project is progressing.

  • Is the scrum team complaining about being bossed around by the scrum master?

Command-and-control techniques are the antithesis of self-management and are in direct conflict with agile principles. Scrum teams are teams of peers — the only boss is the team. Have a discussion with the agile mentor and act quickly to reset the scrum master’s expectations of his or her role.

  • Is the scrum team putting in a lot of overtime?

If the end of each sprint becomes a rush to complete tasks, you aren’t practicing sustainable development. Look for root causes, such as pressure to underestimate. The scrum master may need to coach the development team and shield its members from product owner pressure if this is the case. Reduce the story points for each sprint until the development team can get a handle on the work.

  • What retrospective?

If scrum team members start avoiding or cancelling sprint retrospectives, you’re on the slide back to waterfall. Remember the importance of inspecting and adapting and be sure to look at why people are missing the retrospective in the first place. If you’re not progressing, complacency usually results in sliding backwards. Even if the scrum team has great velocity, development speed can always be better, so keep the retrospective, and keep improving.