janvier 2010Monthly :

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…

Following is a conversation I had with a new Scum Master that had me thinking about how coaching works. It’s not about telling people what to do but allowing them to figure out what needs to bo done. One powerful tool to do just that is changing perspectives. Reliving the facts as they happened but from a different angle may generate insights that open new opportunities for the coachee. Below is the conversation as I remember it. I hope it generates some insights for you as well.

SM: So what do you think about the sprint planning the other day ?

Coach: Well one thing I noticed, and I did mention it on the spot, the team was about to bend some process improvement rules they agreed on implementing during the last retrospective. Your role as a Scrum Master is to make sure that the team follows its own process so that they may inspect and adapt it if need be. If the team partially implements the process in some cases and fully in some others, than interpretation of the results is more difficult and it will be harder to see what to improve next. You want to be careful when introducing changes to a process so that you know what you will be inspecting in the end.

SM: Well you are right. Sticking to our decision not to include big or unclear stories in the sprint made us realise that we were accepting to tackle underspecified functionality. No wonder our estimates were off and we were not able to complete all the stories in the sprint.

Coach: Good. But what about you ? What do you think about the sprint planning meeting ?

SM: Well, one thing that bugs me is that team members don’t participate in the process.

Coach: Oh? What do you mean ?

SM: I mean they don’t seem to care or are not motivated. For instance, in our Scrum Masters group we thought it would be a good idea to let developers take turn at the Scrum Master’s role in the daily meeting so that they realize what we are dealing with. When I asked my team if one of them would like to take my place I had to wait for a long time before someone reluctantly offered to conduct the daily.

Coach: So you want them to feel what it’s like to wear your shoes ?

SM: It’s not that. It’s just that team members are not getting involved. You witnessed what happened at the sprint planning meeting. When I asked them if they were able to commit on delivering the sprint backlog, I didn’t get an answer.

Coach: Well your organisation has a culture in which developers have been told what to do, when and how to do things. The change to self organisation is not going to happen overnight.

SM: I know. That’s why I want them to get involved in the process but they don’t want to get onboard.

Coach: And why do you think the don’t want to get onboard ?

SM: I don’t know. And that’s why I’m asking you this because I’m running out of ideas.

Coach: So… What are you doing that’s impeding them from getting involved in the process ?

SM: I’m not sure I understand the question… What do you mean ?

Coach: When you are not getting the response you’re expecting from others it’s often useful to consider that you are the one causing them to act the way they do. This empowers to make some changes instead of waiting for others to change their behaviour.

SM: I’m not following you at all…

Coach: Ok. So let’s go back to that sprint planning meeting. Remember how the room was laid out and where everyone was sitting. You remember ?

SM: Yeah…

Coach: Let’s say you take John’s place. What do you see ?

SM: I’m really not sure where you want to go with this… But the only thing I see is that the monitor is too far away and its difficult to read.

Coach: Well that’s something to consider. And what are you doing in the meantime ?

SM: I’m updating the backlog and moving stuff around.

Coach: And how do you think John is perceiving this given the organisational culture ?

SM: I see… So we should probably use index cards that team members will be able to play with and update themselves.

Coach: Good! That way you solve two problems. By giving the team access to the sprint backlog you allow them to grasp more fully and own its content. They’ll probably feel more comfortable committing to it at the end.

SM (not really listening anymore): I can even update the backlog in the tool afterwards so that the flow is not interrupted. Thank you. That’s a great idea!

Coach: Well you know it wasn’t my idea. It’s yours. You just had to change your perspective on things.

SM (already leaving): Good. I’ll let you know how it turns out. Talk to you soon.

Coach (to himself): I’m not really sure what he saw exactly, but changing his perspective really allowed him to find new ideas on how to tackle this issue. This coaching stuff really works… I should blog this…

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…

Dans un article intitulé 2010 Trends in Project Management, deux d’entre elles ont particulièrement attiré mon attention :

