The basic principle is that there should exist a contract between software development and the business. The business must choose what programs get developed, release dates, and feature content (expressed in terms of business requirements), but all the time subject to the capacity constraint (see below). The software development department must estimate feature sizings, and then deliver on those estimates with an appropriate level of quality and productivity. The capacity constraint states that at no time should the requirement for resources (in person-days) exceed the capacity (also in person-days).
Adherence to this principle ensures that software development can act in a professional manner: estimating and then delivering on estimates. At the same time, the business retains the controls it needs so that it can make the appropriate business tradeoffs in a timely fashion. This fosters a good relationship between the two sides, helps to ensure business success, and provides a sane working environment for the software developers which in turn is the single greatest boost to attraction and retention.
This approach can be applied to any situation where software
is being developed including
software vendor organizations,
software consulting businesses,
application service providers,
'.com' companies,
and internal company IT.
Implementation
While the principle is straightforward, it is very difficult to implement in practice, and few software development organizations do a good job of it.
It takes active effort on the part of the software development organization to expose exactly what they are currently working on, what they intend to work on in the immediate future, and what they can potentially be working on instead. These work elements need to be expressed in terms of business requirements, with appropriate sizing information attached, and at an appropriately low level of granularity. It requires a large commitment from the software development organization to have this information readily available at all times. The commitment involves both time and appropriate managerial organization.
When this information is unavailable, the business does not have what it needs to make tradeoffs that satisfy the capacity constraint. For example, if the business situation is such that it is necessary to insert a late-breaking requirement into plan (for example, a large sale hinges upon a new feature), then it will not be feasible to decide what to remove from the plan to make room for the new requirement unless this information is available.
While it is possible to muddle through as long as the number
of necessary,
late-breaking changes is small,
when the changes become a flood
(as they will inevitably become in any successful enterprise)
appropriate processes must be in place to deal with the situation.
If not,
development will become over-committed,
miss dates,
throw out functionality chosen without reference to business needs,
deliver poor quality products,
experience loss in productivity due to thrashing,
and will have no time to implement
improvements in their software development practices.
As a secondary effect, developer morale will suffer leading
to a "sweat shop" reputation,
the inability to attract talented new staff,
and an increase in developer turnover together with
its massive, but often under-appreciated, costs.
Road-map
To implement the philosophy, we will need to travel the following road.
You may read about the details of each step here.
What's Next?
Implementing this approach is not a trivial undertaking. The trick in process improvement is not defining the process itself, but rather in implementing the change of behaviour within the organization. The simpler the process, the higher the likelihood that the change can be implemented and will stick. That is why I advocate this relatively straightforward planning methodology. It captures the essentials, targets the most problematic areas in typical software organizations, and is simple to understand.
If you need consulting help in implementing such an approach,
please call.
(home)
Copyright © 2003, David Penny