PMI-ACP and My New Book “Beyond Agile: Achieving Success with Situational Knowledge and Skills”

10 YearsIt has been 10 years since the PMI-ACP exam was created, and I published my PMI-ACP Exam Prep book. I recall the Steering Committee meetings where we discussed what we believed was necessary for agile practitioners and team leaders to have experience in and an understanding of.

Since then, the exam has been updated a couple of times based on Role Delineation Studies (RDS) and Job Task Analysis (JTA), which is how PMI surveys practitioners and asks what techniques are commonly used. However, the core content has mainly endured unchanged, which is testimony to its usefulness.

CommitteeI remember discussing the scope and goals for the credential among the committee that comprised: Alistair Cockburn, Mike Cottmeyer, Jim Cundiff, Jesse Fewell, Mike Griffiths, Ahmed Sidkey, Michele Sliger, Dennis Stevens and PMI researchers.

In addition to an agnostic understanding of Lean, Kanban, Scrum and other agile approaches, we also agreed people should know about the basics of servant leadership, conflict management, team decision making, and coaching. So our scope included more than just Lean and agile; it had a little leadership and emotional intelligence.

Agile and Leadership 1

At the time, someone suggested a three-tier credential consisting of something like Agile Basics, Agile Journeyman (journeyperson), Agile Consultant that mirrored Shu-Ha-Ri. PMI leadership rightly reined this in, explaining it was a good idea, but how about we just focus on getting the basic level credential created for now.

PMI was correct to focus on the universal fundamentals. As we get into more advanced topics, there is no single correct answer. So, topics like agile scaling frameworks, strategies for motivating teams, the pros and cons of different leadership approaches that get deeper into agile, leadership and emotional intelligence were never tackled but are topics that my blog readers know I care deeply about.

Agile and Leadership 2
My new Beyond Agile book is my exploration of these topics (plus others.) I dig deeper into unlocking the power of individuals and teams. How can we encourage better engagement, focus on the project goals, and ditch non-value-add mindsets and processes? These are based on my experiences and research.

You likely won’t agree with everything I suggest, and that’s fine; not everything will work for your situation. However, I am confident you will find many valuable concepts and connections between ideas you thought about separately before.

As the book title suggests, it goes beyond agile. Sometimes the best way to tackle a problem might be with a plan-driven approach. Agile Myopia is the mistaken belief that every project situation has an agile solution.

Agile Leadership and Plan Driven

I am more of a pragmatist. Sometimes, the best way to assess and analyze risk is with the risk management process from plan-driven project management approaches. We may then choose to implement the risk responses in an iterative, incremental way via our backlog and spikes, but that again is being pragmatic.

My previous post mentioned a disconnect between teams being agile and the highest-performance teams I was able to work with. These high-performing teams hardly discussed agile concepts or paid much attention to the agile ceremonies, although they lived the mindset emphatically. Often what set them apart was the deep industry experience and knowledge they had gained, making them trusted partners within the business groups they served.


Beyond Agile Model
I set out to define what sets high-performing teams apart and outline the steps to replicating them. There may be no formula but I did uncover a set of knowledge, skills and thinking tools people can use to chart their own course. It represents the What’s Next beyond the ideas in my PMI-ACP books and provides a broader landscape to explore. I hope you enjoy it.

Beyond Agile Book Image


Unlikely Origins

Agile ExceptionForbes ran a nice article a couple of weeks ago on how agile is the next big thing for management, but its unlikely origin in the software industry may hamper its adoption. The article provided some nice analogies:

1)    When the British government, in 1714, offered a prize for determining longitude at sea, of £20,000 (£3M in today’s money), a Yorkshire carpenter called John Harrison eventually solved it, but the scientific community refused to believe that a carpenter could have solved the problem that had thwarted the best scientific minds. In 1773, when John was 80 years old, he received an award of £8,750 but not the actual prize. A Yorkshire carpenter was the wrong person to have solved the problem.

2)    In 1865, Gregor Mendel, an unknown professor created a theory about gene inheritance after studying pea plants. It answered inheritance issues that had stumped the finest scientific minds. The paper was ignored by the scientific community for the next 35 years until people eventually realized that Mendel had indeed come up with the solution. His theory later became known as Mendel’s Laws of Inheritance. His work had been ignored; a researcher on peas was the wrong person to have created the theory.

3)    In 1981, Barry Marshall, a pathologist in Perth, Australia, came up with a bizarre new theory that ulcers were caused by spiral bacteria. No one believed him so in 1984 he drank a batch of spiral bacteria and sure enough developed ulcers. Eventually in 2005 he received a Nobel prize for medicine for his work, but it took that long to be accepted. An unknown pathologist from Perth was the wrong person to have made the discovery.

So then we come to agile; for decades management had struggled to balance execution with innovation. How do we simultaneously get work done yet still drive improvements without one factor stifling the other? Now we know agile methods do a great job of balancing delivery with improvement.

Agile methods also provide a framework for sense-making and managing ambiguity when there are significant gaps in our understanding of requirements, approach, or technology. These uncertainties have a habit of stalling plan-driven approaches that struggle to reach escape velocity from the process of gathering requirements and planning. Agile methods instead choose to build what we know, evaluate, gain consensus on where to go next and iterate to a final solution.

