The 4Cs of Delay: #1 Cognitive Overload
Requirements Delay can be experienced at the start of a project or initiative, in the middle or near the end. Delays can accumulate. They are expensive. What are Requirements Delays?
Requirements Delay can be experienced before a project ever starts by a lengthy requirement authoring process that focuses not on user story writing but on context setting requirement artifacts. These are (not an exhaustive list): uses cases, business cases, business requirements specifications, technical specifications, roadmaps, vision documents, project charters, scope summaries and so on. Because a user story or a set of user stories need context to be interpreted well, these requirements artifacts are IMPORTANT and NECESSARY.
The Scaled Agile Framework©, a commercial enterprise framework, defines a lean requirements model that emphasizes just-in-time information, lightweight artifacts, visions, and roadmaps to provide the business and architectural context for teams to build effective backlogs of good user stories. Other frameworks offer similar alternatives. In all frameworks, it is assumed that a business requirements pipeline exists and is managed, even if informally.
After a project or initiative starts delay can be experienced at any time when the requirements pipeline fails to support the incremental development schedule. The agile principle of incremental development is specifically designed to reduce the volume of requirements needed for a team to start development. Defining only two weeks of business scope is much easier than defining 10 weeks. However, when the requirements pipeline needs to support more than one team, it is a challenge to scale up.
The are four specific types of delay identified including cognitive overload, consensus, calendar and convergence, nicknamed the 4Cs of Delay. This post covers the first one, “Cognitive Overload Delay.”
Cognitive Overload Thought Experiment
It’s September and your company is planning the next year. Ideas and budgets for the new year are being finalized for enhancements to existing systems as well as a new software product for a new marketplace. A new product manager was just hired from a competitor and your best business systems analyst has already presented draft designs and workflows for the new product. By December the new product manager and business system analysts have completed requirements and preliminary design for key existing system enhancements and the new software product. Several requirement artifact documents are produced including Lean Canvas definitions for two critical MVP pilots.
An 8-page power point on existing system changes with a companion list spreadsheet documents the existing system changes wanted for the coming year. For the new system, a detailed 100-page document of requirements and design information is published and approved. All of these documents are handed over to the team on January 7 as your best two agile teams returns from holiday. No user stories exist or at best a list of 15 bullet points.
As you can imagine the team’s product owner and all team members dive into the requirements and information provided. As expected, a ton of questions arise and while user stories are being written, doubts and concerns surface as to feasibility, sequence and value.
It is decided to move the first sprint start date out 4 weeks (4 weeks) to give the team time to build a backlog of decent user stories that will deliver value and keep momentum going. “Real work” does not start until Sprint 3 the new Sprint 1. This delay costs $102,400 using the Table 2 values below. Multiply this by 20 to 100 agile teams and the costs skyrocket.
As you can see the requirements process in this thought experiment exhibited a waterfall type cadence. The agile team DID NOT SEE anything from September to January and then a huge cognitive absorption load is dropped on the team. Delay was inevitable.
In the future posts, the remaining “Cs” of delay will be addressed.