Thanks for the theory, let me solve the problems I actually have first.

Thanks for the theory, let me solve the problems I actually have first.

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 helpful 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 essential point is to encourage you to adopt a practice change only as remediation to some actual problem faced by your team on a project. As self-evident as that sounds, 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 support this narrative are:

  • Approaches to story composition: Decomposition vs Estimation
  • How to get all the work on the surface: defining types of work and classes of service.
  • 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, timeboxing and release management.
  • Measuring outcome: what is a meaningful measure; getting to outcomes we can trust.

The goal of this session is to illustrate how to take a more scientific approach to identifying inefficiencies and impediments faced by your team, and how to measure the outcome of the practice changes you adopt, to insure that the practices you adopt will actually be best practices for your organization.

We all want the same thing: improved margin, 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.


Michael Godeck has over 25 years of experience as consultant to Fortune 500 telecom, aviation, insurance and pharmaceutical clients on software development and development practices.