This week marks the annual North American Scrum Gathering in Orlando. This year’s event promises to be very dynamic, with a track dedicated to project management as well as several Pecha Kucha talks.

Day Zero
But before the festivities even began, Mike Vizdos and Jean Tabaka convened a pre-gathering  retreat for Certified Scrum Trainers/Coaches. Thirty or so of Scrum’s thought leaders spent a full day trading tips and techniques for helping people learn and do Agile Project Management with Scrum.

There was much discussion around the correlation between coaching and training. The consensus that, regardless of which certification you hold, you need to do both coaching and training for any successful Agile change initiative.

Day 1 Kickoff
Then yesterday came the big kickoff. Scrum Alliance President, Tom Mellor, welcomed 300 attendees. Like last year, he asked for a show of hands for who was a PMI member / PMP, and a solid 40%-50% responded. He also announced the Scrum Alliance board will feature member-elected slots starting in the second quarter of this year. Then Luke Hohmann briefed everyone on the process the Scrum Alliance used to prioritize the backlog of member needs and requests. The results are yet to be finalized, but it was encouraging to see the Scrum Alliance share how intentional it is being with developing its strategic plan. After these introductions, Jeff Sutherland and Kent Johnson took the stage to talk about Scrum + CMMI. And offered some juicy quotes and tidbits:

• Regarding role of managers in large scrum: learn to let go of control, motivate improvement, and lead.
• Some companies are using scrum to manage their cmmi level 3 efforts…with great results
• Root cause analysis of failures. Is a key source for Scrummaster’s impediment list
• common benefit of cmmi is rework. Systematic, a CMMI Level 5 agile company moved from 50% of efforts reworked to 6%
• scrum maps closely to cmmi level 3 when used with agile engineering
• 50% of Scrum teams do not have working software at the end of
• “pure scrum” doesn’t make sense and is useless.
• 20% improvement with scrum is a waste of time you shoul be striving for 10x improvement
• Self-organization does NOT mean you get to do what you want
• Don’t misread the agile manifesto to say process has NO value

Day 1 Deep Dive
After the intro sessions, there were several day-long deep-dive sessions to choose from:

• Dialogue Room & Scrum Clinic hosted by Michael de la Maza and Gerry Kirk
  Project management, How to: Specify Critical Product Quality Requirements -  Tom Gilb and Kai Gilb
• Software Craftsmanship Workshop – Micah Martin
• Artful Making Workshop – Lee Devin
• Coaching the Coaches - Lyssa Adkins
• The Kanban Exploration – Karl Scotland
• Coaching Self-Organized Teams - Joseph Pelrine
• Improv: The Mechanics of Collaboration - Matt Smith
• Innovation Games® for Scrum Teams - Luke Hohmann

I chose Innovation Games, and was floored. After only a couple hours, I knew that I would simply have to attend the full 2-day class to get all the golden goodness Luke had to offer.

Innovation Games are facilitation techniques for collecting, organizing, and prioritizing requirements. I continue to be amazed at how little project managers (i.e. people like me) are trained in real product management. I used to think “requirements management” was about enforcing scope with change requests, but now there’s a whole new world I’ve been exposed to. For example, here’s a question every PM should be able to answer: how do you know your requirements are even correct? Yeah, it stumped me too.

It was a fantastic first day, with only more exciting stuff to come tomorrow.

Over the last week or so, Cory Foy and I have been trading posts about the state of the Scrum universe [Click here for Part 1]. In his last entry, he writes with vim and vinegar, and comes to a compelling conclusion: “Get Scrum Working Well in One Industry” BEFORE we “Implement Scrum In [other] Specific Industries”.

That is to say, if the co-founder of Scrum estimates that “75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it”, then what makes us think we’ll do any better by broadening the scope of what we want to do?

It sounds pretty cut and dry, doesn’t it? Focus on your niche, and don’t overstretch. But there was something about it that left me unsettled. It’s taken me days to digest this, but I think I have some counter-points:

