There are contests:

  • The Super Bowl

    what can you Hemi contest

    Tim Kowalec, 2005 finalist of Chrysler Group's "What Can You Hemi(R)?" Contest

  • The World Cup
  • The World’s Strongest Man

And then there are other ‘smaller-scale’ contests:

  • Fastest to chug a glass of milk

At the workplace, contests run the gamut:

from the noble:

  • Let’s raise $10,000 for the Red Cross.

To the aggressive:

  • Double our revenues in one quarter.

To the strange:

  • Longest requirements document get a prize.

Sadly, I lived this last goal. And I am not proud of it. There is, however, much learning that came from this experience.

Earlier in my career, it wasn’t strange to see my fellow Product Managers and I spending multiple weeks writing lengthy, epic requirements documents for highly-dynamic, frequently changing interactive online projects. In the early 2000s, this wasn’t out of the ordinary.

We’d spend weeks writing use cases, documenting flow, sketching out prototypes, addressing change control boards.

If a colleague wrote a document that was 50 pages, then 51 pages was the benchmark. This wasn’t a ‘corporate/endorsed’ goal per se, yet we took it pretty seriously. If we needed to snap another screenshot, map out another sequence of events to get to 51 pages then it happened. We had the quality vs. quantity scale confused.

Surprisingly, we still delivered stakeholder value (or at least we thought we did?) through these text-heavy masterpieces. We presented our masterpieces (page-by-page!) in long meetings; the developers were able to understand the site structure; the designers visualized a look and feel that mapped to our vision. Management would be shocked to know how much time we flitted away in these meetings. Sadly, we knew no other way.

This crazy contest of expanding requirements documents isn’t the point here. That was a symptom of bad management, demotivated employees, unclear goals, lack of understanding or some odd mix of the four.

The point is that there’s a better way today to deliver stakeholder value, utilize your talented and gifted team, and inform stakeholders. In hindsight, if only I had a way to turn back the clock and redo all those projects with a more ‘enlightened’ perspective.

It’s agile.

Agile development isn’t just about holding a standup or moving stickies on a whiteboard. It’s a different way of thinking about your teams, products and services.

I have a new contest for today’s workplaces: Deliver value in the most efficient way possible.  If you’ve embraced agile, you’re winning this contest every day.

Dan Naden

  • New to agile? Or are you experienced with agile, but believe you’ve hit a wall?Ask us how we can help. We can help you clear the path for your teams to get back on track.

Join the Discussion

    • Air

      Thanks for the interesting article. You have mentioned the important point about the requirements document. I agree with you that communication is a key for success. In Agile team, I always make sure that all parties have the same understanding about the product. The development team must know what the customers really want. So we will be able to satisfy them by delivering the product/service that can bring the greatest value to customers. When I work in Agile team, I usually start from grouping and prioritizing the tasks, and then developing the plan. So I know what I really need to do and deliver, without using the long list of documents.

    59 − = 58