It has been a busy week for PMI Agile work. Last week I was in San Antonio with the PMI Agile Certification Steering Committee reviewing the latest market research and next steps for the certification launch. Things are also moving forward on the PMBOK v5 Guide with some more agile terms defined and content suggested for Chapter 6.

The PMI recently sent a detailed Agile survey out to a sample of its members and received feedback from >1,300 people. They were looking for feedback on the types of project managers using agile and their adoption of the domains and knowledge areas that comprise the Domains and Knowledge & Skills that will be in the exam.

Nearly 60% of the respondents were from the US with Canada, India, and Brazil being the next most popular. Not surprisingly the biggest industry sector was in IT, with Finance and Consulting being well represented. Most had 2 or more years’ agile experience and had participated in 4 projects or more in a leadership role. 80% held PMP certifications and nearly 30% CSM certifications.

One of the aims of the survey was to ask for rankings of the Techniques, Tools, Knowledge and Skills that will form the body of knowledge  that the exam is based upon. I would love to share these categories here but have been asked not to until after the official release on April 15th. This is understandable, and only fair, but once they are publicized I will have plenty to say about them.

I am sure the 1500 or so PMI Registered Education Providers  (REPs) along the Scrum CST’s who will be offering exam preparation courses will be having a busy Spring and Summer.

Meanwhile on the PMBOK v5 Guide, each of the chapter teams are busy completing the initial chapter re-writes ahead of integration and review. I have been surprised at the rigour and constraints imposed on the writing. Due to the guide being translated into a dozen languages, readability and consistency is key. As, for instance, on our latest effort one PMI reviewer commented that the Microsoft Word 2007 Readability Statistics show a Flesch Reading Ease score of 26.6, which is considered to be "very confusing" and "not easily understood by college graduates". A score between 60 and 70 is largely considered acceptable. So we have rewritten chunks and tried to simplify.

The increased accommodation of agile content is great, not just in my chapter, but I am  hearing  about agile content for the other chapters too. When the call for feedback goes out we will get to see what has been incorporated. I will publicize it here and encourage people to review the new PMBOK v5 Guide for agile content and suggest where more can be added – if appropriate.

That’s the update for now, stay tuned for more on the certification categories after the PMI reveal. Rest assured since we had a great mix of Agile Manifesto authors, PM experts, and pragmatic agilists working on it I don’t think people will be disappointed.

Part 2 of my article on Agile contracts has been published on Gantthead.com. Part 1 reviewed the existing agile contract samples from the DSDM Consortium that speaks to “Fit for business purpose” acceptance criteria and “Passing Tests” rather than meeting specifications. Part 1 also examined the CoActivate Community sample Fixed Price agile contract and Jeff Sutherland’s suggestions on early termination and functionality swapping.

Part 2 highlights some of the ideas Jesse Fewell presented on agile contracts at the PMI Global Congress last year. These include Graduated Fixed Price and Fixed Price Work Packages as building blocks for creating agile contracts.

Clearly these contract options are not panaceas to possible engagement woes, but they do offer some examples of how organizations and suppliers have been able to utilize the flexibility of agile for mutual competitive advantage. 

The new PMI Agile certification will come on stream in two waves. The first is the pilot program starting in May where participants get the chance to sit the 120 question, multiple choice, 3 hr exam and instead of pressing the dreaded “Submit” button at the end, they will be advised 10-12 weeks later. This long wait is to allow the PMI to score everyone in the pilot and then calibrate the cut-off scores.

For enduring the wait, and I guess being guinea pigs in the process, pilot participants will receive a 20% refund on the exam fee bringing the cost to members of $435 down to $348. To qualify to sit the exam participants must satisfy the following criteria:

• High school or equivalent education
• 2,000 hours general project management experience within the last 5 years (if you already hold a PMP you can forget this since you had to prove that for your PMP)
• 1,500 hours agile project management experience working on agile project teams or in agile methodologies within the last 2 years. These hours are in addition to the 2,000 hours required in general project management experience
• 21 hours agile project management training

 

The full certification program will be publically available in the third quarter of 2011. To maintain the credential you must earn 30 PDUs every 3 years in agile project management and these hours would also count toward fulfilling PMP requirements.

 

The PMI took the wraps off their new PMI Agile Certification program today. If that sounds like an oxymoron then take a closer look. There have been a growing number of agile sessions at PMI conferences over the last 6 years and an entire agile track at the last PMI Global Congress. The PMI reports that 65% of its members are involved in IT projects and Gartner are predicting agile will be used by 80% of software projects by 2012, so the demand is huge. My PMI SeminarsWorld course is popular not because anyone wants to see me, but instead the demand is high for information on how to run agile projects within PMI based organizations.

I have been working with the PMI on the program for about 18 months now, but muffled under NDA contracts so it is nice for it to be out in the open. Doubtless there will be criticism against the whole idea of certification and then again about an agile certification from the PMI. I thought long and hard before agreeing to participate, but then committed enthusiastically. Two things were clear to me.

1. The PMI had a big elephant in the room. Many IT projects were using agile methods and project managers were offered little guidance from the PMI on how to incorporate such endeavours.
2. The PMI were committed to providing a knowledge base, training options, and a certification program with or without me. If it was going to happen anyway, I wanted to be on the inside trying to steer it in the right direction rather than on the outside wondering if it might suddenly take a left turn.

Fortunately others felt the same way and the core team of steering committee has a wealth of grass roots agile knowledge. With Agile Manifesto authors and industry experts, we have a great pool of agile knowledge feeding into the design. Plus for some of us it was not the first go round of defining an agile project management certification. Mike Cottmeyer  and myself were engaged on the APLN effort that morphed into the DSDM program and is now quite popular in the UK. The PMI-APP materials, training and certification will provide people with vetted information based on practices found to work in these hybrid environments.

While the routes taken by agile and PMBOK methods can appear very different to the lay person (explore and validate versus plan, plan, plan) both approaches have the same ultimate destination of successful projects and satisfied stakeholders. Tools and techniques that help determine the appropriate level of planning and introduce agile team benefits are vital tools for today’s project manager’s toolbox.

While certifications do not assure competence or capability to manage projects, they are a useful learning tool for people new to the domain. In this role I welcome the certification for the training and awareness it will bring to this important and expanding field.

I am especially pleased by the quality of the agile thought leaders engaged in the design and evolution of the program. By having expert contributors from the agile field, the risk of misapplication by the uninitiated, or rejection by the agile community should be reduced (but not eliminated).

So for me it is not so much about the certification, but hopefully the training materials, studying and increased awareness of successful adoption strategies it should bring. 

What do you think? I would love you hear your thoughts…

The next occurrence of my Agile Project Management class will be in New Orleans on February 28 and March 1st (Feb 18 Update: and is now full ). After that there is:

Savannah, GA - April 11, 12
Dallas, TX  - October 26, 27
Anaheim, CA - November 7,8

I enjoy delivering these courses and people enjoy attending them too, here are some feedback comments:

"Mike delivers an exceptionally well reasoned and effective presentation of agile. Thoroughly appreciated" - Bill Palace, El Sugund, CA
“The best PMI class I have ever taken.” - Scott Hall, Marriot International
"This was a very well executed course. Instructor (Mike Griffiths) was very engaging!" – Ameila White, Boeing
"The instructor was very knowledgeable, class well organized, content at the right level of detail and very comprehensive. One of the best classes I have taken regarding PM topics" – James Bernard, Scottsdale
"Excellent course with great information" – Tom Gehret, JNJ Vision Care
"Excellent facilitator. Mike is respectful and knowledgeable" - Nghiem Pauline, San Diego, CA
"The course was fantastic " - Kimberly Kehoe, San Diego, CA
"Mike is an excellent instructor and I really appreciated his organized and clear, well researched presentation. His domain and project management experience is evident from his talk. Also I appreciate his exposure/experience to multiple approaches like PRINCE2, PMBOK, Scrum, DSDM etc." - Sarah Harris, OpenText
"Great content and delivery" – Andrea Williams, Fed Ex
"Great Stuff!, Really enjoyed instructor and real-world examples" - Don Brusasco, Northridge, CA
"The instructor did an excellent job of keeping the pace, - clearly explaining topics and providing practical applications" - Cathy MacKinnon, Schering Plough Corp
"Excellent!" – Peter Colquohoun, Australian Defence

All of these classes sold out last year so if you want to attend I suggest you book early; I hope to see you in New Orleans!

So we had our Agile Mythbusters session and it went really well. I was a little concerned that we would present a myth to the audience and there would be no discussion, debate or dialogue, just crickets chirping and tumbleweed rolling through. However, as normal, people were great and we had some good explanation and analysis of the myths.

After a warm up round debating the likelihood of the Calgary Flames making the playoffs (currently theoretically “Plausible”) we got started with “You cannot accurately estimate agile projects”. There was a good discussion about how we estimate agile projects and how in fact the feedback from iterations provides concrete evidence for better estimating. Yet the larger issues with accurately estimating something as intangible as software were highlighted.

We talked about if you changed the phrase from “You cannot accurately estimate agile projects” to “You cannot accurately estimate software projects” people were happier to label it as “Confirmed” so the debate was really about if agile software projects are easier or more difficult to estimate than traditional projects. Anyway, after nearly 30 minutes on the first agile myth we wanted to move on, so we labelled this one "Confirmed" and continued.

“Agile will increase Quality” was the next one and we had some frank discussion about the poor quality agile projects that occur. Like many things “it depends” was the consensus. Clearly there are opportunities for improved quality, but often a lack of discipline prevents these opportunities from occurring. So in the end “Agile will increase Quality” was labelled  “Plausible”.

Next up was “Since empowered teams self organize and self-select work, the role of the project manager goes away”.  This one was not contentious and several useful lists of project manager roles were generated. Our most unanimous myth decision, “… the role of the PM goes away” was "Busted".

