Management and Process Chapter 4

The Controversy over “Process” “Process” is a shorthand term we use for the methods and techniques used to build software. This includes methods and techniques at both the management level as well as the “Individual Contributor” level.

Fred Taylor's Scientific Management In the 1890’s Fredrick Taylor (a mechanical engineer) coined the term “scientific management” to describe a management philosophy of management techniques based on data. With this line of thought came the notion that managers should be trained in these techniques, and were “professional managers.” This line of thinking is still in operation today (just look at all the books and courses on management!)

Program Development as a Formal Process Consider that the word “Formal” derives from the word “Form”! “Program Development as a Formal Process” implies simply that program development ought to have a defined “form”. Form gives an element of predictability, by setting expectations about what should happen next. Too little process can result in chaos and unpredictability, while too much can result in predictability at the expense of flexibility and timeliness.

Capability Maturity Model (CMM) The CMM provides a systematic approach to developing maturity, where maturity is equated with predictability of quality and schedule. The CMM seems to presume that predictability and quality are the natural goals of software process. The concerns and driving factors of business are, in the author’s opinion, conspicuously absent as major factors in the CMM.

Critique of the CMM levels The CMM levels (levels that are supposed to indicate the maturity of the organization) make presumptions. CMM brings management into play rather late in the game (in several ways.)

Using the CMM to evaluate a potential employer Using the CMM as a “touchstone” to gauge an employer is useful. Employers that appear to be at a high CMM level could be good for engineers who are process oriented. Employers that appear to be at a low CMM level could be good for engineers who dislike structured environments.

Process management isn't for every organization Consider the research and development arms of organizations: they develop prototypes, not intended for market, as “proof of concept” tools. Where time to market is a factor, and phased deployment, or re-deployment, of software is a reasonably straightforward thing (such as web- based software at the “dot-coms”, rigorous process might prove fatal to the company.

Engineering Management “Engineering Management” are simply the managers of engineers. They are professional managers that may or may not be technically trained in engineering disciplines. Managers get paid to look after the company’s interests, not the individual contributors interests (although they are hopefully the same!) With management, show how an idea is in the business interests of the company! This is what will usually “resonate” with management.

Metrics Metrics are the feedback that allow objective (data driven) decisions about what changes should be made to a process, or what effect changes have had on process! Metrics allow us to decide whether a guessing technique (estimation model) is a reasonable basis for making future predictions.

Estimation models When trying to guess how long (or how many people) a project will take, we will always be guessing: no one can see the future. At issue is whether the guess we make is objectively driven. The best predictor (not foolproof, just best) of future behavior is past behavior. So behavior should be measured. The best way to measure is as we go along, so collect your data as you go!

Feedback from metrics First the questions, then the metrics: pose questions first, then decide what data should be collected to answer these questions. Don’t just start collecting data. Don’t expect metrics to answer every question you pose. Sometimes, metrics simply raise different (but better defined) questions.