… Your company likens software development to a production (manufacturing) environment and expects people and processes to reflect the same.
???
A number of organizations use Waterfall based processes for software development that call for all requirements to be gathered at the start of a project.
Software project managers and delivery departments (IT) are often evaluated on how well they meet the budgetary and schedule constraints while delivering the agreed to scope. Variations are frowned upon and delays are attributed to poor planning — if the team had done a good job in anticipating and planning, the team would not have been surprised in the middle of the project, and would have delivered on time. To get better, then, the bias is to try and drive out the variation by doing more rigorous up-front planning.
A perfect metaphor for this is manufacturing — isn’t the team producing units of work just like in a manufacturing environment? If manufacturers can get to 6-sigma tolerances then can’t software engineers do the same?
It is important to note that manufacturing environments work well because:
- The requirements can be well defined and these requirements seldom change.
- Production systems have a very low variance of time spent on a step — each unit produced is the same and six sigma tolerances can be defined for each unit and for the time spent at each step needed for the production of the unit. Variability is the enemy in manufacturing and needs to be driven out.
Treating software development as manufacturing gives a false impression that everything can be planned upfront and that subsequent deviations from the plan are due to people problems, i.e., people did not plan well enough.
But, software development differs significantly from production processes:
- It is fallacious to assume that software requirements can be well defined and that these requirements will seldom change. If there is one thing about software development that we have learned over the years it is that requirements will change due to market changes, competitor moves, regulations, and just plain insight gained from seeing a mockup or a prototype.
- Meeting the original requirements as defined is not the end goal; the only measure of success is whether the implemented solution solves the customers’ real problem.
- In software development projects the requirements and technologies used differ — no two projects are exactly the same. Learning (discovery) is the central value creating activity in software development; consequently, the definition of tight variances is fraught with danger — there is a much higher variance of time spent on a step. Put another way, if software development was analogous to manufacturing then software development teams would be highly successful by simply writing the same code over and over again. However, reality tells us that every worthwhile software development project is a custom one-off endeavor to solve a singular problem.
- In manufacturing, backflows are rare and viewed as errors. But, in software development backflows are common (whether encouraged or not) and help learning.
Therefore:
To optimize software development, quit trying to make it look like production.
To succeed you must:
- Create feedback early and often to accelerate learning.
- Avoid measures and tolerances which drive a predictive factory mindset.
???
Think of software development as a inventing a recipe for a book; production as someone else following the printed recipe exactly. Inventing a recipe involves experimentation and the final recipe is rarely the first attempt at coming up with the right dish. Following the printed directions is easier and if done correctly will lead to a faithful reproduction.
To optimize software development, quit trying to make it look like production. Recognize that learning (discovery) is the critical activity and that software development is about people who are inventing and communicating in the face of a problem that keeps changing, a solution that keeps changing, technology that keeps changing.
Alistair Cockburn, said it best when he wrote that software development is a cooperative game of invention and communication, where people are:
- Inventing and communicating and attempting to solve a problem they don’t yet understand (which keeps changing)
- Creating a solution they don’t really understand (and which keeps changing)
- Expressing ideas in restricted languages they don’t really understand (and which keep changing) to an interpreter unforgiving of error.
- Resources are limited and every choice has economic consequences.
Standard defined methodologies also err by assuming that a single methodology will work all the time:
- One size fits all methodology is not always applicable as projects vary in size, complexity, etc.
- Intolerant methodologies fail as people do vary
Heavier methodologies incorrectly assume that more planning and documentation up-front equates to greater safety. But safety is not the goal; delivering user-valued functionality as fast as possible is! Signed-off documents at each phase of the project do not guarantee success — signing-off does not equate to eventual user happiness; close collaboration with the users to determine their shifting needs and how best to fulfill them is what is important.
Software development also has the advantage that the end-product does not have to be perfect (incorporate every bell and whistle) before release. Teams have the option of delivering value sooner even if in smaller chunks. This is unlike manufacturing, where often only the final product can be sold to the end user — would you like to buy just the engine and car chassis from then wait months till other sections of the car become available!