The Project Song

Sung to the tune of Ballad of Thunder Road

You might have heard the story
and maybe lived the tale
about a fateful project
that was driven off the rails

The business passed on planning
The budget was a SWAG
The PM says ‘Go faster,
don’t you let this project drag!’

The BA got canned early
But no one’s sayin why
We think he quoted Covey
and the sponsor hit the sky

CHORUS:

And there is scope creep, scope creep
everywhere we go
Planning is for pansies and
the budget is a joke
And there’ll be rework, rework
till the day we die
Don’t bother with requirements
We’ll invent them on the fly

The PM and the architect
Threw angry words today
It seems she took exception to
the phrase ‘No freakin’ way!”

Designer’s in a funk now
His feature got the axe
He took a month’s vacation and
we hope he’s comin’ back

The engineers are fuming
The schedule is too tight
Release was planned for April
Now it’s due on Friday night.

* CHORUS *

We had a QA lead, she was
the best we could afford
When she fin’lly saw the schedule
she ran screaming out the door.

The testers went to job fairs
The sponsor can’t be found
But the PM’s gonna ride us
till we run into the ground.

* CHORUS *

A Tale of Two Stories

SAME USER STORY – TWO VERSIONS

Both of the following are legitimate Agile User Stories. They are very different because they would be consumed by very different types of teams. The overriding principle is know your audience and write for them.

Story 1 is appropriate for a US-based start-up team. They have a good relationship with a co-located Product Owner who can spend time with them as needed to answer questions, give guidance on design, and provide feedback on mock-ups or prototypes. This is generally considered an ideal environment for an Agile development team. Because the team has a UX designer on board and a strong lead developer, they do not want the User Stories to be prescriptive in nature. In this environment the Agile BA must give stories a light touch, but provide enough clarity to allow for estimation and prioritization.

Story 2 is for an offshore team that does all the coding but works through a BA or design lead based in the US. The team understands English pretty well and the company does not want the overhead of formal functional specifications. The developers are used to working in a short turnaround loop with a remote liaison. The cross-cultural challenge as well as the remote location and time-shifted work require more detail in the story to prevent confusion, provide consistent naming and UI, and to lower the delay caused by many back-and-forth questions.

BUSINESS SCENARIO

Internal sales staff receive new leads through a form submitted on the company website. The leads arrive by email and the staff must relay the leads to the appropriate salesperson based on the geography of the prospect. An internal sales portal is being built/configured to allow in-house staff to enter the raw information from sales leads. The system will then route the lead to the right sales rep based on geographic mapping. The user must also be able to work from a list of printed lead information.

STORY TITLE

“Enter New Sales Lead”

USER STORY 1 – STARTUP TEAM

As a sales user, I want to send a new sales lead to the appropriate regional sales rep so that the rep can quickly contact the prospect.

Acceptance Tests

  1. When I enter all required contact information, then the system saves and routes the lead.
  2. When I omit any required field, then the system informs me about the missing information without losing any of the data I have already entered.
  3. When I successfully enter and save a new lead, the system displays a success message containing the name and email of the last lead entered.

USER STORY 2 – OFFSHORE DEVELOPMENT

As a sales user, I want to enter personal information about a new sales prospect and save* it to the sales lead database so that the appropriate regional sales rep can quickly contact the prospect.

Required Fields:

  • First Name (20 characters)
  • Last Name (20 characters)
  • Email Address (validate format as user@domainName.tld)
  • Phone Number [formatted as (NNN) NNN-NNNN after entry]
  • City (30 characters; minimum of 3 characters)
  • State (drop-down list of US States, showing abbreviation and name, sorted alphabetically by Abbreviation, display format: AA – XXXXXXXX; Data source: http://www.50states.com/abbreviations.htm)
  • Zip Code (10 characters; minimum of 5 characters)

Acceptance Tests:

  1. When I enter all required contact information, then the system saves* the record.
  2. When I omit any required field, then the system informs me about the missing information without losing any of the data I have already entered into the fields on the screen.
  3. When I successfully enter and save a new lead, the system displays a success message containing the name and email of the last lead entered.
  4. When a new lead is saved, the entry screen is cleared and reset, ready for a new lead to be entered.

 

* You’ll note that the language of the second story and related tests has been made more limited. My experience with offshore teams suggests that requirements should be narrowed to prevent unwanted work. Whereas the co-located team would likely spin off a new “Route Sales Lead” story, a remote team that earns money by the hour might choose, without asking, to make the ‘routing’ part of the original story. You can argue that the original story be treated as an Epic and automatically split into smaller bites, but that is beyond the scope of this small article.

Recruiters – Get Agile!

sleepy-dog800

Above: Me after reading your exhausting list of job requirements.

Please. Enough of the the laundry list taken from the practice manual. These copy-and-paste job req’s are enough to make me ill. Wait, is that part of the test? Are you proving that I can stave off sleep long enough to read all 60 bullets and respond to your boilerplate ad?

KNOWLEDGE vs. SYNTAX

Look. The people you really want on your team are not spending their days memorizing the “numerous well documented patterns and techniques for filling in the intentional gaps left in the Scrum approach.”

That’s syntax. That’s like advertising for a programmer and saying, “familiar with many clever ways of creating a conditional loop.”

Agilists reach for tools and techniques when we need them – as the need arises. The whole idea of “maximizing the amount of work not done” is that you don’t waste time doing things you don’t need yet. That includes memorizing pages from a book just so you can impress an HR screener.

My copy of Agile Retrospectives lists eight ways to gather information. Do you think there are less than eight more available with a quick Google search? Your “patterns and techniques” bullet might was well say, “Working knowledge of Internet search engines.”

LONGEVITY vs. EFFECTIVENESS

Does your requirement of “at least two years” in the role really tell you anything? Wouldn’t you like to know if those two years were effective?

Why not skip that one and use this in the interview:

“Describe some of your favorite Retrospectives. What activities did your team enjoy and what experiments came out of them?”

If I crushed that question in an interview, would it matter that I had 6 months or 6 years of experience? Maybe I’m the kind of person who has run a tight continuous feedback loop for the last year and my team experiments resulted in a huge productivity boost, or reduced team churn, or created a leap in trust and transparency. On the other hand, maybe I’ve only led one Retrospective in the last year and it bombed. Your “two years” criteria tells you nothing about my effectiveness. Only about my ability to stay hired.

GET AGILE

How about this: Maximize the amount of bullets not fired so we can all get to the interview stage. Start thinking like an agilist instead of someone writing a Scrum book.

Think MVP: What are the minimum skills we need in this position? How would we prove that the candidate has them so we can get someone good instead of someone who can cram well before a test?

Conduct a job requirements Retrospective. What is the quality of the product (candidate) I’m shipping (hiring) as a result of the material presented?

Maybe you find yourself in Mark Twain’s situation:

“I didn’t have time to write a short letter, so I wrote a long one instead.”

I get it. We’re all busy. As I’m writing this, I’m choosing to delay the six things on my written to-do list.

But let’s not bullshit each other. We prioritize every day. We do what we think is important and defer the rest.

We also make judgments about others based on the effort we perceive from them. We regularly judge a product or service company by the responsiveness (or lack of) in their sales department. First impressions matter.

THE QUESTION

If your company can’t find the time to write a creative, enticing job description… why would we as candidates assume that you’ve taken the time to do other important things like articulate your mission, define a good strategy, staff appropriate to the demand, or create a healthy culture?

Photo credit: Kerry Lannert