The class had an interesting discussion around Project view in which high tech development projects characterizes the work in terms of four key variables:

Quality, Cost, Time and Scope.

Allen initiated the discussion around how the project success is dependent on these 4 variables.

Allen projected the slides which had his own handmade graphs showing the impact for these variables on the project success and then whole class has discourse around the graphs on each dimension

The first variable picked up was Time. Time is a crucial dimension of production activity. It turns out that an appropriate time line is a huge enabler for a project. However too aggressive a time target dooms a project to undue hast, unrealistic delivery times and, potentially, failure. Similarly, an excessively long time frame can defocus a team’s attention and starve the project of valuable feedback and checkpoints.

“How does a project get to be a year late?… One day at a time.” (Brooks Jr., 1995)

Second variable on which project success is dependent is Scope. It was deduced during discussions that scope management is very crucial for project success. Typically project scope will expand over time to include more features in greater detail as you learn what the customer wants/needs/really needs. The feature list of a project should always be clear and concise. Too large a list of features or feature creep generates problems of priority and coherence. A smaller set of the most crucial features probably has a stronger (positive) influence on the underlying architecture of the product. And “less scope makes it possible to delivery better quality”

“If you actively manage scope, you can provide managers and customers with control of cost, quality, and time.” (Beck, 2000)

Third variable is Quality which was a bit contentious and generated some debate. However quality might be defined we should keep in mind that a definition of quality is a non-trivial exercise. Quality is usually highly contextual, situated in a prevailing culture of what constitutes good or bad quality. In the case of software the product (or service) is not a physical good and so does not wear out in the way that hardware does. Hardware degrades over time due to physical wear and tear, breaking down and mechanical or physical failure. Software still fails and so it undergoes maintenance work to fix or enhance it over its economic life. For the purpose of a particular project the product’s quality is generally a negotiated concept. Don’t deliver something you know hasn’t been tested, or fails the tests; quality should be used to set thresholds and targets, using it as a control variable undermines and destroys the values we all aspire to.

“Quality is a terrible control variable” (Beck, 2000)

The final and perhaps the most important variable discussed was Cost. The project go, no-go decisions are generally taken on the cost basis only. The “Estimation as practice” relies on the skill, knowledge, resources and contexts of those involved in a situation. Estimations are ‘situated’ in the same way that other kinds of knowledge work are situated amongst context, history, place and moments in time. Accepted wisdom suggests that you make a guess, double it and hope for the best. Why? Novel valuable high tech requirements are by definition unknowns. And estimating how to produce an as yet unknown, unfinished thing is necessarily an art, not a science. But we don’t need to leave it there; there are some approaches and practices, that combined, enable us to make informed ‘guesstimates’ or scientific wild-ass guesses (SWAG) that help us overcome this bind.

“more software projects have gone awry for lace of calendar time than for all other causes combined… but adding manpower to a late software project makes it later.” (Brooks Jr., 1995)

For estimation, Allen introduced the class to an interesting notion of Planning Poker. Planning Poker is “played” by the team as a part of the Sprint Planning meeting. A Planning Poker session begins by the customer or marketing representative explaining each requirement to the extended development team. We use the term extended development team (often called the “whole team” by agile software developers) to refer to all those involved in the development of a product, including product managers, project managers, software developers, testers, usability engineers, security engineers and others. In turn, the team discusses the work involved in fully implementing and testing a requirement until they believe that they have enough information to estimate the effort. Each team member then privately and independently estimates the effort. The team members reveal their estimates simultaneously. Next, the team members with the lowest and highest estimate explain their estimates to the group. Discussion ensues until the group is ready to re-vote on their estimates. More estimation rounds take place until the team can come to a consensus on an effort estimate for the requirement. Most often, only one or two Planning Poker rounds are necessary on a particular requirement before consensus is reached.

Each group was instructed to use Planning Poker to estimate the cost in number of hours to build the Lego robot the class had built in the earlier session. Our group has 4 people and we used the provided poker cards to deduce the estimates. In most cases our estimates were quite close but still we need a few iteration of card playing before building the consensus around estimates.