Making an Actionable plan

Updated Saturday, December 05, 2009

Making an Actionable plan

Among strong developers, the problem that most often causes project failure is the Action Plan. There are several reasons I think this type of failure is common. It usually involves these misconceptions:

Specs are actionable

Maybe if we were building a small fort in your backyard and everyone showed up with tools and materials, they could follow the fort design. Everyone knows the sides should be built before the roof. Software is so different.

Having an outcome (design specs) does not mean the team will efficiently execute the best plan.

The project can be managed after it starts

True, it can, but there should be planing before it starts. Why? Well, you look like a doofus if you start the project and no one knows what they should do. After you figure out what they should do, nobody knows what to do next. After you figure out what to do next, it’s confirmed that you are a doofus.

Just plan it!

Lucky you! Creating a plan isn’t rocket science. We can quickly grab from the wisdom of the last couple decades of software development. They’ve made so many costly mistakes, why not learn from them?

Let’s go over the major pieces of a plan. These pieces can be put together by a programmer and manager or a good product owner.

Priority

Each task must have a priority to it. A major cause for employee/developer dissatisfaction is not knowing what to do. “They have a hundred tasks!” the dull manager screams. Yes, they do, but you ask them about the progress of task #67, and they were assuming task #12 and #15 were top priority. They didn’t know #67 was priority because every task the dull manager assigns is TOP priority.

Now, there are many ways to weight priority. The most important factors to consider are:

• Value to customer
• Cost
• Risk

Karl Weigers has an excellent article on the issue. The weight approach he presents is useful for business as well as development. Most import for large projects is risk. If the task is risky, you need to program that first. Yeah, it might get ugly; but it’s much better to spend time up front on the hard issues than to run out of budget because you waited until the end and assumed it would be easier.

Versions

This is a hard pill to swallow for non-developers. They don’t understand that they can’t have it all on their budget. Versions go hand in hand with priority. So, tickets/tasks go inside versions, and versions and tasks have priority.

Here is a good way to version your first product release. Break it into three:

• Version .9
  • Good enough to release, but still needs love
• Verion 1
  • All the core functionality is done
• Version Someday Maybe
  • A place to categorize features that are neat, but not adding customer value easily

If your project is long, it’s better to have small versions that match up with your sprint. In between sprint the devs and clients can recap and plan the next sprint.

Scope

Don’t worry about the entire project right now. Assess the priority of everything, but make a plan only for the next sprint. Ahhhh! That make life easy suddenly. Now you don’t have to worry about the distant future, just the next couple of weeks. This doesn’t mean that you don’t care about the future, it’s just a realization that scheduling out resources so far in the future is nearly pointless. You know what needs to be done, and in which order, but the exact when and who remains undecided until later.

The Result

Now you have made your developers happy. They know what you want done first, and will gladly work on it for you. You should have a nice Trac/Basecamp/etcetera environment setup where they can collaborate around your plan daily. Tickets should always be assigned to someone who can move them towards a close.

Work on this art of planning and your team will be extremely productive and happy. The full Scrum implementation we used on Aplos Software wasn’t rocket science, and I had never worked with happier devs. Time and time again during our sprint review we saw the developers comment about how great the teamwork was.

Lastly, there is really little developer management at this point. It shifts to product management. Your whole duty will become one of looking at the results, tweaking, planning features, prioritizing and the like. Instead of whipping devs around, you are engineering a beautiful product, and everyone is having a good time.

About the author. I'm Adam Temple. After a degree in religion I ended up in the business world and just love it. Sermonspice.com was my first big splash as it's now a multi-million dollar company (which I love saying!). Bixly.com is the next notable effort. Expert programming seriously low prices. It came about as a last ditch effort to avoid working security detail. Bixly reminds me of adolescence: thriving with health and potential, but still learning.