• First, the 75% failure rate of Scrum is one man’s hunch. When Ken Schwaber says only a quarter of those trying Scrum get what they want from it, that’s based on his own implmentations. Certainly most teams would fail to meet Ken’s very high standards. But what if we instead asked “How many of those who tried Scrum or Agile techniques saw at least some positive improvement?” or “How many teams were in on the whole at least a little bit better off for exploring Scrum?” I bet the answer would be much different. There’s no way I would say a majority of my own clients and trainees meet my standard of a high-performing team”. However, I would say that most are HIGHER performing. The goal is improvement, not perfection. Don’t let your ideal take away from the good that is being done.
• Second, defining your niche as broad vs. deep is a false dilemma.
  The Scrum Alliance is NOT a company that has to choose between a narrow vertical industry or a very specific generic offering. Rather, it is a formalized body that supports an organic movement to “transform the world of work”. It is a big tent that provides tools and products to equip any one person’s niche within that movement. Whether offering an article for how to interact with a large company PMO, or supporting a local user group consisting mostly of GUI designers, the SA responds to what its members ask for.

  

  The niche for the SA is not a specific depth or a specific breadth of product, it’s this: “helping teams get better using Scrum”. From Tony Robbins to Colin Powell, many people make the world better by having a similarly broad-based niche. Your niche can be both deep and broad, so long as it is still a very narrow deep and a very thin wide. Tony Robbins can tell you get a little bit better as a person (thin & broad), but will mentor only a few people to become amazing as self-help instructors (thin & deep). Colin Powell will help many many people become better leaders (thin & broad), but will advise only the senior-most generals and politicians on how to become chiefs of state (thin & deep).

ABSOLUTELY, Cory is right that the Scrum Alliance has some work to do to become more effective at this mission. The recent leadership drama, churn over the certification exam, and the delayed transparancy are all problems that need to be fixed. Furthermore, he is right to describe the lack of industry-specific guidance as “magic happens here”. You should read his post. However, I do not think the SA’s execution issues point to having the wrong mission.

There has never been a shortage of criticism around the Scrum method for agile project management. However there has been a recent spike in the churn and swirl, and it’s time for some perspective. Specifically this:

The old understanding of the Scrum landscape is dead, and a newer more relevant version is rising in its place.

However, with this jarring change, comes a lot of complaints, confusion, and cults.

1. Complaints over Scrum It’s hip to complain about Scrum. All the kids are doing it, and it makes you feel good. A couple years ago, Jim Shore was among the first cool rebels, saying “Rescuing Scrum teams keeps me in business”. His complaints boiled down to Scrum certifications, which give beginners a false sense of competence, leading to disasters that he has to clean up. The criticisms haven’t changed since then. Just a couple weeks ago, agile co-founder Bob Martin posted his thesis on the shortcomings of Scrum, which offered the same old critiques we’ve heard before. Several people offered their rebuttals, but I doubt that will stop the hen-pecking any time soon. Granted, some of the criticisms are legitimate. But I see very few of these hipsters stepping into the mire to make things better. I am much more impressed by gurus like Ron Jeffries or Alistair Cockburn, who became Scrum trainers because of the complaints, so that they could be a part of the solution. It turns out that Bob Martin and Jim Shore have been contributing to the upcoming Certified Scrum Developer program. This, it seems, is their noble attempt to fixing Scrum’s lack of focus on technical training, which confuses me a little…since they’re still complaining.

2. Confusion over Scrum Over the last week, Mike Cottmeyer has been asking some good hard questions about what Scrum really is:

• “How can you certify something that doesn’t have a standard body of knowledge around it?”Actually, the official statement of the Scrum method is spelled out in the Scrum Guide. The problem is that it’s too prescriptive, and the ‘experts’ aren’t very good at explaining what that means. For example, I’ve seen several hyper-performing teams that don’t have a burndown chart anywhere. The official body of knowledge would call them non-compliant ‘ScrumButs’, but I would say the burndown is optional. As long as you some kind of empirical visibility into whether they will make your deadlines, you’re okay. Further exacerbating the problem is the exam, which offers a few questions that focus on the letter of the law, rather than the spirit. So, as in any complex field, there are good ScrumMasters and bad ScrumMasters, good PMPs and bad PMPs, good doctors and bad doctors, good lawyers and bad lawyers. When you have a disparity among experts certified in a complex field of many grey areas, then the market is the ultimate decider of who’s got it together. There is a reason why Mike Cohn is the best-selling author on Scrum: his examples offer the pragmatic flexibility the market wants.
• “How can you certify a developer, when there’s no developer role in Scrum?”. The Scrum Alliance already certifies more than just the official roles in the Scrum method (i.e. practitioner, trainer, coach). A developer certification will be the first introduction of a scrum application role. There is a LOT of dialog happening around the Agile BA, the Agile User Experience Designer, and the Agile Portfolio Manager. But there’s no formal agile method that calls those roles out either. Yes, the market is yearning for practical knowledge on application of agile thinking to specific job descriptions. I get a lot of questions from people asking how to apply scrum if they are a graphic artist, or a tech writer. But, that doesn’t mean Scrum is confused about what it is. Scrum is still the same at its core. I think it’s perfectly reasonable for the stewards of a methodology to offer maturity around how to apply it to a given skillset. What’s even more ironic about all this is the ongoing complaints. It used to be “Scrum is evil, because it leaves out technical practices.” Now it’s “Scrum is evil, because it wants to promote technical practices.” So which is it?
• “Shouldn’t Scrum focus only the IT field?” - Software people grumble about the Scrum Alliance’s stated mission to “transform the world of work”. However, I believe we could have the most mature IT department in the world, but still have that IT department reporting into a broken corporate culture. We’re seeing high-quality software evolving the fundamentals of human communication and learning at break-neck speeds, but we still laugh nervously at the sit-coms depicting bad bosses. You mission is your mission. My mission is my mission. You want to create a new set of expectations around what it means to be a software engineer. I want to create a new set of expectations about what it means to be a manager or executive. Scrum fits my mission, and it doesn’t fit your mission, that’s okay. Just don’t tell me my mission is foolish.

