Navigating the Unknown
Don’t decide everything at the point you know the least
When I teach Agile Development and Planning in my DevOps course, I like to start off with this quote by Douglas Adams:
“I love deadlines. I love the whooshing sound they make as they fly by”
Whoooshhhh… He’s right! This happens to us all the time; we set a deadline and we miss it. The question is, why does this happen? But more importantly, what can we do to avoid it?
Destination unknown
I like to call this “navigating the unknown.” If I told you that you need to navigate across the field of penguins pictured above, you might look down at the ground ahead and say to yourself, “Well… I can see where there are open spaces and if I put my foot here, and maybe step in there, and step around this one…” But then when you get to the middle, the penguin population gets dense. How do you plot a course from where you are to the other side? Oh, and by the way, the penguins are going to keep moving as you traverse them.
This is a lot like software development, where the operating system is getting patched and software packages are getting upgraded to new versions all the time. The software ecosystem is organic. It changes over time even if your code doesn’t. Often when planning, things keep changing, which is why Agile teaches you to not plan too far ahead.
It’s all about vantage points
You know that as you tiptoe into the middle of those penguins and you look down, it’s going to look a lot like it did at the beginning, with some obvious open spaces. This is because now you know more; you’re at a different vantage point. That’s the whole idea of Agile planning. From your new vantage point in the middle of the penguins, you can probably continue to plot a course to the other side. As you get closer to your goal, you’ll be at the next vantage point where you can adjust and plot a course again. Eventually you will reach the green field on the other side. There is no way you could have plotted this course from your initial vantage point.So why do we try?
At the start of a development project, you probably won’t have all the answers. You may feel like you’re navigating a field of penguins. That’s OK! You don’t need to have those answers until you get to the point where you need to implement them. Don’t waste time making decisions now because the situation might change by the time you get to implementation. You’ll only end up changing those decisions later.
Iterative development without iterative planning
A lot of companies mistakenly think that Agile is all about iterative development, and they forget about iterative planning. They make grand and glorious plans up-front and then just execute them iteratively. That is not Agile! It’s what David West calls Water-Scrum-Fall. Create an elaborate plan up-front just like Waterfall, then develop in iterations without ever deploying or getting feedback, and spend the last mile trying to deploy everything at the end.
Agile is about using the feedback from the current sprint to influence the planning of the next sprint. If all you are doing is implementing a large, predetermined plan in small iterations, then you are not being agile; you are just being iterative. You will gain almost none of the benefits of Agile because you did not change your Waterfall thinking.
Being agile requires you to think differently. It requires a different mindset. You might be asking yourself, “If I don’t lay out a complete end-to-end plan, how will I know if I can achieve my goal?” I hate to tell you but making a plan up-front based on unknown assumptions isn’t going to get you to your goal with any greater accuracy. That is why we miss deadlines when we do this!
If somebody asks me what my project will be doing six months from now, I tell them, “Well… I can tell you that with maybe only 50% accuracy. But I can tell you with almost 100% accuracy what I’m going to do two weeks from now.” So the idea is not to try to be omnipotent because you’re not! Don’t try to plan everything up-front. You want to plan as you go, and as you learn more you can add to the plan and become more and more accurate in your estimates of how long it’s going to take for you to get from here to there.
Conclusion
It’s difficult to plan an entire project given your limited knowledge at the beginning, and the fact that situations and requirements will almost always change. Attempting to do this usually results in missed deadlines. Allowing yourself to plan iteratively is what being Agile is all about. With Agile planning, you can start the journey with what you do know, and as you move forward and gain valuable feedback, the next steps will reveal themselves from your more advanced vantage point down the road.
So don’t plan everything in the beginning when you know the least. That’s not being Agile!
If you’d like to learn more about Agile planning, I teach a course on Coursera called Introduction to Agile Development and Scrum that is part of a DevOps Foundation specialization.