The last myth we debated was “It is very difficult to negotiate contracts for agile work”.  This triggered some interesting accounts of contracting and the goals of suppliers and buyers. Many people struggle with agile contracting and are not aware of all the work done in this field. I was looking for a topic for this month’s “Agility Now” newsletter at Gantthead.com so I wrote up an account of agile contracting that may be of interest if this is an issue for you.

Anyway, it was a fun session and thanks to Mike Haden and Janice Aston for facilitating.

I like myths and have written on Leadership Myths previoulsy. For our next Calgary APLN Meeting we are hosting an Agile Mythbusters discussion. The idea being to debate some agile myths and through group discussion determine if they are Busted, Confirmed, or Plausible.

Now, likely an APLN audience might have a little bias, since the “A” in APLN stands for "Agile", but I hope that since we have cross posted the invitation to the local PMI group we might even things out.

Through my teaching for the PMI I get to hear many questions and rebuttals to agile’s claims and I think it is good to question benefits and have an honest reality check from time to time. Some of the myths proposed for discussion so far include:

•    You cannot accurately estimate agile projects
•    Agile methods promote scope creep
•    It is very difficult to negotiate contracts for agile work
•    Agile projects cannot be tracked with earned value
•    Agile projects employ counter intuitive planning practices
•    Stage gates don't work for agile projects
•    Agile methods avoid accountability
•    Agile projects are cheaper
•    Without specifications you do not know when you are done
•    You would not allow a housing contractor to proceed without a clear plan and estimate, why develop SW this way?
•    Agile scales naturally
•    Agile teams are happier
•    Since empowered teams self-organize and self-select work, the role of the project manager goes away
•    Agile methods erode the gains made towards recognizing SW development as a serious engineering discipline
•    Agile methods ignore enterprise architecture
•    Agile is quicker


Please send me your own agile myths for us to discuss. We will be choosing 5-6 to run through at the meeting. If you are in Calgary on January 26 please join us for the session. Registration details here at the Calgary APLN site.

If you cannot make it in person, I will write up some findings and publish them here later.

A big part of project management is working to grow a high performing team and then caring for that team so it stays healthy and productive. Agile concepts around empowered teams and team decision making support these goals and so there should be no surprise that agile project management aligns well with team development best practices.

However, it never hurts to better understand some of the things that can go wrong on teams so that we can quickly take action and hopefully resolve issues before they become full blown team problems. Patrick Lencioni’s book “The 5 Dysfunction of a Team” lists the following 5 common problems that build on from each other to undermine trust and eventually performance.

1) An absence of trust – an unwillingness to be vulnerable and honest within the group.

2) Fear of Conflict – Teams that lack trust cannot engage in unfiltered debate. Instead they resort to veiled discussions and guarded comments

3) Lack of commitment – without passionate debate, team members rarely if ever, buy in and commit to decisions, though they may feign agreement during meetings

4) Avoidance of Accountability – Due to the lack of commitment and buy-in most people will hesitate to call their peers on actions and behaviours that seem counterproductive to the good of the team.

5) Inattention to results – Failure to hold one another accountable leads to putting individual goals (or department goals) ahead of the project.

Fortunately agile methods and some common sense offer many tools and values to address these issues...

Agile methods encourage partnering more closely with the business customer to benefit from shorter customer feedback cycles. When this works, it is great; we get quick confirmation of deliverables and engage in collaborative evolution towards the true business requirements as opposed to the originally stated requirements that may have been flawed or incomplete.

Yet poor customer feedback can really undermine progress. Effectively the customer has become a more central member of our project team and just like a poor BA, developer, or QA, the impact of a weak customer link is significant.

Often customer engagement issues stem from confusion over roles and levels of involvement. Perhaps the customer has not been invited into development teams before and may feel uncomfortable speaking out about potential gaps in functionality early in the project when work is still underway. This is why it is important to clearly outline benefits of good feedback and the issues with poor feedback.

For project managers some warning signs of poor customer engagement can be:

1)    Little or no customer feedback – If following a demo or promotion of functionality to a test environment for customer review we get very little feedback, then the optimist in us may think “Great, we must have nailed it, there have been no complaints or requests for changes”. Yet, it is more likely that no one has thought about it much or used it in anger. In this instance “No news, is rarely good news” and is instead should be viewed as a warning sign that effective evaluation may not have occurred.

2)    Late reporting of errors – If as a release date approaches we see the reporting of errors or requests for change relating to functionality that has been in previous demos, but never commented upon, then it is a sign that this functionality was not seriously reviewed previously. Instead only now, as the release date is approaching does it appear the customer representatives are reviewing seriously. This is a problem since functionality may have been built on top of the early code, and opportunities for change and improvement have now been lost.

LeadingAnswers recently placed 8th in the Top 50 Leadership blogs list, rated by The Entrepreneur Blog. This was a great surprise and I did not even know it was nominated for reader voting. First and second spots went to Seth Godin and Daniel Pink so I am honoured to be listed in this kind of company.

Many of the other sites were new to me and I am guessing new to you also, check out the full list and maybe discover some other sources of leadership information.

 
So you think you know agile? Well then why not take the Agile Star Quiz and find out if you are really an agile star or more of an information black hole. The questions in each category start out easy, but get harder. Score yourself either manually with the answers shown below or use the attached Excel Agile Star Quiz and scoring model spreadsheet to generate your agile star graph scores.

History
1)    The Agile Manifesto was created at a meeting at:
     A) A rugby match, Auckland, New Zealand, February 2001
     B) A ski resort in Vail, Colorado, February 2001
     C) A ski resort in Snowbird, Utah, February 2001
     D) The OOPSLA software conference, 1999

2)    The last three “Agile 20xx” North American agile conferences have been held at:
     A)  2010 Orlando, 2009 Chicago, 2008 Toronto
     B)  2010 Nashville, 2009 Salt Lake City, 2008 Toronto
     C)  2010 Salt Lake City, 2009 Orlando, 2008 Washington D.C
     D)  2010 Orlando, 2009 Chicago, 2008 Washington D.C

3)    Who published the statement “Software development should be done incrementally, in stages with continuous user participation and replanning”?
     A)  Kent Beck, 1997
     B)  Harlan Mills, 1976
     C)  Ken Schwaber, 2001
     D)  Jeff Sutherland, 1995

This was a regional competition, not the national one, but I am really pleased to report that the IPS project I managed for the last 3+ years won the PMI-SAC Business & IT “Project of the Year” award at last week’s PMI Gala and Conference.

The Integrated Pipeline Solution (IPS) manages about a third of Canada’s heavy oil transportation. While you may think tracking oil moving through a pipeline sounds pretty simple, like anything, the devil is in the details. Husky has about 30,000km of pipeline and complications such as blending products, forecasting production, optimizing capacity, custody transfers, billing, accruals, etc and the fact that billions of dollars are at stake mean that the rules, regulations and complexity adds up pretty quickly.

We had an amazing team and engaged, savvy business representatives – these were the real reasons for success, not the methods we followed. However, there were lots of challenges too and our approach helped us here. We “inherited” the project $1.1M behind budget after an outsourced vendor doubled their estimate following a year of analysis. They were asked to leave and the project was brought in-house, but with no adjustment to the original budget.

Agile methods excel at fixed budget projects providing the sponsor is willing to flex functionality. This is what occurred and we actually ended up delivering more functionality that originally scoped within the initial budget.

The PMI Awards assess projects on a variety of criteria and asks for submissions in a specific 10 page format. I will spare you the 10 page version and instead list a quick summary of the benefits:

• Enhanced Business and IT relations – against a backdrop of varying degrees of business / IT co-operation, the project stood out as an example of completing a long and challenging project through close cooperation. The stakeholders were practical and pragmatic about decision making and priorities. The increased trust built on this project has been useful for launching subsequent projects.

• Business Benefits – the business benefits of creating a single, integrated pipeline system are numerous. User configurable calculations, better data quality, faster calculation speeds, and improved reporting are just some of the tangible benefits.

• Improved resilience and support – The IPS project moved the Pipeline group from a set of unsupported, legacy systems to a new platform of state of the art .Net and Oracle 11g solutions. User developed spreadsheets with questionable data integrity were also replaced.

• Project Objectives met – The project delivered all the requested functionality within the defined project schedule. This functionality was delivered to a very high level of quality, and while there have been some changes and minor fixes since April 2010, there have been no production outages. The project finished just under the $6.1M budget frozen in 2006 despite having to incorporate late breaking business changes in 2009.

Does your PMO Produce Multiple Obstacles for your project or Promote Many Opportunities for success?

A Project Management Office (PMO) can act as an obstacle to agile projects. This can take the form of asking for inappropriate planning detail by not recognizing the likelihood of changes; or asking for conformance to templates that are not even used on an agile project. For these reasons PMOs often get a bad reputation on agile teams, but it need not be that way, they can also add tremendous support and be a great help.

First let’s look at what a PMO actually does (or what they should do, since implementations and services vary). In the September 2010 issue of the Project Management Journal (the PMI’s research publication) there was a nice definition of PMO roles:

1.    Monitor and control project performance
2.    Develop and implement standard methodologies, processes, and tools
3.    Develop the competency of project personnel, including training and mentoring
4.    Multiproject management, including program and portfolio management, coordination and allocation of resources between projects
5.    Strategic management, including participation in strategic planning and benefits management
6.    Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance
7.    Management of customer interfaces 
8.    Recruit, select, and evaluate project managers
9.    Execute specialized tasks for project managers (e.g. preparation of schedulers)

This definition is good because it speaks to the “supporting” and “developing” roles a PMO should provide and moves beyond the “conformance” and “compliance checking” functions that many teams think of when they consider a PMO. However, when taken with a rigid, traditional-only view of how projects should be run, the PMO can lead to the Produce Multiple Obstacles issue:

