Avoiding the Best Practices Trap
Darmstadt, Germany 2018
Agile development process is routinely overlaid in an attempt to bring order out of chaos, sometimes to good effect, but often resulting in fragmentation of important but undeclared processes. The future value of some fully-realized agile work-place may not make up for the losses incurred in laying down a new process. The problem is not necessarily in the new process but in how it is applied.
To minimize risk in introducing process change, it’s essential to understand the process that is being changed. As obvious as that sounds, even mature, cooperative teams are not always able to articulate the complexity and ambiguity of what they have to deal with in order to deliver software.
Our central premise is that most process or practice changes should be adopted only as remediation to some actual problem faced by your team on a project. As self-evident as that seems, it is surprisingly common for agile advocates to throw caution to the wind in their enthusiasm to adopt “best practices”.
Topics we’ll cover to develop the narrative are:
Approaches to story composition: Decomposition vs Estimation Modeling types of work and classes of service to discover tacit processes Modeling the work, not the worker. Avoiding mixed metaphors: Verifiably Done vs Releasable vs Deliverable. Making hard choices: Verifiably Done vs. Feature Complete in the context of iterations, time-boxing and release management. Measuring outcome: what is a meaningful measure; getting to outcomes we can trust. Our standard of improvement is better margin, improved time to market and reduced total cost of ownership. Let’s talk about how to get there without introducing unnecessary risk of adopting practice changes based on the theory that “best practices” somehow always make things better.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.