There’s been a lot of interest recently in the application of lean principles to software development. See for example the 2003 book Lean Software Development: An Agile Toolkit for Software Development Managers by Mary and Tom Poppendieck. A basic principle of lean thinking is pull. In pull, the materials and services required by a given task are requested, or pulled, by workers responsible for that task just in time to make them available when they can be used. Pull devolves power to workers. Workers decide based on the conditions on the ground what they need and when they need it. The role of a plan is de-emphasized in favor of dynamic self-organization.

Pull may be contrasted with command-and-control. A good generic account of this contrast appears in Leadership in Project Management: Time for a Shift From Fayol to Flores. Here is a brief summary of this contrast based in part on that account.

The traditional style of project organization as a command and control regime is rooted in the work of Henri Fayol a century ago. This type of management may be summarized as: make a grand plan; set it in motion; apply thermostatic controls to it to keep it on track; and motivate workers by reward and punishment.

In contrast, an empowering pull style of project organization can be summarized as: have people figure out what they need from others, and make requests for needed materials and services (pull); allow people to volunteer to fulfill those requests; obtain commitments for the delivery of the requests based on mutually negotiated conditions of satisfaction; and foster an environment in which commitments are taken seriously.

Of course, one commitment may require other pieces of work for its satisfaction, leading to additional requests and commitments to fulfill those requests, and so on. The result is a network of commitments, a phrase coined in the eighties by Fernando Flores, a philosopher-turned-management-guru.

The conditions of satisfaction for each commitment, including its time of delivery, are negotiated between a requester, generically called a customer, and a provider. Recognizing that negotiation is a normal part of the customer-provider relationship empowers providers by acknowledging their autonomy.

In an empowering regime, people are motivated by having the freedom to produce things to their standards of quality and utility, by the honor of keeping commitments, and by the need to maintain the respect and trust of their peers. Trust means that people can rely on promised commitments for the fulfillment of their requests, so that they in turn can reliably make dependent commitments to other requests. To develop trust, team members make and keep significant commitments to each other, and they welcome feedback.

Consequences 

Organizing our work around autonomous pulled commitments means:

1. Incremental commitment. As we commit to and start developing functions and features in an iteration, we need the ability to pull commitments of assistance from other team members to perform specialized sub-tasks, to pair up with area specialists, or simply to obtain more bandwidth for the timely delivery of our commitments. So it must be the case that others leave time on their schedules to provide these types of assistance in a timely manner. This is only possible if we commit our time incrementally and in small chunks, and leave sufficient slack in our schedules. So the scheduling of commitments is an incremental, and highly dynamic affair, and the plan, as such, unfolds on a daily basis.
2. Local autonomy in distributing work. The overall decomposition of the work of an iteration into primary commitments is a group responsibility. But it is left to the provider of a commitment to divide its work as he sees fit, and to get others to work with him by pairing, sub-contracting, or pulling specific expertise. The best way to collaborate depends on the nature of the work and the sensibilities of the the collaborating individuals. Management does not drive these lower-level work distribution issues.
3. Provider estimates supersede group estimates. The estimates by which the team tracks the progress of commitments are those furnished after due reflection and negotiation by individual providers. Team members need reasonable time to reflect on what is being committed to, and to line up collaborators and include their inputs into estimates. Providers estimates are furnished dynamically during the course of the iteration as commitments are made. Group estimates arrived at in the planning game are considered as rough measures of required work. Nevertheless, group estimates are of great value. The exercise of group estimation allows all team members to contribute their experience to the planning process. And group estimates provide guidelines for comparison with the ultimate provider-supplied estimates. A large discrepancy between the two has to be understood as part of the negotiation for each commitment.

Unfortunately, software is notoriously hard to estimate. So in an atmosphere of high estimation uncertainty, what does it mean to meet commitments? Basically it means making fuzzy estimates with relatively narrow ranges, and consistently falling within the estimated range in a statistically balanced way.

It is unnecessary and counter-productive to measure estimation accuracy and judge people by that measurement. But estimation accuracy is one area for self-evaluation. And in a tightly-knit team, people will come to know the reliability of different people’s estimates soon enough, and to balance that with other variables that go into the trust equation, such as propensity to collaborate, amicability, and so on.

Upper management tracks the progress of the team as a whole by using burn charts: comparing group estimates for fully-completed commitments at a point in time to actual effort up to that point. Lower management tracks each individual commitment by comparing its actual effort with its provider-supplied estimate, raising a flag when actual effort approaches the pessimistic end of the provider-supplied estimate.

© Copyright 2006 Bolour Computing.