3. Cults Recently, Scrum co-founder Ken Schwaber stepped away from his activities at the Scrum Alliance and launched the Scrum.org initiative to focus on the software industry. Yes, there was some disagreement and some hurt feelings about how things played out. Yes, there is some confusion as to the differences and similarities between the two organizations’ products. It’s messy and confusing, and Cory Foy spells out all the sordid drama. Many have been left feeling like they have to pick sides.

But that’s what creative destruction is all about. One guy does something first, the next guy does it better. Another guy holds true to a niche, and another branches out. Then, you have a little consolidation of players and a few products being abandoned, and eventually the landscape settles. Already, the Scrum Alliance points to Scrum.org as the authoritative definition of the Scrum method itself. Furthermore, Schwaber is being featured as a headliner at the upcoming Scrum Alliance Gathering in Orlando. So, some reconciliation and consolidation is happening already. Unfortunately, it’s human nature to gossip about the drama, but that won’t be the ultimate determination of what the market will choose.

That’s my take on things. The old understanding of Scrum is dead. It no longer fits nicely into a the box you want it to be confined to. Instead, there is a newer more mature understanding of Scrum evolving. The Product Owner committee, the skill-specific applications of Scrum, and the transfer of ownership from Ken Schwaber to a democratic community are all examples. Scrum is adapting to real world constraints, in order to become more relevant to the real world.

Scrum is dead. Long live Scrum.

[Read the comments below, and then read Part 2]

This year, the 2010 Scrum Gathering in Orlando is featuring a dedicated project management track called “When worlds collide – Scrum and traditional Project Management”. I’ve been invited to participate in two sessions:

• “Agile Contracts for the Real World” – This will be a blitz talk in Pecha Kuca format (20 slides, 20 seconds each). The last time I did one of these was at the 2009 PMI Global Congress, also in Orlando.
• “Roundtable on the Agile PMO” – I will be moderating a panel discussion freaturing some pretty impressive experts: “Leading Agile” blogger Mike Cottmeyer; Scrum expert and PMP Jimi Fosdick; APLN co-founder Sanjiv Augustine, and Lyssa Adkins, the Agile coaches’ coach.

Not only is the PM track worth checking out, but PMPs get members get a $100 discount off regular registration. Hope to see you there.

A couple weeks ago, the PMI Washington DC hosted a webinar by Agile practitioner Joe Luttrell. The talk was call “Project Management: The Ultimate Calling?”, and it blew me away. You can download the slides, but they don’t convey the full essence of his story.

What’s Happened Before
Take a look at these facts:

Granted, I took some liberty by adding in the the observations about the Agile PM movement, but the overlap is uncanny. CPM, the PMI, the PMBOK, even the Agile movement were motivated by a shakeup in the business economy, or to cut to the chase:

When the market suffered recession, the market reacted with a further maturing of project management.

What’s Next
Joe also offered an analysis of what the next innovation in project management might be, by taking a look at digital technology. While most futurists declare us to have entered into the Knowledge Age or the Information Age, Joe noticed emerging technologies are mostly centered around communication. The Cell phone, CD/DVD, PDA, internet, PDA phone, Wireless, intranets, and social media are all communication media. Granted, communication is how knowledge and information is created. But look closer, and you’ll see these technologies are also progressively more collaborative. It’s more than an information age we’ve stumbled into; it’s a “Collaboration Age”.