Most people studied the Highway Code before taking their drivers licence exam. They had to learn (enough of) it to pass the exam, but then most likely did not reference it again, except until helping a friend study for the exam. Maps on the other hand, in printed paper form, or digital like GPS, are referenced much more frequently. Maps help us plan, track progress, and get to our destinations and we refer to them often when travelling anywhere new.

So, is the PMBOK Guide like the Highway Code or a map? Do we only read it to pass our PMP exam and then it gathers dust, maybe picked up again to lend to a friend? I think for many this is the case. Maybe for the first couple of projects, people may refer to it for guidance on how to undertake a task or process, but just a soon as people have a few real world examples they no longer refer to the guide.

Recently I have spent hours revisiting Chapter 6, the Time Management chapter as part of the PMBOK Guide v5 update. It has got me thinking about “who reads this stuff?” and I expect mainly people studying for the PMP exam. So maybe some jokes would be in order, to lighten up the learning experience? “We now break from 6.4 Estimate Activity Durations to tell you about the two project managers who walked into a bar…” but I somehow think this would not get past the review committees and proof readers.

Because many people find exams stressful and unpleasant we tend to lump things associated with that stressful experience as unpleasant also. If you pick up a Highway Code book from a dusty bookcase many years after passing your test and leaf through it, it can bring back emotions of learning about road signs and stopping distances. I wonder if this is why many people never return to the PMBOK Guide, too many stressful memories.

So could the PMBOK Guide be more like a map, a useful resource we return to time after time before planning our project journey? How would it need to change, maybe with some checklists and how-to steps? Yet, for an industry agnostic guide aiming to apply to construction projects, IT, and bio science, how could these guides apply beyond the most generic items?

Agile methods are best suited for small projects. Women are not suited for extreme endurance events like marathons and ultra (beyond marathon) races. Oh, how conventional wisdom seems ludicrous after being proven wrong time and time again.

“The heresy of one age becomes the orthodoxy of the next.” - Helen Keller

I have been doing more trail running this year, and some ultras. It is great to see the sport is not male dominated and many events are won outright by women. Before the 1980s, there were no women's distance races in the Olympics at all; 1,500m was the furthest race distance allowed for them. Before 1972, women were barred from the Boston marathon and most other marathons.

Pam Reed beat all the men in the Badwater 135-miler two years in a row. Local girl Ellie Greenwood, often beats all the guys in her ultra races. Scientists believe women may metabolize fat more efficiently than men for better fuelling and that estrogen may delay mental weariness. I just know there are lots of ponytails passing me on the trails, and am good with that.

As women go from being thought of as too frail to run marathons to kicking major butt in ultra marathons, so too do agile methods. First described as “light weight” and only for small, co-located teams, we are now seeing more and more use of agile methods in truly huge, distributed, complex projects.

At last year’s Agile Business Conference in London I learned about Nokia’s massive agile roll-out where 1,800 software developers are using agile techniques to develop the Symbian mobile phone platform. This immensely complex endeavour is tightly coupled to quickly evolving hardware, divergent phone standards, and a variety of different cell providers worldwide. Using a variant of Dean Leffingwell’s “Agile Train” approach they are scaling agile to tackle a very complex domain and produce rapid, high quality results.

At this year’s PMI Global Congress last week Richard Spires CIO of the Department for Homeland Security (DHS) spoke about his role overseeing $6.5 billion of IT focussed spend annually. He has 91 projects greater $50M in his portfolio. So, how does he and his team manage it all? “With more and more adoption of agile methods” he said. It is the only way to keep up with the complexity and high rates of change required for this massive portfolio of projects.

Agile started small, and this is still my recommendation for companies looking to adopt it, but do not limit its application or growth there. Command and control structures get heavy and slow to change as they scale up. The weight of the control system seems to over burden the operation of the functions. Perhaps the lighter weight of agile methods can actually be an asset to solving truly huge projects by not smothering operations as they expand?

I think we will be seeing more accounts of ultra sized agile projects in the future.

  There has been some hubbub on the PMI Agile Yahoo Group these last couple of weeks. A lively back-and-forth about a slide deck published by the PMI Network magazine entitled “Is Agile Right for your project?”

The original slides were here, but interestingly the slides appear to have been taken down now, or perhaps they have been temporarily lost in the recent PMI web site reorganization. An example of some of the feedback can be seen here. On the one hand I think the PMI should be applauded for making some steps towards providing information for its members. On the other hand the material could have been vetted by some members of the PMI Agile Community of Practice before release to smooth out the contentious issues and avoid the backlash.

I recall the original request for information on agile adoption guidance was sent to the PMI Agile Community of Practice. I submitted my thoughts on the topic (posted previously here) and many other people joined in the discussion thread, but I am not aware of what, or if any, of this information made it to the original requestor.

Anyway, my point is not so much on the content of the slides and what was right or wrong, but more on the reconciliation of agile and traditional PMI mindsets.

Social Integration Problems
Whenever two different groups come together for the first time, we get some friction, clashing of norms, exposing of preconceptions and good old fashioned faux pas by one or more groups. But, hey, it at least means the two groups are coming together and providing we have thick enough skins to tolerate the friction progress can be made.

Jane Jenson, from the University of Montreal, provides a model for social integration that lists 5 characteristics that need to be in place to create good social cohesion between different groups:

1)    Recognition – Both groups need to recognize the other group’s position
2)    Legitimacy – Both groups need to acknowledge the validity of the other group’s point of view
3)    Inclusion – Neither group should be excluded from events, roles, or functions
4)    Belonging – The benefits of belonging to a combined whole need to be understood
5)    Participation – Both groups need to work alongside each other on shared initiatives

Researchers also provide the following model of how social cohesion works:

Project management has matured with many professional organizations, certifications, and bodies of knowledge, yet we still hear of numerous project failures. What has gone wrong; is project management broken? I don’t think it is broken in terms of any of it being fundamentally wrong, but certainly flawed in the view that good project management ensures success.

You see, what project management with all its plans, estimates and reporting omits is a good recognition for the huge impact people play in projects. Consider for a moment the roadblocks we encounter on projects, the most common and toughest to resolve are people related. Yet the classic project management guides focus more on Earned Value than Influencing, more on KPI’s than Knowledge Transfer, more on Project Tracking than Team Performance. Project management may be correct, but it is not sufficient for creating success.

Like considering only speed limits and traffic signals, but ignoring other traffic movement when driving, we will run into people, have accidents, and not get to our destination on time with such a myopic view of the big picture. A large portion of the missing part of project success is Emotional Intelligence (EI) and the EI skills most needed by project managers include:

•    Communication Skills
•    Persuasive Leadership
•    Conflict Management
•    Change Management
•    Adaptive Personality

For more information on the importance of EI for project managers and how these skills are applied see this recent White Paper.

Well, what an on / off / on-again relationship this has turned out to be. After explaining how I was rejected from the PMI PMBOK v5 initiative previously, I received news this week that I have been accepted onto the content creation group for the next version of the PMBOK v5 Guide.

I am not sure if this is a result of me expressing my concern to the PMI that the roughly 60% of PMI members who are engaged in IT likely want some better agile project management guidance and there seemed no one on the committee to provide that. Or simply the ripple down selection of more candidates inthe content creation categories. 

Anyway, I am grateful for the opportunity and am looking forward to contributing wherever I can, because here’s the kicker, I have been accepted onto the group to rewrite Chapter 12 on Procurement. This is odd because when volunteering to contribute we had to rank which chapters we would most like to work on. Given my agile designs on planning, scheduling and estimation these are the areas I ranked highest, ranking Procurement as the lowest.

Now, perhaps I got my high / low ends of the scales mixed up and I accidently voted Procurement highest, but I do not think so. Perhaps the selection committee thought fine, if we have to have this agile windbag onboard, put him over in Procurement where he can do least damage! Or perhaps simply not many people volunteered for Procurement and so that’s where the only opening was. I have sent an enquiry into the PMI, but am not holding my breath for a reply.

Anyways, so now I need to determine how to best influence the Procurement process with an agile perspective. It is quite applicable as I am currently going through an RFI and RFP process with my main client and last year, at the Agile Business Conference in London, I was in discussions with the developers of the new Agile Contract group which may have a tie in.

So, not the role I was looking for, but perhaps a small foot in the door, time will tell and I will keep you posted.

Following my post on 5 Things to Think About Before Stand-Up, it is only right that I follow it up with the 5 things I think about after Stand-up.
 
1) Issues – Anything that was reported as a blocker, impediment, or issue to making progress needs removal or avoidance. Agile employs a “constraints view” of production systems similar to Eli Goldratt’s Theory of Constraints where the role of the manager is to remove impediments from the process. The impediments or blocker issues reported at stand-up should become the project managers To-Do list to ensure their resolution.
 
2) Velocities Deviations – We know the task estimates so when a 2 day task has taken 4 days and is still going with no end in sight, it is time to investigate. If there is time in the stand-up it might be appropriate to ask if there are any problems? Alternatively it might be better to follow up afterwards and determine the issue. Was it a poor estimate, a wicked problem, or sign that perhaps someone else should take a look? In isolation these occurrences are common; however repeating delays in work areas or with team members might be signs of deeper issues. Likewise overly high velocity (all the 4 day tasks being burned through in a day each) might be signs that we can re-evaluate our iteration goals. Just make sure “done” really is “done” and the tasks are all passing QA and user acceptance before booking the end of project party a month early.
 
3) Emotions – Consider what was said and what perhaps was not said. Was anyone upset or angry, were there tensions that need to be understood, a bubbly person abnormally quiet? All might be signs that a quick chat could be in order. These are impediments to progress just as much as reported problems. Some we may not be able to solve, but perhaps just enquiring and listening to what they have to say is a useful step towards resolution itself. (Thus allowing the worker bee to then produce more code... Buwahah!)
 
