It takes two to agile tango

Agile projects are a dance between the business and project teams. While many organizations use agile approaches, too often, adoption is limited to the mechanical process. There is a lack of real commitment from the business. But it takes two to agile tango.

The Requirements Shuffle

Traditional project management approaches are sequential. They are also based on the fallacy that business and the project team understand the needs and that nothing changes.

Here’s where things go off the rails: analysts interview business stakeholders to gather requirements, then ceremoniously throw them over the fence to a design team. With the business people back to their day jobs, designers whip up the outlines of a solution and hand it off to a build team. At some point, the business is invited back to see what was built and guess what: it doesn’t at all match what was intended. Or what is needed has changed. Or both.

Agile hokey pokey

Agile approaches are based on the notion of close collaboration between all parties and roles. Build a little, test a little, deliver a little. Short cycles of deployable components, rinse and repeat.

Close communication is key to a common understanding of the minimum viable product and how to prioritize the work to reflect changing needs.  No handoffs, no ceremonies, no throwing things over the fence.

It requires embedding the business into the project team. Not surprisingly, this requires grace, discipline and effort.

Often, agile takes more effort than people from the business side are willing to invest. So they send a delegate. Or they send nobody, thinking that all this agile talk is just a technology thing. The team, eager to make progress, improvises and assigns a proxy: someone who represents what the business wants. Sort of. Perhaps an analyst who interacted with the business stakeholders for some time. Or even worse: a liaison. Cue this classic scene in Office Space: “I deal with the &%@* customers so the engineers don’t have to, I have people skills!”

It usually doesn’t work well. Instead of graceful collaboration, we have an agile hokey pokey. The proxy turns her requirements in, the team puts the software out. When the sawdust settles, the real business stakeholders find that the solution is shaky all about.

Sure, the work may get done faster, but the goal of agile is not just to go fast, it is to achieve outcomes.

It takes two to tango

If a project is critical, then it’s critical for the business to invest real time and effort to work closely with the project team. These are some options to that may help the business side:

• Short-term: assign a delegate to take over some day-to-day business operations. From a run/grow/transform perspective, projects should fall into the grow or transform buckets.
• Long-term: adopt a product-based organization model in which product management becomes a core competency. Product managers closely collaborate with the project teams and are responsible for the vision and business value of product capabilities.
• Or… defer the project to a time when the business has the needed bandwidth.

None of these are easy. However, if the business cannot afford it, then the project may not be critical enough.

Asking Business to Dance

Even when some work is delegated, or with a product organization in place, business stakeholders can’t devote all their time to your project. Nor should they. It’s important to focus on the areas of most impact: visioning, capability modeling, conceptual architecture, user stories and feedback loops.

Usually, business stakeholders are delighted that you will have carved out a meaningful role that makes the best use of their time. But not always. Just as too little commitment is a challenge, too much exposure can be risky too.

• Too much involvement in the granular design is a bad idea. It’s much more productive and effective to use customer experience (CX) and user experience (UX) experts sort out the design. These are not “gut feel” activities: it takes art and science to skillfully craft experience models. Trust the team to do what it is good at.
• Too much involvement in project management is just as bad. For all but the most short-lived innovative projects, there must be some balance between cranking out features and creating a sustainable solution. Even when using pre-built cloud platforms, it takes time and effort to engineer for scale and resilience. Otherwise, you end up with creative plumbing.

In summary: enroll business stakeholders into the right elements of the project and use their time wisely. Teach them to dance, but not to step on the project’s toes.

Let’s tango!

Ernst Rampen ©2018