The software development life cycle is like a puzzle: Each piece fits into the other in order to create a complete product. When teams decide to adopt new methodologies, such as agile, or revise their current methodologies to be more agile, it is important to make a road map in order to determine what you’re doing and what you want to be doing, according to experts.

Jeff Amfahr, director of product management at Seapine (an agile application life-cycle management solution provider), said that to begin an agile adoption process, teams should assess what metrics will be used to determine if the transition was successful.

“Establish up front how you’re going to know if the adoption was successful. It could be productivity of the team, less software bugs or more customer satisfaction,” he said, adding that it is most likely the business value gained from adopting agile from adopting these new methodologies.

Amfahr said it is important to start with a team that is interested in agile (or the new methodology you’re interesting in adopting). The project should also be one that lends itself to being measured and can be released quickly, he said.

Alex Perec, senior product manager at TechExcel (a maker of application life-cycle management software), said that, based on his experience on a team transitioning to agile, the adoption process can be quite daunting.

He recommended going agile one piece of the process at a time. He said that being partially agile does not mean you are inefficient, it means you are slowly growing toward maximum efficiency.

For some teams and projects, Perec said it is important to realize that Water-Scrum-Fall may be your only option.

“For contract-based work, heavy requirements up front [in the style of waterfall] is important because you are getting paid to specifically deliver a function or series of features,” he said.
Tools can help
Mik Kersten, CEO of TaskTop (creator of the Eclipse Mylyn project), said that heterogeneous software life-cycle management systems for projects are the norm.

Kersten said he sees teams with multiple tools from different suppliers who often need an overarching management view, which he said can lead to inefficiency because each team is using a different piece of software, which often means that the metrics and charts needed for teams to assess progress need to be manually generated.

Steve Miller, vice president of ALM solutions at SmartBear, said tools should allow teams to be better at what they’re doing. “Make sure, when you’re evaluating a tool, that they are easy to use. You don’t want [team members] to stay in the tool and stop doing [their] job,” Miller said.

Visibility is what tools provide, according to Robert Holler, president and CEO of VersionOne, a provider of agile project management software. Holler said the transition to agile application life-cycle management is all about bringing better visibility to the cycle in order to help the team understand what they’re doing right and where they can improve. He said this is essential when a team is transitioning to agile because everything is moving much faster.

Chris Clarke, vice president of product management at CollabNet (a provider of agile application life-cycle management software solutions), agreed with Holler and said that a trend his company is seeing is that teams have a variety of tools that need to be integrated so that each department can see and understand what the other department is doing.

Kersten said that once teams start to think of software development projects in a “task-centric way,” it is natural for team members to want tasks displayed in an activity stream. Tasks, he said, allow teams to connect all the workflows instead of thinking of them as individual pieces of a cycle.

Clarke said a manager of a software development team needs to be able to see all the different divisions in order to make informed decisions, and for the project management office, this is hard when teams are using different tools that are not integrated.

The project management office (PMO) is a role that is necessary in the waterfall methodology, and now, according to experts, it is struggling to find a place in the new world of combined development methodologies.

Clarke said an important thing for the PMO to remember is that trends that influence business decisions are not just around products but are also trends in technology.

Forrester analysts are also analyzing the trends in PMOs and business initiatives in a series of research papers that will be published this year.

Margo Visitacion, vice president and principal analyst at Forrester, said PMOs need to realize that, at times, developers see the PMO team as too “heavy” in its approach.

“PMOs need to open more lines of communication and understand what types of information needs to be shared,” she said. (She recently published a research paper entitled “PMOs: Stop Being the Office of No.”)

Visitacion added that for PMOs, it is more about developing a community within the company around the methodology, noting that companies that have done this have benefited. She and Tom Grant, senior analyst at Forrester Research, agreed that it is not only an adoption of a methodology but also a change of behavior within the company. She said mentorships for all roles within the company, focusing on how agile helps each individual position, greatly enhance the effects of adoption. Success of the PMO can also be a metric used to determine how successful a team is, especially when it comes to merging an entire enterprise.
Emphasis on clarity
Grant said lean principles are coming into their own at the same time as all these other agile trends are emerging. It is the “yin and yang of agile,” a perfect compliment to the methodologies that are already being widely used, he said. This concerns the upstream part of the process while the other agile methodologies focus on the development, build and test segments of the cycle.

