Software development is a complex activity in itself and it serves to build complex products in complex circumstances.
One perspective on the degree of ‘complexity’ relates to the number of parameters, variables and events that influence an activity and its course. In software development some of the more commonly known parameters are requirements, skills, experience, people, teams, technology, technical integrations, market conditions, regulations and dependencies.
However, it is not only the number of known parameters that’s important, but also the knowledge of these parameters, the available knowledge as well as the required knowledge. What is the level of detail required to comprehend a variable as well as the future behavior of the variable? Even if a parameter is known, the level of detail may be too deep to be able to manage and control it. And then, of course, the behavior of the parameter is still not necessarily predictable. A variable may behave completely differently to what is expected.
‘Complexity’ is also dependent on the nature of the activity itself. The exact and detailed outcomes of software development are hard to describe and predict before or at the beginning of the actual development. The steps, tasks and activities that combine to make the actual software development work aren’t predictable with any degree of high precision. People perform them, and the involvement of people is dependent on many circumstances. And then there’s also working with technology itself, where technology evolves constantly and is dependent on the particularity of the organization’s environment.
The steps, tasks and activities of software development aren’t predictable to any degree of precision because they are not repeatable. Every ‘product’ being built is unique, new technologies emerge, new interfaces need to be built, new plug-ins are used, new integrations need to be set up, new insights and techniques for programming are discovered daily.
The degree of dynamism of a problem or activity requires the right process to be in place in order to have control over the activity:
■ Open loop system: All of the variables are gathered upfront because they need to be presented to the system, where in a single run a number of steps are performed resulting in a predicted outcome. In order to have predictability of the elapsed time, this type of process control assumes a high degree of predictability of the variables that influence the process as well as of the process activities themselves.
To gain control over large or complex problems, in an open loop system, subsystems are created where each subsystem is an open loop system. Each subsystem is presented with the output of the previous subsystem. In situations of increased turbulence and frequent change, deviations and variances will accumulate across the various subsystems, far beyond acceptable levels and will only be detected at the end of the final subsystem. Open loop system Predictive plans are expressions of the industrial paradigm and implementations of open loop thinking. But predictive plans can only include known variables, and their expected behavior. Predictive plans create the illusion that the behavior of the known variables is precisely understood and that other variables are non-existent.
Predictive plans invite lengthy upfront consideration of all elements that should be part of the plan, and attempt to foresee the unforeseeable. In order to control non-predicted variables or unexpected behavior weighty procedures are required to check, maintain and update the predictive plan.
■ Closed loop system: The actual outcome of the system is regularly compared to the desired outcome, in order to eliminate or gradually diminish any undesired variances. Not all variables and parameters need to be known precisely and in detail upfront, as the process applies self-correction and takes into account new or changing parameters. This technique of regular inspections requires and creates transparency. The real situation is inspected, and exposed, so that the most appropriate adaptations can be undertaken to close the gap between the effective and the expected outputs. The people performing the inspections, the inspectors, need clear and agreed standards in order to carry out their inspections. Hence the need for transparency of the process and all its variables for all players involved.
Scrum acknowledges that the complexity of software development requires the right process, i.e. closed loop feedback. Scrum replaces the open loops of traditional processes with the empiricism of closed loop systems.
Scrum implements regular inspection and adaptation opportunities at which the players can learn from an inspection, gather feedback over the output and improve. Scrum brings reality-based control over software development. Scrum implements two specific closed-loop feedback cycles. A Sprint forms an ‘inspect and adapt’ cycle that wraps the 24-hours ‘inspect and adapt’ of the Daily Scrum:
■ The Daily Scrum: The Development Team inspects its progress, and estimates and plans its tasks within the container of the Sprint. All of these elements were initially laid out in the Sprint Planning. They use the Sprint Backlog, the Sprint Goal and a progress trend to consider the remaining effort. It assures they don’t get out of sync with each other in the team and with the Sprint Goal for more than 24 hours.
■ The Sprint: A Sprint is a cycle that starts with forecasting the work and ends with an inspection of what was actually built, the product Increment, including how it was built, the process, the team interactions and the technology.
The events of Scrum set the frequency of the inspection and adaptation, where the artifacts contain the information to be inspected and adapted:
These are the formal events that Scrum foresees as opportunities to inspect and adapt to the actual situation, so that the art of empiricism is performed no later than at the time of these events. This should not impede team members from improving and discussing improvements and progress whenever required. In a world of high dynamism that leads to using the Scrum framework it would be very strange if teams did not capitalize on new information and insights that improve their development life as soon as possible.
- Verheyen, Gunther. Scrum - A Pocket Guide