For many, many years software companies were trying to employ waterfall (traditional, defined) type approach to software development. Challenges with this kind of approach are:
- Waterfall approach is appropriate for projects when we have got clearly defined and understood requirements, very well-known domain and technology, and a predictable way of creating a product. Unfortunately majority of projects are not even close to this kind of assumptions.
- Waterfall approach is based on false assumption that each stage in waterfall project will have positive outcome, ignoring possibility that things will change or will not be as we anticipated. In software, things change all the time: builds get broken, software doesn’t do what you expect, integration doesn’t work, people get sick, issue with HW …
- In traditional product development, requirements are defined up front as a non-negotiable, very detailed specifications, that product must satisfy. Based on these requirements Project Management creates a detailed plan and this up-front plan is created when we have at least level of knowledge about product. After that development teams have a very challengeable job to deliver product which satisfy these requirements.
One of Agile Manifesto values is “Responding to change over following a plan”. 2nd Agile Principle says “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” We need to have some kind of plan, but this plan needs to be flexible and we need embrace changes, because they will happen inevitable.
So, what are characteristic of Agile planning?
- History has shown that many companies were and still are struggling with an attempt to perfectly predict a software plan, so rather being obsessed with a plan itself, Agile planning is more focus on a process of planning.
- During Agile planning, decision making happens often (utilizing empirical inspect and adapt mechanism), and it is spread throughout the project taking into account an information which we have.
- Agile planning is a multilevel planning (daily, sprint, release, product, portfolio) with different level of details and precision. Re-planning occurs frequently, so we need to create plans that can be easily changed based on new information– at the start of each sprint, during sprint planning, a sprint plan (part of sprint backlog) is created for that sprint. During daily standup meeting scrum team synchronize their work and sprint plan is updated based on latest information. The release plan is updated after each sprint.
- Uncertainty about product and the way how we develop product needs to be acknowledged and plan for during Agile planning. Both uncertainty are reduced with a nature of iterative and incremental Agile product development.
To be able to create any plan or any projections about when will certain number of features be delivered or what can be delivered by certain date, we need to have some level of estimations done by team. Process of estimation helps the team to better discuss and understand requirements by discovering missing information and hidden assumptions or details. Agile estimation is related to relative estimation with story points or ideal days for requirements and absolute estimation for tasks. There are different techniques for relative estimation, most used one is “Planning poker”. Based on team estimation and team velocity we derive duration which help us with projections and forecast.
Software engineers and business people who are, in any way, involved in software development should definitely know concepts and best practices when we are talking about the planning process related to IT projects. If you find this text interesting for your business, then think about the formal education on those topics.