Grant also said that ALM tools are important to teams because of the visibility and reporting capabilities that they provide. He added that it is very important for teams to explain why they’re transitioning to agile and talk about how they’re doing it, so that all members of the organization feel included in the process.

Perec said this was a major pain point during his company’s own transition to agile: The developers selected to transition to agile were resistant, and this made it harder to do.

Grant added that the requirements-gathering process, done at the beginning of the ALM cycle, is something that is slowly being blended with the design-modeling phase of the application development cycle. End users, according to his “Navigate the Future of agile and Lean” report published in January, are driving apps. He said in his report that “the relationship between developers and customers will mature beyond developers treating users as objects to be acted upon. Technology already exists…to let users start the process of application development themselves. Agile teams may officially incorporate the user-generated applications into the development process so that they can pick up where users left off.”

Mendix, a provider of an agile management platform,  already takes this approach, as do some of the other tools out there, including one from Rally Software, which has a social voting feature to allow developers to vote on specific features. Mendix’s agile platform does the same thing: Features can be voted on through social networks and other websites, and then the features are turned into requirements, which are tagged throughout the process, according to Derek Roos, cofounder and CEO of Mendix.

According to him, Mendix also allows end users to participate in testing. Users can submit feedback from within the application itself to catch the exact point of an error or the exact screen they wish to change, he said. This takes any and all questions out of the meaning of a requirement and allows for better, more precise collaboration between developers, stakeholders and end users.

More precise collaboration and the ability to respond to changing requirements quickly are often what drive agile application life-cycle management tool adoption, according to Pete DuPré, chief architect at Borland, a Micro Focus company. He said that in the past few years, he has seen teams looking to adopt agile in order to respond to business trends and changing initiatives, which is what makes them look for an overall solution that offers metrics and visibility.

DuPré was part of an agile transformation at Borland, and he said that in order for a team to be more agile, the entire organization needs to be agile. It is not, as he said, “just a software development thing.”

He also cautioned against the PMO being the product owner, a role he believes is better suited for someone from the user community.

“The PMO, in an enterprise, could [be the office to] house the skills to speak for the business requirements of an application,” DuPré said, adding that some companies have an IT PMO that typically runs the IT projects and thus does not have the skills or permissions necessary to speak to the business requirements of a specific application.

The challenge for some enterprises in switching to an agile project management system is not necessarily what tooling to use, but who owns the rights to oversee the project, according to DuPré. He added that this challenge was something the Borland team faced during its own agile transformation, and that the team ultimately changed its ALM product to suit its needs. He said the bidirectional traceability—up and down the cycle from requirements to deployment and management—was very important to the visibility of the project and success of the team.

Kovair’s CTO, Sky Basu, said that the success of agile application life-cycle development in his opinion is based on tools that are not necessarily a part of the ALM tool set.

“IDEs, build tools and continuous integration tools are all separate from agile project management, and still needed for development,” he said.

Kovair’s ALM Studio is an agile, cloud-based platform for cycle management and is only part of the overall management story, Basu said.

ALM Studio has two flavors, according to Basu: one for iterative development organizations that don’t necessarily follow Scrum, and one for Scrum teams. On top of the Scrum version, he said, Kovair added a project management solution.

Kovair’s solution for the distributed enterprise agile teams solves some of the issues discussed above (including who owns the project and how metrics can be generated to determine the success of the project) with a virtual backlog, meeting rooms and automated processes.

Customization of a tool to combat your specific issues is key, according to all the experts. Todd Olsen, vice president of products at Rally Software, said that it is important to support many methods because there are so many teams doing a combination, which is a point that the Forrester analysts also supported in their reports.