4) Questions – Perhaps we did not fully understand some progress or issue discussed at the stand-up. If a quick clarification during the meeting did not help then likely some follow up questions are required. (I used to be a developer and understood technical things, now I sometimes have to explain that I am a project manager and you have to speak slowly to me. If that still does not work I explain that I am actually a PMP certified project manager and so you will have to speak really s-l-o-w-l-y). We cannot fix what we cannot understand and while many things remain the domain of the technical team, when escalation and impediment removal is required (i.e. my job) I need to fully comprehend the issue so I can best resolve it. 
 
5) Recognitions – All work and no play makes for a dull week, month, or project. Look for opportunities for some kind of recognition, event or milestone to celebrate. We want to maintain motivation so people have the energy to blast through obstacles not run out of steam at the first hurdle. A great way to do this is to frequently recognize progress and contributions. This can be a simple thank-you explaining what people did that was useful and how it helped the project, or a team lunch, or gift. These events can make all the difference between a death march and rapid team progress.
 
Again these are my Top 5 today, on a different day I may include different things like the skills fit for selected tasks, resource load balancing, or if we are mitigating the remaining project risks, but these are currently not as high priorities on my team. What about you? Please share what you consider following stand-up?

Stand-up meetings are familiar to agile teams and as the saying goes “familiarity breeds contempt” or at least complacency. It is all too easy to drift into a daily routine of holding a stand-up meeting without getting the full set of benefits out of it. So this led me to consider: what are the 5 most important things to think about as a project manager before stand-up?
 
(If you are using Scrum and have a Scrummaster role that is distinct from the project manager, then I would suggest these are things the Scrummaster should be considering)
 
1) A View of the WIP – A view of the work in progress is critical to understanding the items reported from the team. If you thought invoicing was a focus right now and no one mentions it, chances are we have an issue somewhere! Appreciating the work areas helps oversee new work selection, areas that might be falling behind, or where extra help may be required.
 
2) Yesterday’s issues – What did people report as issues yesterday or earlier? Have these issues been resolved now, or do we at least have an update on the resolution plan. It is pretty disheartening for people to report impediments to progress day after day and not have them worked on. It does not show much respect for their concerns or our valuation of their time. So, what is the news? Are there any follow-up items that need to happen?
 
3) Team View – Projects are more than tasks and schedules, they are networks of collaborating individuals. We need to understand the people elements of the team to build a shared commitment to a goal. Show an interest, recognizing a birthday, or upcoming wedding or vacation. Know what is going on with your team as it will colour their behaviours and provides a good opportunity to demonstrate an interest in them. If some people dial-in, try to follow the headlines there so you can ask them about the heat wave, giant sink hole, or whatever it is that is happening, this also helps them feel more integrated.
 
4) Areas of Spin and Churn – not all issues are reported specifically as issues or blocks to progress, some are more subtle, perhaps dragging anchors that slow progress rather than road blocks. Are there any tasks that have been going slower than anticipated, perhaps people are struggling to get traction (spinning) on a new task? Be especially attentive to the discussion of these items during stand-up. If things are moving again now, then great, here was a potential for micro-management interference avoided. A fact of project life is that some tasks will take longer than anticipated. If however team members are stuck on a task for a couple of days or flip-flopping on decisions or approaches (churn) then perhaps it is time to suggest a fresh set of eyes to pair on the problem or help move things along.
 
5) What you are going to say – just like the team members who we expect to have a list of accomplishments, planned tasks, and any impediments ready to report; it is important to have the same items to describe. I report on my progress on impediment removal and since I believe in transparent project management, run through the main project items too. While my issues may not be of as much relevance to the technical team, a review of any budget, hiring, and steering committee items is generally welcome (or at least politely tolerated!)
 
Obviously there are many other things to consider (shared commitment, vision, energy), but I am interested in understanding what you think the Top 5 are? If you have suggestions for items to replace any of these 5 please leave a comment, I would love hear your thoughts.

Agile methods are powerful approaches that bring many benefits to how we undertake project work. However, they are not immune to misuse or failure. The following list of 5 common pitfalls are often seen in organizations switching to agile. “To be forewarned is to be forearmed” as they say, so look out for these pitfalls and if you see any developing, a side step can be useful to help avoid the mistakes of others.

1) Agile as a silver bullet - Yes, agile methods can save time, increase business buy-in, and create a high quality product, but they are no silver bullet. They will not bend space or time and allow you to deliver more work that is possible within the constraints of limited time, budget, and resources.

Deciding to switch a doomed project to an agile approach will not make it succeed. You may fail faster, or at least discover realistic progress indicators (velocity) earlier than with a traditional approach, but unachievable goals will remain unachievable. By all means use an agile approach to salvage a core set of valuable functionality from a failing project, but don’t expect agile methods to miraculously make the impossible possible.

2) Agile as an excuse for no discipline – Contrary to some people’s beliefs, agile methods do not abandon discipline and jump straight to coding without the need for plans and estimates. Agile methods involve many high discipline activities and techniques like Test Driven Development, Wideband Delphi estimation, and bi-weekly iteration planning and estimation sessions take a lot of discipline.

If team members are pushing back on estimating or cannot explain the release plan, these are warning signs that they may not be following the agile practices. Instead they could be using agile’s preference for low ceremony documents as an excuse for avoiding doing the disciplined activities that make up each of the agile methods. Hold them accountable, ask for their estimates and request their retrospective findings.

Why so much Communication?
“We work with bits not atoms”. This phrase speaks to the distinction of IT projects from physical construction. Our tools and processes manipulate ideas, concepts, and models, not steel, concrete, or plastic. Given the intangible nature of software, it is no surprise we need more focus on communications, collaboration and information sharing to keep everyone informed and aligned towards a common goal.

Agile methods recognize this increased need for communication and provide a variety of tools and checkpoints to help avoid the classic project mistakes of mismatched expectations and confusion. In the absence of a visible physical product to point at and measure, we need to be constantly confirming understandings and aligning ideas against increments of the final solution. Otherwise we get the “That’s not what I asked for” or “That’s not what I need” of yesteryear’s IT projects.

Why So Often?
Daily Stand-Up meetings are common on agile projects, not because IT folk are more forgetful than other workers and need to discuss work goals and results more often; but instead because the potential for misunderstanding is higher when working on novel, hard to describe problems. Stand-Up meetings keep the team informed of work and issues that change quickly and also provide a forum to raise obstacles to progress so they can quickly removed before they unduly impact performance.

Why So Many Demo’s?
Software projects typically contain a lot of uncertainty. You would have to be clairvoyant to accurately predict the final business requirements of an organization 18 months out into the future in today’s rapidly changing business environment. So agile methods accept some requirements are likely to change and rather than have a change control process that should really be called a “Change Suppression Process” they welcome new ideas and then seek priority within a backlog of requested features. Obviously changes cost money, but if it is more important than some previously discussed item, then why not incorporate it and deliver some late breaking competitive advantage?

Agile methods promote the frequent demonstration of software for a couple of reasons. One, to get feedback and make sure it is fit for business purpose. Quite often it is not until we see something that we can better articulate what we really need, now with reference to a visible prototype. Another reason is that it is often during these demonstrations we learn about business changes and new requirements. Many times I have heard comments along the lines of ‘Oh, and for product ABC we will need to way of entering X” when this has been news to us. That’s OK, visual demo’s tap into the right hand side of our brain, not used much in analytical, left brain list making and requirements gathering. It is the combination of lists and visual cues that frequent demo’s provide that create our final views of what the system should encompass.

I am posting my recent Gantthead articles here for those of you without Gantthead access. This is also a ploy on my part to keep some regular contributions coming to this site during the short Canadian summer while I am out enjoying the trail running and mountain biking prime time. Summers in the mountains here are just spectacular and every event and race in the high elevations is crammed into a short 2-3 month window.
 
So, for now I will post my recent Gantthead articles to keep the content rolling. There are also some exciting developments at the PMI I am itching to tell you about, but am sworn to secrecy under a non-disclosure agreement for now, but stay tuned.

Recently I volunteered to help write the PMBOK v5 Edition and encouraged other agile project managers to get involved in the initiative also. Well, last week I heard back that my application to serve on the PMBOK v5 Core Committee was not successful.

The email explained that because they “…had received over 250 applications from a highly qualified group of candidates.  Unfortunately, we had more qualified candidates than available positions…” but I can’t help wondering if my “PMBOK v5 - Raise a Little Hell” post might have set off a couple of alarm bells with them too.

Anyway, apparently they are still looking for people to work on the Content Committee and Review Committee so perhaps I will get a spot there; I hope so since I enjoyed my involvement in the PMBOK v3 Edition.

I would be really interested to hear from anyone in the agile community who was successful in gaining a spot on the core PMBOK v5 committee. I hope there are some agile proponents represented. So please drop me a line if you were successful.

As one door closes another one opens, and Gantthead.com the online project management portal and recourse site with >470,000 members, has launched an agile newsletter called “Agility Now!” and have asked me to help.

I have been writing for them for a couple of years now as part of Doug DeCarlo’s eXtreme Project Management department and so was thrilled when they offered me the role. Each month the newsletter will contain new articles on agile project management and highlight agile blogs, tools, and events of interest to agile project managers.

Fellow PMI Agile Community of Practice cohort Jesse Fewell will be contributing a regular “Agile People” article too and I am looking forward to seeing how it develops. To sign-up go to Gantthead.com, My Account, Subscriptions and Notifications, and select the “Agility Now!” Newsletter.

Back in 1994 when we were defining DSDM, I remember our experiment of getting the user community engaged in the application architecture. (Not a successful experience!) It was at Data Sciences in Farnborough, UK and we were working on a project for a government client called ECGD. Following ideas from Enid Mumford on Participative Design we were testing how far the benefits of closer business engagement went and discovered a limit.
 
