Agile is a huge term, and there are many different directions an organization can take in its transition, according to JFrog’s Sadogursky. It takes some failure sometimes to figure out which direction will work best within the organization.
“Some companies see the benefit of going ‘full monty’ and rewriting all their procedures and starting clean from a new agile slate,” he said. “Others adopt parts of the methodology and see how things work for them. Take it slowly, take it step by step, and don’t be afraid to fail.”
In addition to embracing that failure, developers, testers, product owners and anyone else on the team have to learn that they can’t avoid owning up to failure, according to CollabNet’s Brown. “When we practice agile, we can’t avoid the blame,” he said. “If we are the reason something didn’t go well, that is obvious to everyone because the practices and processes will show us that.”
In the past, when development cycles took years, it was the end of the world if a failure happened because the business would have lost millions. Today, people need to realize that if you fail in agile, failure is only a couple of weeks or a couple of months, according to Brown. “It is short, it is cheap, and we learn from it. It is not actually a bad thing to have a failure if you can see something that will help you improve,” he said.
Organizations also need to be transparent with their customers about any failures that may have happened. “Part of being agile is that you are going to be a lot closer to your customers,” said QASymphony’s Dunne. “You need to be transparent about how it might have happened and how you are going to fix it. Customers feel closer to companies that do that, and are sometimes willing to give them some leeway when they own up to mistakes like that.”
Developers are on the team, but don’t make up the team
Developers are not the be-all and end-all in agile development, according to Rally’s Polk. “Agile teams are not just developers,” he said. “Agile teams are business people, analysts, testers, operators, not just developers. You need to figure out how to build the right balanced team with all of those different roles.”
Developers are in high demand, so organizations fall into the trap of creating practices that are good for developers, but not necessarily good for the company or the customers who are benefiting from the products. “We are all fighting for good people to work on our teams,” said Polk. “Nobody wants to make developers upset. We all just want to give them the best practices so that they don’t leave us and go to another company. But we have to create agile teams that build good products for our customers. It can’t be entirely developer-focused.”
A team should be made up of people who can do the whole cycle, from the design, implementation, testing and rollout, and they should understand that while they are going to work more, it is going to be more rewarding, according to JFrog’s Sadogursky.
“The team should understand they learn more, they do more, and they do more in terms of touching different parts of the project,” he said. “But it is very rewarding because we are in this industry to do cool stuff, and when they are new, versatile and coming from different aspects of [the] industry, it is always fun.”