How to prove this new “Agile” thing you’re trying is really working.

Your beloved metrics won’t work.

“My team of 5 is doing 40 story points every two weeks do you understand what this means?!

Track velocity over time. Be able to report an X% increase in work accomplished.

You are not a team of 5 doing 40 story points per sprint. You’re a team that was doing 20 story points 4 sprints ago, has steadily improved productivity since then, and are now doing 100% more work per sprint than you were 8 weeks ago. 100% improvement in productivity makes sense to anyone.

The measure of success for any Agile team is WORKING SOFTWARE.

If you can’t show the release of working software, resulting in a real or at least predicted ROI, you have to question why. Our goal is not to do a process, after all. The goal is to make money, get return on our investment. Trying to justify a process without being able to show that it’s doing that is just dishonest. Scrum is about staring problems in the face and fixing them. Dishonesty is an impediment; remove it.

First of all, if possible, show that you’ve released ahead of an original schedule.

You can do this by setting an original schedule based on the early velocity you expect to improve over time. You will keep changing that schedule as scope and velocity shift, but hang on to that original release date, and when you do your first release, compare them. Time is money, so when you release early you’re most likely under budget as a result.

Whatever the ROI targets of a release are, know them in advance. Then, after release, verify that you got the return if possible. If it’s too early to verify, brag about why you know it’s coming.

Beyond ROI, working software after each iteration has it’s own value as technical inventory. Measure how many iterations have resulted in working software that is ready to ship even if it wasn’t released. Come up with creative other uses for the working software even if the product/project was abandoned. Explain the benefit:

Happiness matters… right?

A wizard appears in a puff of smoke and booms, “ScrumMaster! With a twitch of my aged outstretched hand I will give you wealth beyond the grasp of your imagination… but you will never experience happiness again. What say you?! No one would take that offer and we’d all walk away really happy to have seen a real life wizard.

If you’re going to sell the happiness metric, your case must be: “increased happiness equals lower turnover, & lower turnover equals more money.”

Better than waterfall? Prove it.

“So,” your boss says, “you’ve had successes. How do I know these successes wouldn’t have happened in a waterfall project?”

The best suggestion I can offer: gather the same metrics on ALL waterfall projects and ALL Scrum teams. Then calculate averages and compare.

Time to release, improvement in productivity, happiness, total cost; whatever the metric, compare the average Scrum team’s score to the average waterfall project if you can. Ideal, but not always possible.

Find specific instances when requirements changed at the same time they would have changed during a waterfall project’s post-requirements phases.

This is usually a late change due to an external influence, not a change resulting from clarification of requirements that were low in the backlog priority (a waterfall project would have clarified such a “change” before beginning any work).

Theme not found. Dumping all thoughts.

Theme not found. Dumping all thoughts.