When starting a new software development project, we usually feel the need to answer questions about the faraway future. Shedding some light on those answers requires an occasionally complex, long-term planning exercise. Can we do that by using an Agile methodology?
Software development is not exempt from the general business rules, and like any other industry, one of the most important tasks is Strategic Planning. However, software development particularities make such a goal harder to achieve if some aspects are not carefully considered.
One of the most popular frameworks in our industry is Agile. Under this perspective, we have a very clear idea of what we will be working on in the next few days, although it is not entirely clear what we will be doing in the next few months. This concept is especially important in Sprint execution because, in a small time span, we can clearly define our priorities, finish some work, and generate frequent releases. The benefit of working with short cycles is that we can bring value to the product incrementally, collect feedback more often, and use such knowledge in each new iteration.
However, there is a dark side that is not always mentioned, or even worse, it is feared: Long-term Planning. Wait, isn’t that the enemy of Agile? Certainly not, and let’s see why!
Content related: Agile process improvement: ways to boost your software projects
Zooming into this process
Moving away from the immediate and short-term goals, it is also very important to start looking at the future but be mindful of the amount of energy that we invest in it. With Agile, the farthest we plan from today, the blurrier the goals become. For example, we will have a perfect idea of what we are doing in our current Sprint, and we also have a clear idea of what we will work on (and how we will do it) in the next couple of Sprints. But beyond that, we have only some notion of what we may do in a few months, as well as a solid (or sometimes vague) concept of what we want to achieve, probably, in a few quarters or a year.
The nature of software development is change and adaptation. Many factors can weigh in when adjusting our plans: Machine Learning advantages, customers providing feedback, the occurrence of a pandemic and the unexpected need of non-functional requirements, startups introducing innovation to their businesses, and complex organizations working on large-scale projects across several countries.
In all cases, we need to define a plan that involves both the current goals and the final objective. We want to monitor if we are on track to our final deliverable if we need to hire more people or anticipate giving “early access” to our customers. Moreover, larger companies have several departments expecting these answers to continue their own processes: Sales needs details of the deliverables to start offering the product; Marketing needs definitions to create promotion campaigns; Finance needs it to know if they have the right budget, and other Stakeholders want to know more details. So, how do we deal with all that?
The complexity of this matter increases as the project scales. What would happen if we were planning for a multi-year project or getting things done faster and allocating dozens or hundreds of people to do the work? Beyond any doubt, we cannot restrict ourselves to a short-term plan only.
Take a look at this: Best project scheduling techniques in project management
Uncertainties and estimations
In traditional methodologies, where the product definition usually happens upfront, there’s little room for changes. Scope, time, and budget are fixed values, and such level of commitment returns a comfortable level of previsibility in some aspects: what we are going to do, when it will be done, and how much it will cost.
This looks perfect for a long-term prediction and will probably work as long as there are no contingencies or changes along the project execution.
Long story short — there are always contingencies and changes in software projects. We can assume with some level of confidence that what we have planned will probably change in some way. And it will not change in a bad way; it will simply adjust to the real world or turn into a better version.
So, is it really worth it to invest a big effort in defining all the future tasks the same perfect way we do it for the present tasks? With Agile methodologies, we can be flexible enough to avoid defining the whole plan up front with the finest detail, considering that scope, time, or budget may change.
This does not mean that we will not have a clue about the what, when, and how questions. We need to work on a plan to answer those questions with the goals we know today and try to get a sense of the effort required to do it. However, as we move forward with product development and (possible) scope changes, we should adjust to re-estimate and reprioritize.
So, while working with Agile, we can still — and we should — work on long-term planning!
Such plan will be elaborated with estimations that have some level of uncertainty. When the development team plans and estimates, they do it based on their past experiences and estimate an idea of what they understood about the task.
If what has to be done has a great level of detail and it is something we can put our hands on very soon, we will probably have a comfortable level of certainty and accuracy in our estimations. However, when there is some level of abstraction, blurriness, or lack of definition in the tasks that the dev team should do (because it isn’t a completely defined idea yet or it has been opened to changes based on user’s feedback), the estimation accuracy will be much lower, and the effort to make that estimation should also be smaller.
Those estimations, however, are still useful and contribute to elaborate a plan with at least high-level predictions, which will help us draft some conclusions about the future. With these conclusions, we will be able to put our energy into where it matters most and, if time allows, to work on secondary goals.
The Product Owner: a key role
Even though in software development many roles participate in Strategic Planning, the Product Owner (PO) is responsible for reaching a consensus among the company’s involved parts about what needs to be done. This person should know the expectations of Stakeholders regarding product value, quality, and releases and will work with the development team to give shape to them and put the plan into action.
As we mentioned, when the original plan changes (or something unpredictable happens), the PO needs to adjust it to the new reality and keep it healthy. This task should not be perceived as time wasted but instead as the perfect exercise to understand how these changes would impact the long-term plan and use that knowledge to clarify what the pending work is to re-estimate and prioritize it.
While prioritizing, the PO will look carefully for the Most Valuable Product items in the plan so that the team’s effort is always focused on adding value to each iteration, as well as reprioritizing items that now seem less critical and can be postponed to a future work.
This is not an easy task though. Every time the plan changes, it means that either the completion time, scope, or budget can change as well. Therefore, it’s critical the PO correctly manages the Stakeholders’ expectations, keeping them informed on how the project and the plan is evolving based on the decisions taken during the project lifecycle.
Don’t miss this reading: The most effective software projects leadership tactics
To sum up
- In software development, we need to be flexible to incorporate changes as the product evolves, and Agile helps achieve that goal.
- Flexibility can require scope changes. Therefore, we should be open to anticipate that what we had initially estimated may change.
- We should define a long-term planning and adjust it as we move on. However, we should balance the effort we invest in that task, allocating more time to the tasks we know in the present and less effort for those we may do (or not do) in the future.
- As reality strikes and new requirements are added to the project, the PO should select the Most Valuable Product items by having a great understanding of what is most important for the company, managing expectations, and communicating how the plan changes.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