The credibility problem we have is that software people, those weird IT geeks with poor communication skills are the wrong people to have proceduralized a complex communication and collaboration process. It should have been some management professors at the Harvard Business Review or Sloan School of Management at MIT. How can that IT crowd, who some believe have trouble making eye contact and describing an issue without resorting to techy speak, have figured out a way to collaborate and communicate on unique problems with unprecedented solutions?

Continue reading "Unlikely Origins" »


Wednesday’s ALN Talk – Training in Teamwork

ALN_LogoOn Wednesday March 26 the Calgary Agile Leadership Network (CALN) is very pleased to welcome Steve Adolph from Rally Software.

Steve’s talk is related to his PhD thesis and focused on why smart hardworking people often fail to deliver on their commitments? He asks if there is something missing from our Agile training programs? Also, is something missing from our Agile practices? Steve will explain how part of the answer to these questions comes from the theory developed during his research and a course of action is offered for improving agile teams.

This promises to be a fun filled talk with tales from the airline industry and practical advice on why we need training on how to work together. Registration is free, please join is if you can, click here to reserve your place.


Agile Interruptions

By Mike Griffiths

Agile Communications“My team has stopped talking to me, and I like it!” This may sound like heresy since agile teams are centered on face-to-face conversation, but as with most sound-bites it is missing context and clarification. A more accurate description would be: “We are replacing some face-to-face conversations with other communication channels and this practice seems to improve flow.”

Like all good stories I have started in the middle, let’s back up and examine the full picture. “Flow” is the quiet and highly productive state of work when you are really “in the zone” and making real progress on a topic.

In the book “Flow: The Psychology of Optimal Experience” Mihaly Csikszentmihalyi explains what makes an experience genuinely satisfying and how people typically experience deep enjoyment, creativity, and a total involvement in their work when in this state of flow.  We experience flow when work is challenging enough to provide a reward of problem solving yet not too crazy difficult that it is frustrating. So, not too easy, and not too hard, but a perfect “Goldilocks” rating of “Just-Right.”


Task Difficulty

Shimon Edelman, a cognitive expert and professor of psychology at Cornell University, offers some insight in his book “The Happiness of Pursuit: What Neuroscience Can Teach Us About the Good Life.” He explains it this way: “Flow is the enjoyment derived from being engaged in an activity that is challenging, but not frustratingly so. Evolutionarily, we are selected for being good at certain kinds of things. You’re not challenged if you’re not tested, we get rewarded incredibly with this feeling of well-being and excitement.”

Enjoyment and Productivity are self-reinforcing factors that give rise to high performance.

Work Productivity and Enjoyment

The befits of flow on productivity are so significant Tom DeMarco and Anthony Lister in their book “Peopleware” recommend designating two hours a day as “Quiet time” with no meetings or interruptions. Programmers need sufficient quiet time to get into this productive mode, and as Alistair Cockburn observes, it takes only a minute or two of other conversation to disturb it.

This is the flow / communication paradox, on the one hand we want to get to a state of flow, on the other we want a collocated team environment with lots of high bandwidth, face-to-face communications to get questions answered quickly. There have been a few suggestions strike to balance . In the “XP Applied: Playing to Win” book Ken Auer suggest the “Caves and Common” idea. Caves are quiet rooms to work in, Common is the common work area where we learn via osmotic communication and get our questions answered quickly. People can go an work in the quiet “caves” when they need to focus and return to the common area to share and learn when they are done that high concentration task.

Why my team has stopped talking to me, is because they now use instant messaging. So instead of them coming over and asking a question mid way through my angry birds, status report, instead I get a little pop-up at the bottom right hand side of my monitor for me to reply to. The key difference is that this is not so interrupting as having someone physically come over. I can continue with my chain of thought, reach a convenient checkpoint and then type a reply.

Working this way flow seems to be less interrupted, it is no longer a cold reset of re-establishing where I was in my work and getting back into the groove, the interruption was less obtrusive and flow returns quicker. Perhaps because we decide the exact moment when to reply, allowing us to reach a better checkpoint/return point.

When team members who sit 6 feet away started sending me messages rather than talking to me I dismissed it as the poor communication skills of today’s younger workers, the product of text messaging generation, and generally a cop-out of having a meaningful conversation.

Now I realize that many quick questions are not worth the flow interruption penalty of a full face-to-face conversation. So items do however, if we think there is a problem, or need for a direction change then a full stop and discussion is exactly what is required, but for perhaps 5 times as many questions an electronic ping gets the answer without the interruption of flow.

I am not disputing the advantages of face-to-face communications, we will always benefit from the emotion and body language we lose electronically. However, given the value of flow and being in that productive zone, if we can keep that speed going for longer with less disruptive questioning, perhaps the overall business value delivered can go up with fewer face-to-face interruptions?

Likely this is very environment dependant, some projects will be constrained by their rate of learning and more face-to-face communications would help. However other projects, or perhaps the same project at a later phase, could be constrained by productive flow and better served by less intrusive Q&A. Balancing flow and feedback will always be dynamic.

What do you think, does technology help us here in balancing flow with being informed? How are you managing these competing demands? I would love to hear alternative solutions to this widespread issue.

(Note: This article first appeared on Gantthead.com here)


Using ANT to Measure Project Success

