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.

Capability Maturity Model (CMM)1. Initial (chaotic, ad hoc, heroic) the starting point for

use of a new process. 2. Repeatable (project management, process

discipline) the process is used repeatedly. 3. Defined (institutionalized) the process is

defined/confirmed as a standard business process. 4. Managed (quantified) process management and

measurement takes place. 5. Optimising (process improvement) process

management includes deliberate process optimization/improvement.

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.

Process management isn't for every organization For project with 200,00 LOC and two years

Technical Model Use senior software engineers and not managers 1200 lines of code per person month

Managed Model Use two managers and 16 junior engineers 500 LOC/pm

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.