A coworker recently used the familiar nursery rhyme, Jack and Jill, to illustrate what not to do when a project has issues, and I thought I’d expand on that and share it here.

Clear Requirements

“Jack and Jill
Went up the hill
To fetch a pail of water.”

— Traditional English nursery rhyme

Looking at the text, we see a basic goal: fetch a pail of water. Missing here is the agile development story statement structure of, As a ___ I want ___ in order to ____.  We see the requirement for a pail of water, but without that business need, the in order to part of the story statement, we’re lacking success criteria. We don’t know why the water is needed.

The story statement isn’t just lacking success criteria, it’s unclear. Does the water have to be in a pail? Does the pail serve some significance other than a way to carry the water? Would an alternate vessel, like a jug, be sufficient? Water (and other things) tends to roll down hill. Is up the hill the only location for water?

Agile best practices call for the story statement to be constructed so that it doesn’t dictate the method of delivery. Product is responsible for supplying the what and why of the development effort; the Developer (who) makes the technical decisions on the best method of delivery (how and where), and QA/ testing ensures that the requirements where met in the sprint (when).

If this were actually an agile project, it would be pushed back to the Product Owner, not accepted into a sprint until the requirements were Ready (agile definition of story readiness). But the task was accepted, Jack and Jill went up that hill; the need is to get the pail of water.

Status and Communication

“Jack fell down
And broke his crown,
And Jill came tumbling after.

Up Jack got
And home did trot,
As fast as he could caper;
And went to bed
And bound his head
With vinegar and brown paper.”

— Traditional English nursery rhyme

A large part of the reason we use agile development methodology is the clarity it provides. Agile ceremonies require the Dev team to talk to one another and the Product Owner, to make the status of what they’re working on clear. The Scrum Master encourages the delivery of these status updates, and when necessary, holds the team accountable for updating status and actually delivering. Accountability comes in the form of burn down reports, among other things, reports that show how much was accomplished over the course of a sprint in terms of the points assigned to the story. That burn down report can and should be broken out by contributor. Failure to update your story status would result in stories not marked complete within the sprint, meaning no burn down (a burn down of zero). If you’re not delivering on goals, why are you here? Not a question any developer wants asked about them.

Jack fell, and completely failed to communicate to Jill, resulting in her falling too.

There has been a priority shift: the primary objective of the project, the pail of water, has been abandoned. We’re in disaster recovery mode now. And we’re down a resource: Jack hasn’t just failed to provide a status update, he’s removed himself from the project completely.

“When Jill came in
How she did grin
To see Jack’s paper plaster;
Mother vexed
Did whip her next
For causing Jack’s disaster.”

— Traditional English nursery rhyme

As frequently happens when the project goal is out of reach, blame is assigned, and as usual when it gets to the finger pointing stage, blame is assigned incorrectly. Jill didn’t cause Jack’s disaster, in fact, his failure to communicate created a disaster for her, making her fall too. But because of her reaction, Mother decided she was at fault.

If agile ceremonies were being preserved, the project status would come out in the daily scrum meeting, and notification escalated through scrum of scrums by the Scrum Master and/ or Product Owner. As it is, Jack and Jill failed to quickly, clearly, and correctly communicate with their stakeholders (represented by Mother), resulting in reactive action.

Amid the recriminations and disaster recovery efforts, we have no idea what happened to the pail of water.

In Conclusion

• The lack of success criteria meant we weren’t ready to attempt the project.
• The project went ahead with poor requirements.
• Communication within the team and to the stakeholders was lacking.
• The primary project objective was abandoned, and the project resulted not just in a failed enhancement, but in making the situation worse: we’re down 1 resource, and another has lost credibility.

It was not a successful project. It could have been saved if communication had been clear. Either Jack could have told Jill about his fall so she could avoid it, or Jill could have spoken to Jack, inquired for his status, and therefore known enough to avoid falling. Even if Jill could not have avoided the fall, she wasn’t reported as being hurt. The story of fetching the pail of water was assigned to both of them: she could have gotten another pail of water from the hill, and delivered the need. She could have chosen to contain her laughter at Jack, at least until after she’d presented the completed effort to the stakeholder, Mother. Perhaps then her stakeholder wouldn’t have lost confidence in her (or whipped her).