IT projects and software teams need to include Agile people

Agile people interact with the business

Certainly, the success or failure of a software project affects various business levels within the organization. So software projects have to include the business side in some fashion.  

 "Agile is true inclusion. You bring in the sales, marketing and finance people because everyone has a perspective," said Shouvik Bhattacharyya, chief innovator at B12 Consulting.

It may be difficult at for software development teams to incorporate business stakeholders. But it's time to ask better questions, hone storytelling skills, and focus on communicating business value. These three practices will help your organization create Agile people and teams. They'll make sure the project serves its purpose, has strong internal support, and actually keeps a laser focus on delivering value.

Balance the big picture

Companies typically run waterfall from the top down and pay deference to those with the most experience in the field. While there's always a need for high-level knowledge, it's a mistake to discount input from those who actually do the work on a daily basis. Agile offers this balance.

Methodologies don't create great results, people do.

"At the end of the day, frameworks are nothing more than ways for people to make decisions," Packlick said. "What decisions do we make? Who is the best person to make those decisions? How are we going to verify it's the right decision? The answer is going to vary according to your context."

Organizations need Agile people making most of the decisions, not the customer or a senior architect somewhere far away.

Find the end customer

When a Latin American bank wanted to roll out a credit card project in time for the 2016 Olympics in Rio de Janeiro, it enlisted Bhattacharyya for the switch to Agile. The project's success would rely on targeting the end customer.

"When you think of an IT project in Waterfall, IT owns the project," Bhattacharyya said. "When you switch over to Agile, they might say, 'Marketing owns the project.' That was the hypothesis for the bank. But when we came in, we said, 'No, we are going to take the company that's going to issue the credit cards and make them the customer.'"

Bhattacharyya and his team took that extra step. For an IT project, it's critical to define the business boundary and identify the real end customer.

In any IT project, it's essential to match your production priorities with the desired end points. For example, speed might be paramount to one set of stakeholders while lots of features might be the focus for another. In the case of the credit card example, the real priority was to get those cards in the hands of consumers before the big Olympic spending season.

Ensure the customer is included

Mark Yarbro, an enterprise performance test manager at Bank of America, has seen what happens when an organization gives lip service to the idea of customer inclusion but not real commitment. Yarbro mostly works in cyclical Waterfall and sees too many shortcuts with Agile.

"People on the team may say they are customer representatives, but they aren't really the customer because the customer isn't available," Yarbro said.

In his experience, Agile results in a set of watered-down requirements with a proxy speaking for a group of customers. This proxy will, naturally, spin what's really important to the customer and this bias can easily kill an Agile project.

Satyapal Chhabra, founder of iDeliver Technologies, a software testing consultancy, agreed that it's a little late to talk about inclusion when the end customer isn't available until 18 or 19 sprints into the project.

Packlick argued that it's essential, then, to adapt and figure out how and where to get the early feedback to make the Agile process work. In the end, both methodologies are all about making decisions and adjusting those decisions as new situations arise.

"You need the best information and knowledge to make the decision," Packlick said. "Regardless of the framework, if you do that, you're going to succeed. You do Agile with the wrong inclusion, you fail -- and it's the same with Waterfall."

Don't rule out a hybrid structure

On that note, organizations should consider including the structure of a project, not just its levels of inclusion. It might need more of a Waterfall structure simply to ensure that things are done the right way. 

Curt Raschke, new product development manager at Product Focused Project Management, believes hybrid is an important aspect in the future of Agile.

"From my perspective, project organization comes from the product," Raschke said. "How much certainty is needed? Control and centralization lend themselves to Waterfall. The more flexibility is needed, the more Agile it becomes."

Almost all Agile projects have a Waterfall component. In fact, most Agile projects start with a business case.

"Customers need infrastructure, and they need the product maintained and rolled out," Raschke said. "These product activities don't tend to be Agile. They tend to be Waterfall-ish. After the outlines are established, it can branch out into one or the other or a bit of both."

Not every opinion has value

Sadly, Agile processes cannot include every voice and give each idea equal weight. At some point, you have to make a decision and move forward. Without hard decisions, Agile can easily turn into eternal software development.

 "Agile tends to think, 'We can do it because we have inclusion by the right people.' That's where Agile becomes cyclic and goes on forever," Chhabra said.

So what's the ticket to Agile success? It's leadership that guides the process without it turning into a free for all.