Management and Process

1. Management and Process Chapter 4

2. 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.

3. 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!)

4. 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.

5. 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.

6. Capability Maturity Model (CMM) • Initial (chaotic, ad hoc, heroic) the starting point for use of a new process. • Repeatable (project management, process discipline) the process is used repeatedly. • Defined (institutionalized) the process is defined/confirmed as a standard business process. • Managed (quantified) process management and measurement takes place. • Optimising (process improvement) process management includes deliberate process optimization/improvement.

7. 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.)

8. 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.

9. 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.

10. 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

11. 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.

12. 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.

13. 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!

14. 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.