This collaboration dynamic is a having a game-changing dynamic on management. Work used to be done under a centralized control structure. From customer support call centers to outsourcing vendors to teleworking professionals, work is increasingly decentralized. As it becomes more distributed, collaboration becomes the power play that differentiates one team over another. In yesterday’s world, the one with the most control over resources was the winner. In today’s world, the one with the most distributed and collaborative power structure is the winner. Nobody is making serious money on social media, but everyone is raving about it…because we know that collaboration is the new killer app. Well isn’t that what project managers do? We corral a variety of players from all departments toward a common goal.

What Now?
Joe concluded by giving us 3 concrete techniques we can employ to become those collaborative project managers:

1. Progressive Collaboration – Working together is a fluid endeavor. You learn each other’s habits, styles, interests, and preferences. And as soon as you get to know one another, someone new has entered the project. You can’t figure this collaboration thing all at once. You have to adapt to people along the way, and you have to persist through the annoying personalities and awkward moments
2. Conflict Confrontation – Joe reminded us that there are 3 ways to resolve conflict: Compromise (lose-lose), Smoothing (avoidance), or Confrontation. I struggle with this. I am a people-pleaser by nature. Even though I know putting an awkward issue on the table is the most effective thing to do, I get anxious about it. I get it, but that doesn’t make it easy.
3. Decisive Facilitation – As you can imagine, “collaboration” does NOT mean sitting in a meeting for hours on end, listening to everyone ramble, and beloabor the points over and over. Instead, be an intentional leader of any meeting. Know what decisions need to be made, so that you can drive discussion towards that goal.

If you can’t tell, I’m inspired. We are about to ride a the wave of a collaboration revolution. Our teams are relying on us to be the leaders that guide them along that wave. If you commit to developing these three skills, then you be a project manager that helps to change the world.

To those of you in the sunshine state, I will be teaching a Certified ScrumMaster class next month on behalf of the PMI South Florida Chapter.

I’m particularly excited about this session, because we’ll be tailoring the material specifically for every day project managers who have been trained in PMI circles. So, we’ll be covering Scrum for sure, but we’ll also talk about converting burndowns to EVM, how to work with CMMI, and most especially where the PM fits in an Agile environment. And we’ll be doing it hands-on exercises of real-world business scenarios.

Here are the details:

• Class: Certified ScrumMaster for Project Managers
• Date: March 18-19, 2010
• Location: Westin at Ft. Lauderdale, FL
• Price: $1,400 for general admission ($1,200 for members of PMI South Florida)
• PDUs: 16

Agile tool vendor, Version One released its “first annual Agile Salary survey” today on its website [PDF download]. The survey yielded some interesting results, that are worth mentioning here.

According to the survey, those North Americans aggressively using Agile techniques earn a premium of a 2.5% to 2.8% annually. The survey declines to speculate why this is. Certainly, you could interpret this to mean that Agile teams deliver sooner with higher quality, and thus are in higher demand. However, it is equally possible that only those projects with more experienced and valued professionals feel confident to experiment with Agile project management. Further complicating this observation is the breakdown of WHO actually responded to this survey:

Only 28% of respondants were involved in management, but 46% respondants were software engineers. When you consider, on average, that senior software engineers earn more than senior project managers, this may skew the results. That is, it could be that all members of an Agile team earn more than those using conventional project management. But it could also be Agile software engineers earn so much more than their conventional counterparts, it could mask the fact that there is little to no difference for project managers. That being said, I’m inclined to think that Agile project managers ARE in higher demand, especially when you consider the dramatic increase in Certified ScrumMasters, the attendance at Agile PM events, and increased interested by executives.

Finally, there was this added observation:

Not much surprise here: more experience earns more salary. Consider also that team members end up in the project manager role only after at least a few years on the job, and this aligns with common observation. Doing the math, each year of experience gets you another $2,724 annually. However, what is noteworthy is WHO has the requisite years under their belt:

While the agile community may be a young community of professionals (the majority are 39 years old or younger), it’s a very experienced group with the vast majority (70%) having at least 5 years or more of experience.

Bottom line? The survey doesn’t tell you why, but Agile Project Managers do earn more money.

