[jroseattle]

I recently inherited a project that was "late". The team and project were 6 months into execution, and had nothing to show for it. The status on my Day 1 was "estimates were missed -- now what?"

On appearances, everything should have been just fine. The SWEs and product leader were running two-week sprints, with all the ceremonies scheduled on all calendars (well, everything except the end-of-sprint demo.) Every two weeks, a status powerpoint slide deck came from the product leader espousing all the fantastic capabilities that were recently implemented by the team.

I needed to understand what was going on. I chose to observe everything for two sprints (and not interrupt how everyone worked) while I focused on establishing a clear and comprehensive view of The Project.

What I discovered:

- An ambiguous and unclear definition of the project. Key facts, problem statement, overall solution ... did not exist. The product leader could give you some spin of this off the top of his head, which would invariably change from time to time.

- Work stories (we used JIRA) were garbage. I'm an engineer and even I couldn't understand what work was being completed.

- No capacity for the team to build & deploy software in a reasonable manner.

- No agreement or understanding of expectations among stakeholders.

So, what did we do?

1) Defined the project, with stakeholders in agreement.

2) Devised a solution, based on the project definition.

3) Broke down the work necessary to implement and deliver the solution.

4) Determined individual lengths of time to complete the list of work.

5) Reviewed everything, finding areas of risk and potential further problems.

It sounds like BUD (big upfront design) -- but in practice, it was Big Upfront Discovery. We structured work and components to ensure we had plenty of two-way doors (only a few one-way doors, based on requirements from stakeholders.)

And with that, we made our estimate. Another 6 months. The stakeholders did not like the timeline, but agreed "as long as we make that date." We provided weekly status updates, leaving out no details. Our stakeholder meetings went from contentious and confused to understanding and brothers-in-arms. We made the date and we didn't kill the team (morale actually went up.) The stakeholders loved the resulting solution.

****************

No magic here, just a focus on attention to details and honest assessment.

[mason55]

Yes, ultimately if you don’t have a clear vision of the problem you’re solving and the value you’re providing then success will be impossible. And most people confuse building features with providing value or solving a problem and so most projects fail.

If you’re able to define the problem you’re solving and what counts as “solved” then success it’s much easier. It’s also much clearer from the start when a problem is intractable. And it’s easy to tell if you’re not ready to start building yet.

[pylua]

Sounds like stakeholders are expecting waterfall guarantees without the overhead of proper planning and refinement.

Honestly, the industry should move back to waterfall.

[jroseattle]

Yes, we had some "stakeholder training" that was necessary.

The biggest complaint: "I don't understand why this takes so long."

Our stakeholders were mostly plant operations people -- users, not engineers. We re-framed the discussion to focus on WHAT they didn't understand. They didn't understand how software comes together, gets deployed or updated, etc.

I explained that it wasn't important that they understand how that occurs (or, if they do, please join the engineering team!) This literally took pressure off of them to be knowledgeable. I pulled a few of them in as "first-pass quality control", ensuring what we built would work for them and their teams.

Immediately, I had advocates for us and interested stakeholders willing to participate as partners.

[poszlem]

I'm not a die-hard GTD or David Allen fan, but I think he got some things right. My favorite quote of his goes like this: "Things rarely get stuck because of lack of time. They get stuck because the doing of them has not been defined."