Pyxis

In the same thread of the very entertaining series from Eric “An Agile coach’s journey into PMI country”, I stumbled upon an excellent paper from Charles G. Cobb that summarizes the most popular misconceptions about Agile and makes a pretty clear comparison with the PMI PMBOK. The paper ends with a list of the major challenges an organisation would face in its transition to a “more Agile” development process.

It’s so clear …and true; I wish I wrote it…

Nice work Mr. Cobb!

Becoming More Agile, A Project Management Perspective By Charles G. Cobb, PMP

My journey is actually the PMI bootcamp – A five day course to prepare for the PMP certification, completed with fellow Agile coach – and it has allowed us to see some great stuff.

To the left, we had beautiful Rolling Waves and to the right, Progressive Elaboration. Most days were warm and sunny in PMI country – running through the green fields of cost, risk, and talent, oops! HR management. But these dark clouds kept showing up once in a while and without warning, a bolt of lightning would reveal this official process: “Create Work Breakdown Structure” a.k.a. the WBS.

What we’ve got here is process number 3.4.4 in the PMBoK and this, I believe, is where the PMI got cocky. WBS is so central to the PMI that our trainers would actually say that if you don’t have the answer to a certification question and WBS is one of the options – choose it!

Throughout the PMI-PMP bootcamp training I kept asking myself the same question – If these PMI trainers recognize the distinctive nature of project management within software development, why am I getting so much resistance in the field?

My last blog generated some parallel discussions in the Scrum Practionners Group on LinkedIn, and some of the replies did shed some light.

Doug Shimp stated:

“The difference [between a WBS and the Product Backlog ] is big and forms a paradigm shift in thinking equivalent in magnitude as going from procedural code to object code. This is not easy and takes most people months to understand by doing an applied practice.”

He continued to say:

“This is one area I see messed up so often, it is painful. Our training community must get much better at understanding and teaching this stuff. For PMs coming from an long history of using an activity based WBS the change to an agile/scrum format can be quite head rattling.”

This is exactly why my colleague and I attended the PMI training. We need to understand where PMs are coming from. What are those things that prevent PMs from making the shift? The WBS seems to be one of the culprits. I’m not saying a WBS is not practical or even essential in some cases. Maybe upper management demands this type of breakdown and is not quite ready to deal with a simple and naive release burnup chart based on tested and working software, available on a pre-production server. Ok, I’m being a bit facetious. I do see value in a high level WBS that identifies product AND project requirements. I’d just assume use a mindmap but that might be too “fluffy” for some. There I go again. A WBS can provide some great value by:

• Defining deliverables
• Helping to define what DONE means
• Establishing a common language
• Setting up Organizational Breakdown Structure (OBS)
• Managing change

I might even encourage a team to create a WBS and link it up to their Product Backlog if I thought it would add value to the project. But for the most part, the Scrum teams I work with start with a Product Vision broken down into clear business objectives. We then identify the Epics required to achieve those objectives and wrap up with just enough User Stories to get started.

One thing, new agility seeking organizations can be certain of, is that WE WILL set aside the WBS, just like we would any other “traditional” tools and methodologies. I might recognize the immense potential value of their WBS, but as an experiment, we’ll leave all that aside, start anew, and see what happens. Every 2 to 4 weeks, we’ll inspect, adapt and start yet another experiment.

Of course there are those PMs who resist and feel the need to create a WBS and break it down as quickly as possible to the task level. You can imagine their reaction when I tell them that the team will do this at “the latest most responsible moment”. Some PMs almost pee their pants when I add the fact that “the latest most responsible moment” is actually one day before we start coding. I must admit – I do enjoy that one. (Yes, I do practice “Situational Coaching”, and in some cases, “TELLING” offers the highest return on investment)

At issue here is not the potential value of a WBS, but the obligatory use of one. Actually, I wonder if OPM3 would consider our Agile teams “immature” for not having this. Would it recognize the fact that we compensate or even exceed the value of a WBS with Agile related artefacts and ceremonies? CMMi Level 3 does!

But who am I to criticize the fact that the WBS is a required process and not just an optional tool? Scrum does require the use a Product and Sprint Backlog. They’re not optional tools but nonnegotiable artefacts. But there is one difference; Scrum is all about software development. It’s not interested in building sky scrapers or highways. PMI boasts that their processes apply to “all of the above” projects, and I’m fine with that. But if it wants to remain credible, it needs to abstract this WBS process. I’d call it the…Work Refinement through Execution Process. The WRX…I like the sound of that! It might include various tools and techniques such as a WBS, Product and Work (not to say Sprint) Backlog, and some activities to get these to evolve throughout a project.

I think the sun is coming out again. Time to go play with Project Communications Management…

It feels good to have a common enemy, someone or something to hate or discredit. What this usually does is create a sense of unity between individuals who share a common view. We do this with programming languages (Java vs. .Net), philosophies (Waterfall vs. Agile) and even within those philosophies (Scrum vs. DSDM vs. Crystal vs. …).

One of my preferred antagonists was the all mighty monolithic Project Management Institute (PMI) and its PMP disciples. In an attempt to keep my friends close and my PERCEIVED enemies closer, a colleague and I decided to attend the PMI bootcamp – a five day course to prepare for the PMP certification.

As an Agile coach, helping medium to large organizations transition away from traditional methodologies, I am continuously confronted and challenged by Project Managers armed with a PMP certification. Don’t get me wrong, I like being challenged! It actually makes my job easier and greatly increases the chances of a successful transition. That said, I’d like to understand where he or she is coming from. What is the driving force behind a PMP certified Project Manager? Do they have their own manifesto and maybe Project Management Charter? And who knows…Maybe this five day course would offer some additional tools to work with within an agile context.

One of my preconceived notions was that the PMI trainer’s underlying message would have been: “You must plan software projects exactly the same way as you would a high rise project” You must plan the living daylights out of the project, execute that plan and all we be fine in lala land. With my past experiences with PMPs, can you blame me?

I was very disappointed!

What we saw and heard as not an evil empire headed by an evildoer with acute asthma, but an open minded, experienced project manager coupled with a great deal of common sense. Mind you that this refers only to our first day and we get a different trainer every day (BTW, I like the “different trainer every day” concept and thinking we could do this with our Certified ScrumMaster Training – Food for thought and maybe a future post)

What we saw is a slide similar to this one…

…and the trainer actually said: “In I.T., we don’t even know what we are doing next week so don’t start planning to much ahead”.

I almost got teary eyed!

On the other hand, there is also the strong notion that the project manager is fully responsible for the success of the project. As an Agile coach continuously working to establish shared responsibility between the ScrumMaster, Product Owner and development team members, this notion rubs me the wrong way.

Some of the things I did like were:

• Project versus Product Life Cycle
• The Rolling Wave
• Progressive Elaboration: “Continuously improving and detailing a plan… ”
• The 9 knowledge areas
• Process assets (Lessons learned)
• Including “Expert judgment” in most processes

So I guess Project Managers who keep telling me that their sound PMI practices does not allow them to adopt an “Agile” way of doing things are just pulling my leg – some kind of bad joke. Next time it happens I’ll be ready with a full hearted laugh and a high five. Hopefully he/she doesn’t leave me hanging

I’ll be elaborating on the Knowledge Areas and Process Groups in future posts, but for now, suffice to say that I’m prudently putting aside my perceived dichotomy between PMI and Agile.

Stay tuned…