For us at least, having the business closely engaged in scope discussions, screen designs, and planning was extremely positive, but having them engaged in our architecture sessions was a net negative experience. They leapt to implementation ideas, disregarded IS strategy, and did not know enough about the architectural issues to be helpful in the discussions. We got frustrated, they got frustrated, and no body seemed better off.

So we discussed it with other DSDM Consortium members and agreed business involvement should not extend to architecture. The DSDM framework was updated and we carried on with our experiments and evolution of the method. For me this was a transformational moment, it was my first time of witnessing a failure and adaptation of a process within DSDM and how we learn and adapt. We just changed the methodology; there was no sacred cow, just good old scientific experimentation.

Business involvement in GUI design: Good
Business involvement in architecture design: Bad.
Therefore, involve them in GUI design, but not in architecture.

Decision making is both analytical and emotional. We need to make decisions to move forward beyond the forks in the road, but when exactly is the best time to make them? Agilists have the automatic response of “At the last responsible moment” drummed into their heads so often that you may think they are drones rather than free thinking individuals.

Delayed
Agile and Lean gurus have explained the benefits of delaying decisions until the last responsible moment for many years. It prevents us from committing to potentially harmful decisions too soon and instead enables us to gather more information and then make a better decision when we actually need to. It keeps design options open, enhances agility, and allows agile teams to be more responsive to change than teams who have locked into a defined approach early.

Dated
Real Options adds some math to the picture. It supports the same general idea of decision delaying and providing some dates and values for our decision making calendar. This could be reassuring for people left feeling a little uneasy by all the “up in the air” decisions. Now, it is not that we are just putting them off, but instead have agreed that there is an optimal time to make each decision and when that arrives we will make them.

Done
I recently read the excellent “Rework” book by Jason Fried and David Heinemeier Hansson of 37 Signals and it was refreshing to read about their thoughts on Decision Making. They say: “Decisions are progress. Don’t wait for the perfect solution. Decide and move forward. You want to get into the rhythm of making choices. When you get in that flow of making decision after decision, you build momentum and boost morale. You can’t build on top of “We’ll decide later”, but you can build on top of “Done”.

Plus, you don’t have to live with a decision forever. If you make a mistake, you can correct it later. It doesn’t matter how much you plan, you will still get some stuff wrong anyway. Don’t make things worse by overanalyzing and delaying before you even get going. Long projects zap morale. Make the call, make progress, and get something out now – while you’ve got the motivation and momentum to do so.”

I like this a lot. We can often get caught up in the analysis of the perfect moment to make a decision and forget the very real motivational impact of not deciding. Decisions are emotional and our emotions impact our productivity. Yes it might be marginally better to decide on that reporting tool at the end of the month, but if everyone is non-committal until then or only 90% focussed, perhaps not sure on what will happen, then what is the real cost of this Real Option?

People’s ability to deal with ambiguity varies from person to person. However many people find it disconcerting to work with little bits of their commitment parked at each of these delayed decisions. It is foolish to try and schedule being happy on Thursday at 2pm, likewise it is foolish to assume delaying decisions comes without motivational penalties.

Like most things, we can’t live by a single mantra such a “Delay decisions to the last responsible moment”, instead we need to balance the analytical benefits of delaying decisions against the emotional costs and remember that, as Rework goes on to say: “Momentum fuels motivation. The way you build momentum is by getting something done then moving on to the next thing.” Rework keeps it real, and for that is a great read.

“…we need to balance the analytical benefits of delaying decisions against the emotional costs …”

If you don't like
What you got
Why don't you change it?
If your world is all screwed up
Rearrange it

The PMI is calling for volunteers to help write and shape PMBOK v5 Guide Link. Here is your chance to inject more recognition and support for agile methods. I was involved in The PMBOK v3 Guide rewrite and got two small changes accepted in 2004 when agile methods and the PMBOK were hardly being talk about and I was a bit of a lone voice at the party.
 
If you don't like what you see
Why don't you fight it
If you know there's something wrong
Why don't you right it
 
Since then the tides have changed and now the PMI Agile Community of Practice is the largest and fastest growing PMI community. In the last PMI Network Magazine sent to members there were two full articles on Agile project management. Of the PMI’s 340,000 members an estimated 65% are in IT and the demand for agile guidance that has proliferated in other disciplines of IT (development, analysis, QA) is very apparent to the PMI, who need to serve their members.

In the end it comes down to your thinking
And there's really nobody to blame
When it feels like your ship is sinking
And you're too tired to play the game

A “Pendentive” is an architectural converter that lets you fit a domed roof on a square base. The pendentive shown in the image on the right is the yellow part.
 
When working in a traditional project management setting we often need agile pendentives that let us fit agile practices onto a traditional base. Here are some examples:

Traditional to Agile
1.    WBS –>  Prioritized Backlog. When asked to show the Work Breakdown Structure (WBS) sponsors and PMO are likely looking for a breakdown of the project deliverables. Traditional project management approaches recommend creating a WBS early in a project lifecycle after gathering requirements and defining scope.

Agile projects acknowledge this upfront design is likely to change and so deliberately go a little lighter on these definition activities, preferring to invest the time in building portions of application and arriving at agreement of functionality through feedback.

2.    Detailed Gantt Chart –> Release Plan. Detailed Gantt charts are another example of a detailed upfront design deliverable that is likely to be brittle and changing too frequently to warrant the update effort in project environments that have high levels of requirements uncertainty or technology uncertainty. It is not that we cannot create Gantt charts for agile projects – I do for some stakeholders. Rather that the time and effort required to update them is probably best used elsewhere in gaining agreement of the true business requirements.

So, instead of producing detailed Gantt charts that list tasks and do not survive contact with the reality of software projects, release plans that layout iterations and release timeframes are a more robust planning tool.

Agile methods emphasize and encourage empowerment and creating empowered teams, but empowerment is not enough. Empowerment, according to Daniel Pink author of “Drive: The Surprising truth about what motivates us“, is just a slightly more civilized form of control. This control is part of a broken motivation system corporations use that he calls Motivation 2.0.

Here’s the quick summary. Motivation 1.0 is our basic desire to find food, shelter, sex, etc. Once met, people look to higher levels of rewards to motivate us. Motivation 2.0 has been traditional management’s carrot and stick motivation system. If you do this…, then you get this…. The trouble with IF-THEN rewards is that while we like them at first we quickly tire of them. Then because the reward can never continue to escalate at levels that excite us, we grow used to them and get discouraged if we fail to meet the IF condition and do not get the reward or worse, if the IF-THEN reward is removed.

Daniel Pink states several MIT studies where adults and children were rewarded for conducting work, hobbies and play activities. Once the reward is removed people stopped doing them, even if the had previously happily voluntarily done them before. Once tainted by IF-THEN rewards, the motivation was sucked right out of it.

Pink asserts the current IF-THEN extrinsic motivation corporations use, that he describes as Motivation 2.0 is flawed and needs an upgrade. Hence the need and rise of Motivation 3.0 based on the intrinsic concepts of:
•    Autonomy
•    Mastery
•    Purpose.

Autonomy means giving people control over how they work. Moving beyond empowered teams who are required to be in work for stand-up meetings at set times each day, instead giving them control over:
    Task – the work then do and how they undertake them
    Time – when they choose to work in the day, week, year
    Technique – How they perform tasks and from where
    Team – How they organize, interact and collaborate

I have written previously on Results Only Work Environments (ROWEs) where people are given these freedoms and Ricardo Semler’s Semco is the poster child, but Pink offered additional examples of Meddius and Best Buy headquarters. Not only do people prefer it, but productivity and profits increase as satisfaction and motivation blossom.

Mastery describes the pleasure we get from doing what we love and following our passion. This can be seen when someone is so absorbed in a task that they are in the zone, or what Pink calls finding their flow. “Flow” is a great term to describe the state of mind when time seems to disappear and we are just immersed in the task. This feeling of flow can be difficult to find when our work environment puts obstacle after obstacle in font of us, whether it is admin and rules that limit our time in the role that we love, or restrictive work processes that impinge too much to allow us to get into this flow.

Mastery comes from:
    Flow – having the time, space and freedom to find and exercise your passion for a profession
    Goldilocks Tasks – Not too difficult and not too easy, but just right. We need enough Goldilocks tasks to stretch, engage and indulge our desire for completion and satisfaction.
    Mindset of learning – people who believe intelligence and knowledge is not a fixed capacity we are endowed with, but rather a muscle or skill we can grow. People who are happy to face their limitations and continually find new learning opportunities achieve mastery easier.

Purpose describes tapping into people’s belief that there should be more to work than just making money and being successful. Instead aligning company goals with individual’s aspirations for doing good and meeting a higher guiding principle.

This is why companies like TOMS Shoes were created that give away a pair of shoes to poor countries for every pair sold. Buyers feel good since their purchase has a charitable impact and the workers at TOMS feel good since they are doing more than just generating shareholder value. Instead they are tapping into their motivation 3.0 principle of a compelling Purpose.

Motivation 3.0 for Agile Teams

For the last 25 years I have been learning about high performing teams and trying to create high performing teams. Well, I finally got to work with one for 3 years solid and I totally loved it.

For the last 3 years I have been working on the IPS project at Husky Energy with the best team and project I have experienced or reviewed. More of a program than a project, we rewrote a number of legacy pipeline control and billing systems in .NET and removed a clutter of spreadsheets and Access applications that had sprung up to fill the gaps left by difficult to upgrade legacy systems.

I had worked with great people before, I have seen the difference good executive support, and engaged business representatives make. However, as the cliché goes, when you bring them together, and add enough freedom to make big changes, the result is much more than the sum of its parts.

Why So Successful?
Freedom to reset and redo - This was a project restart. After several unsuccessful attempts to kick-off the project and then a failed experience with a vendor to out-source it, the project was brought back in house and restarted. I was fortunate to join at a time when management was open to fresh approaches. Already $1M behind budget and 2 years delayed, we were able to introduce changes into an organization receptive to hearing new ideas and changing process.