Agile successWhat is project success? Is it just on time, on budget, with required functionality, and to a high quality standard? Or is there more, some missing X factor, a good after-taste, or resonance that we just know is great?

I did some training for a client recently who is interested in measuring project success. The traditional constraint measures of on budget, on schedule, happy stakeholders were not cutting it for him. They were missing this unknown element he was really more keen to measure. We talked about other measures of success including how people feel about the project and the act of leaving a valuable legacy.

There are plenty of examples of projects that might be judged failures by the constraint measures of on budget, on schedule, etc, but successes in terms of how people felt about them and the act of leaving a legacy. They include the Apollo 13 mission, the Titanic Movie, Shackleton and the Endurance, and the Iridium Satellite Network. I wrote about how these “failed” by constraint measures were successes by other measures in a post a couple of years ago.

This still was not satisfactory and these measures were often only apparent long after the project was done. They were too late and retroactive, my client wanted something he could use right now to get a better handle on projects. It turns out what he was looking for might be better explained by Actor Networks with Convergent and Divergent behaviour, (but I did not know that then, so back to the story.)

Bothered by not fully answering his question, I attended the Agile on The Beach conference in Cornwall, UK. I flew into London, where I worked in the 1990’s at Canary Wharf and saw the Millennium Dome being built. Seen in films such as James Bond: The World is Not Enough, the Millennium Dome project that, while on schedule, has been widely labeled as a failure. The white elephant that hardly anyone wanted, and struggled to attract or please visitors. I was even a little surprised to see it was still there, since I knew it had been left empty for a while, used as a temporary homeless shelter, and other things.
 
Dome 1

Continue reading "Using ANT to Measure Project Success" »


Agile Outside of Software

Different Agile Agile adoption outside of software is nothing new--it dates back very close to the origin of today’s agile methods, predating the term “agile”. However, what is new and noteworthy is the rate and scale of non-software agile adoption being witnessed today. Now--as more companies than ever are exposed to agile methods in their IT practices--these methods are being employed beyond the regular IT domain.

The key to understanding the applicability of agile outside of IT is the concept of the “knowledge worker”. Knowledge workers are people with subject matter expertise who communicate this knowledge and take part in analysis and/or development. This not only covers the IT industry, but also engineers, teachers, scientists, lawyers, doctors and many others employed today. In fact, knowledge workers have become the largest segment of the North American workforce; the so-called Third Wave of human socio-economic development after the Agricultural Age (land based) and the Industrial Age (factory based). In the Knowledge Age, value is based upon the ownership of knowledge and the ability to use that knowledge to create or improve goods and services.

Knowledge worker theory and agile theory are a little like twins separated at birth, growing up independently. As the agile community was determining the best way for software teams to collaborate, knowledge worker researchers were establishing ideas like Human Interaction Management--which asserts there are five principles characterizing effective knowledge work:

  • Build effective teams
  • Communicate in a structured way
  • Create, share and maintain knowledge
  • Align your time with strategic goals
  • Negotiate next steps as you work

If you think this list sounds a lot like how we manage our daily stand-ups, prioritize the backlog and work in iterations, then it you are not alone. The two camps are very similar, and the ways to effectively collaborate when manipulating bits and not atoms (information not materials) are now widely taught. However, not all our guidebooks or practices embrace the subtleties of knowledge worker environments and many Industrial Worker relics remain. In the industrial age, after product design was complete, work was relatively predictable with only breakdowns, human error and raw material defects to content with. Change rates were relatively low and uncertainty can be largely planned out of a process through a management focus on process. In the knowledge worker environment, high value often comes from combining information from new or unlikely sources. Levels of uncertainty in job execution can be high, and management focuses on people rather than process.

This “Uncertainty and Management Focus” spectrum is shown below:

Continue reading "Agile Outside of Software" »


PMI Agile Cert to be called “Agile Certified Practitioner”

Agile Certified Practitioner 0 It turns out the original suggestion of “Agile Project Practitioner” (PMI-APP) was too close to “App.” as in an Application or phone app to easily trademark (in this case service mark). So the name will now be “Agile Certified Practitioner” ACP as in Fred Blogs, PMP, ACP.

The timeline for people wanting to apply will be:
•    May 23rd    - Launch of application to Public
•    Mid July    - Pilot Participants can schedule exams at Prometric test centres
•    September 15    - Pilot Program Testing begins
•    November 30    - Pilot Program Testing Concludes
•    January 1    - First set of individuals that passed the exam are notified.

I am getting lots of questions about the content of the exam, so I thought I would present a couple of ways of interpreting it. In my last post on this subject I showed the box model for reconciling the Domains with the Knowledge & Skills (KS), and Tools & Techniques (TT).

Agile Certified Practitioner 6

Here is a version with the KS and TT’s listed:


Agile Certified Practitioner 1
 
(click on any of the images above or on the continuation page to see a bigger version)

Continue reading "PMI Agile Cert to be called “Agile Certified Practitioner”" »


Agile as a Solution for "Miscalibration Errors"

Error Malcolm Gladwell (author of Blink and Tipping Point) was in town a couple of weeks ago and I enjoyed a great presentation he gave on what happens when we think we have complete information on a subject.

The Problem
Gladwell asserts that the global economic crisis was largely caused by “Miscalibration Errors”. These are errors made by leaders who become over confident due to reliance on information. Those in charge of the major banks were smart, professional, and respected people at the top of their game; who, as it turns out, are prime candidates from miscalibration errors.

