Signals to our customers

Tuesday?s reading group session prompted me to consider what signals we send our customers, and how they receive and process them. I am sometimes frustrated to be seen as a generic development resource (seat-filler) when our offering is (or should be) larger. Some of this is just habit on their part — they might have been looking for bodies to fill out a Gantt chart at the start of the sales cycle. But I wonder how we contribute to this.

Mistaking means and ends is one source of confusion. For example, consider a tasking session. At the end of a successful tasking session, the team has a shared view of the work. The tasks on the board are secondary. If the tasking was successful, one could erase the board and any single team member could re-create a serviceable task list. But outsiders often mistake the tasks on the board as the primary output.

This gets worse when we have different reference points. Agile teams are accustomed to relying on shared, implicit knowledge. Spending time, and creating throw-away drawings to advance shared understanding is a normal process. But many environments are rooted in artifact based processes: project charters, specs, sign-off sheets, test plans, etc. If a meeting produces an artifact, that must have been the meetings purpose.

And so we get the road-map that “grows horns and fangs” and transforms into a fixed-price, fixed-schedule, fixed-feature monster. How do we stop this from happening?

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply