Project Planning in Agile Environments

Welcome back to our series on Agile and Project Governance!

Remember our previous post about ‘Agile Mindset: Key for Success’? If you missed it, you can catch up here: Agile Minset Key for Success

So, now that we’ve covered why having an Agile mindset is important in our fast-paced world and touched on some basics of Agile, let’s look more closely at Agile and Project Governance.

In this post, I will occasionally reference specific sections from the PRINCE2 Agile guide (PRINCE2 Agile), which I highly recommend reading and obtaining certification for.

While I won’t extensively explore PRINCE2 Agile here, I’ll highlight certain parts that I believe well contribute significantly to our discussion.

As in previous post, I’ll be sharing my perspective, feel free to adopt what connects with you. I’m always open to challenges and eager to hear other viewpoints. If you have any thoughts or questions, don’t hesitate to drop them in the comments below. Let’s keep the conversation dynamic and enriching!

Projects: A Continuous Presence

Projects do and will always exist.

At its core, a real project is about solving a particular problem (scope) within set time and budget constraints. While it’s challenging to balance all three aspects simultaneously, we can’t just ignore the ones we don’t like.

This is encapsulated in the phrase: “This is Agile — we don’t do dates.”

Elements such as scope, schedule, timescales, and budget are fundamental aspects of conducting business and delivering results for stakeholders and customers. Therefore, they must be managed appropriately.

Agile Governance: Simplifying Control

Many people think of governance as strict rules and processes, especially in old-fashioned Waterfall setups. However, I believe the problem is that they don’t understand what governance means.

Governance isn’t about having too many pointless rules; it’s about making sure a project stays on track and everyone knows who’s responsible for what. In simple terms, it’s like the system that keeps a project moving forward and ensures things get done properly. So, why wouldn’t Agile projects also need good governance to succeed?

Effective project governance can, for instance, spot a project that’s going to exceed its budget. This can lead to discussions of cancelling the project. Oversight can also see if a product is changing too much from its original goals, or if a project isn’t following the organization’s plans properly.

In an ideal scenario of infinite time and budget, project management methods could be replaced entirely by Agile principles. However, real-world constraints such as limited time and budget, alongside demands from business managers or clients for specific deadlines and results, need a more structured approach.

Agile prioritizes collaboration, agility, and interactions, but some wrongly believe it means skipping documentation. This is false; while the purpose of documentation in an agile context differs, it remains essential. Documentation is meant to record outcomes after discussions and decisions, not just to fulfill a requirement. Similarly, project plans are also essential, but their creation and refinement differ from traditional methods.

Let’s investigate this further in the next sections, comparing project planning in Agile versus traditional methods.

Project Planning is Needed

As we’ve previously mentioned, planning is crucial in the real world where time and budget constraints exist, and businesses require transparency regarding progress and results.

For this analysis (as noted earlier), I’ll take ideas directly from PRINCE2 Agile , finding its principles valuable and, based on my experience, entirely applicable. I must say, I completly agree with these principles and consider them the way forward.

In PRINCE2 there are three levels of planning: project, stage and team (see below image). The difference in the plans lies in the scope and level of detail.

For me, the project plan level could be considered as an agile roadmap (product roadmap), which we can also complement with a high-level project plan.

Note: I include as optional a high-level project plan. This can be created in MS Project to include high-level activities. But should avoid detailed step-by-step activities typical of waterfall projects. Focusing instead on feature-based planning and progress tracking based on value delivered to customers.

But what I do see is that different levels of plans are needed. Choosing the right planning approach depends on the project’s scope and requirements, which is where the Planning Onion (see below figure) comes in to assist teams in making informed decisions. The Planning Onion assists teams in selecting the appropriate level of planning for each timeframe they are considering.

Agile Project Plans vs Traditional Project Plans

As we have been discussing, Agile methodology emphasizes delivering value to customers and fostering collaboration between the development team and the customer to ensure alignment and adaptability. Rather than rigidly planning far ahead, Agile encourages remaining open to changes and improvements as circumstances evolve.

Even for experienced scrum masters, project managers, and/or talented team members, software development’s long-term predictability remains a challenge, often resulting in unforeseen work, late nights, and stress when faced with inflexible deadlines/plans. ☹

Therefore: over-planning should be avoided, as it’s impossible to anticipate every eventuality. Instead, the focus should be on doing ‘enough’ planning and no more, as extra work may not bring as much benefit as expected, following the idea that as you do more of something, the extra benefit you get from each additional bit decreases.

Traditional methods meticulously plan every aspect of a project upfront, but unexpected events often make parts of the plan obsolete. Agile, on the other hand, breaks down project scope into short iterations, allowing for ongoing adjustments based on new findings or information that comes up during the project. This flexibility is vital for navigating uncertainty, especially in complex projects.

A potential challenge with some of the agile planning techniques is that in a project context (where a project is finite), we need to estimate and plan before we start and not after. Having an end date is one thing, but how accurate and realistic it can be something quite different.

Both Agile and PRINCE2 accept the premise that the further you look into the future the more uncertainty there is. This means that longer-term estimation will need an increasing margin of error compared with shorter-term estimation. This results in the concept of a ‘planning horizon,’ where a plan for the next two weeks would be very detailed with a relatively low margin of error, while a plan for the next 12 months would be less detailed with a higher margin of error.

In agile, estimation and planning are viewed as evolving processes rather than one-time events. They occur continuously throughout the project and at every level of the plan.

When using PRINCE2 in an agile context it is important to plan around features and groups of features. Agile primarily focuses on adapting what is delivered, so features, expressed through requirements or user stories, represent the contingency on a project when combining PRINCE2 with agile. Alternatively, time and cost are not used as contingency and are therefore likely to remain stable.

In our upcoming posts, we’ll discuss this concept further. When creating a product roadmap the focus will be on fulfilling features. It would not be appropriate to use technical phases during this exercise in an agile context (e.g. analysis, design, build, and test) as this is not the focus of the agile way of working.

Clearly defining what constitutes the Minimum Viable Product (MVP) is recommended.

In the next post, we’ll explore steps to build an Agile roadmap.

About the Author

Vanesa Alvarez is a Delivery Manager at Version 1.