Repeatable results over repeatable processes

DAD teams focus on producing repeatable results, such as delivering high-quality software which meets stakeholder needs in a timely and cost effective manner.  DAD teams do not strive to follow repeatable processes.  The observation is that because each DAD team finds themselves in a unique situation, to be most efficient they need to follow a unique process tailored to reflect that situation.  That “unique process” may be comprised of a relatively standard lifecycle and common practices such as architecture envisioning, database regression testing, non-solo development, and many others (granted, those practices may be tailored to reflect the situation too).  The point is that each team in your organization may follow a different process, albeit processes which share similar components defined by a common process framework, while achieving the results required of them.

This may of course be heresy in some organizations.  The danger with “repeatable processes” is that they grow in size over the years to address all possible situations, and as a result address none of them very well.  Imagine a project team that is large and has regulatory compliance concerns.  This team will tailor its practices accordingly.  Now imagine a small team that doesn’t have to address regulatory concerns.  An organization focused on repeatable processes might have that team follow the same process that the previous team followed, even though some of the practices had been tailored to meet scaling factors that don’t apply.  In other words, the repeatable process included some aspects that were overkill for the second team, thereby impacting their ability to deliver in a timely manner or in a cost efficient manner.  In the vast majority of organizations, when given the choice, stakeholders prefer to spend the money wisely and have the solution delivered in a timely manner, not to have the team follow a consistently “repeatable process.”

Have any Question or Comment?

2 comments on “Repeatable results over repeatable processes

Sometimes stating the obvious reorients us to reality. Thus was my experience from reading ‘[t]he danger with “repeatable processes” is that they grow in size over the years to address all possible situations, and as a result address none of them very well.’ Simple, obvious, yet profound and well grounded in software development experience.

In former life as a quality engineer, establishing procedures to ensure a process remained within control limits on an assembly line made good sense because the goal was to minimize deviation in the product. Repeatable process was our means to that end, and continuous improvement required the process itself to be continually tweaked to reduce production costs _without_ causing change to the product.

Commercial software development teams are _never_ supposed to produce exactly the same product, so the core assumption for process control does not apply. (One partial exception may be configuration deployments, where consistency, with some replication, is necessary.) Even when reverse engineering or porting, “repeatable results” for software does not mean reproducing the same product; rather, as you described, the desired result is efficient delivery. So the drivers for control of software development are cost and value. (We may even broaden our measures for cost to include quantifiable risk.)

That said, agility implies continuous learning with a goal of continuous improvement, so repeating results is less valuable than improving results. If it cost us 100 hours per function point to deliver project A and found 80 percent utilization of released features, we would like to spend fewer hours/point during project B and achieve greater utilization. [So let me offer my own statement of the obvious: Delivering fewer features faster should be achievable simply because the number of confounded paths through an app are reduced.]


Leave a Reply

Your email address will not be published. Required fields are marked *