Tuesday, September 17, 2013

Good prioritizers; bad prioritizers

Even though there are many excellent techniques to prioritize a project or a backlog of work -- e.g. Story Mapping and MoSCoW -- it doesn't mean that it's easy.

In the various Agile approaches we usually split high-level prioritization and estimation between different roles: the stakeholder representative / customer or proxy / product owner (in Scrum) prioritizes the over-arching product backlog, while those who will do the work (typically a development or delivery team) estimate the cost.

Good prioritizers
  • seek bang-for-buck
  • own the project vision (or at least thoroughly understand the intent)
  • strive to get the "must haves" down to around 20% of the backlog
  • are great listeners who distil insights from a range of stakeholders
  • expect to learn a lot along the way
  • are privy to high enough level information to order the relative value of different pieces of work (quantification, e.g. cost-of-delay, would be even better!)
Bad prioritizers
  • try to please everyone, and may be punished for "poor customer service"
  • negotiate for as many "must haves" to be around 80% of the backlog
  • think they know pretty much what's needed up-front
  • struggle to synthesise a coherent picture from multiple stakeholders
  • bargain with or push the delivery team
  • may be exposed to too much detailed information
Entrepreneurs, especially those who are spending their own cash seem to have an advantage in terms of setting priorities because they are crafting their vision (although they may struggle with new information that challenges their pre-conceptions) and typically have both significant financial and emotional investment.

In an organizational context these advantages can be easily lost in the org chart.  We need to deliberately set up or carve out favourable conditions for our prioritizers to do a good job.  Then our Agile techniques can work wonderfully well.

Friday, September 6, 2013

My Talk on Design by Contract, Functional Contracts, Automated Testing and Static Typing

Last night I gave a well-received ;-) talk on Design by Contract at the Melbourne Functional (Programming) User Group.

Here are the slides:


For clojurists: James Sofra said afterwards that my talk reminded hime of this recent talk: Beyond Contracts.