Why do we plan?

Imagine you want to spend a month in Europe. It’s something you always wanted to do and now you have a few Argentinian pesos in your wallet. Would you plan it? How thoroughly? I know I would. I’d do some research to figure out the best cities and how long I would stay in each city to see the most important spots. I’d also like to have an idea of how much money I would need for accommodation, traveling around and eating. I’d also google if I need visas and what’s the temperature like around those dates. Why would I do all these things? Because I believe that it will allow me to make the most out of my trip and it will maximize my profit. With software products, I believe it’s quite similar. We plan because we’d like to make the best possible product, considering the constraints such as time, money, technology, people, etc. In order to do this, we’d like to have an idea of the product and business outcomes expected, the features needed to test these hypotheses, the needed team and how much money it requires. The plan is just the initial answer to all these questions with the information we have so far (which is of course far more limited than in the case of the trip!). It represents our shared vision describing how to  achieve the desired results.

Agile changed the way we work, thus the way we plan

When I was starting with Agile, I heard many times that there was no planning in Agile. I realized that wasn’t true, but it’s certainly different. I also realized that Agile changed the way we work, the way we build the product. Planning was adjusted to this new way of working.

So what changed? The most important change is that Agile uses an iterative and incremental process (often called an Agile process). There isn’t a big bang release with all features in the end. Instead, features are released incrementally and iterated afterwards. Working this way enables incremental releases and incremental plans.

Building features incrementally bring prioritization attached. We build features according to their importance. Big bang releases have the disadvantage of mixing very important features with others that are nice to have but not needed in a first release. Agile plans incremental releases containing the features that add more value and help uncover the riskiest assumptions first.

The Agile process embraces change. Perhaps I should call it learning instead. Building features incrementally and iteratively produces a lot of knowledge. We learn as we build. We see things working, we experiment. And we use all that learning to re-plan, to decide what to build next, what to iterate. In their book Planning eXtreme Programming, Beck and Fowler use the drive metaphor to describe these changes. They say: “Driving is not about pointing the car in one direction and holding to it; driving is about making lots of little course corrections”. Agile plans set the direction, but leave room for steering in the way. The Agile process enables this.

Another important change is that Agile teams are self-organized, empowered teams. These teams participate in all phases of development, they build their plans and they track their progress. Planning and tracking are activities performed by the whole team.

Finally, releases became smaller (and they are becoming smaller over time). This is good, both in terms of maximizing the ROI and decreasing the risk because we release value early at a lower cost. Added benefits are expectations are managed better and it is easier to plan.

As you can see, Agile brought a very different way of working, of building software products. Before Agile, projects were big and they were made up of many activities that provided no value per se. Risks and mitigation strategies needed to be predicted. If things went well, a product was released in the end with all the expected value. No wonder it was really important to make a good plan those days, right? Agile shortened projects through incremental, prioritized, releases developed through an iterative and incremental process that enabled adaptation throughout the construction. This new way of working made Agile plans light and adaptable, with no blind assumptions and no commitments when there isn’t enough information. I like to say that agilists acknowledge risk, plan for it and adapt their plans as they learn.

The Iron Triangle and its successors

The iron triangle or project management triangle is a model that describes the relationship among the 3 major constraints of project management: Scope, Time & Cost. It basically states that if one of them changes, one of the others must forcefully change. For example, if the scope is increased, we must add more developers or extend the deadline. If you look at the triangle, you can visualize this relationship (you can see that any vertex is related to all the others).

Before Agile, in times of sequential project teams tried to fix the 3 constraints. Things went well when the team could build the planned scope within the estimated time and the estimated costs. Project Managers that could achieve these objectives were real heroes 💪

When I was starting with Agile, I saw some agilists proposing to ‘invert’ the iron triangle and fix only the time & cost constraint, leaving the scope variable. As this scope was prioritized and built iteratively and incrementally, this basically meant building the most important features the team can within a fixed timebox.

Not long after that, I read Jim Highsmith’s book, where he states the Agile Triangle goes in the right direction, but it misses the most important factor, which is the value. Therefore, he suggests another triangle in which one of the vertices is the value, in terms of a releasable product (which we want to maximize), another is the internal quality and the 3rd one is the constraints (scope, time & cost). I’m not sure if I ever understood this triangle, but it really made me think about our objective when we develop software: creating value (solving a problem, need or desire that will eventually create value).

Not long after that (it seems I was interested in triangles in those times), I read another very interesting post: Replacing the Iron Triangle of Project Management by Mike Cottemeyer where he agrees that value should be treated as a first class citizen, but does not agree with Jim’s triangle. Instead, he proposes that value and quality be parts of the scope, together with the requirements. After all, would the Product Owner accept a story that doesn’t have the quality or that won’t provide the expected value?

I really like Mike’s post, but I am still unsure that we should add value, something that we can’t manage in one of the constraints. It’s clearer to me to think that scope/time/cost are part of the output and value is something more indirect, which will be the result of reaching the desired outcomes in adequate time (I’ve been hearing this from Patton/Cagan/Torres). The outcomes are less abstract because we can imagine the behavioural changes that we are expecting and we can measure them through leading indicators. Product teams know the outcomes, discuss alternatives to reach them (often making compromises) and plan experiments.