People who are incompetent make frequent, largely unimportant errors, and that is understandable. They are largely unimportant errors because people who are incompetent rarely get into positions of power. Yet those who are highly competent are susceptible to rare, but hugely significant errors. 

Think of the global economic crisis where bank CEOs were seemingly in denial of the impending collapse of the sub-prime mortgage market. (I don’t mean close to the end when they were secretly betting against the market while still recommending products to their clients, but earlier on when they were happy to bet their own firms on “AAA” rated derivatives that they knew were really just a collection of highly suspect subprime mortgages.)

Anyway, this phenomenon of educated, well informed leaders making rare, but catastrophic errors is not new and unlikely to go away soon, it seems to be a baked-in human flaw. When presented with increasing levels of information our perception of judgement accuracy increases when in reality their judgement may be very suspect. Let’s look at some examples:

Continue reading "Agile as a Solution for "Miscalibration Errors"" »


Training in New Orleans - Updated: Now Full

New Orleans 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!


Agile Mythbusters

Agile Myths 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.


Functional Teams

Functional Team 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...

Continue reading "Functional Teams" »


Customer Engagement

Bored Customers 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.

Continue reading "Customer Engagement" »


Agile Star Quiz

Agile Graphs
 
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

Continue reading "Agile Star Quiz" »


Agile Project Wins PMI Award

PMI Award 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.

Continue reading "Agile Project Wins PMI Award" »


Aligning PMOs using Game Theory

PMO Pos PMO Neg 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:

Continue reading "Aligning PMOs using Game Theory" »


Ultra Agile

Ultra 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.


Traditional and Agile PM Integration Pains - a Positive Sign?

 Integration 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:

Continue reading "Traditional and Agile PM Integration Pains - a Positive Sign?" »


Agile Communications

Communicating 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.

Continue reading "Agile Communications" »


Agile Preservation or Progression?

Shell 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.

Continue reading "Agile Preservation or Progression?" »


Decisions: Delayed, Dated, or Done?

Decisions Burden 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 …”

PMBOK v5 – Raise a Little Hell

Change Something 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

Continue reading "PMBOK v5 – Raise a Little Hell" »


Empowered Teams Are Dead – Long Live Autonomy, Mastery and Purpose

Demotivated 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

Continue reading "Empowered Teams Are Dead – Long Live Autonomy, Mastery and Purpose" »


High Performance Team

Ips_poster_small 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.

Continue reading "High Performance Team" »


Starting an Agile Project within a Traditional Framework

Starting Agile Project 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.
 
Methodology_scope_fig3
 
 

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.

Start Up Activities
 
 


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.

Agile Early Process
 

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.

2010 Training Courses and Events

Training Course 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!

Are Your Metrics Dumb or Smart?

Agile Estimates 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

Building Trust and Respect

Agile 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.

Trust and Respect Lifecyle
 

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.
 
Respect Pyramid
 
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

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

Listen
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.

Make Commitments
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
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 – 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
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."

Six Project Trends Every PM Should be Aware Of

Future 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.

Continue reading "Six Project Trends Every PM Should be Aware Of" »


Project Progress, Optical Illusions, and the Simpsons

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...
Parking Lot Diagram


becomes a scaled Parking Lot diagram like this...

Parking Lot Diagram Scaled

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...

Continue reading "Project Progress, Optical Illusions, and the Simpsons" »


The Science of Empowerment

Pleasure Response 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.


Hiring for an Agile Team

Agile Team 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...

Continue reading "Hiring for an Agile Team" »


Zombieland Project Management

Zombie 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.

Continue reading "Zombieland Project Management" »


Scrum, Bikram Yoga and The Attention Economy

Yoga

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...

Continue reading "Scrum, Bikram Yoga and The Attention Economy" »


Agile Business Conference 2009

London 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.

Continue reading "Agile Business Conference 2009" »


PMBOK v4 and Agile mappings

PMBOK pdf 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?...

Continue reading "PMBOK v4 and Agile mappings" »


Passion and Talent

Passion 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.


PMI Agile Launch Event

Agile 2009 Chicago 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.


Back Blogging Again

Boomerang 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.


Launch of the PMI Agile Community

Agile 2009 The “PMI Agile Community” will be officially launched at the Agile 2009 Conference in Chicago, August 24. This has been made possible by Jesse Fewell and the strong team of volunteers pushing through the red tape of the PMI and the help from supportive PMI members.

For over eight years now I have been promoting taking agile principles to the PMI. In 2001-2003 my proposals for the PMI Global Congress conference (that were pretty derogatory of command and control approaches) were rejected. It was not until 2004 I smartened up and was successful in getting my paper (Using Agile Alongside the PMBOK) accepted and went to Anaheim to present at the PMI conference.  That was the only agile presentation that year at the conference, but year on year since, there have been more and more agile sessions at the PMI conferences. In 2007 when I met Jesse at the PMI Global Congress in Atlanta (where I presented on Developments in Agile Project Management) there were about 10 other agile related sessions.

This year I had decided to skip the Agile Conference, only because August is prime hiking, biking and climbing season in Canada’s short summer in the mountains. Yet, I cannot miss this launch; it has been so long coming, so I’m flying in for a couple of days for the community kick-off. I am glad to be attending, if only for a short time.

