Agile Management: How to Ensure Software Development Sprints Stay on the Rails
One theme seems to reappear in almost every client environment in which I've worked. New teams often struggle to deliver software products according to management's plan. It happens as frequently for internal development teams as it does for outsourced partnerships; however, experienced product development partners quickly identify and navigate your team through these challenges so that you can reliably deliver products to your customers. Even better, your development partner should set the expectations for the relationship early to avoid these common problems.
Agile development methodologies provide a framework for addressing delivery challenges, but all levels within an organization or partnership must be in alignment to be successful. Misalignment in operations or expectations quickly stresses a team’s ability to deliver quality software products on time. Tune in to your team’s conversations and challenges. If you are hearing the following message from your team, there is a way through.
"My team is struggling with agile adoption. We are not completing our user stories on time and it is jeopardizing our release plan. We are finding that escalations for decisions mid-sprint are frequent and costly. How do we break this cycle?"
This is a common problem with new scrum teams, and it’s one that has received a lot of attention at 3Pillar. There are a few areas to investigate that may contribute to development teams not finishing all the functionality committed for a sprint. We’ll look at this topic on a tactical level in this post, and at an operational level in a follow-on post.
From an agile process perspective, not completing stories within a sprint means that you have overcommitted on what the team can deliver. This may happen because the team did not understand what their commitments entailed, they were not making the commitments to begin with, or distractions arose mid-sprint that interfered with completing the stories.
Commitments should be made coming out of sprint planning, where each story is broken down to a granular enough level that an engineer can accurately estimate the tasks and effort necessary to deliver. Leading up to sprint planning, user stories must be "development ready" - all acceptance criteria is defined, reviewed by development and test engineers, and signed off by the product owner.
Some teams refine their stories to be "development ready" during a 1-2 day sprint planning session at the beginning of a sprint, but any follow-up questions, which depend upon answers from stakeholders outside the team, will challenge this effort. If stories are not well understood, estimates cannot be accurately made, and questions, escalations, and scope changes are likely to arise throughout the sprint.
If the team did not understand the commitments they were making, spend more time in sprint planning. Hold the product owner accountable for defining and signing off on the acceptance criteria of what they want. If the product owner is not responsive enough for the team, have them delegate authority to someone who can be more available. Review stories with the team to resolve open questions, and spend time before kicking off a sprint to get your stories "development ready.” If stories are still too large to complete within a sprint, break them into something you can deliver in the allotted time period.
If the team was distracted during the sprint, the engineering manager and product manager need to step up to shield the team from the noise, and push back on the product owner and other stakeholders. Don't fall into the trap of the Tyranny of the Urgent. Tasks should be planned and scheduled in sprints; or create an overhead task in each sprint for addressing production support and other ad hoc requests needed to support the business.
When stories are not completed within a sprint, it means the team's velocity is lower than was anticipated, and subsequent sprints should be adjusted for the new actual velocity. Lowering velocity moves your anticipated release date, with scope remaining the same. This is a common problem area - commitments are often made on release maps and feature sets, which dictate what the velocity NEEDS to be to hit an unchanging target. Clients need to understand from the beginning of the relationship how their partner develops software, and what that means for their business operations. The education process about product development starts with sales and transitions through to client management and delivery. To some extent, you can add team members to increase velocity, but there is a short-term performance hit as they ramp up and draw on productive team members; we find that there are also diminishing returns after about 10 team members.
If roadmaps and deadlines are making the commitments for the team, then you've done something wrong from the beginning, and you need to look at changing the culture of your engagements. You may need to add people and cost, have the product owner de-scope functionality or move the deadline. Holding all of those variables as fixed, the only option is to ask the team to work longer hours, which has a history of low morale, decreased quality, rocky product releases, and damaged reputations.
In the next post, we'll look at some operational processes that may be contributing to missed commitments and delayed releases.