Speed counts

I usually pay most attention to my speed as I’m driving. To be honest, I’ve received a few speeding tickets in my time—mostly because I’m preoccupied and not paying attention to my surroundings and the speed limits. It also happens because I’m an aggressive driver and am willing to take the risk of getting to my destination faster versus being pulled over. However, the risk does catch up with you…

I think speed is meaningful within software projects as well. The agile folks have virtually abandoned the idea of plan & estimation driven project planning in lieu of velocity based approaches. The traditional views tried to anticipate the future early on in projects by carefully reviewing requirements, planning end-to-end, and exhaustively estimating tasks (perhaps padding or buffering for all of the inherent uncertainty) all focused towards accurately predicting project outcomes.

Now here comes the bad news, at least for most projects. They rarely got it right and the majority of projects disappoint in some fashion. While I really hate statistics because they’re usually taken out of context, the most recent Standish Group - Chaos Report does provide some insight into this point. And again, I reference it ONLY to show a general view to our track record. The sad news it that we fail on roughly two thirds of our projects. The even sadder news is that we've failed to significantly improve from 1994 - 2006 on these statistics even given our focus on tools, process improvement and methodologies. (read the fine print in the report and only differentiate between success and failure)

Instead of taking that up-front planned approach, what if you iteratively progressed through a project? Of course, you would have made a high level, large grained plan for it. Consider it a road-map if you will. But you would not fool yourself into believing that you can predict every nuance and outcome.

Instead, you could measure frequent deliveries of features or functionality and the effort associated with those features. That becomes your velocity for future work and you adjust your higher level plan as appropriate—based on the realities of your teams' raw capacity. If you want to go faster, then apply some changes. For example adding people, but before getting too rambunctious, measure the velocity implications of the change to be grounded in realism.

That's how the agile methodologies approach project planning - basically aligning a High Level view to a very realistic and velocity based iterative view to performance. Then connect the two for forecasting.

Another part of the agile speed equation is delivering high value features quickly. Once you understand what has value, you want to get it into the hands of the customer as quickly as possible—to determine if it meets their expectations or not. In other words, are you DONE? This philosophy is threaded with notions of Just Enough and Just in Time in your efforts. Instead of working on massive feature sets and delivering (or not) at the end, building incrementally creates a wonderful, earned value and feedback loop that is essential for measuring your TRUE speed and not some artificial interpretation without gaining feedback.

So, if you want to go truly fast:

• work iteratively
• project your delivery based on real team velocity
• and work on the most important things first

and forget about long term planning. Instead, keep your eye on the ball of today and connect it incrementally towards your goals.

Windshields, mirrors, and blind spots

I was driving behind someone the other morning who was putting makeup on while driving. It was clear that she wasn’t paying attention to anything around her – even though her vehicle had wonderful visibility. This brings up an important point regarding visibility. One has to be watchfully engaged in order to effectively negotiate the road.

Another part of visibility is that it needs to be multi-directional. It’s not enough to be looking at what’s in front of you. You also need to pay attention to what is flowing with you and even what’s behind. This 360 degree view is important, for example, if something happens in front of you and you need to take evasive action, you’ll want to know the safest path. Is it ahead of you, to the side, or behind? Only by establishing an active 360 degree view will you know.

And no matter how hard you try, you’ll have blind spots or places that are simply too difficult to sample accurately and often. However, a healthy awareness of your blind spots is crucial as well because it leads towards your awareness and compensation mechanisms.

From a project management perspective, you want to maintain a 360 degree view to your software projects. Most competent project managers keep their eyes on the road ahead. That’s sort of SOP. Gathering progress, mapping it to the plan and determining where things stand. It even leads to detecting issues and corrective action where appropriate.

However, there is more to the project road than that. We also need to pay attention to other projects in process with us – sort of who is to right and left? In case we need to make a lane change or share resources. Often we can have blinders as it relates to other projects—assuming that there is no interaction between the two. While this may be the case, stay vigilant in actually looking for interactions and dependencies. This sort of active dependency management is crucial for good project management. Of course, it will take extra effort to monitor other projects. And you’ll have to establish partnerships across your organization.

Finally, there is a powerful view in your rear view mirror. That is your past. When was the last time you did a project retrospective or lessons learned? Ok, perhaps that does occasionally occur. Now here’s a tougher question. When was the last time you actually did something with the findings? I’m talking about making crisp, finely grained project adjustments based on retrospective results. Much harder to reply isn't it?

Another powerful historical reference point can be gained from your estimates and project actual data. There are trending patterns within it that I’ve found to repeat themselves across organizations. Again, it will cost you for these insights in extra effort and in healthy analysis of the data—carefully avoiding overreaction and micromanagement. But if you can be balanced, there are treasures that can help guide your success.

So when leading your next project take a full look around. A complete look around! You might be surprised at what you see…

Planes, trains & automobiles…from a software project perspective

I spent quite a bit of time working with 6^th Sense Analytics on their metrics product. This blog isn’t specifically about that, but about metrics in general and software metrics in particular. A metaphor has been running around my head of late when it comes to software metrics and I’ll probably ramble a bit on the topic.

Driving a car is very much like driving a software project. You start out with a specific destination in mind, but along the way, you have to be adaptive to your environment. A huge part of that adjustment is related to your reading various gauges and indicators on your dashboard, while also paying attention to the surrounding environment.

There are several things that come into play:

• Maintaining visibility
• Managing your speed
• Trusting your gauges
• Watch out for “Death by Data”

I hope the metaphor makes sense and drives you to think harder about how you manage software projects.