The PMI Agile Community is a grass-roots initiative between a group of Agilists and the Project Management Institute (PMI) to create a new Agile Community of Practice (CoP) within the PMI, with the stated purpose "to equip PMI members with Agile knowledge and skills". To read more about the PMI Agile Community see the Community Wiki

Thanks to the Scrum Alliance for sponsoring our launch event and the Agile Alliance for helping us kick this off at the best event of the year, the Agile Conference . I am looking forward to it.

2004 PMI Paper - Using Agile Alongside the PMBOK

2007 PMI Paper - Developments in Agile Project Management


Agile Project Management Viewed from Behavioral Science

Behavioural Science Background
Earlier this year I attended an interesting talk by Tony Parrottino on Applied Behavior Analysis Science and posted a short write up. Recently I have had a couple of follow-on meetings with Tony and have become fascinated by the science of behaviour. I think it is a powerful, but under utilized resource for project managers, yet I am still trying to reconcile it with some other theories. Fortunately, Tony agreed to help outline some of the key concepts and clear up some issues.

1) Mike: Q: As a project manager I spend lots of time managing budgets and schedules, but in you say that in reality we can only hope to manage behaviour. Can you explain this?

1) Tony: A: Sure. Simply put, the “means” to all business results is “behavior” or what people do. That’s why we hire them – to produce these results. Money (budgets) for example is usually a “measure” of a result (selling value for example) or a behavior (labor cost for example). It’s not a result – we don’t actually make it, unless you’re a Counterfeiter? So if you think about it more precisely you really are “managing behavior” and the budget is really one “measure” of how well you are doing that. The same can be said about “schedules” or time in terms of managing a person’s behavior. If you’re doing that well the measure of “time” or what we call one dimension of productivity in business should improve. This is not a question of semantics either. This is a question about scientific precision and understanding what variables you have control over as a Project Manager – like behavior. Behavior Analysis Science helps managers understand how to “control” performer’s behaviors to positively enhance things like productivity and budgets. 


2) Q: Following an agile methodology approach, our team meets daily to briefly review work and issues. Everyone answers three questions: 1) What have you done since yesterday? What do you plan on working on today? What blockers or impediments do you have to progress? I recall you thought this was a sub-optimal set of questions; can you explain why, and suggest a better set?

2) A: Well Mike I apologize if I said these questions were “sub-optimal” – I didn’t mean to be so critical. This is another great question but requires an extremely lengthily answer to be complete, as it has several elements related to performance. So I will be general and brief in my answer and hope to make just a few points here. My first comment may sound strange but here it goes: “managers” tend to “over-emphasize” “asking questions of their performers” and also focusing on “removing” impediments. At the heart of performance management is the focus on not what people typically have to say, but what we want people to accomplish precisely and what we want people to do precisely. When we start there the data provided gives us objective information about how well any individual or team is performing or progressing. Also, when we focus on what we want and reinforce it we simply get it. If managers are finding they are spending a lot of time managing what they don’t want (like impediments, blockers, etc.) this is a strong sign of managing what we call “a deviation of performance”. This may not be obvious to most but I’m sure that every project manager has experienced a lot of spent time trying to manage what he doesn’t want? Just remember trying to remove what you don’t want will not ensure you will get what you do want! I would suggest if you feel there is value in asking daily questions to start with what precisely you want from your performers (results data preferably) and have clear objective measurable data on that performance. Then, here is one of my favorite questions I like to ask, after reviewing the data for progress; “How did you do that?” In this way you can reinforce the behaviors to accelerate the performance further. This may seem somewhat strange to most managers as most are constantly in problem solving mode and want to “remove” obstacles. If you find yourself doing this often I would recommend a review of your pinpoints and make sure they focus on what you want.

Continue reading "Agile Project Management Viewed from Behavioral Science" »


Assessing Your Emotional Capital

Expectation Heart Dream Trust IQ (Intelligence Quotient) and IQ tests that attempt to measure intelligence are well known. However, IQ is not a good predictor of how successful you will be in life, or how effective and valued you will be at work.

Emotional Intelligence (EI), often measured as an Emotional Intelligence Quotient (EQ), is a different measure that describes the ability to identify, assess, and manage the emotions of one's self, of others, and of groups.

“Research shows convincingly that EQ is more important than IQ in almost every role and many times more important in leadership roles. This finding is accentuated as we move from the control philosophy of the industrial age to an empowering release philosophy of the knowledge worker age.” - Stephen Covey

So since software is a knowledge worker activity, and agile methods promote an empowering release philosophy, for leaders of agile projects EQ is of special importance. How can we measure our EQ? Well Martyn Newman’s Emotional Capital Inventory (ECI) is a great place to start. This online assessment scores participants against the 10 EQ dimensions of:

1. Self-Awareness
2. Self-Confidence
3. Self-Reliance
4. Self-Actualization
5. Assertiveness
6. Relationships Skills
7. Empathy
8. Self-Control
9. Flexibility
10. Optimism

LeadingAnswers.com readers are invited to take the short version of the assessment for free, just follow this link. Free Emotional Capital Inventory Test.

EC

