An organization focused on application lifecycle management (ALM), with the appropriate supporting tools and processes, does not need to turn its staffing grid on its head by either shedding personnel or radically rewriting job descriptions, according to industry observers. Rather, an ALM effort "is not so much about using different resources, but using resources very differently," said Steve Porter, technical director of consulting at Wintellect, a consulting and training company based in Knoxville, Tenn. While some of the lines between jobs are blurring, ALM is really about knocking down the walls between silos.
If organizations are committed to an application lifecycle approach, "the meaning behind it is to enhance the communications and collaboration with all constituents in the lifecycle," said Theresa Lanowitz, founder of market analyst firm voke inc., based in Minden, Nev. "It's not just about development, but a broader focus where other groups get involved—line of business, architects, designers, developers, testers, customers."
Many IT shops don't understand that "software development is an intensive endeavor, especially if they're using methodologies like agile and scrum, and now developers have to work more with project managers and business analysts to get the proper requirements," said Clementino de Mendonça, manager, national solution lead, ALM, at global consulting company Sogeti. "This model has been in use by industry, and Microsoft
Lanowitz agrees. "The big thing is we need to see enterprise IT organizations come to terms with the fact that they're building software products that run the business. While they're not commercial software companies selling software as a main business, they are putting products out there that are driving the business." With the pressure to decrease expenses and make IT more efficient, "it's forcing IT to come into alignment with the line of business and behave more like a commercial software company."
According to Porter, the overarching theme of a good ALM process is that the roles and resources involved must have "some amount of overlap on the way, so they understand the project and the process and they're not just throwing something over the wall to anybody."
So what does that mean to the business analysts, developers, testers, project managers and others involved on a team? "You still need a lot of the typical personnel," Porter explained, but organizations need to think out of the box in terms of how they utilize that personnel. "So someone from the development staff may participate as the scrum master. I suggest QA take a very active lead in the project/process. Everyone should be involved from the get-go and QA should drive the process as much as development and management, almost taking on project management."
Team members will have a wider breadth of skills as silos come down. "Today there is value in having professionals that can grasp the lifecycle as a whole and not in pieces," de Mendonça said.
But that doesn't mean roles and responsibilities will go away and everyone on the team will become a generalist, Lanowitz said. "Specialization is good," she said, "but I don't think somebody will only be a performance tester. I think [team members] are going to be aware of what others are doing and where the handoffs are. But specialization is powerful, so I don't think we can mix and match. You won't take a QA professional and say, 'Be a business analyst.' The norm is going to be we'll continue to see specialization; otherwise you end up with amateurs. Just like you don't see a kicker playing a linebacker position—they're not equipped for it or suited to it."