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…

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.

‘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?

I guess you’ve all heard about chickens and pigs in Scrum. A client of mine just offered me a new one: The Scrum Hawk. He explains it like this :

“When SCRUM is new to an organization, the first couple of sprints will likely not go as well as planned. At this point, the scrum chickens magically transform into hawks, ready to pounce on the scrum team. “Pouncing” may include attending the daily standup meetings to put pressure on the team.”

Who are these Hawks?
What are Scrum Hawks doing to your new (or not so new) team?
How are they affecting the team?
How do we ground these Hawks and get them to cluck again?

What about the team?

Individuals and interactions over processes and tools. This basic core value stated in the Agile Manifesto implies so much it’s hard for anyone to totally grasp it. As an Agile coach I owe it to myself and to my clients to properly understand this value and do my best in helping teams and organizations apply it. But how can we achieve an efficient level of interactions that is high in value?

I don’t impose a lot of conditions to organizations who want to start a so called Agile project but there’s one where negotiation is not possible : Having a team. Not a group of individuals working for the same manager but a team of professionals aiming for the same goal. If this can not be appreciated by the organization, I see no need to go any further. It’s the foundation to any successful I.T. project! And forget about moving on to the “working software”, “customer collaboration” and “responding to change” values without a solid team.

I enjoy taking it one step further by creating a team where the frame of mind is one of a small company. While respecting the fact that team members are proud to be working for their employer (at least I hope they are), they need to create this small company feel and understand that THEY are responsible for the failure or success of THEIR project. With this philosophy in place, rich, open and honest interactions become essential. Of course this doesn’t happen over night and a team needs to move through those well known “Forming, Storming, Norming and Performing” stages.

If you want your project to succeed, you need individuals that are able to interact efficiently. Efficient interactions happen when individuals are aiming for the same goal, trust each other and are accountable for their success. Put together a team of competent, cross-functional professionals, allow them to reach a performing stage and there’s not much they can’t achieve. Oh! By the way, this perfect team includes the client…

Scrum stinks? I don’t think so.
Scrum makes you cry? I’ve seen it happen.
You leave Scrum out in the sun, it gets all brown, start sprouting’ little white hairs?
No! Layers! Scrum has layers!

The outer layer of Scrum is the high level process. This includes the ceremonies of Scrum such as the daily scrum, the sprint review and retrospective. We can also include the product and sprint backlogs, and burndown charts. These things can be explained in a few minutes to a bunch of drunken friends at a party and they’d still remember it in the morning.

Going deeper into the next layer involves something that comes before the actual Scrum framework. Before diving into a Scrum project, we need to assemble a cross-functional team and create a common vision with the help of a competent Product Owner and ScrumMaster. A project launch, Sprint 0, or whatever you want to call it is needed to deliver the oh so important Project Charter. Only then can a team slowly move from being a group of individuals working for the same manager to a group of professionals collaborating towards the same goals.

Our onion also has a technical layer to it. The incremental and iterative development layer required in Scrum implies sound engineering practices. At the top of this list of practices is testing. If the product is not thoroughly tested, disaster will soon ensue. If non-tested code is prevalent in the application, courage to refactor will be low and the end result will be a design dead code base. The team must, at a minimum, be exposed to various practices such as Test-Driven-Development, Domain-Driven-Design and Agile Modeling. The scrum team must deliver a high quality product every 4 weeks that responds to the client’s needs, and Agile engineering practices can help the team achieve just that.

Moving inwards gets a bit more stinky. It always amazes me how such a simple framework can provoke so much change. Changes are required not only within the the Scrum team but at all levels of the organization and resistance to change is often more prevalent with upper management than any other sector. This is actually quite funny because upper management is the one calling us to “deliver” Scrum in the organization.

Scrum has a whole bunch of other layers but those are the first ones that came to mind. Not to mention that my eyes are quickly turning red!

Fortement inspiré par un article récent d’Esther Derby, voici mon interprétation du comportement que doit adopter un directeur de service lors de l’introduction d’une approche Agile tel que Scrum.

Read more…