I recently read an early release copy of Martyn Newman’s “Emotional Capitalists: The New Leaders” book and was impressed. Several years ago I finally realized that successful projects are more about people and less about processes and tools. A Computer Science degree and 20 years of technical experience had not equipped me for the role of managing teams. Since then my studies have been focussed on the higher leverage area of people and team dynamics more than project management mechanics. You definitely need the mechanics to run projects, but usually the final outcome comes down to people.

Reuven Bar-On was amongst the pioneers to write about Emotional Intelligence and Daniel Goleman helped bring the subject to the business world with his Emotional Intelligence best seller. I liked these books and agreed with all the points raised, but often finished a book without a clear action plan for what I should start doing differently tomorrow.

What I like best about Emotional Capitalists is the practical nature of the advice given. Not only are the concepts explained clearly with entertaining stories, but each chapter is followed with a one page action plan summary, the advice is very accessible whereas some other books on EQ are more theoretical.

Sample EQ Graph  

Bad News and Good News
The bad news is your IQ peaks in your teens and from there on declines. The good news is that IQ is not a great predictor of happiness or success anyway, EQ is a better predictor of these, and EQ peaks in your late forties and early fifties so we have more time to practice and improve.

(As an aside, I think it is interesting how in our optimism we gravitate towards metrics that suit our circumstances. We are getting older and not any smarter, but hey, that’s OK, here’s a different score that we look better against! Maybe this is being wiser rather than smarter. Since turning forty my chances of running a sub 3hr marathon or sub 36 minute 10K again have approached zero, however I now use Age Weighted Scores and, problem solved, I’m not getting slower (well I am) but I can now compare my times against others my own age and use that as a metric for performance.) 

Anyway, have a look at the assessment, if nothing else it will familiarize you with some aspects of Emotional Intelligence that are critical to being successful today. Thanks again to Martyn Newman for giving a free trial of the tool for readers of this blog. The book covers many great topics that I plan to write on in the future, but for now I will end with some of my favourite quotes:


"You can’t lead a cavalry charge if you think you look funny on a horse" - John Peters

“Before you are a leader, success is all about growing yourself. When you become a leader, success is all about growing others" - Jack Welch

"What lies before us and what lies behind us are small matters compared to what lies within us. And when we bring what is within out into the world, miracles happen" - Henry David Thoreau

"To be independent of public opinion is the first formal condition of achieving anything great" - Friedrich Hegel

“Nothing splendid has ever been achieved except by those who dared believe that something inside them was superior to circumstance” - Bruce Barton

"If leadership is ultimately the art of accomplishing extraordinary things with ordinary people then building emotional capital is how you achieve it" – Martyn Newman


Project Success?

Measuring Success What defines project success? On “time and budget”, or “to specification and quality requirements”, maybe all of these? No, we are missing some less tangible, but critical components; how do people feel about the project once it is done.

On May 12 the PMI-SAC Awards for the best projects and the best project managers will be held in Calgary and Captain James Lovell, Commander of Apollo 13 will be giving the keynote “Apollo 13 – A Successful Failure”. This year I am a judge for the awards ceremony and in reviewing the applicants I have been thinking about what constitutes a successful project which prompted the recollection of some famous projects...

Apollo 13
Let’s consider Apollo 13. The third manned mission by NASA intended to land on the moon that experienced electrical problems 2 days after liftoff. An explosion occurred resulting in the loss of oxygen and power and the "Houston, we've had a problem" quote from Lovell (that is widely misquoted as, "Houston, we have a problem".)

The crew shut down the Command Module and used the Lunar Module as a "lifeboat" during the return trip to earth. Despite great hardship caused by limited electrical power, extreme cold, and a shortage of water, the crew returned safely to Earth and while missing the main moon-based scope, it was a very successful rescue, allowing future missions. “A Successful Failure

Titanic
(The 1997 film not the original ship). This film was six months late, massively over budget and finished with a bloated 194-minute running time. Seemingly not a good performance given the original schedule, budget and scope requirements. Yet the film turned into an enormous critical and commercial success, winning eleven Academy Awards, including Best Picture and became the highest-grossing film of all time.

 

Continue reading "Project Success?" »


Upcoming Events

2009 Calendar After returning from teaching a PMI class in New Orleans, the PMI have added some additional venues for the course later in the year. This is a good sign for agile methods within the PMI community; the course sold out quickly which hopefully indicates that many companies are still able to invest in training.

My 2 day Agile Project Management courses will be offered:

Of course PMI events go on throughout the year (full schedule), but this year I have deliberately kept the summer free from work events to enjoy some outdoor things closer to home. I am currently signed up for the Police Half Marathon, Calgary Marathon, Canmore 24hrs of Adrenaline, The Canadian Death Race, The TransRockies Bike Race, and Half Moon Adventure Race. Time will tell if I survive them all or stub my toe on the first one and miss the rest – hopefully not! I will report any remotely work related news back here.

Other agile events that look interesting this year include:
Atern Road Shows in the UK: London May 14, Bristol June 18, Manchester June 25.
XP 2009 Sardinia, Italy May 25-29
Agile 2009 Conference, Chicago August 24-28
Agile Business Conference, London October 13, 14

So many events, so little time!


Agile in New Orleans