Executive Support and Business Champion – These terms “Executive Support” and “Business Champion” are often just titles, mere names or nouns. For our project they were verbs that described their everyday jobs. The sponsor fought to retain our budget during cut backs, the business champion repeatedly went to battle to retain resources, gain exceptions from harmful processes and ensure we had access to the very best business resources.

An experienced, pragmatic team – Most of them had “been there and done that with pure agile”, they had seen the benefits and costs associated with pure TDD, XP, and Scrum. They knew all the theory and had heard the theological debates and just wanted to work now. They were exceptionally strong technically, with mature use of design patterns and layer abstraction. Mainly experienced contractors and some experienced full time staff, humility was high and ego’s low.

Great domain knowledge – We had an insider, an architect from some of the original systems we were replacing on our team. The bugs, the flaws, the big chunks of tricky logic from the original systems could all be highlighted and explained rather than rediscovered, a great time saver.

Embedded with our business users – Being away from the IT group and in with the business was critical in learning their day job and building rapport. By seeing their business cycles, busy days and deadlines we were better able to plan iterations, demos and meetings. Being face to face and sharing a kitchen helped with conversations and quick questions too.

Right Process – Way behind our people’s influence on success was our process, using a relaxed interpretation of agile, we worked with two week iterations, daily stand-ups, user stories, and empowered teams. Given we were replacing existing required functionality it meant prioritization and detailed task estimates were less valuable. From a perspective of minimizing waste we naturally gravitated to do less story point estimation and lighter iteration planning sessions. It was reassuring to hear David Anderson in 2008 talking about Kanban and viewing estimation and iteration rigour as waste. We were not just being lazy; we needed a certain fidelity of estimation for planning, but beyond that got diminishing returns.

The Outcomes
High Productivity - The last release contained over 1400 function points that were developed in one month by 6 developers. This is approximately 12 function points per developer per day, over three times the industry average and other releases had similar productivity. This was despite the domain being complex, we had a full time PhD mathematician SME (subject mater expert) on the team to define and test the linear programming, and iterative calculations being used.

Personas get little mention in project management guidelines, yet they can energise the dullest of requirements and remind us of absent stakeholders. So I was pleased we Mike Haden suggested the topic for our next Calgary APLN meeting. Here’s the outline:

Title: "Using Persona to Move Your Project Forward"

Outline:
The use of personas has received scant attention in project management literature. First utilized in the late '90s as a tool of business analysis, a persona is a detailed description of a fictional end-user including how they use and perceive the product you're delivering. However, personas can have a strong impact on projects by providing a project team with a human face to enhance otherwise abstract data about customers. From streamlining communications, to managing stake-holder expectations, to maintaining the team's alignment with the project goals, personas can engage your team and enhance your capability to move the project forward rapidly.

This presentation touches on the origins and definitions of personas, the benefits and criticisms of their use, and includes a case study of persona implementation on a complex application development effort. Focused on how personas can galvanize a project team into action, it is an engaging, interactive presentation lasting of interest to all members of systems and application development teams.

Bio:
Mike Haden is an independent consultant with over 20-year's experience in Application Development, Project / Product Management, and Global Product Development. Throughout his career, he has delivered complex data analysis tools to the demanding Canadian oil and gas industry. Mike has experience in bridging the business and technical domains, balancing the communication needs of multiple stake-holders, and aligning project teams to the end-user.

While working in commercial software firms leading development teams that utilize agile project methods, Mike gained valuable experience in delivering application development projects ranging from true R&D through new commercial developments to replacements of “industry-flagship” applications. His current role at EnergyIQ is focused on a new data analysis product for the US oil and gas industry, developing business processes and technology to support distributed product development.

Mike is a Project Management Professional, a Certified ScrumMaster, and a Six Sigma Green Belt. He is presently the VP Communications for the Southern Alberta Chapter of PMI. He dreams of eventually finishing the rejuvenation of a 100-year-old house and having more time for his outdoor pursuits in the mountains near Calgary.

Date: Wednesday April 28, 2010  Noon-1:00pm

Location: Fifth Avenue Place (Conference Room) Map

Register: Attendance is free, but please register in advance to guarantee your spot.

Agile methods typically don’t cover the early stages of projects very well. They often assume you are ready to start gathering requirements as user stories, or that you even have some candidate features or stories magically ready to go. This is shown by the scope coverage diagram below.
 

 
 

Yet for all but the smallest, most process-light organizations, there are stages of envisioning, feasibility, and setup that happen before we are ready to jump into requirements gathering. This is where many companies come unstuck with agile. Either they jump straight to stories and miss out the early project stuff and suffer disoriented stakeholders and disengaged project offices. Or they go too heavy with the upfront chartering and scope definition, create brittle plans and lose some of the advantages of adaptation and iterative development.

The following diagram is a good place to consider starting from. It combines some of the bare necessities from a traditional approach that will satisfy the project office. Yet it does not go too far into Big Design Up Front (BDUF) to create problems or consume too much time that could be better spent working directly with the business to determine their requirements via collaborative development.

 
 

The overall duration is short, just 15% of the likely (guestimated) project duration, but yields lightweight versions of the key deliverables familiar to the PMI process police. We get stakeholders informed and engaged, the project office placated, and the bulk of the project duration dedicated to iterative development. 

Instead of a Work Breakdown Structure (WBS) I would recommend a candidate prioritised Feature List or prioritised Story list.

 

Kick-Off meetings using the Design The Product Box exercise, or Shape the Poduct Tree are a great way to start identifying candidate features and then follow them up with Feature Discovery Workshops. The length and number of feature workshops will vary depending on the size and complexity of your project. A three month web project with a team of three people might be scoped in a day or two. Yet a three year project with 30 people will take longer to drive out all the candidate features.

I am actually quite a fan of the early project deliverables like Project Charters since they explain important W5+ (What, Why, When, Who, Where + How) elements of a project, but believe these documents don’t have to be verbose or costly to create.

Instead cover the basics, get people onside and the whole endeavour will go quicker than if you try to start without these things and have to catch people up later.

This article summarizes my “Lessons Learned in Project Metrics: Are your Metrics Dumb or Smart?” presentation. It covers the following six topics

 

2010 is shaping up to be a good year for training courses and events. I have the following public enrolment courses available through the PMI.


March 10-11 Anaheim, CA

April 13-14 Scottsdale, AZ

September 15-16 Las Vegas, NV

November 10-11 Scottsdale, AZ

December 15-16 San Diego, CA

 
My private courses are available year round, see here for a list and course outlines, and I am also hoping to head back to Alaska this summer to teach a class for the PMI Alaska Chapter there again.

As normal I’m keeping the bulk of the summer free to take full advantage of the short, but fantastic hiking and mountain biking season we get here around Calgary. I was hoping to attend the Agile 2010 Conference in Nashville, but the dates August 9-13 clash with the TransRockies Mountain Bike Race August 8-14 that comes right through my backyard of Kananaskis and is too good to pass up.

Instead of the Nashville agile conference, I hope to attend another agile conference in the fall, perhaps the Agile Business Conference in England again, or a Scrum Gathering event. Then of course there is the PMI Global Congress conference in Washington, DC in October. With the PMI Agile Community of Practice now the largest PMI community with >1700 members there will be a large Agile contingent attending and many great agile sessions to go to. Once again so many events and so little time!

On February the 16th I will be presenting at the Calgary Software Quality Discussion Group. This was the first group I presented for when I moved to Calgary nearly 10 years ago and I am very happy to go back and talk about a topic I really care about: Project Metrics. I care not in the sense that I think they are fantastic, instead I care because I think the majority of common metrics are counter productive and misguided. Here’s the outline:

Lessons Learned in Project Metrics - Are Your Metrics Dumb or Smart?


Collecting and reporting effective metrics can be a tricky business. Einstein captured it well when he noted "Not everything that can be counted counts, and not everything that counts can be counted".

Software projects have a history of measuring irrelevant and even counter-productive progress tracking metrics. The "Hawthorne Effect" should teach us that we will influence what we measure, yet companies continue to overtly track things like hours worked and lines of code written, unaware that they send the message of valuing long hours over results, and discourage simplifications and healthy refactoring. Quite often the metrics we want to track are intangible and subjective and so people tend to shy away from them.

More fundamentally, why are we even tracking these metrics? Is it to report on what has already occurred or help steer our future course? Often an imperfect view of the future is more useful than a perfect view of the past. In the real world, rear-view mirrors are much smaller than windshields for good reason, yet the accuracy of hind-sight and our attraction to certainty often creates too much of an emphasis on lagging, already occurred measurements compared to leading metrics. So we get fancy graphs of project spend and defect rates, but no better insights into what we should be doing differently in order to meet our goal.

In this presentation I will review many common project metrics and explain why they are largely misguided and counter productive. An alternative set of "Design Factory" metrics will be presented that are "simple and relevant to the true project goal", these metrics leverage the Hawthorne effect and focus on leading metrics to support smarter decision making.
 

Registration Link

I have just started my second season of mentoring for our local PMI chapter. This week’s launch workshop was facilitated by Right Management and they introduced a great model for building (and rebuilding) Trust and Respect that I would like to share. It was used to help explain how to build trust and respect with those we are mentoring, but it is a useful model that has much wider applications.

Establishing trust and respect can build tremendous support for goals, and likewise losing trust and respect puts us back at the beginning in a relationship or even further behind and the process has to start again. I am sure we have all experienced it, I know I have. Trust is a slow process to build and can be quickly eroded by a single bad deed or poor choice, as shown in the graph below.


 

While this is common sense stuff, what I liked about the workshop is the Howard Jackson Model for systematically building trust and respect. It is a repeatable series of steps that build on from each other in sequence to establish better collaboration.
 

 
In this model we start at the bottom of the pyramid with Straight Talk, and move through the steps of Listening for Understanding, Making Commitments, being Reliable, creating Trust, and then finally earning Respect.

Straight Talk  - Open and direct communication is the first building block for trust and respect.

Listening for Understanding – Focus your attention on understanding the meaning behind what people are saying. There is a big difference between waiting for your turn to speak and really listening. Hear, Understand, Interpret, and then Respond.

Making Commitments – Be clear about what you will do. Agree on the What, By When, By Whom, and How steps. Communicate your intentions and stick to them.


Reliability – Do what you say you will do without fail. If circumstances have changed and it no longer makes sense to do what you said you would do, communicate back and explain why, and discuss and agree on the new steps.  Follow through over-and-over, be reliable, unfailing, dependable.


Trust – Trust results from the firm belief that another person can be relied upon. Trust is the result of straight talk, making sure you understand and are understood, and keeping confidences as well as commitments.


Respect – Although there are many levels of respect, the respect that follows trust leads to deep esteem for another person. We value their thoughts and input, and we know we can count on them because they have proven themselves out to us.

Why so much focus on soft skills for an Agile PM Blog?
When I started this blog in 2006 I wanted to explain the new techniques used on agile projects in an easy to understand format, with real life examples. Now I find myself writing more on soft skills than agile techniques.

This is because people are the engine that drives a high performance project. Without a good team that embodies trust and respect, the best process and tools in the world will not help you. I am as geeky about process as the next agilist, I love experimenting with Kanban and Lean and know that they offer better ways of executing projects. However, bigger improvements can be had from the people side of things.

Another passion of mine is mountain biking. I lust after lightweight exotic bikes like the Super Fly 100 and S-Works Epic, imagining how much faster I could go, the hills I could finally climb. I am sure they would help, but the advantages are small, a good rider will dwarf the performance gains of the machinery and it comes down to the person powering the bike not the bike its self. It is like this with people and process too. Yes we can tweak and improve the process and I encourage you to, but the biggest gains come from within the team. From trust and respect comes great commitment and creativity which cannot be made up for with tools and processes. We undoubtedly need a combination of soft skills, tools, and process, but when considering where to focus effort I believe the biggest payback is on the people side.

"From trust and respect comes great commitment and creativity which cannot be made up for with tools and processes."

As we start 2010, the second decade of the 21st century, project managers really should be embracing 21st century technologies and approaches. While developers and other project members have been benefiting from improved communication and collaboration via new technology in the last 10 years, project managers have been slower to adopt them.

The plus side of being a late adopter is that most of the kinks get ironed out before you experience them and all the features you may need have probably already been developed. So, time to get with it. Perhaps it can be a New Year’s resolution to at least examine these tools and approaches if you are not already using them on your projects.

The World Has Changed – Why Haven’t Your PM Tools and Approaches?
In the last 10 years many changes have occurred in the world of managing IT projects, yet we still see the same tools and approaches being employed. Is this because they are classic and timeless? Are the traditional PM approaches so successful that they do not need to be dragged here and there following trends and immature technology fads? No, I fear it is more that people are creatures of habit, and the usually more mature project management community, are worse than most at evaluating and adopting new approaches.

Also, project management is a largely individual activity, teams of developers and business analysts are far more common than teams of project managers, so peer-to-peer learning and tool support is almost nonexistent for project managers. Plus, project management can often be a reputation based market and to some people fumbling around as a beginner in a new approach is very uncomfortable to them. Well it is time to get over it, this is how we learn anything, and if you are concerned about looking foolish, just imagine how foolish you will look when everyone else has moved with recent trends and you are in the last stand of dinosaurs.

My last post was on modifying Parking Lot Diagrams to use the area of boxes to show the relative effort of differing parts of the system. The idea was that while traditional Parking Lot diagrams are a great way of summarizing progress at a project level, the customary approach of giving all the feature groups the same size box may lead people to believe these chunks of functionality are of equivalent size or complexity.

In the boxes below, the number in brackets describes the feature count, but this requires people to read the numbers and then consider the relative sizes. My goal was to create a new graphical summary that depicts the relative sizes via box area to make the summaries easier to understand.

So a standard Parking Lot diagram like this...

becomes a scaled Parking Lot diagram like this...

In the second example we can quickly see the relative estimated sizes of the areas of work, with for example, “Enter Order Details” being three times the size (in area) of “Create New Order”. In this example to keep things simple, I am using feature count (15 vs 5) to depict effort and area. Most projects will use development effort in points or person days as the scaling factor.

Anyway, I have been using these scaled Parking Lot diagrams on my projects for a while, created quite laboriously in Excel and PowerPoint, and I was hoping that someone with better skills than I have could help me streamline the process. Well, in typical fashion, soon after posting I learned that:

A)    I may be asking the wrong question
B)    My invented solution has already been done before and far more elegantly
C)    It has been done on the Simpsons

Oh, the joy of the internet! Actually this is of course a great thing and now I can progress from a much firmer foundation, and far quicker than my slow evolution was taking me...

Parking Lot diagrams are a great way of summarizing an entire project’s progress and status onto a single page. They illustrate work done, work in progress, work planned and identify what is behind schedule.
 
In this example we can see that “Stock Search” in red, is behind, it was due to finish in November. “Create New Order” shown in green is complete, the boxes in yellow are ‘in progress’ and those in white have not been started yet. I have posted previously about their use and examples of how to produce them.

However, they miss an important element, the relative sizes (usually in terms of effort, but could be cost or risk) of the functional areas. So, in the example above, the fact that “Enter Order Details” might be 3 times the development effort of “Create New Order” is likely lost on the stakeholders reviewing the chart. Sure they can look at the number of features 15 vs 5 and likely surmise “Enter Order Details” is more work, but upon first impression, this is not immediately apparent.

So, bring on Scaled Progress charts, the box size represents estimated development effort. I have been using these with my current Steering Committee for a while. I meet some of these people infrequently and these charts provide a nice reminder of the overall project scope and where the project progress right now.

Solving problems with innovative solutions is fun, exciting and rewarding. Yet, being told what to do is generally boring and not very motivating, but why is this? Why exactly do some ways of working seem enjoyable and satisfying while others the total opposite? Well, the explanation involves chemistry and electricity.

I had coffee today with Dr Michael Aucoin, author of Right Brain Project Management, that I have discussed previously. He has been in Banff working on his new book and we chatted about empowered teams and productivity.

He explained that simply presenting work as questions rather than statements can engage mental models that make work more engaging, rewarding and in turn productive. More and more research on the brain is showing that we are hard-wired to reward ourselves for solving problems. Thinking about this, it makes sense, evolution rewards problem solvers and so an appropriate response is to make it feel good so that we continue doing it.

When we solve a problem and get that “ah-ha” moment, pleasure circuits in the brain light-up and endorphins are released that give us the buzz of solving the problem.  We also generate ownership for the solution and motivation to make it work, even if we encounter obstacles during the implementation. Contrast this level of enthusiasm with the prospect of having to do mandatory administration tasks or form filling. It is no surprise people enjoy working on empowered teams more than being directed exactly what to do, and some teams are orders of magnitude more productive than others.

So, as a project manager looking to increase productivity and motivation, is it simply a case of posing all work as questions and problems to be solved?  Obviously not, asking “Can anyone get our time recording entered?”, “Or, how can we write up these meeting minutes?” is likely to elicit the deserved response of “Yes, you need to stop wasting our time with dumb questions and do it!”

However, most projects could greatly benefit from engaging people’s problem solving skills and the motivation from solution-finding. Rather than over analyse difficult problems and prematurely decompose complexity into simple tasks, instead invite the team to find solutions. Make use of people’s problem solving skills and increased motivation it brings to create a more rewarding environment.

Is this manipulation, a mind trick to get people to work harder? I don’t  think so, instead a more insightful and respectful way of engaging a team. After all “We manage property and lead people. If we try to manage people they will feel like property”. Research on the brain is helping us understand what we instinctively feel. I am looking forward to Mike’s next book and learning more about working smarter.

What characteristics do you look for when hiring for an agile team? Our next Calgary APLN meeting is a panel discussion on the topic and looks set be a great one.

 

Some broad characteristics identified in the planning emails for the panel include:

Characteristics of a high performing team:

• Collaborative / effective communicator
• Willing to cross boundaries
• Work side by side / discuss work out problems real time
• A lot of face to face communication required
• Humility - accept feedback
• Able to compromise / support team decisions
• Able to reflect back on events and provide insights (critical for retrospectives)
• Always looking to improve
• Think about things rather than blinding moving forward…..
• Pragmatic - Knows what “just” enough is, Do what it takes
• Adaptive / Flexible - Change direction as required
• Takes initiative / self motivated
• Willing to try new things (may be evident by a desire for continuous learning)
• Can figure out the most important thing to do next. Doesn’t need to be told what to do.
• Risk tolerant – able to make a decision and act based on the information known
• Able to work in fast pace / intense
• Willing to work in a team room – little privacy, very noisy, no prestige
• Can challenge ideas in a respectful manner
• Work incrementally - Willing to revisit work
• Accepting that the big picture will evolve over time

Detecting these characteristics:

• Behavioural descriptive questions – tell me a time when….give me an example of….
• Interests / desires may be evidence of the characteristics
• Informal references from prior projects / peers etc.
• Auditions – pairing on an activity
• Trial periods

The panel members have also identified a set of technical requirements based on the various roles (developer, test, architect, etc), but I am most excited about who we have on our panel...

Zombies and Project Managers; to many people the images are synonymous, fools blindly shuffling from one goal to the next. Not too smart, but a major annoyance if you are trying to get somewhere, or get something done.

Yet, as a project manager I have a weakness for zombie films, they appeal to my inner urge to cut down those who impede progress or just don’t get it. I know you can not really do that, and these feelings are more likely a reflection on my inability to communicate effectively, but none the less, a socially acceptable demographic for outpourings of frustration seems to have wide appeal, and box office success.

So, other than some people thinking project managers are lumbering dullards, and this one occasionally thinking of chainsaws, what does the film Zombieland and project management have in common?

• The Insecurity Complex
• The Goal Obsession

In the film comedy Zombieland two mismatched characters team up to survive zombie attacks, find love and pursue a goal. Our hero is Columbus, a socially awkward young man who’s obsessions and aversions in normal life had made him a lonely misfit, now keep him alive in a time when most people have succumbed to zombies. His partner is Tallahassee a hard hitting, shoot first ask questions later, type guy who is driven by an overwhelming desire to find the world’s remaining supply of “Twinkie” cakes.

The Insecurity Complex

An Insecurity Complex is a common feeling for new project managers. Linda Hill describes it well in her book “On Becoming a Manager”. She explains how people who did well in technical and sales roles often struggle and experience “Self-Doubt” when first in a management position.

What do Scrum and Bikram Yoga have in common? They both cater for the attention economy. Humans derive a lot of their sense of security and confidence, what psychologist Albert Bandura calls “self-efficacy,” from predictable routines. Without these predictable routines we can feel uncomfortable and uncertain.

 

I was talking to a colleague, Mike McCullough, last week who was creating agile training materials and quick-start templates to help organizations adopt agile. I was teasing him on the irony of creating prescriptive templates to guide people through an adaptive process that should probably be tailored for each project. He agreed, but pointed out that definitive models (even if not optimal) are much easier to sell than open-end frameworks requiring adjustment and set-up.

 

This is true, known entities create buying confidence. Comforted by the certainty (or less uncertainty) of a well defined approach our mental search for predictability is satisfied. Plus, really, which is easier to explain and sell to sponsors:

1. We are adopting Scrum, it has two-week iterations, a Product Owner role, and work prioritized in a Product Backlog.
2. We will select a hybrid of agile and traditional approaches, based on project and organizational characteristics, and selectively add and subtract approaches based on stakeholder feedback and project performance.

 

Even if option 2 is better, it sounds so fuzzy and nebulous that frankly as a sponsor, I am not sure what I am buying into.

 

Scrum

At the heart of Scrum is a simple process, obviously a great deal of skill is required to make it successful in challenging environments, but the underlying model is simple and this is a great strength. Scrum is the fastest growing and most widely used agile method, due to this simplicity. It can be quickly described, the rules are clearly defined, and there is a certainty to the process guidelines that (regardless of whether they always really apply) satisfy our urge for completeness and certainty.

• There are clearly defined activities (Release Planning Meeting, Sprint Planning Meeting, Daily Scrum, Sprint Review)
• Sprints are fixed time periods, traditionally 30 days, but now many teams use 2 weeks
• Only Certified Scrum Trainers can deliver Certified Scrum Master training courses

Bikram Yoga

Bikram Yoga is a form of hot-yoga developed by Bikram Choudhury. It caused some controversy when the 26 postures were pursued under copyright and wide-scale franchising occurred. The whole commercialization of yoga for personal profit seemed, well, un-yoga -ish and spawned the “Yoga, Inc” documentary and terms like “McYoga “.  Regardless of the controversy, it has been amazingly successful. With over 600 studios worldwide, it is the fastest growing form of yoga.

• All classes perform the same 26 Postures
• Classes are always 90 minutes in length and conducted at 104F
• Only certified Bikram instructors can run Bikram hot yoga classes

The Attention Economy...

I attended the Agile Business Conference in London this week and presented on Tracking Project Performance. I missed this conference last year and so it was especially good to catch up with people again and hear what they have been doing. Also, after working in London for six years, but then living in Canada for the last nine years, it is always interesting to see how things have changed since my last visit. This year it was video screens replacing all the paper billboards going up and down the escalators on the Underground that caught my eye.

 

The conference was very good, and had the general theme of “Agile Grown Up”, focussing on the organizational impacts of using agile. This may not have been as much interest to technical people, but was right up my street. On Tuesday there was a great session about agile at Nokia where 1800 software developers are using agile to develop the Symbian mobile phone platform. They are using a version of Dean Leffingwell’s “Agile Train” approach for scaling agile to such a large team and most agile practices, but not pair-programming or emerging architecture. However, the main emphasis was beyond the technical process scaling and more on the ongoing coaching, mentoring and training that is required for such a large undertaking. In a discussion with the presenter Simon Buck after the talk I learned that they aim for one full time coach/trainer for each set of 5 Scrum Teams (each about 7 people). Quite the undertaking.

For the attendees of my recent Las Vegas course, below is a link to the PMBOK v4 to Agile mappings we discussed. My previous course material mappings were based on PMBOK v3, and before that the 2000 edition, which are out of date now.

 

Quite a lot changed from the PMBOK v3 to v4; all the processes were renamed into the new verb-noun format. Six of the old processes were merged into four new ones, two processes were deleted, and two new ones added. So it seemed like time to redo the mappings and post them online this time.

 

Cautions

Process guidelines and templates are not an acceptable replacement for common sense, thought, dialog, or collaboration. A fool with a tool is still a fool, but can be especially dangerous since they give the impression that they have a potential solution to tricky problems. Beware of simply following any project guidelines that seem counter to your objectives.

 

So, why would you want to be mapping the PMBOK v4 to Agile techniques anyway?...

The Calgary Agile Project Leadership Network (Calgary APLN) 2009/2010 season kicks off this week with a social at the Barley Mill in Eau Claire, Thursday Oct 1, 4:30 – 6:30pm.

“To help build a vibrant Agile community in Calgary, we would like to invite you to a networking event. Come out and meet other Agile Leaders within Calgary, swap stories and share some laughs. Agile Recruiting has graciously sponsored the event by providing appetizers. Cash bar will be available.”

This is a chance to meet and chat to other people in the agile project leadership community in Calgary. We have a limited capacity so register to reserve a place. I hope to see you there.

Passion is infectious; we are drawn to people who are passionate about topics and goals. We share their excitement and feel the rush, it is authentic and attractive. You cannot really fake passion, it is the raw unfiltered outflow that makes it recognizable as genuine.

I have been entertained by friends who are passionate about chess, dance and bird watching even though I have little interest in these topics. Yet when brought alive by genuine enthusiasm it is interesting. I have been talked into crazy adventures by people buzzing with excitement. I have invested in companies, enthralled by the passion for a vision described by their founders. I am not alone, it is a fundamental human urge.

Passion for a cause is powerful and while we cannot manufacture it, we can learn to channel our own genuine passion to help on projects. By opening up on what you are passionate about we can bring enthusiasm into any endeavor. Yet, we should be aware that passion is independent from talent.

Talent, the measure of proficiency, often accompanies experts who love their craft. They are focused, passionate and accomplished at their art; think of the great musicians and painters, they have passion and talent.

I have a passion, but not much of a talent for mountain biking, this is not the best combination. I love to ride, but crash more than most and as I’m getting older take longer to heal than before. I need to develop my biking skills, yet while still keen and willing to get out I have plenty of opportunities to learn and improve (or get into more trouble.)

The good news in the work environment is that a little passion about a cause goes a long way. The idea of leaders having to be charismatic rock-stars to get people to follow them is a myth. Research by Jim Collins in “Good to Great” proved this repeatedly; the Level 5 Leaders, of the “Great” companies were more often described as “quiet” and “considered” than “flamboyant” or “outspoken”. There just needs to be the occasional sparks of unprocessed joy for a goal to keep people engaged and looking for that next glimpse of passion.

On Tuesday I was in Chicago for the PMI Agile Community of Practice launch event. It was hosted by Thoughtworks and kicked off by Martin Fowler and Jim Highsmith. Jesse Fewell and I introduced the community and outlined the goals.

With getting on for half a million PMI members worldwide, many in the knowledge-worker domain, agile methods have a lot to offer this already huge community. It is set to get larger too, PMI member growth progresses at about 20% per year, and PMI research indicates there are up to 20 million people engaged in knowledge-worker projects worldwide.

The spread of agile ideas to the PMI is inevitable and already happening on many fronts. I was concerned that it would be adopted incorrectly, fail and then be dismissed. This is still a risk, but with the launch event at Agile 2009 and an open invitation to Agile Alliance members to get involved and drive the initiative, the hope is that the initiative will succeed.

For an event that proposed bringing agile and PMI groups together, there was surprisingly little conflict or debate. But, then I suppose those people opposed self-selected and chose not to attend. Besides, few people subscribe to a purely agile or purely traditional approach to all projects anyway. We have to be pragmatic and chose our approach based on project and organizational circumstances.

The “PMI-Agile Community of Practice” is a free to join group aimed at “Equipping PMI members with Agile knowledge and skills".  For more details see the community wiki.

OK, I'm back and I really need to post here more often. Summers in Canada are so short that I try to pack a year’s worth of adventures into 3-4 short months. We (hopefully) still have plenty of summer left, but I intend to post more frequently as there is lots going on in the agile project management space too.

In a couple of weeks we have the Agile Conference in Chicago and I’m looking forward to the PMI-Agile Community Launch. (See this week’s GanttHead article). In September I’ll be teaching my 2 day class in Las Vegas (Sep. 14-15). In October I’ll be presenting at the Agile Business Conference in London (Oct 11- 15). Then training again in November in Savannah (Nov 7-11) and San Diego (Dec 12-16).

 

This summer’s silly idea was to try competitive mountain biking. A sport in which I quickly progressed beyond my ability and paid the penalty with crashes and injuries. So for now, I’m keeping the extreme to the projects and would like to thank Kelly Waters for pointing out that my site needed some long over due maintenance (one link was now an “off-topic” site.) Kelly runs the great site www.allaboutagile.com check it out if it is not on your regular list of sites.