Scrum Overview: Top 3 Agile Temptations to Avoid

Internalizing Agile and Scrum best practices enables businesses to predict better how development processes can have interesting repercussions on project success and team dynamic.

Software is not a free, timeless solution that bridges the gap between a business and its customers. Quality software solutions require maintenance — from server environment upgrades and database re-architecture to new greenfield development. How can teams best approach these scenarios to maintain momentum and optimism while enabling the business to better forecast deadlines and sales cycles?

Temptation 1: Modifying the Sprint Schedule

Don’t Adjust Sprint Duration in Calendar Days Because of Known Changes to Capacity

Especially during the holidays, it’s easy to want to stretch things out. But this only further disrupts the rhythm and leaves people wondering what is going to happen and when. Reduce velocity a commensurate amount to stay on track.

Resist Increasing Sprint Length So More Stories Can Be Completed

It’s the day before the end of the sprint, and you can already see there are a couple of key stories that aren’t going to make it. They are big stories. Without them, your team’s velocity will be less than half what you expected. Someone on the team suggests that it would be better to extend the sprint than to arbitrarily end it now when you are so close — even a mere two days would make a difference. It’s a win-win, right? The team maintains a positive outlook, and the client sees success.

This behavior indicates several forces are at work: 1) Stories are too big; 2) Too many stories are being worked on in parallel and 3) The team may not have planned enough at the start of the sprint to form a better vision of the final product.

Software is a gas that expands to fill 110% of the space provided. By extending the sprint to let in that last 10%, you will learn nothing from your mistakes and just do the same for the next sprint.

You also sacrifice your rhythm. Last minute changes in expectations confuse everyone as you try to figure out who has the authority to change the rhythm and who is responsible for communicating the new plan. Leave the plan alone, examine in your retrospective what really went wrong, and fix it so it doesn’t happen again.

Avoid Cutting the Sprint Short Because All “Bought” Stories Are Complete

Interrupting the established pace of the project just confuses everyone. You’re better off finding other small stories to add to the scope until the time is up than to break the rhythm. Be careful not to start big stories that you can’t finish. This just leaves the product in an unstable state and threatens the principle that the product be shippable at the end of the sprint.

Temptation 2: Playing Fast and Loose with the Guidelines for Estimation

Don’t Change the Process Because the Team Is Constantly “Under”

This one is more of a “major sin” because it can have serious consequences. The theory behind estimating is that it does not have to be accurate to work, but it does have to be stable. Velocity becomes unstable when the estimating team consciously shifts its bias. It’s far better to keep your estimating process stable and let your velocity change to account for the real variation in productivity.

Stop Giving Bugs Story Points

I would call this a “major sin” as well because it strikes right at the heart of Agile values. Story points are a proxy for “value.” They are the credit or reward we give to a team for doing something the customer values. Do customers value bugs in the product? Absolutely not.

There is one exception I have made to this rule when working with a new team to embrace improving the quality of a legacy product they did not create. In this scenario, it’s hard to motivate them to solve the problem unless they receive credit for doing the work.

When bugs start to show up in new work or are caused by other bug fixes, then you need to go back to giving developers zero story points.

Avoid “Splitting the Difference” in Story Point Estimation When the Team Gets Stuck

This represents another “minor sin” but is still indicative of a problem that can be better solved another way. This temptation usually rears its head on stories with larger point values. (The jump from 20 to 40 points can be a tough pill to swallow.) When faced with this impasse and team members who can’t agree, the best remedy is to break the large story down into smaller stories. If that fails, your team is better off using the higher point value.

Splitting the difference can feel like a compromise and create the illusion of “fairness.” Odds are, the worst case estimate is actually more accurate, especially if it is coming from the person with deeper knowledge into a particular area of the product.

Resist Estimating During the Sprint Planning Meeting

This observation is controversial as there are certainly going to be situations where you are forced to do this by no apparent fault of your own. If you find yourself in that situation, then by all means just do it. But understand the risk you are taking: You are estimating the story in isolation, perhaps with a different group of people than normal. Estimating during sprint planning can also mean estimating through the lens of desired outcomes; you know what you want in the sprint. This probably means you already know how big you need it to be, so you are anchored on this answer. What happens in this situation? You might just underestimate the sprint’s complexity.

Temptation 3: Disrespecting the Boundaries of a Sprint

Abstain from Separating Feature Testing Into a Later Sprint

This one falls somewhere in the range of “major sin” and “mortal sin,” yet it’s surprisingly common. Some types of testing (such as the development of new automation testing or full regression testing) are truly impractical to commit to in every sprint. Once a team starts down this slippery slope, they might conclude that all test activities have until the end of the next sprint to complete.

When you decouple software testing from development, then test activities regress from process control to inspection. You lose your ability to determine if development or testing is your process bottleneck. Separating when developers and testers work on features also violates one of the most important Agile values: Individuals and Interactions. If they work on the feature together, they will both be available and motivated to work through it as a team.

Don’t Set “Stretch” Goals by Adding Stories to a Sprint That Exceed Velocity

To create a sustainable rhythm and enable development the business to forecast sales based (in part) on development velocity, you have to set goals for the team that can be met with regularity. If it requires heroics to accomplish one sprint, then heroics become the norm for future sprints as your team velocity adjusts to account for this. New teams often fall prey to this trap. Their desire to make a good impression on their product owner gets the better of them. Allowing a product owner to put more stories into the sprint than is prudent because of a team’s uncertainty about their actual velocity opens the door for the unrealistic optimism of a development team.

Inflated velocity is unsustainable. As with any economy, real growth can only come from an increase in resources or in the productivity of the existing resources. In the short term, teams amass a string of missed goals and miss the opportunity to establish and celebrate a pattern of successes. In the long run, this behavior leads to burnout and turnover as you find yourself trapped in a “death march” of unsustainable expectations.

Stop Giving Credit for a Story When It’s Not Shippable

Yes, it feels good to show off your work in the sprint review and to claim victory, but with each passing event where “done” is not really done, your team has taken on a future debt that must be repaid. Once you compromise on this a little, it becomes a slippery slope of lowering expectations as individuals vie for credit for their work. Product owners can be fooled in a demo, so acceptance by the product owner is not really enough. The scrum master and testers should hold firm to the team’s definition of success and only agree to take credit when credit is due.

Why Development Rhythm Matters?

By holding firm to the tenants set forth by Agile, software development becomes predictable enabling leaders to create a roadmap for the rest of the organization. When progress is predictable, so are product releases, and an organization’s sales team can preview new functionality that the business and users can count on.

Image Source: Unsplash.com