When Henry Ford designed his factories in 1913 to build the Model T, he reduced the time to assemble a car from over 12 hours to 2 hours and 30 minutes. This process allowed for the production of an automobile at a price point targeted for the “working man.” All cars had the same design, and all were painted black.
Preconfigured designs work when predictions meet expectations (who in 1913 would have asked for a red car?) and when one specialist can hand off work to the next with little if any lag time between work hand-offs.
When a firm is in the business of producing innovative products and services, its plans rely on one or more estimates and assumptions. These estimates are nothing more than probabilities. Basing a project plan on assumptions requires that your system can handle change.
Mary Poppendieck stated in Lean Software Development, An Agile Toolkit, “The simple mathematical fact working here is that variation is always amplified as it moves down a chain of connected events. A little variation in step one introduces a huge variation five steps later.” So the question remains as to why managers continue to plan projects based on sequential assumptions.
To understand how unexpected change can cause significant downstream delays, visualize a crowded highway with cars moving at the speed limit. Traffic flows until there is a vehicle merge or some other event that causes one driver to tap the brakes. Highway traffic then comes to a halt for some period and then begins to flow again with no apparent sign as to why it slowed in the first place. The highway example illustrates how, unless systems are designed to focus on flow; these systems will not operate efficiently at capacity. Because software development is a complex endeavor, assumptions, and decisions should be made at the last possible moment. Making decisions at the last possible moment allows the Scrum Team to pivot to work on the most valuable product backlog items given the most recent observations.
Stacking many assumptions one after another in a project plan significantly reduces the likelihood of a positive outcome. For example, consider five tasks all with a 90% probability of completion in one week. (0.9 * 0.9 * 0.9 * 0.9 * 0.9 = .59) In this case, we have five tasks that we feel pretty sure about, but the cumulative result is that we are only 59% likely to finish these five tasks in the estimated five weeks. I would argue that based on my experience as a Project Management Professional, it is also unlikely that five sequential tasks would ever each have a 90% confidence level. Are you still surprised when you read the Standish Group’s Chaos Report that indicates approximately 70% of all information technology projects fail to meet their objective and are significantly late and over budget?
The best way to optimize delivery of value is to make value-adding tasks visible to all stakeholders. Documenting each value stream will highlight the lead and lag times between hand-offs. By quantifying value stream activities, the cost of delay now also becomes visible. This visibility will help the organization determine where building cross-functional teams will immediately improve customer responsiveness.
Using Scrum to make these inefficiencies visible is only the first step. Does leadership have the desire and commitment to effect change? Craig Larman, the author of Laws of Organizational Behavior, has observed that organizations are implicitly optimized to avoid changing the status quo positions and power structures.[1] He also noted that if you want to change the culture of a firm, you will need to change your organization’s structure because culture/behavior and mindset follow organizational systems or design.
Institutions like Insurance companies and banks typically have fortressed silos of specialization around applications, technologies, and functions. Each of these departments have developed carefully crafted rules and procedures that inhibit change. These administrative processes have the unintended consequence of disrupting the value stream that flows from concept to customer delivery. Mary Poppendieck described this situation in Lean Software Development: An Agile Toolkit, “Policies established to solve a problem will often exacerbate the problem, creating a downward spiral: As a problem gets worse, managers apply even more aggressively the very policies that are causing the problem.” (Have you ever heard someone say, "The beatings will continue until morale improves."?) Assembling cross-functional teams that have all the skills to complete the work without handing off across functional silos will have a surprisingly positive impact on an organizations ability to improve quality and time to market.
Does your leadership have the courage and commitment to take on the hard work of removing processes and procedures that do not add value? Most firms considering the adoption of Scrum will need to change their organizational structures to support autonomous cross-functional teams. If the Organizational structure doesn’t change behavior is not likely to change. If your business model depends upon innovation, this change should be a top priority
[1] http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior