Planning Priorities - The Agile Method

I've talked in other blog posts about 90-day priorities, what we call “rocks,” the importance of having those 90-day priorities, the importance of them being outcome driven, the importance of there being some measurable finish line. But I still find a lot of my clients just struggling to create rocks and plan rocks that add real value. The reason for a lot of that is what I call the difference between a "waterfall method" of creating priorities and an "agile method."

Let me describe what the waterfall method is first. Back 30, 35 years ago in my career - back when I did a bunch of big system implementations - we used what was called a waterfall methodology. In a waterfall methodology, you'd start with three months of high-level design, and then you have four months of detail design, and then five months of programming and five months of testing, and then migration and implementation, and a year and a half, two years later, and many millions of dollars later, you have this new monstrosity of a system implemented that everybody hated. That added no value for your organization. The world had changed three or four or five different times while you were doing all that work. Those requirements you had for the system a year and a half ago are just not right for you anymore.

What I find is, as crazy as it sounds, that's the way people are planning their rocks. They're starting off by trying to build a foundation for something, and they'll add value later. The problem is, later never comes. A great example is when I was talking to a client earlier this week about a leadership development program that they wanted to put in place, which is great. They were going to have a great impact on net promoter scores and productivity and employee retention and percent of A-players. That's all wonderful. But what they were looking to do is to spend 90 days figuring out who needs to be trained, what they needed to be trained on, what methods of training made the most sense, all of these things. And at the end of 90 days, where's the value? What would happen next is they'd probably design these programs, then they'd implement them. Meanwhile, the world has changed, their business has changed five times in between there, and the chances of them getting real value go down very low and the chances of getting short-term value are nil.

So what I want to talk about is the idea of more of an agile method of creating rocks and the agile method of technology, which is where it started. Instead of that old waterfall methodology, it's about creating value in these short-term sprints. In technology, they're typically 30-day sprints where in those 30 days, you're not building a foundation in order to program and test and all that stuff. In those 30 days, you're adding a small piece of value. At any given 30 days, the value is probably not all that great, but it's value throughout. All that time, you're adding more and more value. As the business changes, you're able to zig and zag with the business.

I want to suggest you do the same thing with your 90-day priorities or your rocks. Instead of building a 90-day foundation of what a leadership development program may look like, what about taking a narrower scope or creating a smaller pilot where you could add real value now, real value within the next 90 days that you could build on? And as the business changes, you can zig and zag with the business. Again, making it value-driven, outcome-driven, so you can make sure you're getting that value along the way and tweak the plan and the execution as you need to. So what are you doing to shift from the waterfall method - I'm building a foundation, and we'll get value later - to an agile method of getting value now.