February - 2nd Agile Principle
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The second agile principle can be expressed in two words: embrace change. It is an appeal in opposition to the traditional fixed cost waterfall model. The waterfall model makes change as hard as possible. Every time a requirement changes, the waterfall model prescribes that specifications are rewritten, the estimate is updated and the contract renegotiated. As this involves considerable administrative effort, there is a high barrier to change. This barrier is intentional, because change is considered detrimental. The waterfall model attempts to eliminate uncertainties and perceives change a risk to project success.
However, if you have worked in project management for any length of time, you will know that change is inevitable. Organisations and businesses are not static. They grow and evolve. Their external environment puts them under constant pressure. Markets, competitors, changing regulations, and new technologies force organisations to respond and adapt. Likewise, internal changes happen all the time. When an organisation expands or takes on new projects, for example, internal structures and procedures often require overhaul. This in turn means that software requirements change. Because the degree to which organisations are computerised is increasing, the rate of software requirements change is also increasing. Consequently, we can expect that change is a constant and that the pace of change accelerates.
This is were the second agile principle comes in. The agile philosophy accepts change and uncertainty as “facts of life” so to speak instead of creating an artificial bulwark against it. The very meaning of agility is defined by this principle and this is a major departure from traditional project management. It is important to understand the implications of embracing change. What does this mean for the software development lifecycle and how does it affect the planning process? One can’t deny that welcoming change implies welcoming uncertainty, because change is hardly ever predictable. The farther one tries to look into the future, the less predictable it becomes. But how do you welcome uncertainty in project planning? The agile answer to this question is temporal focus.
In agile frameworks such as Kanban and Scrum, project goals are well defined only for the present and for the immediate future. For example, Kanban is like a pipeline where the focal point is narrowed on the tasks that are currently flowing through it. These tasks are described in detail, whereas the tasks that are queued receive less attention. Scrum is an iterative framework where the focus is on the current iteration (Sprint), whereas the backlog is out of focus. This means that tasks in the intermediate future are less defined. The degree of detail is limited and the time and effort estimations are rough. Tasks in the farther future are even more fuzzy. There may be large scale goals, roadmaps and ballpark estimates, but these are open to change. So, an important difference to the waterfall model is that projects are not determined from beginning to the end.
The fuzziness of long-term and indefinite future projects is not necessarily a disadvantage. It is the price of agility, so to speak. It affords nimbleness and the ability to harness change, which brings us back to the phrasing of the second agile principle. What exactly does it mean to “harness” change? Wasn’t change something that traditional project management tries to avoid? At the basic level, harnessing change means not being overwhelmed or overrun by external events. This is something that happened all too often in the past. Because agile methods are lightweight by definition, the agile team can respond and adapt to external changes quicker and more gracefully, even if such changes entail undesirable aspects.
At a more advanced level, change is proactive and initiated by the project team. For example, the project team might decide to adopt a new technology, or it may decide to include new features, or it may respond to a specific competitive challenge. The possibilities are endless. Because the cost of rethinking and overturning things is low in comparison with traditional project management, agile methods excel in responsiveness. This is especially relevant in environments that develop at a fast pace, such as emerging markets and technologies. Which brings us to the last term of the second principle: the customer’s competitive advantage. A competitive advantage is created when an organisation gets ahead of its competitors. Being the first to release a new feature or a new technology, for example, creates a competitive advantage. Agile project management provides the methods and practices to make this possible.