The Infamous MVP

One of the most important things we decide for our first plan are the features that will be included in the Minimum Viable Product (MVP). I read about the MVP concept for the first time in Eric Ries book, The Lean Startup and loved the idea of building the minimum product that would allow us to test our assumptions with real users (what he called validated learning). My experience tells me that at the moment the concept was popularized (2011), it made us think of smaller releases. Nowadays, I have the perception that the opposite is happening. Way too many times I see MVPs which are bigger than what I believe should be. Perhaps thinking of a ‘product’ that needs to be ‘viable’ makes us include many features when there’s still too much uncertainty. I also noticed that there are different understandings of what the MVP is depending on who you ask.

Listening to Patton, I learned that the MVP concept was not invented in 2011 but in 2001. Do you remember what software looked like in those times? Let me remind you. It came in storage devices, often distributed via snail mail. Software couldn’t be shipped often in those times. Back then, Sir Francis Robinson coined the term Minimum Viable Product. Products and viability have different meanings in 2001. We needed to think more carefully about the features to include and the viability of the product. Ries reused the term, but software looked different in 2011 (the web times). The MVP in 2011 really meant the next best test/experiment. Something much smaller, which might not be a product (doesn’t need to be) and that could be viable only for a very restricted number of users.

Realizing that sometimes, MVP was not the best name, I started using some other names. For example, I used ‘Internal MVP’ to describe a version of the product that was not releasable outside, but could be shown inside (really useful to manage expectations in big companies). I saw Josh Kerievsky in a post I already recommended talking about an embryonic version. I also saw it called Minimum Learning Product, which really makes sense as it’s talking about learning and not making something viable (I also saw it called Riskiest Assumption Test - RAT-, which I really like, but perhaps the acronym is not very appealing :-)). I also saw other acronyms to name the products after their first release. For example, Minimum Marketable Product for products that can make money and Minimum Lovable Product for a release that customers would love. So many names. I prefer to think about ‘the next best’. What do we need to build now to maximize our learning, to test our most important/riskiest assumptions? At the beginning it might be desirability. Do users/customers want to use our product? In later stages, it might be viability. Will we be able to make money with our product? The product team will always need to define the next best experiment based on what they already learned and what they want to learn.

How do we track progress?

I said how do we track progress because it’s not the responsibility of a Project Manager (or Scrum Master). It’s a whole team responsibility, as the rest of the things an Agile team does. The team created the initial plan and then tries to understand how things are progressing, when they believe they will finish, what are the outstanding risks, the blockers, etc.

There are tools that allow us to visualize progress, to try to get a shared understanding of the status of the project, to facilitate conversations. These tools are useful, but they are by no means the source of truth. There’s a lot of subtle information that only the team (working actively on the experiment) knows. The Scrum Master needs to facilitate status conversations. As a Scrum Master, I believe there’s nothing as useful as asking the team ‘how are we doing?’, ‘how do we feel?’, ‘Do we think we are progressing according to what we plan?'.

Here’s a couple of tools I’ve used to track progress:

Burndown chart: perhaps the most well known. If you estimated your Backlog, you can measure your velocity and graph how many points you ‘burn’ each iteration.

Bear in mind that with this tool you can’t differentiate the points that are burned from the ones that are added (a new estimated story). In other words, what you see is how many points you still need to burn after each iteration. If you want to visualize this, you can draw a bar graph with the difference (I’m not sure if it makes sense though).

Parking lot: A colleague taught me about this tool (and wrote about it in the spanish book) which she uses to visualize progress/blockers/status in a set of epics. The idea is to maximize the information that is provided in something that looks like a dashboard.

Notice how the size of the parking lot (epic) is proportional to the estimated size of the epic, there are estimated completion dates and blocked epics, all in the same place.

Something related to the team progress I read recently in Ryan Singer’s Shape up book which I found really interesting is that he states that ‘Work is like a hill’. At the beginning of the project, there’s more uncertainty as we need to figure out what to do. We are going up the hill and things will probably go slower. The 2nd part is going down the hill, we already figured out what to do, there’s less risk. We just need to complete the work. In terms of progress, when we go down the hill we will go faster. When we are at the top of the hill, we completed more than 50% of the work and we are confident that we will finish the rest of the work soon enough because we know what to do. Tools like the two I mentioned above don’t show this. The gut feeling of the team does.

Conclusion

Agile changed the way we worked and thus the way we plan. Waterfall projects needed a carefully crafted plan that coordinated activities and mitigated risks to deliver a product in the end. Agile brought the iterative and incremental process back, which resulted in being able to work with smaller incremental prioritized releases. This way, plans lost importance as they are lighter and adaptable.

Agile plans are a shared vision of what the team wants to accomplish and how it will do it. It sets the initial path. As the team learns, it incorporates this knowledge into the plan. The most important items of the plan are the product and business outcomes expected and the features needed to test them. In the first plan, this set of features is usually called Minimum Viable Product although it might not be the best name. If things go well, there will be many more next best tests after this initial one.

One last thing. Product teams are worried about the product outcomes. They know the behavioral changes they expect on certain users. They evaluate solutions and plan accordingly. The final objective is not to build software (we don’t want to fall into the build trap) but to obtain the desired outcomes. We have this in mind when we plan and build software.