That was a quote from Sanjiv Augustine, who presented this past week at the DC chapter of the APLN. His talk was titled “The Agile PMO: Scaling Agile through Adaptive Governance”. You can download the slides from his company’s website, but Sanjiv offered a few great points you won’t find in there.

“If you consistently deliver garbage, then all you have is a repeatable process”

Sanjiv offered us this point when explaining WHY you want a Project Management Office (PMO). Too often, project managers are told to serve the PMO, when it should be the PMO working to help projects be successful. The whole point of a PMO should be to improve project delivery, not merely achieving policy compliance. If your PMO can derive its tasks from this kind of focus, then you’re already ahead of the game.

“An Agile PMO is NOT a Scrum team”

After explaining what a PMO should do, Sanjiv gave us an idea of what it should look like. In particular, it should not consist of dedicated resources. Instead, it should be a standing committee, comprised of representatives from each of the portfolio’s projects. In that way, the projects retain the ultimate authority over the process. The committee discusses and debates what decisions should be made to support project delivery: switching staff, moving budget, or even killing a failing project. If there are no dedicated staff on a PMO, and it’s charged with supporting (as opposed to delivering), then by definition, it’s not a cross-functional Scrum team. This was a fascinating model, because it flies in the face of the conventional PMO, having full-time staff mandating decisions to project teams from on high….a model which seems to contribute to the very high kill rate for PMOs themselves.

“I make more money finishing smaller projects one at a time”

One of the more compelling parts of Sanjiv’s talk was when he wasn’t actually talking. Specifically, he showed off a video interview of his home renovation contractor, Steve. It turns out that Steve is a construction guy that embraces Lean management principles. He explained in the interview that when he had a larger crew, working several projects at once, he had nothing but headaches. He wasn’t able to guide the all the work sites at once, so he would often show up to find misunderstandings and mistakes. Furthermore, visiting all those work sites every day left Steve feeling stressed out and frayed around the edges. Eventually, he trimmed down to just one team, working on one project at a time, and became much happier. Apparently, downsizing his operation didn’t hurt the bottom line: Steven the one-project-at-a-time “lean contractor” drives a Porsche 911.

As always, the best part of the evening came with the networking afterwards. Once the talk was over, Sanjiv sat down with me, Richard Cheng, and the gang from Code71 to talk about these topics more in depth. I strongly encourage all of you to consider attending the next APLN chapter meeting in Washington DC, or in your own neck of the woods.

In the last few posts, I’ve been elaborating on an upcoming column I wrote for PM Network magazine. In those posts, we discovered that methodology doesn’t matter, but that doesn’t stop us from engaging in the methodology wars. In particular, the methodology war is about whether process compliance or process customization is more important for tailoring your work to the job at hand. It’s been an active conversation, with alternate posts offered up by Bob Tarne, Glen Allen, Pawel Brodzinski, Andrew Sparks, and Tathagat Varma.

Certainly, the debate between compliance-to-methodology vs. customizing-methodology is interesting. But I want to take a detour to a more fundamental question about exactly process tailoring is in the first place. Project Management experts have told us that to be effective, you have to tailor your organization’s processes for the specific context and constraints of a specific project. But they never told us HOW to do that. Exactly HOW am I supposed to know what parts are fixed, and which parts can be altered or pitched? Since no one ever gave me a good answer, I offer the following framework:

Step 1: Start With What Is Easiest.
Usually that means you start with what you have. If your organization has been using an internal procedure standard for years, then it makes sense to use that standard as a baseline for how to get work done. On the other hand, if you’ve just launched a new division or a new startup, it will be easiest to choose from a more industry-wide process standard. Doing so will give you access to more training and coaching options to get your staff setup. Whatever you do, don’t be dramatic. If you start with something that simply doesn’t fit your culture, you’ll find a lot of resistance to all the ideas, even the good ones.

Step 2: Delivery Early, Deliver Often.
The entire point of a project is to execute a strategic objective. Whatever execution framework you choose (PMBOK, Scrum, RUP, etc), you have to be able to deliver to your customer…frequently. One of your greatest risk mitigation strategies is to use your process standard to deliver completed work as soon as possible, rather than all at once. Once a work package is delivered, you no longer need to manage the project risk associated with that work package. Furthermore, your sponsors will be satisfied at having preliminary or intermediate results as a track record towards the final result. The best project management metric out there is delivered results.

