This has been an ongoing debate for a number of years. There are essentially three groups of Project Managers:

  • Traditional Project Managers – they’ve typically operated in Waterfall environments and frequently reference the PMBOK. They often follow best practices, templates, and models for effectively “managing” projects. Usually they view success to be plan-driven.
  • Agile Project Managers – who are normally quite different than their traditional counterparts. They focus on the team and are more facilitators and coaches than project managers. They also consider success to be team-driven.
  • Then there are Traditional Project Managers who want to play in agile environments, so they start looking for specific tools and techniques that they can “borrow” from the agile approaches. They take more of a hybrid approach to project management, and this group seems to be increasing as agile approaches have become mainstream. Often these folks have acquired PMI-ACP certification, but they have little else in the way of real world agile experience.

Cutting to the chase

I don’t think you can be “agile” and still approach your projects with the same tactics you’ve always used for more traditional or waterfall projects!

I don’t look at this as a war of religion or terminology. Nor am I trying to create a divide between traditional and agile approaches. What I’m implying is that there IS a natural divide. It’s a divide in approach and mindset. It also crosses into team empowerment and accountability—a view around whether Project Managers or Teams ultimately drive the success of software projects.

In other words, I just think that agile approaches are different. That to decompose them into a series of tools and techniques does them a disservice. And to think that every technique can be independently applied without losing it’s aggregate value and impact is naïve.

By way of example, Chuck Cobb is an author, writer, and project manager who views agile and traditional project management as a toolbox. He quite often takes the position of middle ground, and I appreciate the fact that he seems to adopt a unifying vision. Chuck’s blogging platform is called Managed Agile Development, with a sub-title of Blending Agile and Traditional Project Management. A recent blog post of his was entitled Multi-Dimensional Project Management, where he made case for blending what he calls Plan-Driven (traditional) and Adaptive (agile) project management approaches.

What’s interesting is I see lots of traditional project managers wanting to unify with agile approaches and leverage some of their tactics. But I rarely see an agile-centric coach or project manager who reciprocates. It’s not that we think waterfall and traditional approaches are inherently bad. In fact, many of us have used them. It’s just that we prefer the more pure and collective agile approaches rather than cobbling tactics together.

In order to investigate the point, I’ll talk about several agile techniques and then I’ll try to explore the “behind the scenes value proposition” of each. Hopefully, I’ll expose the mindset behind them – illustrating that it’s more important than the simple replication of the technique.

Daily Stand-up

The daily standup is a fairly common agile technique. It’s a daily meeting where the team gets together and shares on their progress and travels within an iteration. The meeting is “for” the team, but can also be incredibly valuable for interested parties to observe.

The tactical stand-up is fairly easy and follows along these lines:

  • It’s a daily meeting
  • Usually 15 minutes in duration, the entire team attends
  • Everyone speaks and the Scrum 3-questions are often used:
  • What did I do yesterday?
  • What do I plan on doing today?
  • And is there anything in my way?
  • The Scrum Master usually facilitates the meeting
  • The team breaks the “huddle” then goes to work for the remainder of the day…

A traditional project manager can easily facilitate such a meeting with their team. In fact, many do. So I ask the question, are they agile? And is this technique, taken out of context, impactful as intended?

This is the rub. Often you hear the model in the agile community of “Doing Agile” vs. “Being Agile”. Doing agile is leveraging the techniques, often in sub-sets of how they were originally intended, and sort of going through the tactical motions of agility.

Do you gain some value doing this? I think everyone agrees – yes. But, you are missing the true power of the daily stand-up meeting. There’s much more surrounding it than simply “status” for the Project Manager/ScrumMaster.

What is the more advanced nuance of an effective and agile stand-up?

  • Everyone (the team) attends because they honor and respect the team. Even if it’s a distributed team, team members figure out how to schedule the stand-up so that it’s fair for everyone.
  • They (the team) speak to their commitment to the work, not only as planned, but towards adjustments they need to make in real-time;
  • They speak to the common goal that the team committed to and, if issues arise, explore how they might creatively hold to their goal;
  • They also don’t necessarily use language like: we’re behind schedule and need to catch-up. In other words they embrace the reality of complex work and try to deliver as much value as possible.

And my point is if you view it as an independent tool, then you often lose much of the value. The stand-up is NOT a status-reporting device for project management. It IS a collaborative synch-point for the team to revisit their commitments and brainstorm any requisite adjustments. And the stand-up should generate loads of collaboration before and afterwards.

Let’s look at another agile technique.

Retrospective

Again, the agile retrospective is just another way of saying project review or post-mortem as we’ve all held them. In the traditional sense, these lessons-learned can be incredibly valuable. But the old joke has always been—what do you do with the results? And the answer is often disappointingly, very little.

Then you simply rehash the lessons in future post-mortems, with very little resulting action, and rarely with real improvement. It’s a practice of collecting data to imply you had the discussions, but with very little eye towards continuous improvement; which is always the tougher nut to crack.

Agile retrospectives are in many ways – exactly the opposite. The entire team is engaged in brainstorming, discussing, and prioritizing high-impact improvements after each and every sprint. It requires a deft facilitative hand on the part of the Scrum Master to facilitate and effective meeting that drives REAL improvements.

There’s a balance between cross-team respect and emphasizing that team members need to hold each other accountable to their agile principles.

Often traditional project managers focus tactically on the meeting, creating lists, assigning owners and dates for resolution. It often doesn’t matter if these are the most impactful items or not, just that they’re managing an “action log”. And they often want to “report out” the results to management.

Making the switch to true facilitator with great skills here and focusing on enabling the teams’ ownership and decision-making is a key skill. And rarely is it important to report out the results of the retrospective. What IS important is that the team is continuously improving, trying new things, and exploring their capabilities. Additionally, the team takes pride and accountability for their actions and improvement. And the ScrumMaster/Project Manager should trust their team and protect them from unnecessary micromanagement. Again, in my experience – most traditional project managers struggle mightily with these notions.

Wrapping Up

Keep in mind that I just shared the differences in two agile practices. We could explore more of the others, as there are distinct differences in doing them well and activating the power of agility. But I hope my examples illustrated the difference in looking at agile practices as simply tools or tactics versus attaining a deeper understanding of the principles behind them. In essence, getting to “doing” versus “being” agile.

Besides Chuck Cobb, there are quite a few others who are trying to “blend” traditional project management/planning with their agile equivalents. Calvin Baldwin is another and you can see the beginning of a series of articles here on this topic.

Again, if you view the effort from a tactical perspective, then these approaches might work for you. But if you view it from an agile principled perspective, then I think it’s an apples to oranges comparison.

I also question whether many of these folks have had deep, broad, and longer-term experience within agile teams. I actually suspect they haven’t. But rather I’d guess they only have academic and/or superficial experience. If they had the deeper experience, I think they’d better understand my position and back off of trying to merge the approaches. I think their efforts will only ever results in a “Poor Man’s Agility” that barely scratches the surface of the potential of agile done well.

Stay agile my friends,

Bob.

 

1 Comment