The Agile Project Manager – Why are Software Projects Different?

I was doing some introductory agile training recently. As quite often happens, I got challenged about adopting agile in the “real world”. The implication I guess is that I’m from some other planet. So someone asked: how is agile is going to solve the following problem?

It seemed as if they had a project that had been going on for a while. It involved some new technologies that they hadn’t integrated before. I believe in this case, it was a Microsoft product that needed to be integrated with one of their major legacy products.

In traditional Waterfall fashion, they pulled together a project plan, did some requirements analysis and design, and approved the project through their phase-gate processes as a Phase 2 approved project.

From their leadership’s point of view, the rest was simply technical execution. The business was expecting the project to meet its scope and date commitments from the phase review. Life was good!

That was until…

The team found that physical integration with the Microsoft product was much more difficult than everyone had thought. The documentation was wrong and, in many cases, insufficient to describe how to effectively integrate. Calls to Microsoft went unanswered or didn’t really help with the challenges. The teams kept spinning their wheels; trying to sort out problem after problem and never seeming to make much forward progress.

When they went to their management team to report the challenge the project was encountering, they received two basic replies:

• First, what is the team doing to hold the date? Did everyone realize that the date was incredibly important and that, heads would roll, if it slipped.
• And second, when would they have answers to all of these problems and a solution? On what date would things settle back to normal and resume on plan?

So, making a long story short, the students question was: In the above situation, how would agile enable the team to give the stakeholders a definitive answer as to when this technical problem would be solved?

Software Projects

I think I disappointed them, because I said: Agile was not a silver bullet that would provide a magical end date for the solution to their problems.

I further offered that they needed to “push back” on their management demands for specific resolution dates. Clearly they were encountering “unexpected turbulence” in their project. Clearly they were doing the best they could. Complex problems are often impossible to accurately predict. Instead, the effort becomes one of intelligently and systematically attacking the problem—triangulating towards a solution.

This is simply the nature of software development. It’s exacerbated because software is soft, amorphous, and intangible and we’ve ALLOWED our customers and stakeholders to push us around in these situations. And since software is well, soft, we struggle to defend ourselves.

What “Agile” would do…

Now I explained that an agile approach would certainly help them in analyzing, finding and integrating a solution. For example, the following would be typical ‘agile’ reactions to the problem and probably generally helpful steps towards a solution:

• Take a whole-team approach; perhaps getting a small team in a room, totally focused on solving the problem.
• Raising the lack of Microsoft support as an impediment to Sr. Leadership team—asking them for help.
• Ideating a backlog of things to try or an overall strategy with the team. Prioritizing them into the best workflow to augment discovery, learning, and progress.
• Having daily stand-ups to ascertain progress, discovery and to plan adjustments.
• Perhaps time-boxing their efforts into 1-week (or very short ‘Sprints’) so that they could provide progress insights.
• Retrospecting often on what they’ve learned and then leveraging that for future adjustments.

I’ve often used these techniques with problems of this sort in agile and non-agile projects. And they certainly help to drive progress through ambiguous and chaotic situations!

Home Projects

In fact, I also responded with the following counter story.

I asked if any of them ever watched two shows on HGTV. There is The Property Brothers and Love it Or List it. In both cases, the shows take on renovation projects for relatively older homes. Usually these are extensive renovations. 

The shows usually start with the homeowners (or prospective homeowners) providing the hosts a budget. It’s normally a range, with a max that cannot be crossed. In many cases the bank imposes these hard limits. Then the hosts dive into the renovations. 

I remember in one episode of Love it Or List it, that Hilary (the renovation expert) uncovered a basement wall that was in danger of failing. It was bulging and leaning into the basement, preventing them from covering it. The bigger problem was that it was the foundation—or a load bearing wall. 

She had planned on simply covering the wall with drywall as part of the basement makeover. Instead, they had to literally build another foundation wall the length of the basement to shore up the failing foundation wall. This was unexpected and costly. I seem to recall that it would take 30% of the planned budget, and it was literally a must have from a building code and safety perspective.

When she first went to the homeowners and shared the news; they were upset. Then they went into denial that they would have to lose some of the enhancements that they’d planned for their budget. Then they yelled at Hilary as if it were her fault. But eventually, the emotions settled down and they worked with her to accommodate the changes and still have their highest priority renovation changes made.

The Unexpected

Encountering unexpected work in home projects happens ALL THE TIME. It’s the nature of things. And it always impacts expectations around budget (cost), time (schedule), and the overall design (scope expectations).

What’s surprising though is how the home stakeholders eventually adjust to the unexpected in a constructive way. Quite often, as my initial story showed, software stakeholders aren’t as accommodating. Somehow, they always expect the budget to be maintained along with the timeline and the scope. They demand creativity and initiative and hard work; as if those things aren’t happening. They question the commitment of the team to the company or their professionalism. 

If compromises are made, they’re often under the banner that the team failed the stakeholders in some way—that they didn’t do their job.

Wrapping Up

Agile won’t help these situations. In fact, it will make them potentially worse. Agile doesn’t work well with unrealistic or demanding customers. Or with customers who can’t handle the unexpected; who can’t handle the truth.

It expects customers to embrace unknown risks, discovered as early as possible, and then partner with the team towards trade-offs and solutions. It expects stakeholders to realize that software development is HARD and virtually impossible to guarantee. 

At the end of every Love it Or List it episode, both hosts have done a remarkable job and the clients are left with a very hard decision. Hilary always delivers a delightful renovation that is constrained to what she had to work with. She delivers the highest priority items, with high quality. She even throws a bit of a stretch in now and then. But the customers NEVER get 100% of their initial expectation. That’s because it was unrealistic.

From my perspective, software projects are no different than these home projects. Now if we can only get our software customers and stakeholders to have the maturity and realism of these homeowners. Well, I can hope can’t I?

Thanks for listening,
Bob.

Don’t forget to leave your comments below.