Micro-Optimizing

This gene represents the adaptive nature of agile processes. We employ the term “Optimizing” because, in most agile methodologies, teams are empowered if not encouraged to modify aspects of the development process or dynamically adapt to changing circumstances. “Micro” is used to indicate that small process adjustments and improvements are made frequently and as needed. For example, the Scrum process requires a “Sprint Retrospective” in between iterations. Likewise, Alistair Cockburn – author of the Crystal methods -- believes that as the project and the people evolve over time, the methodology so too must be tuned and evolved. Crystal therefore calls for reflection workshops to be held after every delivery so that the methodology is self-adapting.

This relates to the concept of Double Loop Learning, as applied to software development: Single Loop learning describes the plan-do-check-adjust cycle where we learn and increase the efficiency of what we are doing. Double Loop learning is when we step back and question our assumptions and goals and revise them.

As an example of this, consider code reviews in a software development organization that has a process in place that calls for software inspections. This process may include an onerous series of tasks such as the manual preparation of code review packages. There are so many components, checklists, and forms required to be part of the package that it may take a developer a whole day (or from a project management perspective, a person-day worth of effort) to produce this package. Then perhaps several days elapse before a meeting can be scheduled for all of the necessary players to convene and perform the code review. Finally, action items must be documented, implemented, and verified.

Traditional improvement efforts will focus on automating this process and making it more efficient. The result of single-loop learning may be process enhancements and automations to speed up the code review process for example by automating the review package generation task.

On the other hand, a team that exhibits characteristics of double loop learning will question the goal of the inspection process itself. What is the return on investment (ROI), or value-add, that this inspection process brings to the development effort? It may find that the intent is to simply detect and correct coding defects. The team may react by eliminating this process altogether and adopting the use of pair programming (as a flavor of real-time code inspection) in conjunction with static analysis tools, and even arrange for customer demonstrations and user involvement events, in a push to even further attain the goal of detecting software defects at the implementation level as well as at the level of system users’ needs.

Classic development approaches, even ones that employ a single-pass waterfall, can exhibit a “light” flavour of this gene: heavyweight processes often call for Lessons Learned activities at the completion of a software project. The problem is that this usually produces a Lessons Learned document that rarely feeds into the next development cycle and has little improvement effect on subsequent development projects. In the context of Agile, however, the sprints are short enough and retrospectives frequent enough so that process adjustment is near-continuous throughout the life of a project.

Another aspect of many agile methodologies is that teams are often empowered to self-regulate workload. Teams are trusted to self-adjust and gradually learn about how much work they can handle in a given period of time (e.g. sprint). In Scrum, the measure of “Velocity” or “Sprint Velocity” represents how much product backlog effort can handle in one sprint. It is established on a sprint-by-sprint basis as the team learns about the project and about working with each other. Typically, team velocity improves as sprint cycles are completed and experience gained.