AdaptingProject Management

The Nature of Agile

By November 12, 2021December 20th, 2021No Comments

Abandon Tradition, Embrace Change

As more companies try to implement Agile practices, the nature of Agile becomes lost in a series of practices, ceremonies, and artifacts. None of these items on their own define being Agile, which is a philosophy of remaining adaptive to change. It is the belief that change drives progress, and our process must be open to change to be successful. What many companies fail to realize as they implement Agile methods, is that Agile is at it’s core a risk mitigation strategy. The risk it seeks to mitigate is the risk that the environment will change and that the product will no longer be relevant. Agile promotes rapid development processes to deliver customer value in a rapidly changing environment.

This concept is contrary to traditional methods of reducing risk by documenting every function and feature that needs to be in the product before designing the product, and designing the entire product before taking the risk to develop the product. Yet, when organizations first experiment with Agile, there is a tendency to try to document every possible user story as though they were requirements, and then deliver the entire product all at once. They’ve simply replaced their traditional definitions with Agile ones and changed nothing of their practice.

Instead, Agile focuses it’s attention only on what can be accomplished to deliver value in the upcoming sprint. By time-boxing their focus, the Agile team delivers measurable value on the regular pace of the sprint. This is not the same as releasing an incomplete product and then hoping to improve it over time. It means delivering a complete and functional, but scaled down scope of the final product. The released product must deliver customer value on its own, even without the scope that has not yet been included.

Visualize the Goal, Focus on the Next Step

There is a tendency in any organization to obsessively analyze the final product. Will it work in this situation, what happens in this example, will it be able to do that. The truth is that none of those questions matter if nothing is delivered. In order to avoid analysis paralysis, build consensus around the next step and take it.

There is no value in discussing the intricate details of the solution if there is no log in screen. Build a login screen. There is no value in documenting the final reports if there are no data entry screens. Build the data entry screens. Every finished product gets delivered one feature at a time, and yet, corporate project managers spend so long discussing 100% feature requirement lists that no features get delivered.

Agile values working solutions over comprehensive documentation. This does not mean documentation is not comprehensive. It means that documentation must be enough to plan and complete the next step. Novel Project Management is modeled after the creative process of writing a book. Authors do not sit down and write out an entire book. Instead they utilize a method of progressive elaboration. Start with the framework of the solution, and then work through each step towards that goal.

Work in Parallel, Deliver in Serial

Traditional project management works in series to the final product. First, all the requirements gathering is done, then all the planning is done, then all the development is done, then all the testing is done, until a final product is delivered and released. Any small problem in development can quickly become a much larger problem in other areas also being developed. Agile works in parallel, meaning multiple groups each take a single feature and move through requirements gathering to delivery. They deliver in series because each feature is delivered incrementally until functionality is complete enough to provide value to the customer and can be released.

An advantage of Agile is that lessons learned on building one feature can be applied to the building of the next feature. Performance and efficiency improves for the development team every delivery cycle they make. Feedback on completed features can be incorporated into future features with no additional work. While the traditional process delivers everything at once, feedback can only create more work, requiring developers to go back to finished features and update them.

Working in parallel means the Agile team is working on all stages of a planned feature at the same time. It is being planned, designed, developed, and tested within the same time-box. This allows the team to adapt the feature to the current environment and knowledge, rather than relying on a plan and design that was developed 6 months to a year earlier. While those plans may be helpful, Agile recognizes that delaying development to write plans that will be outdated by the time they are used is wasteful. Instead, writing the plans happens when the feature is ready to be developed.

Adopt and Adapt

Agile can’t be effectively adopted without a fundamental rethinking of how projects are delivered. It requires re-orienting risk management to recognize that not being able to adapt to change is a greater risk than not having a fully documented plan, especially if the plan turns out to be wrong. Planning takes place at the weekly or monthly timeline, instead of the quarterly or yearly timeline. Since plans become less predictable the further in the future they cover, the less accurate and therefor less useful they become. Agile allows ambiguity to exist for aspects of the project that are far enough in the future to be unpredictable. Anyone embracing Agile methodologies must also embrace the ambiguity that allows them to agile in a changing environment.

The nature of Agile accepts change as necessary to improvement. It recognizes that the future is unpredictable and focuses planning exercises to time-boxes under its immediate control. By saving time on the limited accuracy future planning, Agile can provide customer satisfaction through early and continuous software delivery. Since the development process is not overly prescribed, Agile can accommodate changing requirements throughout the development process. These values far out weigh the benefits of having a detailed development plan before the project even begins.

Leave a Reply