Trend 1 – Enterprises continue to look for Efficiencies in Process & Technology
(…)
Companies will continue to look for ways to become more efficient and save money in both the short & long run. They will do this by re-evaluating their processes and technology. Lean Thinking will take precedence in influencing how this happens.
(…)
Trend 2 – Agile and Lean Processes are overtaking Waterfall
With the need to do more with less, the demand by executives for “predictability” in projects and customers needing valuable deliverables produced quicker – Agile and Lean processes will become much more the norm rather than the exception in projects during 2010.
(…)
Companies are already trying to transition to Agile, but when we look under the covers we see they are really just doing waterfall in short iterations. So without proper training on how to do this transition, a concern will continue to grow regarding project managers’ ability to deal with a new Agile world.
(…)
The need for Agile and Lean coaching will be in more demand as well. By companies bringing “experts” in to teach, model and coach teams in the use of Agile and Lean practices that work “for them” – since every environment is different – one size doesn’t always fit all. This will catapult company’s transition to Agile.

Aucun doute, l’Agilité est maintenant un mouvement de masse! Il est temps pour les entreprises d’attraper le train, et de bien se faire accompagner.

De notre côté, nous sommes loin du temps où il fallait prêcher dans le désert sur les vertus des équipes auto-gérées et de l’importance de la gestion par valeur d’affaires! Il est temps plus que jamais de contribuer à ces transitions et d’en faire des succès.

Agile lessons learned #6 : It takes two to tango

In early April 1999, FreeFall inc’s first major web project was canned. Andrew, the lead tech on this project was now without a project to work on.

Being the best and youngest programmer of his former team, he was quickly drafted by a small team working on embedded software. After the first week Andrew felt devastated. He was back to working with old technology with team members whose age averaged more than his own parents’. The last time most of these guys had followed any resemblance of a training course, Andrew was busy fighting teen acne.

Even worse, through the years these guys had developed their own technologies and terminology and were totally cut off the rest of the world. Andrew began feeling like Christopher Columbus might have had it easy with the culture shock compared to him.

Around that time, pro wrestling was the biggest thing on prime time TV. Andrew and his college buddies would gather on Monday nights to watch the “rasslin”.

“Man, that old dude is just becoming a parody of his former self.” Said Andrew
“What d’ya mean” said Mike
“Just look at him! He couldn’t wrestle his way out of a paper bag. He’s dragging all the young guys down. All of his matches have the crowd booing him out of the building as of late”
“Oh really ? “How about his up and coming opponent; are they any good or just a bunch of jobbers ? ”
“Oh man they’re great. They are doing this new fast-paced Japanese influenced style.”
“Oh ok. Couldn’t they just make him look good ? The whole thing is staged after all you know.”
“Look at them, they are booing both guys now. And they’re cutting the match short. ”

“One…..two….threeeeeeeeee it’s over” said the commentator with some despair in his voice.
“Finally it’s over. Out with the dinosaur. Man I wish I could get rid of the dinosaurs I’m working with within a three count.” Said Andrew.

Andrew went on explaining how terrible it was to work with guys that were so behind the curve and so slow.

“I wish I could help but this is pretty desperate. Management won’t unblock any budget for training courses or for coaching.”
“That’s sad. Ever tried doing some pair-programming with these guys?”
“Pair programming? What’s that ? ”
“Well basically two programmer sit together in front of a single computer and program together. Each of them has a specific role. The pilot and copilot just like in a rally.
The pilot pretty much executes the coding, while the copilot takes notes of what the duo wants to accomplish, review what the pilot is doing and gives feedback on the work being done.
“At a frequent interval, each of them alternate the roles. This breaks monotony and keeps you refreshed. How often have you felt drained after a long session of programming ?”
“All the time.”
“Well this will help you out. Also, this process will protect you from yourself. Meaning that with continuous peer review, it it much harder for you to rationalize introducing weird bits of code into the software. Every time you do, someone else will be there to catch it.”
“As a matter of fact, after a while, most realize that the quality of their work starts going up. Way up.”
“Finally, working with a real human rather than working alone with a computer makes the whole programming process more human. You have to experience it for yourself, but you’d have a hard time going back to locking yourself away in a cubicle after a couple of weeks of pair programming.”

“That sounds great but how will that help me with my elderlies? I mean won’t they just slow me down? ”
“At first yes. Like anything else in life there will be a learning curve. But after a while all the discussion brought by the continuous exchanges will bring the other guys up to speed like you wouldn’t believe.”

“You know Andrew, it’s true what they say : it really does takes two to tango.”
“What do you mean.”
“Remember when we used to say that a particular wrestler was so good he could have a four-star match wrestling against a broomstick.”
“Yeah”
“What it means is that if you really are as good as you pretend to be, it’s your job to make other people better than they could ever be by themselves. Who knows, you might even learn a trick or two from the old dogs”

-Nicholas Lemay