Pyxis

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…

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…

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…

Top 10 Agile events of the decade

1- Creation of the Manifesto for Agile Software Development in 2001

2- Kent Beck re-exposes Test Driven Development in 2003

3- First Agile Conference in 2003, held in Salt Lake City

4- Ken Schwaber releases Agile Project Management with Scrum in 2004

5- Mike Cohn releases Agile Estimating and Planning in 2005

6- Esther Derby and Diana Larsen release Agile Retrospectives in 2006

7- In 2007, some of the highly regulated avionics companies start adopting Scrum

8- The Software Engineering Institute, creators of CMMI, recognizes Agile and Scrum in 2008 (http://www.sei.cmu.edu/reports/08tn003.pdf)

9- The Project Management Institute (PMI) actively participates at Agile 2009 in Chicago and formally launches the PMI Agile community

10- In 2009, some ISO 13485 compliant medical device companies start adopting Scrum

But I must cheat just a bit and add: Kent Beck’s Extreme Programming Explained published in 1999.

Top 10 Agile events of the decade

1- Creation of the Manifesto for Agile Software Development in 2001

2- Kent Beck re-exposes Test Driven Development in 2003

3- First Agile Conference in 2003, held in Salt Lake City

4- Ken Schwaber releases Agile Project Management with Scrum in 2004

5- Mike Cohn releases Agile Estimating and Planning in 2005

6- Esther Derby and Diana Larsen release Agile Retrospectives in 2006

7- In 2007, some of the highly regulated avionics companies start adopting Scrum

8- The Software Engineering Institute, creators of CMMI, recognizes Agile and Scrum in 2008 (http://www.sei.cmu.edu/reports/08tn003.pdf)

9- The Project Management Institute (PMI) actively participates at Agile 2009 in Chicago and formally launches the PMI Agile community

10- In 2009, some ISO 13485 compliant medical device companies start adopting Scrum

But I must cheat just a bit and add: Kent Beck’s Extreme Programming Explained published in 1999.

‘Twas the night before Christmas
And Santa was busy
Trying to understand
Why things got so crazy

But the plan was perfect
Created by experts
But the elves on the floor
Knew so much more

What if they’d Scrumed it
Santa as P.O.
Maybe a burndown
And of course a retro

Sprint 0 in March
And a start in April
A review every month
And see if we’re able

But Agile it wasn’t
And waterfall it was
Santa found out too late
That he wouldn’t make the date

Next Christmas will be different
It will be in December
And we won’t have to wait
For our toys in September

Merry Christmas!

‘Twas the night before Christmas
And Santa was busy
Trying to understand
Why things got so crazy

But the plan was perfect
Created by experts
But the elves on the floor
Knew so much more

What if they’d Scrumed it
Santa as P.O.
Maybe a burndown
And of course a retro

Sprint 0 in March
And a start in April
A review every month
And see if we’re able

But Agile it wasn’t
And waterfall it was
Santa found out too late
That he wouldn’t make the date

Next Christmas will be different
It will be in December
And we won’t have to wait
For our toys in September

Merry Christmas!

My current client is located near a McDonald’s so it has become my office away from the office. The main features of this location are wireless internet connection and of course, lots of coffee. To my surprise, the coffee at McD’s is pretty good! But getting a cup of it is a tad bitter.

The procedure to “efficiently” serve clients is quite evident. The cashier takes the order, punches it in the register, the bill comes out and adds it to a queue of orders on the counter, either on a tray, on a take-out bag or stand alone (when you order a coffee). A copy of this order is printed out in the back and another employee is responsible for assembling it. Sounds like a pretty good set-up.

My “beef” with this is… I just want a coffee!

I order a java but it won’t arrive until Joe gets his Egg McMuffin trio, Joan gets her pancakes and that sweet elderly couple get their whole wheat toasts, no butter. Of course, employees are simply following the plan laid out by management to effectively control the flow of orders –The perfect recipe to control chaos. At this point, the cashier is just standing there or even worse, taking more orders and adding to the queue. Now we are about 10 clients huddle together and waiting for orders that vary from a simple blueberry muffin to the complex Egg McMuffin with no cheese.

Using this time to reflect, I get this shiver down my spine when I remember that my many of my clients are doing exactly this! Ouch!

Instead of following the well defined and linear plan, why can’t the cashier quickly dispense the muffins and the coffees and thus reducing the queue by at least half?

Instead of completing form x, going through the architectural review, finalizing a use case and running a formal peer review, why can’t a development team bypass this and deliver quick value and high return on investment?

I often use the McD’s example by asking teams: Is this a coffee or Egg McMuffin trio…with no cheese? For this specific feature, do we really need to go through the regular channels and overhead or do we have an opportunity to deliver quick value? Not surprisingly, the answers are often to bypass the “normal” procedure. What IS surprising is that the methodology gatekeepers often agree! The result of this is:

• reduced inventory
• reduced motion
• and reduced waiting

Who said reducing waste was difficult?

My current client is located near a McDonald’s so it has become my office away from the office. The main features of this location are wireless internet connection and of course, lots of coffee. To my surprise, the coffee at McD’s is pretty good! But getting a cup of it is a tad bitter.

The procedure to “efficiently” serve clients is quite evident. The cashier takes the order, punches it in the register, the bill comes out and adds it to a queue of orders on the counter, either on a tray, on a take-out bag or stand alone (when you order a coffee). A copy of this order is printed out in the back and another employee is responsible for assembling it. Sounds like a pretty good set-up.

My “beef” with this is… I just want a coffee!

I order a java but it won’t arrive until Joe gets his Egg McMuffin trio, Joan gets her pancakes and that sweet elderly couple get their whole wheat toasts, no butter. Of course, employees are simply following the plan laid out by management to effectively control the flow of orders –The perfect recipe to control chaos. At this point, the cashier is just standing there or even worse, taking more orders and adding to the queue. Now we are about 10 clients huddle together and waiting for orders that vary from a simple blueberry muffin to the complex Egg McMuffin with no cheese.

Using this time to reflect, I get this shiver down my spine when I remember that my many of my clients are doing exactly this! Ouch!

Instead of following the well defined and linear plan, why can’t the cashier quickly dispense the muffins and the coffees and thus reducing the queue by at least half?

Instead of completing form x, going through the architectural review, finalizing a use case and running a formal peer review, why can’t a development team bypass this and deliver quick value and high return on investment?

I often use the McD’s example by asking teams: Is this a coffee or Egg McMuffin trio…with no cheese? For this specific feature, do we really need to go through the regular channels and overhead or do we have an opportunity to deliver quick value? Not surprisingly, the answers are often to bypass the “normal” procedure. What IS surprising is that the methodology gatekeepers often agree! The result of this is:

• reduced inventory
• reduced motion
• and reduced waiting

Who said reducing waste was difficult?