New Orleans Next week I’ll be teaching a two day Agile Project Management course for the PMI in New Orleans. The class sold out quickly; I only teach 3 or 4 times a year for the PMI and I wondered if registration numbers would be down this year. The fact that it filled up so quickly is very positive and perhaps more people are tuning to agile as a way to get more work done with less budget.

This year’s Agile Business Conference in London has the theme of “Driving Success in Adversity” and I have submitted a presentation outline and plan to attend. There submission system states “This year we invite presentations and tutorials emphasising how Agile practices promote efficiency in project delivery, guarantee business value and optimise return on investment.” This seems a great theme, agile is all about maximizing business value, and I am looking forward to the conference.
 
Meanwhile, in New Orleans next week, I am keen to hear how organizations are currently using agile methods within their organizations to add value. (I am also looking forward to sampling the food and feeling some warmer weather after a long Canadian winter!)


The "Realization, Suck, Advance" Progression

S Ski Many skills go through a familiar progression:
1) Poor Performance
2) The Point of Realization
3) The “Sucking” Phase
4) The Advancement Phase

I went through this with TDD, then with a switch from management to leadership, more recently with learning to ski down hill in control on cross-country skis.


Realization Suck Advance

1) Poor Performance – Some things you just cannot do, or you have a lack of recognition about. The end result is that performance is poor.

2) The Point Realization – this is when you realize what you are supposed to be doing and the “a-ha” moment occurs. It feels good to now know what you need to do, but usually we are not practiced at it and still continue to fail for a while.

3) The “Suck” Phase – We know what we should do, but despite our best efforts we fail at doing it. This is because we have had no practice and we have not developed our skills yet. It can be frustrating that after making the mental leap that our performance hardly improves at all. From an external view observers may see no discernable improvement between before and immediately after the Point of Realization. Yet the seed has been sown and with practice we will get better.

4) The Advancement Phase – Now at last we start to make progress as we practice, continue to make mistakes, but get better and better. Our performance improves, we still fail occasionally, but less often and we get longer periods of high performance in between.

Applied Behavioral Analysis Science
My latest Point of Realization came during a presentation by Tony Parrottino at a recent PMI-SAC meeting. Tony was talking about Applied Behavioral Analysis Science as outlined by Aubrey Daniels.

Continue reading "The "Realization, Suck, Advance" Progression" »


VUCA Lessons For Agile

Project Uncertainty Bob Johansen author of “Get There Early: Sensing the Future to Compete in the Present” outlines the challenges of VUCA projects. VUCA is a military term used to describe environments characterized by:

Volatility
Uncertainty
Complexity
Ambiguity

In such environments standard Command-and-Control processes are not effective.

I recently attended a great presentation by Denise Caron who outlined Bob’s description of VUCA challenges and the new leadership models that lend themselves to these circumstances. Many of today’s software projects exhibit Volatility, Uncertainty, Complexity and Ambiguity and there are numerous parallels between agile leadership and the VUCA leadership model.

Low complexity, fixed targets and “knowable” problems can be solved with a Command-and-Control approach. Here careful upfront planning and then methodical execution pay dividends. However, projects with high complexity, moving targets and initially unclear end-goals cannot be planned in detail upfront and then simply executed. This is where the advantages agile approaches come into play gaining the benefits of adaption over a traditional “Plan-the-work, work-the-plan” approach.

Johansen brings some useful parallels to the agile model, focusing on the role of a leader when faced with a dilemma involving Volatility, Uncertainty, Complexity and Ambiguity. He highlights a Foresight to Insight to Action cycle as shown next...

Continue reading "VUCA Lessons For Agile" »


Agile Organizations

Agile Organizations The week before last I was in Regina teaching a two day Agile Project Leadership course for the Regina .NET User Group. One of the side conversations we had there was about Agile Organizations. Companies who not only embrace agile principles on their projects, but also within the behaviour and execution of their entire business. There is a big difference between running projects in an agile way within a traditional organization and orienting an entire company around principles that match agile values. Here are four well known and some not so well known examples:

1) Toyota
Toyota’s lean approach is well publicized. Through their passion for worker-led continual improvement they review, learn, adapt and improve at an impressive pace. Much has been written about Toyota’s capacity to innovate and nearly all of it comes from the incorporation of many small internal suggestions. In “The Elegant Solution: Toyota's Formula for Mastering Innovation” author Mathew May describes how Toyota implements over 1 million employee suggestions per year, that is about 3000 per working day, a truly staggering number.

The Elegant Solution
There is no big prize for the best suggestion picked each month. Instead all suggestions are valued equally and thanked in a small way. Toyota believes the biggest improvements come about from implementing thousands of small improvements, not waiting for the next big idea.

How do we learn from this? By creating ways for people to contribute, canvas their ideas frequently and recognize all suggestions for improvement; whether they are ultimately successful or not.

Continue reading "Agile Organizations" »


Batch Size and Velocity Fluctuations

Batch Sizes I recently wrote a post on Velocity Signature Analysis and have been looking at how undertaking large chunks of work as a complete team impacts velocity. We are currently three quarters of the way through a major (4 months long) piece of functionality and velocity is finally rising. This seems a pattern; for the early portion of a new area of work we spend a lot of time understanding the business domain and checking our interpretation using mock-ups and discussions. Velocity, in terms of functionality built and approved by the business is down during this time since many of the team members are involved in understanding the new business area rather than cranking out code.