Step 3: Inspect and Adapt.
How many organizations hold a lessons-learned meeting only after the project is completed? Why? Shouldn’t we be learning lessons about how to be more effective, while the project is actually underway? What if half of your communications team caught the flu in the middle of a project, the same time your subject matter expert suffered a death in the family? Did your methodology have a flowchart for that? It may tell you to crash the schedule or reallocate staff, but the project team will know better than the methodology whether doing so will impact higher priority items. A good project manager will schedule recurring project reviews, where he or she can foster a relentless commitment to process improvement. How can our process be more effective? How can we tailor it to deliver more business value earlier in the project timeline?

Step 4: Go Back To Step 2.
Once you’ve implemented a few tweaks here and there, you’ll be tempted to think that you’re finished with tailoring. However, management is never finished. The secret to a becoming a high-performing team is to be obsessed on delivering more quality, more product, more services, more often, but in a regulated fashion. Don’t burn out, but don’t get complacent. Once you’ve improved a few of your processes and procedures, go back and re-evaluate your deliverables. Then, perform another lessons-learned to become even more effective. Get into the Jim Collins’ flywheel principle, where you get better and better, gradually, consistently.

Granted, all of this is easier said than done. In the last several months, I have been working for one project sponsor that has deep anxiety over changes in the project plan, especially as the final delivery date comes closer. She’s made very significant commitments to her stakeholders, and thus, to her, change represents risk. She doesn’t want to hear that everyone failed to comply with the project process, nor will it comfort her to hear that change is just fine. My role as a project manager is to explain that we merely started with the process standard, and that success is based on how well we adapt.

So what do you think? Does this make sense as a project tailoring framework? Have you formalized your tailoring approach in a different way?

NOTE: This post is an elaboration of my column in an upcoming issue of PM Network magazine

In my previous post, I laid out 3 Reasons Why Methodology Doesn’t Matter. But the question remains: If it doesn’t matter, why do management experts fuss over those methodologies? Why do we see such heated discussions around the virtues and vices of a given set of policies and procedures?

The wars are rooted in “professional pain”
If you’ve worked on a project where you hated going to work in the morning, where the best of your efforts somehow always led to clunky deliverables, where customers and executives demanded that you squeeze juice from a dead rock….then you’ve experienced “professional pain”. I know; I’ve been there. It’s what motivated me to become a project manager in the first place. After spending 3 years on a death march of a government contract, I vowed never to stand by and let my future projects end up in that kind of misery again. When PM experts label each other as self-serving or ignorant, they miss the emotional source of issue. This is not metaphor or simile; this is about creating the humane working conditions that deliver real business results.

The wars are between Compliance vs. Customization
If the passion in today’s project management debates come from professional pain, then the substance of the debate boils down to whether it is better to run projects with more focus on process compliance or process customization. It goes something like this:

“If only we had more compliant processes…we’d have fewer mistakes…we’d have the predictability needed for planning our risks and resources…we’d know what is expected of us…we’d be more successful.”

or

“If only we had more custom processes…we’d be able to deliver real value instead of wasting time on administrative overhead…we’d be able to own more of our work…we’d be able to adapt to new information…we’d be more successful.”

Don’t pay attention to the arguments of which methodology is better; that’s not what people are usually fighting for. The real passion comes from how much compliance is best versus how much customization is best. This is the debate.

The war rages across all camps
Today’s PM thought leaders have generalized the compliance advocates as “traditionalists” and the customization advocates as “modernists”. However, the methodology wars are not limited to whether you consider yourself a traditionalist or a modernist. Some of the most heated discussions arise in the midst of those camps.

Within the PMI community, the PMBOK is strongly charactarized as the “Guide to Project Management”, allowing for whatever customized approach is needed to deliver a project. However, other project managers remind us that same “Guide” contains an official standard for exactly what goes into risk management or quality assurance. Depending on which PMI person you run into, you’ll get a difference story on whether more compliance or more customization is the way to implement the PMBOK practices.

Within Agile circles, Kanban practitioners decry several practices of the Scrum method as wasteful ceremony, driven by compliance rather than by value. Meanwhile, Scrum is also considered way too loose and easy by the eXtreme Programming community, who advocate compliance to specific engineering practices.

But who’s right? Which of the two is the better focus? Well, that’s another question for another post. For today, it’s enough to know what’s really happening the next time you come a project management flame war on some discussion board: Having suffered professional pain, managers believe strongly that either more compliance or more customization is the path to success, and will defend that belief even against those in their own camp.