Agile Project Management; Crossing the Chasm from Traditional Thinking!

Far too often lately I see published materials surrounding traditional and agile project management take the middle road. I see the following sorts of positions taken:

• Yes, the two approaches are different, but they’re also very much the same
• Or, Agile PM is simply a slight twist on old, tried an true techniques
• Or, they are simply a set of new tools for your tool-box
• Or some sort of chart-based comparison, exemplifying them as largely situational or context-based choices
  
  

Let me be clear. From my perspective, Traditional and Agile PM are at two grandly opposed ends of the spectrum. The techniques are widely separated. The practitioners couldn’t be more opposite in skill and approach. Even the overall goals are incredibly different. And I don’t believe you can practice both at the same time. Not, and truly be agile in your thinking and behavior.

As someone with direct experience on both sides of this chasm, I want to take a few posts and really explore the nuance of Agile Project Management. But not from some middle of the road, let’s all play together perspective. Instead from the perspective of Agile PM as something that is disruptive, different, and undeniably successful. If you’re a Traditional PM, you need to STOP what you’re doing and pay attention to the new kid in town. We’re bad, we’re brash, and we’re a killer for software projects!

So, let’s go…

Agile Project Management; First, Break a Few Eggs

In traditional software projects, far too much effort is focused towards getting the beginning well-defined and fully planned. Effort is spent towards:

• Establishing a charter
• Crafting a detailed project plan
• Refining and re-refining the Gantt chart
• Exhaustively looking at dependencies and critical paths
• Planning for every potential risk
• Estimating every task with ultra fine granularity
• And generally feeling like up-front planning drives project success…

It’s as if we think we can create a perfect snap-shot for future events. We simply ignore all of the complexity surrounding software development and software team dynamics, and prefer to pull together a hypothetical view that we think is solid and complete. That will hypothetically guide the team towards delighting their stakeholders and driving business value. Doing all that while still empowering the team to creatively solve all challenges and problems they might encounter!

I posit that in doing all of this up-front definition and focusing on “Planning”, that we miss some things that are critically important. Things that are amplified in agile projects and that, at least I for one believe, are important for ultimate project and team health.

Taking Risks

One thing I see in traditional projects is very little risk-taking. It’s as if risk is a dirty word in these projects and to be avoided at all costs. Now this presupposes that we can easily avoid or manage risk in the first place, which is sort of a fools errand in my view. All projects incur risk, so why not embrace it to some degree and leverage it to our advantage to learn things early-on and make early, better informed adjustments.

Instead of padding estimates or doing exhaustive range-based estimation or exhaustive planning, why don’t we simply pull a strawman plan together and then “go for it”? My experience suggests that these early planning views end up roughly with the same level of effort and the same space in time as the exhaustively planned variants. It’s just that the journey is so much more meaningful.

Then load up the early stages of the plan with exploratory, risk-based activities and try to use them to reduce the overall scope or level of effort for the project. Instead of implementing features in a by-rote fashion, look to leverage the risk discovery towards better 80:20 business decision-making, while understanding and driving minimal marketable feature sets.

The net-net here is to use risk to your advantage. To surface it in all it’s glory early on and then, with your business and technical partners, make adjustment decisions based on this knowledge This is exactly the approach of Agile Project Management.

Looking to Fail

Another thing we try to avoid in traditional project management is failure. We try to avoid it, hide it, or ignore it as much as possible. One terrible side-effect of this is that it creeps into the thinking and actions of every team member. Nobody tries anything new. They stay with the tried and true practices that have historically led them towards a 34.5% project success rate. Woohoo!

And when I say fail in this sense, I’m implying that we fail small, we fail early, we make quick adjustments and try again and most importantly…we fail forward! John Maxwell wrote an entire book about the concept of failing with an eye towards learning and improvement. I think this is one of the strengths of solid agile teams—that they push themselves incessantly to improve by inspecting their results and adapting towards more efficient and effective practices.

It’s this open mindedness to try new things that I admire in mature agile teams. It energizes me much more than teams’ who are simply playing it safe.

Stretching! Please Sir, May I Have Some More?

One attribute I love about agile teams is that, if they get more done in any iteration than was planned, they’ll deliver more than they committed to. Show me the last traditional project you were on when team members consistently over-delivered…and told you that they over delivered?

Instead, what usually happens is they’ll either goldplate the deliverable they’re working on to fill the allotted time or they’ll hold onto it until the point when they planned for delivery—good old Parkinson’s Law coming into play. You remember Parkinson’s Law don’t you?

Work expands so as to fill the time available for its completion.

It, and the complimentary Student Syndrome, work against you in this regard. Student syndrome refers to the phenomenon that many people will start to fully apply themselves to a task just at the last possible moment after a deadline. So call it procrastination.

The mind-set in agile teams is entirely the reverse of these patterns. Teams will constantly ask themselves the just-enough question along the way in delivering on functionality. What is the just enough design proposition, or documentation requirement, or minimal set of tests that need to be performed? Why? So that they can deliver an acceptable feature as quickly as possible, calling it complete or done, and then moving onto the next feature.

Wrap-up

There were three key notions that I explored in this initial post—aggressive risk-taking, embracing failure, and stretching to deliver more within agile teams. These are truly special attributes of successful agile teams and Agile Project Managers. Traditionalists typically struggle with or ignore them entirely. My advice to you would be, if you struggle with these characteristics, take a look at agile practices and embrace them.

In future posts, we’ll continue the views surrounding areas where agile projects are not only different, but far better. Some exploration topics might include:

1. Team-Driven Responsibility
2. Done-Ness Criteria; AKA “No Partial Credit”
3. Agile PM “is” Controlled Chaos
4. Iron Triangle be Damned – Quality is First
5. Read my Lips – No upfront Estimates!
6. Driving Value – Where’s the Beef?
7. Others that you might suggest or that I find interesting…

So hop on the bus. It should be a bumpy ride!