The Million Dollars Picklist

End of sprint demos are ones of the key benefits of Agile methodology over Waterfall.
They pull the curtain during the "build" phase with the intent to collect early feedback from a selection of key-users and influence design for the best.
It avoids any big disappointment when starting UAT by giving the implementation team the possibility to rectify a design and align to the customer expectations before it all go pear shape.
Now, be careful, if managed loosely it can also open the door to project disasters and scope creep.

Empowering users to influence a solution design, doesn’t mean you’re giving them the keys of the kingdom. You’re meant to capture what their say; you’re not meant to do as they say!

And if you believe that always saying ”Yes” to change requests will get you the Vendors' Gold Medal, wait until I tell you the story of the "Million Dollar Picklist"...

This story was told to me by a WebSphere expert but still applies to a Salesforce implementation.

"The customer had decided that they were going to write all their WebSphere portal components using IBM WebSphere Portlet Factory, a tool designed to make portlet development quick and easy without the need of Java nor web development knowledge. However, the key-users insisted the look & feel had to be a pixel-perfect copy of their intranet branding and general navigation.
The level of customisation Portlet Factory needed to create the code and get the right UI was ludicrous. In Portlet factory we had to write custom components for the tooling to display components correctly and picklists, in particular, were a real pain.
Using standard Java, JSP and CSS we would have been able to create the look & feel very quickly and easily and do the whole project in a couple of months. Because of incompatibilities between the business requirements and the limits of the platform of choice it took nearly a year and was way over budget.

Show & Tell demos happen during the build phase. At this time, "the train has already left the station", there's no real way back without big troubles...

And this is what is generating confusion: on one hand, we ask the key-users to provide feedback on a half-baked solution but on the other hand we already know that we have limited room for manoeuvre. Crystal clear communication is key to address these situations.
I’m listing below some of the typical risks of incorrectly managed Show & Tell demos starting with the one which would have prevented the "Million Dollar Picklist".

Users want new features

  • It’s fine but there’s a cost impact though, and you should communicate this your users immediately.
  • The cost can be a budget increase or a feature trade-off (you want this, then you won’t have that so that we all meet the deadline). For this to work, you need to have something to a trade-off in a clear way.
  • User stories are great to avoid scope-creep by keeping the total number of points close to what the team’s velocity can realistically achieve.

Users prescribe implementation methods

  • Make sure that your users express their comments about behaviours and not technical choices.
  • Explain that the solution you will come-up with will meet the functional requirements but also need to take into consideration cost of storage, maintainability, data modelling, usability, design patterns, Salesforce roadmap, re-use of existing code, governor limits, deployments challenges etc...
  • Understand that you are responsible for the quality of the solution you are delivering, not your customer’s users.

Users want a different solution

  • Going back to design board will require you to stop the project and come back with new cost and duration estimates.
  • To prevent this to happen you need to make sure you start your build with the complete set of user stories in scope for the current version as well as a clear Solution Design Document signed-off by your customer.

Users want small changes

  • Hopefully in most cases, though, feedbacks will be small enough to be absorbed by your team's capacity without adding risk to the project.
  • Make sure that you keep assessing the required effort to make a change before any commitment: small changes can sometimes require lot of effort to implement.

I hope you enjoyed this post. Don't hesitate to ping me on Twitter if you have any comment or question. Bye for now!

Fab 🐸