Tagged with: adaption • agile • culture • Freestyling • language • rules of engagement
This is a difficult one. I seem to have two conflicting opinions.
Yesterday Derek Huether explained in a great post how he relates agile approaches in terms of the PMBOK to get acceptance from stakeholders:
“I would propose that you make sure you can communicate with stakeholders in a language they understand. If you start using terms like Sprint, ScrumMaster, and Burndowns, when they understand contract periods of performance, project managers, and EVM reports, you may lose that essential stakeholder buy-in.”
I agree. By changing your language you can also improve the relation with a person. By talking “the same” you appear more similar, and the more similar you are perceived, the more attracted you are to your conversation partner. It doesn’t matter if you have a job interview, talking to a project sponsor or trying to get a date. Like attract likes and language is a huge influencer in that process.
But!
If you are using Scrum, you are using Scrum. There is amazing power in using a method properly. Everyone knows what to expect. All are using the same rules of engagement, you create alignment. If you use a “standard” rule set by it’s name, like Scrum, XP, Prince2, you really have to use the entire set that is covered by the label. PINO, as in Prince In Name Only, or SINO, Scrum In Name Only, is worst case. People will assume they are working according to a certain set of rules, when in reality they are not. Total misalignment.
If you are using the labels PMBOK for sponsors and Scrum for team members, you create a big mess.
So!
So?
I know. It’s somewhere in between. It depends.
But how far is somewhere?
BTW If you are interested in the question: “How do you convince an organization to use Scrum or another agile practice and really adopt it?” I recommend this post.
Bas
PMBOK is a collection of processes and knowledge areas needs for project management
SCRUM is a software development method
They are orthogonal. There are numerous matrices showing how Scrum fulfills the processes groups and knowledge areas of PMBOK.
They are not in conflict they don’t overlap in the sense they’re trying to fulfill the same thing.
Hi Glen, I appreciate you point that out. My conflicting part is in the language, in using the terms.
I disagree with Glen. Scrum can be used as a PM framework, although it needs other things added to it to make sure the work is good and to scale into larger contexts.
But to your original point. The authors of the scrum model propose it as a framework for organizing work, learning and clearing impediments.
If an organization is having problems with project and product delivery and they have called you in as an expert to help – it may be better to take the radical change approach to help shift people out of their comfort zones. If on the other hand you are a front line worker and you are trying to implement change by doing, then co-opting the current language may be better for you.
For a better discussion on this topic see George Orwell’s appendix to 1984.
I think it is unfair on any team to make assumptions about levels of understanding when it comes to jargon.
Part of the project kick-off and induction for every subsequent new joiner should be about ensuring they understand what terms and concepts mean on THIS project.
I have found that many people have worked in PINO environments and so they believe they know Prince2.
Craig,
Could you please make an explicit comparison between the scrum activities and the Process Groups and Knowledge Area of PMBOK to demonstrate how Scrum is a Project Management paradigm.
Craig
As one who is called in to triage projects, the last thing we want to do is make radical changes to the current processes. Instead we have an explicit project recovery and project triage process that starts with the principles, processes and knowledge areas of PMBOK, our own Deliverables Based Planning (r) and a further explicit “getting back to GREEN,” method.
Radical change simply further confuses everyone. I say this not from a personal opinion, but for several decades of doing “project recovery” in commercial, defense, aerospace, and industrial software intensive projects and programs – past performance references available on request.
Craig,
This is a subject close to me heart. So I speak with passion.
One of the better frameworks for project recovery is
Catastrophe Disentanglement, E. M. Bernnatan, Addison Wesley.
We’ve learned over decades, that recovery starts with “going back to basics,” NOT introducing radical change.
I’d love to hear your experiences in recovery of failed enterprise IT projects, maybe we’re are the wrong track.
SAS,
What’s PINO?
Glen
I am not saying introduce change in the context of a failed project, but in the context of a failing organisation. If you have a failure rate approaching 100% you probably want to rethink your whole approach.
In these cases radical change can be a great way to remove organisational impediments. In this context a new vocabulary can help with the cultural change (eg a Hawthorne effect.)
Glen
As for Scrum as a complete pm framework. Remember I said it has limitations – managing quality, scale and inherent complexity are three limits. And as you know i don;t think there are any substantial conflicts in the PMBOK and Scrum either.
I’ll have a go at mapping Scrum to a complete set of pm principles within the above constraints (i.e. not the PMBOK) over the coming week at post it a BetterProjects.
Bas, I’m glad you liked my post. To be clear to the readers out there, I was venting a little. The title of the post (Agile is in the PMBOK so it must be true) was a little misleading. It certainly got some people talking. Some got it. Some certainly did not.
Project management is not the Pepsi challenge. The point I was trying to make is I don’t want people dismissing an approach (cola) just because its not their preferred choice (Coke or Pepsi). Again, this was about people dismissing something before seeing the opportunity.
Some people got this; some didn’t.
One part of my post was about how a certification seems to suddenly make someone an expert. The other part was about the criticality of knowing your audience and being able to communicate in a way they understand.
I agree with you 100 percent when you say using ubiquitous terms that mean different things to different people creates a big mess. You did say that, right?
Again, thank you for reading my post.
Best Regards,
Derek
http://thecriticalpath.info
http://huecubed.com
Hi Derek,
I got that
My point is about communication and it’s use for acceptance of an approach. Reframing topics in a language that people are used to is one way to do that.
Drawback is that a PROPER use of labels is very powerful to avoid ambiguity.
That is my conflict. If you do one, you mess up the other.
I like Craigs original answer about when you are an employee or if you are a hired gun.
Many times we use words in a tongue in cheek way.
Cheers
Bas
Hi Glen,
PINO stands for Prince In Name Only, and it means that people say they are using Prince 2 method, but in reality they don’t. They do something different.
Variant for SCRUM: SINO
Cheers
Bas