As project manager I can get jittery, did we estimate this section of work correctly? Our average velocity for the last module was 60 points per month and now we are only getting 20! Weeks and weeks go by as whiteboards get filled, designs get changed, but the tested story counts hardly moves. Compounding this Discovery Drain phenomenon is the Clean-up Drain pattern. During the early portions of a new phase, fixing up the niggling issues hanging over from the last phase seems to take a long time. This makes perfect sense, if they were easy they would probably have been done earlier. It is always the difficult to reproduce bug, the change request that necessitates a rework of established workflow or multiple stakeholder collaboration that seem to bleed into the next development phase. While there may only be 3 or 4 bugs or change requests hanging over, they take a disproportionate amount of time to resolve.

Continue reading "Batch Size and Velocity Fluctuations" »


PMI Opening the Doors to Agile

Door “To deal with complex projects there is an increased need for agile and flexible project management… In future, ‘people’ and leadership skills will be viewed as more important than technical skills.”

Statements like these hardly seem surprising to regular readers here. This is what I have been advocating for years. However, these recommendations do not come from me, but instead from this month’s PMI Today magazine. Couple this with the announcement last week at the PMI Global Congress in Denver that the next PMI Virtual Community to be created will be for Agile Methods and we begin to see a promising trend.

I reported previously that the PMBOK v4 Guide due out later this year has more iterative lifecycle coverage. Then today I heard that my Agile Project Management course has been added to the PMI Asia Pacific Congress 2009 conference in Kuala Lumpur, next February. So, while agile methods “crossed the chasm” into mainstream development a couple of years ago, I think we are only just witnessing this shift in project management.

Why has it taken so long for the managers to catch up? Well, as the popular stereotypes go, perhaps we are just a little slow, or have more change inertia, or more practices to change before embracing the new approach. Regardless, I am just glad things seem to be moving at last in the right direction.

I am looking forward to the PMI Agile Virtual Community as a great platform for bringing agile methods to project managers worldwide; (Virtual Community is the new PMI name for a Special Interest Group (SIG)). Congratulations to Jesse Fewell and the rest of the PMI Agile Board for pushing through the red tape and making this new group a reality.


Teaching in Costa Rica

Agile Costa RicaNext week I will be teaching two one-day agile workshops and an executive summary session in Costa Rica. The courses are organized by Invenio University Research and Education and will be taking place in the capital, San Jose.

I will be travelling with my friend and colleague Dustin Aleksiuk, who usefully speaks great Spanish and lived in Costa Rica for a while. Dustin has translated my slides into Spanish and the plan is for me to be viewing an English slide deck and Dustin keeping the Spanish projected slide deck in sync. We have a real-time interpreter and headsets for attendees and the whole thing should seem as if it is in Spanish. Questions and Answers will go through the interpreter too.

We will try it for a while and poll the audience, who by all accounts will likely speak good English anyway. If the majority of the audience is more comfortable in English rather than second-hand Spanish we will flip to English, but the process of translation has been fun. The Agile acronyms we use to remember key points like INVEST, CRACK, and IKIWISI just do not translate the same.

I have also been in touch with David Alfaro who lives in Costa Rica, writes the Scrum Costa Rica blog and co-ordinated the first ScrumMaster training in Costa Rica. We are organizing a separate presentation for the University after the regular courses have finished and I hope this attracts a good crowd also.

A trip to Costa Rica would be no fun if it were all work and so we have wrapped the 3 days of courses with 5 days of sight-seeing and activities. It should be great and I’ll post a report with a few photo’s when I return.


The APLN Seattle Leadership Summit

SeattleAPLN The APLN Seattle Leadership Summit is shaping up to be quite the learning event. Here are some of the highlights:

  • Collaboration Games by Luke Hohmann and Allan Shalloway
  • Kanban by David Anderson and Corey Ladas
  • Scrum by Brent Barton and Lance Young
  • Getting Started with Agile by Mitch Lacey and Julie Chickering
  • Writing Agile Contracts by Bruce Eckfeldt and Jim Benson
  • Agile Program Management by Mike Griffiths and Mike Cottmeyer
  • Real Option Theory by Chris Matts and Olav Maassen
  • Agile User Experience by Arlen Bankston and Jeff Patten

The program also includes two leadership keynotes by:

  • Lisa Haneberg, author of seven books including 10 Steps to Be a Successful Manager and Two Weeks to a Breakthrough.
  • John Yuzdepski, a partner at Management Concepts LLC specializing in product transitions and commercialization of new technology and a veteran of the mobile communications industry.

While I am involved in facilitating a session on Agile Program Management with Mike Cottmeyer, my real motivation for attending is to hear the other speakers present.

I am a big fan of Luke’s work on Collaboration Games and posted on it previously here. As too with David’s work on Kanban here and Jim’s work on Agile Contracts here. I know Mitch Lacey does a great job of explaining agile and I was introduced to Real Options as a reviewer of Preston Smith’s Flexible Product Development book and want to learn more.

(I’m sure Mike Cottmeyer can handle the session by himself, I think I’ll be sneaking out to attend some the other sessions!)

So, if you can get to Seattle July 17-18 I recommend the event as the best value agile project leadership training you will find this year. $300 for two days of leading edge knowledge and experience is excellent value (plus you could claim 16 self-directed-learning PDUs too, if you need PDUs).