The agile approach to development comes with expectations of increased continuous delivery of software through team collaborations — but the results are far from guaranteed.
The potential for failure with agile development and how to respond such a breakdown was the of focus of Vertikal CTO Hank Birkdale’s keynote at this week’s DeveloperWeek New York conference. He said that prior to his work with Vertikal, a risk management solution provider, he served as executive program manager for an agile transformation with a large financial services enterprise. The plan then was to turn a shop with some 12,000 people into an agile shop. “This was a while ago,” Birkdale said. “When I first started, I was a little bit skeptical.”
He became more confident about agile methodology after completing that project and expected to apply lessons learned to other roles in the future. Birkdale described agile as an adaptive software development process that delivers in incremental chunks. He said most failures in agile occur while assessments are still underway. “They’re right in front of you during the practice, during a sprint demo, during a sprint planning session, during whatever practices you’re using,” Birkdale said. “That’s where you actually see the failures.”
Diving blindly into agile can also be a quick way to make matters worse, he said. If organizations ignore the core principles of agile while trying to adopt the methodology, Birkdale said they are likely to create more challenges for themselves and increase the chances for failure.
A key indicator that agile is not working is the team is not delivering, he said, and no one knows what they are doing. There may be emails about sprint demos being cancelled but little else to show. “One of the things about agile — working software is the primary measure of progress,” he said. “If you’re not seeing working software, the team is actually failing.”
Here are some of the issues Birkdale said to look for if teams are not delivering:
- There is no backlog for a team that has been around four or more weeks, he said. “I don’t care what the backlog looks like,” Birkdale said. “They should have a list of what they’re actually working towards.” If there is no backlog, the team may be spinning in place and not prioritizing what they are doing.
- The backlog is too big. “If the backlog is 10 times their velocity,” he said, “I tell the team to be careful.” Birkdale said he has witnessed teams with backlogs that represent upwards of 30 times of their velocity. In agile methodology, he said, the product owner should review the backlog on a regular basis, moving things up and down. “If they have too many tickets to be reviewing, it’s going to take too much time,” Birkdale said. There may be too many stakeholders given to the team, he said, and too many applications that must be supported. Guidelines from leadership to prioritize can help, Birkdale said.
- Lack of groomed stories. The purpose of grooming, or refining, tickets is to help teams prioritize their efforts. This can be assessed by reviewing top five to 10 tickets in the backlog. “If you don’t understand what the ticket’s about, if you don’t see any acceptance criteria, if you go to a team member . . . and they can’t [explain what it’s about], it means they haven’t groomed the ticket,” he said. The goal of grooming is to get a shared understanding of requirements, Birkdale said, which can take time. The payoff, he said, is the team getting their arms around the situation.
- Poorly written stories. “If you don’t understand them and you’re a leader in the organization . . . and you can’t actually understand the story that is probably a problem,” Birkdale said. Stories are the work done in increments on software by team members. Poorly written stories can occur if stakeholders treat the team like . . . an encyclopedia of knowledge about applications. “If you start to see stories about how to figure out what is going on with the application, it means your business isn’t thinking about the agile teams,” he said. “They don’t actually know the rules of the current application.” The resolution to such a situation may be to mentor the team, offer guidelines, and potentially retrain them.
- Only the product owners write stories. “Everybody should be able to write stories,” Birkdale said. “Don’t have the [product owner] being the only one responsible for taking notes and writing stories.
For more content on agile methodology, follow up with these stories:
Joao-Pierre S. Ruth has spent his career immersed in business and technology journalism first covering local industries in New Jersey, later as the New York editor for Xconomy delving into the city’s tech startup community, and then as a freelancer for such outlets as … View Full Bio