LeadingAnswers: Leadership and Agile Project Management Blog

Agile Project Management Viewed from Behavioral 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.

 

3) Q: So, what is Pinpointing and why is it important?

3) A:  Pinpointing is a technique that simply means “being precise”. When we want to manage anybody’s performance we need to be precise about two very important variables – results and behaviors, and in that order. These variables define what we want from our performers. Even when measuring these variables we seek the technique of Pinpointing to be precise about the measures as well. The importance of pinpointing should be relatively obvious. Take Project Management for example. If you’ve every asked someone or even yourself “I don’t think that’s what I wanted, or asked for?” I’m quite sure you haven’t pinpointed. I’m always amazed at the lack of “performance precision” that occurs in most organizations. Although pinpointing defines performance precisely, don’t let that fool you – it’s only your first step in successfully managing your team’s performance. Just because you’re precise about what you want doesn’t mean your going to get it now does it? 

4) Q: OK so how would you go about pinpointing for the common roles on software development projects, namely Project Managers, Software developers, Business Analysts and Quality Assurance roles?

4) A: Well the answer to that question might be too lengthily for the space we have here, as the analysis and development process of Pinpointing is not an easy technique. However, I will give you some insights as to where I would start. Firstly, the place I would start is not with any of the job roles at all. I would start with the Project itself. And I would ask the most fundamental question of “what is the one mission critical result” of the Project? Now before you start thinking too hard to try and postulate an answer, keep in mind that most people don’t know the difference between a result and a behavior (activities in this case as a Project doesn’t have arms and legs so it can’t behave). Let me make a few points here. Firstly, when we pinpoint we should always start at the highest level relative to where we stand “organizationally” before we get down to the job roles. Then, when we have that figured out if the next level is job roles once again we should start and only focus on the results for those job roles. This process or technique Tom Gilbert, a performance expert, called “mission pinpointing”. And the critical point to be made here is to never focus on behaviors until you have the “right” result, and even then don’t worry about behaviors until you have the “right” measures of those mission critical results. There are several tests and methods to not only determine pinpoints but also to know if you have a pinpoint. In short, I would recommend starting by taking a training course on “Pinpointing”.

5) Q: I recall you pulling me up on a comment that I made about the IT industry. I thought it overly biased towards left-brain analytical type people who might be less likely to be looking for people-based solutions to project challenges. We discussed the whole validity of the idea of personality types, which you discredited. Can you explain why you believe Myers-Briggs, DISC, Belbin, etc tests are flawed and what you would suggest we concentrate on instead?

5) A: The tests you mention are fundamentally NOT rooted in any science. The subject matter of “behavior” which is of critical importance to any business manager, as it is the means to all business results is fundamentally what we have been discussing. The question to be asked on these “tests” is “what use does the information provided by them present to a manager”? Generalizing, grouping, organizing, and cataloging “behaviors” may have a place in informal coffee discussions but really provides NO value in “explaining” the precise cause-effect relationships of the important variables related to “behavior”. You can’t honestly believe that by simply answering a set of test questions you could explain all the detailed complex and functional processes of “behavior” and furthermore interpret it, predict it, and control it – the use to a manager? Behavior Analysis Science has almost one hundred years of refined scientific and experimental study. Science is the closest thing we have to the truth on any subject matter. Knowing that there is a science to “behavior” is your first clue on what to concentrate on instead of explanatory fictional tests.    

6) Q: Is Applied Behavior Analysis science or psychology?

6) A: Science. Ironically, it got its start in psychology. When Pavlov discovered the process of “reflex conditioning” the “psychology space” started to “extend” the functional relationships of stimulus-response to try and explain all “behavior”. This proved to be futile. But let’s back up a second. Pavlov himself was a Physiologist and was studying the scientific process of the digestive system. Serendipitously, and very scientifically he measured, observed, and discovered the causal variables related to reflexes and “reflex conditioning”. It wasn’t until Thorndike, a psychologist, started to study, measure, observe and document the effect of “consequences” on learning in animals that non-reflex behavioral relationships “started” to take a somewhat “scientific” understanding. Finally, the person that built on and refined all of these scientific studies of behavior was B.F. Skinner. That’s when fundamentally the studies of “behavior” diverged into Psychologies and Behavior Analysis Science. Behavior Analysis Science discards “inner” variables as causes of behavior. For example, how would you measure, observe and explain the functional relationship to behavior of an “ego”? Other sciences like Physics, Biology, and Chemistry rely on physical, measurable, and observable variables to explain how things work. And like these sciences there is only one science of behavior, Behavior Analysis Science. I’ve quite frankly lost count as to how many Psychologies there are?    

7) Q: You emphasize the importance of effective human performance measurement. What should we be looking for? What are the characteristics of a good performance measurement metric?

7) A: This is a great question because measuring human performance has been thought of as a “mystery” to most managers. That’s because “we” think that human performance is some “internal” process that can’t be measured. This is fundamentally false. Human performance is an “outside job”. Its real measures are in what we accomplish (results) and what we do (behaviors). It’s that pragmatic. When we start to look at the real world variables of results and behaviors we can now not only measure human performance we can observe it precisely as well. Keep in mind that the real business “value” is in the result. The behaviors, even though they are the means to the results, quite frankly, “cost” the business – time, effort, money. Often, we spend a lot of time measuring and observing what people do (behaviors) and believe we can measure performance. This is very misleading, as the real value of performance is in the results. In other words “don’t confuse the plough with the crop”. A characteristic of a good performance measurement metric lies in the heart of “pinpointing” again. The more you are precise about what you want to measure the easier it is to measure. If you’re precise about the result you want for example then measuring it is a simple exercise in counting. For example if you know you want precisely 2”X4”X6” pieces of wood (quality measure) and you know you want 50 pieces a day (productivity measure), your ready to measure the precise specifications of the result (wood) – you merely count it. This external focus and pinpointing approach also works for “knowledge” workers. We don’t hire people for their knowledge; we hire people for their results from their behaviors which demonstrate their knowledge.

 

Finally, where can people find out more information on Applied Behavior Analysis Science?

If you’re interested in applications to business performance I highly recommend two books:

1. Performance Management - Aubrey Daniels and James Daniels
2. Human Competence – Tom Gilbert (1976 publication)

If you’re interested in the actual science of behavior I highly recommend this free pdf book: http://www.bfskinner.org/BFSkinner/PDFBooks.html 

And of course anyone who reads this article can feel free to call me directly for more information at 403 461 9100 in Calgary, Alberta, Canada or visit my company’s website (AnMar Management Inc.)

Thank you Tony for sharing your insights into behaviours on teams.

Assessing Your Emotional Capital

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.

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.

 

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?

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.

Upcoming Events

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:

• September 14-15 Las Vegas, Nevada
• November 9-10 Savannah, Georgia
• December 14-15, San Diego, California

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!

Non-Functional Requirements - Minimal Checklist

All IT systems at some point in their lifecycle need to consider non-functional requirements and their testing. For some projects these requirements warrant extensive work and for other project domains a quick check through may be sufficient. As a minimum, the following list can be a helpful reminder to ensure you have covered the basics.  Based on your own project characteristics, I would recommend the topics are converted into SMART (Specific, Measurable, Attainable, Realisable, Timeboxed / Traceable) requirements with the detail and rigour appropriate to your project.

The list is also available at the bottom of the article as a one-page PDF document. While it is easy to make the list longer by adding more items, I would really like to hear how to make the list better while keeping it on one page (and readable) to share with other visitors here.

Security
  • Login requirements - access levels, CRUD levels
  • Password requirements - length, special characters, expiry, recycling policies
  • Inactivity timeouts – durations, actions

Audit
  • Audited elements – what business elements will be audited?
  • Audited fields – which data fields will be audited?
  • Audit file characteristics - before image, after image, user and time stamp, etc

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

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.

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.

VUCA Lessons For Agile

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

Reinvigorate Your Retrospectives

Come and see Jennitta Andrea present on how to reinvigorate your retrospectives at the Calgary APLN meeting this Friday 27 February.

From the outline:
“You know you should be performing regular retrospectives, but you can't convince management or the team that it's a worthwhile investment of time ... Your team has been performing retrospectives every iteration, and they have become monotonous and have stopped producing valuable insights ... You've heard about retrospectives, but don't even know how to get started ...”

Jennitta is a thought leader in the agile community and serves on the board of the Agile Alliance. I am sure the talk will promote many ideas to make retrospectives extra productive.

To register for this free event visit the Calgary APLN Site

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.

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.

Batch Size and Velocity Fluctuations

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.

Lifecycle Variables

I have written a couple of posts now (here and here) about the new PMBOK v4 guide due out soon. One of the new graphs included helps describe how project characteristics change over the project life time.
 

The top blue line of the graph is used to illustrate how Stakeholder Influence, Risk and Uncertainty start off high and then reduce as the project progresses. The Escalating orange line illustrates how the Cost of Changes increase dramatically over the project timeline.

Quite a lot has already been written on flattening the Cost of Change curve within agile, so I will leave that for now and focus first on the top line.

Before discussing ideas such as how ongoing business input in, for example, prioritization of the remaining work prolongs their ability to influence the project, we should take a moment to understand the PMBOK audience. The PMBOK is not just for software projects, or IT projects, it is an industry agnostic guide relevant to construction, engineering, and manufacturing among other disciplines.

As a general guide, I think these curves make sense, especially outside of software projects. The ability to influence does decline rapidly once designs are committed and construction begins. Likewise, Risks and Uncertainty also reduce generally later in the project once technical obstacles have been overcome.

Software though is different, actually I would hazard a guess that every industry is different really, however software is the one that I know about. Software exhibits a characteristic known as “Extreme Modifiability” meaning we can make many changes, even late in the lifecycle and still be successful. While it would be difficult to move a bridge 3 miles upstream when it was 75% complete; we could choose to move validation logic from the presentation layer, to a middle tier, or a database trigger late into a project.

Velocity Signature Analysis

Most agile projects track their velocity. For the past 10 years or so I have been studying the velocity profiles of my projects and any other projects I can get data from. Velocity profiles tell a story about the project, and like signatures are unique.

Tracking stories, or more normally points completed per iteration, gives the classic velocity graphs such as the one shown below.

Here we can see the Projected Velocity shown by the dotted blue line and the Actual Velocity shown in dark blue.

From observing 15-20 projects I have noticed the following reoccurring patterns. Am I the only one, or are these common?
 

Living the Theory of Constraints

This past week I have had an opportunity to experience some hospital process control and contrast it with traditional project process controls. In doing so, I saw many instances of where today’s projects that exhibit uncertainty could be better managed via prioritization and collaborative decision making than preset plans.

How did we get to Traditional Project Management?
Project management is a fairly young discipline, yet because its repeatable process scales so well, and is easy to duplicate and automate; it rapidly became the dominant process for running projects. Frederick Taylor published his studies on “Scientific Management” in 1911 outlining the process of decomposing complex work into simpler and simpler steps until localized labour could be employed to perform each simple task. Embraced by Henry Ford and others, Scientific Management became the prevailing way of problem solving for entire industries.

It was not until the 1950’s when Peter Drucker and then later Michael Porter convinced the world that centralization and command-and-control structures were flawed. Respect for workers and a holistic value based view of systems can produce better results and more sustainable organizations. Yet traditional project management persisted.

Upcoming Calgary APLN Meeting

The next Calgary Agile Project Leadership Network (APLN) meeting will be on Wednesday November 26 at the 5th Avenue Place Meeting room.

At the meeting Mike McCullough from Quadrus Development will be presenting  a re-run of his Agile 2008 conference session “Learning Games For the Agile Practitioner”. At the Agile 2008 conference the session was voted back for a re-run and was very popular. I hope you can make it out to the event.

To register for this free event visit the Calgary APLN site here.

PMI Opening the Doors to Agile

“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

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

Agile Project Management in Alaska

I have just returned from a great trip to Alaska. It was made possible by a request to speak at the PMI Alaska chapter and deliver two one-day training courses. Alaska is one of those places I have always wanted to visit and so I took the family and extended the trip to include a mini vacation.
 
The Work
For a city with a relatively small population (360,000) they have an active and well attended PMI Chapter. Over 70 people turned out for my dinner presentation on “Leading Agile Teams” and then we had 40 people each day for the one day classes.

Both were new classes, the first “Agile Project Mechanics” was a one day class focussed on agile processes, agile planning and estimating, etc. The second one day class, “Agile Project Dynamics” which was all about the people side of projects, building empowered teams and leadership rather than management. I was a bit hesitant about separating these topics since I think you need a combination of mechanics and dynamics; but as it turned out most people attended both days and so a balance was achieved.
 
Agile Beyond IT
The group was more diverse than I am used to. When I teach the SeminarsWorld course normally the attendees come from the IT industry. In Anchorage we had IT, construction and engineering managers, a fireman, and local authority project managers.

PMI Agile SIG Getting Ready For Launch

The PMI Agile SIG is gathering speed. This Special Interest Group (SIG) is set to be launched later this year and is very timely. While currently the interaction between agile and traditional project management approaches in most organizations may be small.

This intersection is set to expand. The agile community knows that interest and adoption of agile is on the increase. We need only look at the attendance figures for the major agile conferences over the past few years to see how usage and interest is on the increase.

    

Yet, at the same time the PMI is seeing dizzying growth too. Fueled by demands for tighter controls and better governance, along with a seeming insatiable demand for the PMP certification PMI membership has seen strong growth over the past 10 years.

The PMI Agile SIG will be a group made available to all PMI members who want to learn, contribute, and discuss using agile methods. It will examine the best ways to manage such projects and should be a powerful voice for driving agile related practices into the PMBOK Guide and other PMI standards.

As both agile and PMI adoption increases we will see far more overlap and iteration on projects.

Agile methods are being used increasingly beyond the software domain and rather than dismiss traditional approaches as not applicable I think it is better to work with them and help shape a better set of standards for the future.

I have written on introducing agile into the PMI several times before (here, here, here) and often end up discussing the IP concerns of working with the PMI with people. My take is that I'd rather be on the inside trying to make changes rather than outside taking shots. That's why I present on agile at the PMI Conferences and teach an agile project management course for PMI SeminarsWorld.

So, for those that want to help change the world of project management, the PMI Agile SIG is a good place to start. We are actively looking for members, anyone interested in joining can send an email to PMIAgileSIG@LeadingAnswers.com

Just what the PMI Agile SIG can do will be limited only by the enthusiasm of its members. I do know that there is a PMBOK Extension for the Construction Industry published by the PMI. It is for people in the Construction industry wanting to use PMBOK processes in their unique domain. Rather than the name suggests of just extending the PMBOK it actually says: "if you are in the construction industry, forget these processes from the standard PMBOK and instead replace them with these ones…" Longer term, a PMBOK Extension for the Software Industry that removes static planning and substitutes some agile methods would be very useful.

The APLN Seattle Leadership Summit

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

A Better S Curve and Simplified EVM

“S Curves” are great to track project spend. They are simple to interpret and quickly let us see if we are over or under budget.

  

However, we could be doing fine spend wise, but behind from a schedule perspective. This is where Tracking Gantt charts come in and show schedule.

 

Yet, Gantt charts lack the spend component. Pretty soon most projects get ahead or behind in spend and time and so trying to gauge the overall project health becomes difficult.

This is why Earned Value Analysis (EVA) and Earned Value Management (EVM) were created, combining both spend and progress variables to produce a comprehensive set of project measures and metrics. However, there begins the problem.

What’s Bad about Earned Value

EVA is beyond most project stakeholders -

Most people who are not using EVM every week do not understand the terms. “Is a negative Schedule Variance good or bad?”, “What’s the difference between BCWP and EV?” (Answers: it is bad, and they are the same). Despite its usefulness, the confusing terms and heavy use of math puts off a large percentage of the population.

Debates digress beyond numerical accuracy - More challenging still is when several people do understand EVM and start debating which versions of the formulae to use and everyone starts obsessing on the math instead of the project. “Should we use EAC = BAC/CPI, or EAC = AC + ETC, or EAC = AC + [(BAC-EV)/CPI ?” Geez people, the developers probably pulled half of these estimates out of the air and we are applying advanced math to them?

What’s the value in tracking progress against a flawed plan? - EVM compares actual project performance to planned performance at a point in time. So, if our initial plan is wrong we could be effectively trying to do the equivalent of tracking our progress on a road trip from Calgary to Salt Lake City on a map of France! The quality of the baseline plan is a critical success factor of EVM. In agile projects we acknowledge initial plans will likely need changing and so the basis for effective EVM is quickly eroded with evolving plans.

Where’s the Quality?  - We could be on time and on budget, but building a horrible product that the business does not like or is low in quality. We should be aware that cost and schedule are not the whole picture. EVM and agile alternatives are just a part of the picture.

What’s Good about Earned value

It is a Leading Indicator - Perfect rear vision is not of much use to people. At least EVM tries to predict completion dates and final costs. Imperfect leading metrics are always more valuable than perfect trailing metrics, since they give us options to re-plan and change our approach.

It is visual - It is easy to forget the EVM graphs and focus on the numbers, but at the heart of the process are some useful graphs. Visual is good because it engages the right-side of the brain and helps us draw on more mental power to understand, interpret and plan appropriate responses. Visual things are also better to discuss and collaborate on since we can point, annotate and extrapolate easier than with words or numbers.

Agile Alternatives
So how can we maintain the Leading and visual components of EVM and reduce some of the down sides? Well "Double S Curves" are a good start.

 
 
In this graph we have a familiar spend line shown in green tracking to the dollar scale on the right hand axis; and also a feature based line shown in blue tracking against the points scale on the left. 

The gradient of the blue line indicates project velocity. Where it rises steeply we got a lot of points developed in a short time, where it is flat, progress was slow.

 

Adding a background on the graph can be useful to show functional areas. Here we can see that the “Configuration” and “Stock” components of the system have been built and we are currently in the “Sales” piece of functionality at just over 1000 points worth of functionality completed.

Also, at the end of 2007 the step in the background image shows where the scope of the “Sales” portion of the system was increased, shifting the remaining functional areas out by the new work amount. Yet we are still missing projections and a sense of if we are ahead or behind from both spend and schedule perspectives. This is where predicted values come in.

  

Now we can see how we are comparing against our projections. In this example we are overspent and a little ahead of progress currently, but the trends in velocity do not correlate with the continuing velocity improvements predicted.

As a replacement for Earned Value Management, these graphs are all you need. We can get the same metrics and indices right here.

 

Traditional EVM metrics like Schedule Performance Index (SPI) and Cost Performance Index (CPI) can be easily translated into Agile terms. For example, if we planned to complete 30 stories this iteration, but only completed 25 then our SPI is 25/30 or 0.83 (we are working at only 83% of the rate planned). Likewise, CPI is the Earned Value (Completed Features Value) to date divided by the Actual Costs to date, in the example above $2.2M / $2.8M = 0.79. This means we are only getting 79 cents on the dollar compared to what we had predicted, (but of course, who is to say what we predicted is correct.)

Cruel Irony
I find it ironic and amusing that “Earned Value” is a traditional project management term and agile projects often track progress in nebulous “Points”. This is backwards. Agile projects deliberately relate things back to real business value, and yet many traditional project track progress against tasks that add little or no business value and call the process “Earned Value”.

Creating a detailed requirements document that formalizes an incomplete, premature view of requirements that should change as details emerge and business continues to evolve is not earning much value at all. Yet prioritizing features by business value and tracking progress against the business oriented features is an excellent example of real “Earned Value”.

Next Steps
I have uploaded the example spreadsheet used to produce these graphs so you can get started with your own if you are intersted. The Excel “tricks” are as follows:

1) To get the two graphs on the same chart use the ‘Line – Column on 2 axes” graph option. This is on the “Custom Graphs” tab in old versions of Excel, In the Vista version of Excel, add a secondary axis to a normal line graph, by Formatting the data series, then click “Secondary Axis” on the Series Options tab.

2) Create a background image with bands that vary in height corresponding to their points estimates. E.G. a project with two phases one 300 points and one 200 points, would have background image with two bands, one, say, 3cm high the other 2 cm high. Just as long as the proportions are correct the image will be scaled to fit the graph region appropriately. I simply use PowerPoint to create my background images, but you can be as fancy as you like.

3) In Excel format the axes and adjust the Min. and Max values from 0 to you budget amount and points estimate for the project. If these number change, create a new background image and reset the scales.

Download graph_examples.xls

Tool support

I try to keep up with the agile PM tools, but as far as I know, Rally, VersionOne, Target Process, Mingle, XPlanner, etc do not produce these graphs yet. I hope they do soon and calculate the EVM numbers too. I talk to many organizations who want to apply EVM type analysis on agile projects or work with PMO’s that ask for these stats.

Discussion on when it is appropriate to use straight line extrapolation to calculate Estimates At Completion (EAC) and the impacts of updating plans will be the subject of a future post. In the mean time you can also read a research paper on the topic written for the 2006 Agile Conference.

Download rp2_cabri_griffiths_agile_and_earned_value_reporting.pdf

Calgery APLN Meeting Slides Posted

On May 15 I presented on “Decomposing large programs into agile projects” and “Mapping the PMI Processes to Agile Best Practices” at the Calgary APLN meeting. I have uploaded the slides in PDF format and also a zip file containing the hyperlinked Process Groups / Knowledge Areas mapping to Agile practices. (You will need to unzip the PowerPoint slide and Word files into the same directory for the hyperlinks to work correctly.)

Calgary APLN May 15 Slides.pdf

PMI Agile Mappings.ZIP

The timing of the presentation was very close to Michele Sliger and  Stacia Broderick’s release of their new book “The Software Project Manager's Bridge to Agility”. I was hoping we could give a copy of their book away as a door prize, but the book was available about a week too late. However, I received a copy this weekend (thanks Michele, Stacia) it looks good and I look forward to reading it. We also have some copies on order as door prizes for future meetings.

Agile Alliance Update

I recently returned from the Agile Alliance Board meeting in Boston. Three times a year we meet as the board to review progress, plan Agile Alliance programs, conferences and member services. This latest meeting was my favourite. Not only did we get lots done in the two day period, but the process (mainly open space) worked really well and rather than committee work being frustratingly slow, it progressed well, and I came away energized by the whole experience!
We had many good discussions including:

Conference 2009 Update – Next year’s agile conference will most likely by in Chicago, at the Hyatt downtown hotel. Options are being kept open and the venue would work well with between 1200-2400 attendees.

  <Todd Little explains the dynamics of conference venue selection>

Click the "Contine Reading..." link below for more updates.

Calgary APLN Meeting: PMI Framework and Agile

At the next Calgary APLN meeting I will be discussing how the PMI framework maps onto Agile best practices. Yikes, what brought me to this!

Well, back in October at the Calgary APLN planning meeting we asked attendees what they would like to hear about this year. People made suggestions and voted on the topics, the top 5 were:

1) Using Agile on distributed teams
2) Team collaboration / motivation / accountability
3) How to decompose large programs into agile projects
4) Mapping the PMI Framework to Agile best practices
5) Fitting agile into the constraints imposed by the business

The first two have been covered; last November Jane Robarts spoke about her first hand experience of managing distributed agile teams and in February Gerard Meszaros spoke about team collaboration. Both were excellent talks and we have an experience report based on topic 5 “Fitting agile into the constraints imposed by the business” scheduled for June.

This leaves “3) How to decompose large programs into agile projects” and “4) Mapping PMI Framework to Agile best practices”.

Not surprisingly, we had no volunteers for the PMI to agile mapping so on May 15 I have the dubious pleasure of presenting on these two topics; weaving the risk reduction concepts of smaller, more agile projects with the connects-and-disconnects of PMI to agile processes.

When I saw the topic “Mapping the PMI Framework to agile best practices” my first thoughts were; “Don’t” and ‘Why would you want to?” it seemed akin to mapping horse-and-cart operating tips to car driving tips. They are just different and have divergent philosophies.

However, I can see that asking for mappings helps provide a familiar context for new knowledge. It also reassures people that everything in our old process is covered-off in the new process and there are no gaps. So, to help provide context, but not to imply equivalence, mapping the PMI framework to agile methods will be explored with the connection points and gaps identified. I will be careful to emphasize the viewpoint shifts in addition to the process differences.

If you can, please join us for what I hope will be an informative and entertaining presentation. Spaces are limited so register in advance to reserve your place. www.calgaryapln.org. For those that cannot attend in person, I will post the slides and resources here after the presentation.

Travel and Training

I have been traveling and training lots recently and not had much time to post new entries here.

However, the travel time has allowed me to read more and two books I am current enjoying are Leadership Agility by Joiner, Josephs and A Leader Becomes a Leader by J. Sheehan.

Neither is specifically about Agile methods, but both highlight great ideas that are universally applicable. I will post complete reviews when I have finished them.

My traveling and training courses continue next week when I will be teaching a public 2 day Agile Project Management course in Scottsdale for the PMI. I will be repeating it in Seattle May 20-21 and Washington D.C. August 11, 12.

Other public courses coming up include a 1 day in Sacramento June 20 and a two day in Anchorage September 11-12. These courses are proving popular (Scottsdale and Seattle are sold-out) but I also offer private courses that can be tailored to company requirements. Please see here for a full list.

Once the Scottsdale course is over I will resume regular postings here.

Print Your Own Planning Poker Cards

Local APLN member Edgardo Gonzalez, has kindly offered a Planning Poker card template for readers to download. (No longer are we tied to the decks generously given out by Mountain Goat Software at conferences; now we can print our own!)  Based on the Fibonacci sequence, these cards print on standard Avery stationery and can be used by team members to estimate story points. (Post on Agile Estimation Techniques)

Thanks Edgardo for your gift to the community.

Download Planning Poker Cards.doc

Top 10 Team Practices

There are some great books on agile team dynamics nowadays. My personal favorites include:

• Collaboration Explained by Jean Tabaka
• Agile Retrospectives by Esther Derby, Diana Larsen, Ken Schwaber
• Right-Brain Project Management by Michael Aucoin
• Great Boss Dead Boss by Ray Immelman
• The Blind Men and the Elephant by David Schmaltz

The problem is that most people do not get the time they want or need to read about these topics. So, I have created the following: Top 10 Team Practices list and one-page printer friendly version to remind us of some of the basic points.

If you lead a team then print the sheet and post it somewhere visible and do a mental inventory of the practices from time to time. If you are a member of a team that could do with a boost, print a copy and post it on your manager’s wall, I am sure they will thank you for it! (actual results may vary.)

1) Empower them – By giving control for local decision making and work sequencing to the team we gain the advantages of additional insights, better motivated teams, and more practical plans with less waiting. 

2) Listen to them – The team is closer to the technical details of the project and also best placed to determine the most successful solutions to project challenges and problems. Encouraging the team to solve the project problems has two main benefits. It demonstrates they are valued for their insight as well as their output, which makes people feel more involved and appreciated. Also, solutions suggested by the team are more likely to be embraced and executed with enthusiasm. It is better to have a 70% optimal solution executed with 80% enthusiasm than a 100% optimal solution executed with 40% enthusiasm.

No Glory in “The Middle Way“

(The “Balanced Blend” Manifesto takes Shape)

Don’t really buy into all the hype of agile? Think it works up to a point, but real-life is actually more complicated and demands more of a hybrid approach? – Don’t worry, you are not alone.

Since helping define DSDM in 1994, I have spent the last 14 years helping organizations adopt agile methods like DSDM, Scrum, XP, FDD, etc and have come to realize, like many others, that these methods are not the solution. Instead they are the over-simplified starting points that you need to blend into what already works within the organization. Then overlay and support with additional approaches to create successful project ecosystems.

We need simplified schematics of systems to assist comprehension and discussion. However, all too often these simplified models are put into production as the entire solution and then problems occur.  Like a simplified model of a car braking system, it is useful in helping us understand how the system works in theory, yet is full of design flaws for practical implementation.

In real life, servo’s and pumps are needed to amplify the braking force from the pedal. There is not a single shared-fluid system, but instead two diagonally opposed systems (so a leak does not result in total brake failure or pulling to one side in a left and right split system). In addition to the basic system shown here, cars also employ an array of supporting systems for fluid level monitoring, ABS, wear detection, etc.

Luckily people do not read about the basics of car braking systems and then decide to replace the one on their car with their own design. However plenty of people read about agile methods and decide to implement that as their new software production system.

The good news is that the state of existing software production systems is often very poor and so implementing any kind of better conceived system is an improvement. (A basic sub-optimal braking system is probably better than relying on throwing an anchor out the window and hoping it snags on something to stop you!) The problems occur when the current system is not optimal, but understood and working; and it is then replaced by an oversimplified alternative.

Agile 2008 Submission Review Marathon

Phew, I am done! We had over 120 submissions for the Agile 2008 “Leadership and Teams” stage which is a great response. However at about 5-10 minutes each to read the bio’s, proposal and submit a review it adds up to a large evaluation effort. Here’s how the stages and numbers broke down:

PMBOK 4 – This Time It’s Iterative!

(Well, maybe a little more iterative)

The current Project Management Body Of Knowledge (PMBOK) Guide is labeled “Third Edition” and was published in 2004. Every 4 years the Project Management Institute (PMI) brings out a new version and the Fourth Edition has just been released to reviewers in Exposure Draft format.

I was a contributor and reviewer for version 3 and will likely submit some feedback for version 4 too. One thing that will be of interest to agile project managers is the increased acceptance of iterative lifecycles.

The concepts of rolling wave planning and progressive elaboration have been in the PMBOK since at least the 2000 edition that I know of. These concepts address the idea that planning near term work in detail and later work in less detail. Then as new details emerge, going back to the plans and updating them with the new data. This is common sense to those in the agile community, but it sometimes surprises people that it has been in the PMBOK for the last 8 years since, unfortunately, many people skim past these important principles in the PMBOK Guide.

Likewise, previous versions of the PMBOK have mentioned alternative lifecycles and nesting of activities. Yet with the PMBOK v 4 draft we start to see more embodiment of iterative approaches.

Collaboration Tools

Last week’s Calgary APLN meeting was on Team Collaboration and afterwards an attendee volunteered a really neat and useful team assessment questionnaire. Gerard Meszaros (author of XUnit Test Patterns) who also has strong project management and team collaboration knowledge, presented on “Using Collaboration to Build Team Commitment”. It was a great presentation and referenced some of the Jean Tabaka’s work from the book “Collaboration Explained”.

I have known Jean since her facilitation work with DSDM in the mid 90’s and she really knows about teams, motivation and working effectively with people. Chapter 4 of her book talks about characteristics of high performance teams. After the presentation, Edgardo Gonzalez sent me a spreadsheet based on these criteria that allows quick and easy team assessments.

As seen from the screenshot above, the tool is a one page Excel sheet that assesses the team’s abilities in:
• Self Organizing
• Empowered to Make Decisions
• Belief in Vision and Success
• Committed Team
• Trust Each Other
• Participatory Decision Making
• Consensus-Driven
• Constructive Disagreement

In our example of a fictitious project, four people completed the questionnaire. The collective team score is shown on the left hand radar chart (indicating a weakness in the “Consensus Driven” field) and the individual scores are shown on the right hand radar diagram. Colour coding flags areas as “Red” for concern, “Yellow” for warning (“Trust…” in the example), and “Green” for good.

Not only is the spreadsheet an effective team diagnostic, but a good lesson in Excel spreadsheet formatting and validation. Thanks Edgardo for agreeing to make this available to everyone and to Gerard and Jean for their work in this important field.

You can download the spreadsheet for your own use below:

Collaborative Team Assessment.xls

Agile Project Leadership and More on Accreditation

Last week I taught the “Agile Project Leadership” course with Sanjiv Augustine in Manchester, UK. The course went really well and we were looked after by Ian and Dot Tudor our hosts from TCC Training and Consultancy. They have a number of training facilities around the UK and ours was Aspen House, a converted church that retained all the arched doorways and high vaulted ceilings you would hope for.

It was a rare treat to teach in such nice surroundings and the church setting made evangelising agile all the more fun. In truth we were “preaching to the choir” as most of the delegates were already familiar with the benefits of agile and were looking for practical tools and more leadership techniques to move their organizations to the next level.

We Don’t Want User Input!

Do you really need those pesky users on your project, forever changing their minds and requesting new functionality just as you are about to be done?

When I was at school, my physic’s teacher was fond of telling us that, "if it were not for the students I would enjoy teaching." The same is true for users, they may cause us issues and headaches, but they are the reason we are there and developing software in the first place.

Why we Need User Input
The truth is that on agile projects we do not want user input we actually need user input in order to be successful. Agile projects are deliberately light on capturing initial requirements because we realize that requirements are likely to change, and evaluation of an emerging system will surface new requirements and improvements to existing requirements that we want to encourage.

Agile 2008 – “Leadership and Teams” Stage

This year’s Agile conference in Toronto this August will be structured slightly differently. Following a music festival structure, the conference will be divided into “stages” to cover different topics. I was able to visit the Agile 2008 conference venue in December when the last Agile Alliance Board meeting was held there and we toured the facility with the Agile 2008 Conference Committee.

Johanna Rothman and I are the “Leadership and Teams” chairs for the conference and we have been allocated a great venue; a large, bright ballroom with high ceilings and lots of natural light. This year the conference has much more space and larger mingling areas both indoors and out which I am sure will help.

On the “Leadership and Teams” stage we are looking for submissions on, you guessed it, leadership and team focused experience reports, research papers, tutorials, and presentations. Now is a great time to submit a proposal, so take a look at the submission system and propose your ideas.

The other element I am excited about is the submission system selection process. I have written previously about encouraging the agile community to prioritize our proposal backlog (list of submissions) and this year it is happening. On the Drupal based submission system anyone can write a review for a session and “up-vote” or “down-vote” a proposal. The cumulative scores for proposals help determine what gets selected.

This will not be a totally crowdsourced selection (like ideagora: Cambrian House), instead panel review will still be involved, but it is great to see the conference users (attendees) involved in prioritizing the features (proposals) for the event.

So, head over to the submission system and up-vote your buddy’s submission, down-vote anything from that guy that won’t return your emails (only kidding) or better yet, submit something valuable on Leadership and Teams for the conference, we would love to see it.

Agile Project Leadership Training Course

On February 4-5th I will be co-instructing with Sanjiv Augustine our new “Agile Project Leadership” training course in Manchester, UK. Sanjiv is the author of the excellent “Managing Agile Projects” book and fellow APLN board member.

This is a fast paced, practical focussed course that covers agile project management, leadership, and avoiding common agile project pitfalls.

You can find further details including a course outline at here.

Top 10 Estimation Best Practices

I have written a few posts now on estimation and so I thought it was time for a summary. Also, I am planning to create a series of one page best practice summaries / cheat-sheets for agile and this seemed like a good candidate.

(I am a real fan of one-pagers; there is special value in getting everything visible and presented on one page that brings unique scope comprehension and clarity.  Toyota and other lean organizations make heavy use of A3 reports, a one page summary of an issue, its root causes, countermeasures, and verification steps to summarize problems and planned solutions - they are powerful tools.

Incidentally, when I first started work I had a wise and cantankerous project manager who was full of oxymoronic proverbs. One I remember was “If you cannot summarize it on only one page, you need to go off and learn more about it!” An astute paradox.)

Anyway, here’s the summary; if you want more explanation on any of the points, refer to my previous posts (Upfront Estimates, Estimation Techniques, Estimate Ranges) on agile estimation.

Personal Agility – Free Webinar

Is agile about new tools and techniques or more a mindset? Philippe Kruchten asserts “agility is not a technology, science, or product but a culture”. This makes sense to me; innovation comes in waves (object oriented programming, business process engineering, lean production, etc); and while they all have their merits, most fail to deliver the full potential of their benefits because people concentrate on the process rather than the mindset. At the heart of agile is a mindset not a toolset.

I was speaking to Christopher Avery today, author of “Teamwork is an Individual Skill” and he shared some thoughts on personal agility and team motivation. Christopher is great for this since he approaches agility and team work from a psychological side whereas my thoughts are usually based on observation and trial and error.

We were discussing motivation and how to motivate peers who you do not necessarily have positional power over. Bosses may try to create motivation via carrot and stick approaches, but these are weak and short lived. People grow tired of such manipulation and find ways to break the system.

Instead, Christopher talked about “Intrinsic Motivation”, a more powerful motivation that comes from within.  People want to be on a winning team, but are not sure how to find or create them. The secret lies in understanding what “winning” means for others and then creating wins around you. In practical terms this means asking people “what is in it for them?” i.e. what is it they would like to learn, do, or gain (beyond a paycheck) from the project and then provide opportunities for these things to happen.

At first this sounded a little odd to me, a bit too touchy-feely. Asking people what they did over the weekend is one thing, but asking them what they want out of a project seems, well, invasive, too personal. However when you think about it, that is backwards, after all the project is something we all have in common. What they did with their spouse over the weekend, now that could be personal!

Telling someone what you really want to get out of a project might seem a little odd too, but fears of doing so indicate a ‘scarcity model’ to information. Why should we worry if people know what we really like to do or gain, chances are they will make opportunities available for us to do them. Helping others get what they want from projects creates an upward spiral of support and co-operation, which when you think about it, is the heart of a winning team.

Chatting to Christopher is always refreshing, he shares so much useful information that I struggle to retain it all. Fortunately for us Chris has recorded a free tele-seminar on Mastering Personal Agility. I heartily recommend it, the people side of projects have the greatest leverage, even small improvements here can yield large benefits; be sure to check it out.

Software Estimates - Managing Expectations via Ranges

Customer: How much is that parrot in the window?
Pet shop owner: Somewhere between $200 and $250
Customer: Erm, OK, I’ll give you $200 for it then!

To some people providing estimates as a range of values seem a strange and unsatisfying way of conducting business. They just want to know how much something will cost, not how much it may or not cost. This is reasonable if the object or service is ready for use, but not if it has yet to be created. The more uncertainty involved in the process the more likely there will be some variability. Now consider this conversation:

Customer: How much will it cost for a taxi ride from the library to the airport
Taxi driver: Probably between $20 and $25, depending on traffic
Customer: OK, that sounds fair, let’s go

It seems more reasonable, we understand the variability of traffic. Unfortunately not all stakeholders understand the variability caused by evolving requirements and changing technology often associated with software projects. However the uncertainties of software development are real and we have an obligation to report estimates as ranges to help manage expectations.

The DOI, Made to Slip?

Nearly three years on, why is the Declaration Of Interdependence (DOI) still not widely known or referenced?

The chances are that most readers will not be familiar with the DOI, yet it is a great piece of work. The DOI lists principles that, like the Agile Manifesto principles, help point the way for teams working on agile projects. It was created by the founders of the Agile Project Leadership Network (APLN) to guide agile project management and rally support for an uprising of new project management thinking.

Other than believing some of the wording was a little too clever for its own good and general consumption. I did not fully understand why it had been avoided. Then I read “Made to Stick” by Chip and Dan Heath and I realized that it has the stickiness and appeal of a greased electric eel.

Agile Estimating – Estimation Approaches

In the last post we covered the importance of engaging the right people in the estimation process and the need to use more than one estimation approach. Today we will look at some examples of team based estimation approaches and practical ways to combine estimate result sets.

Estimation approaches (agile or traditional) can be divided into Heuristic (expert judgment based) and Parametric (calculation based) approaches.

Heuristic
• Comparison to similar systems
• Expert Judgment
• Activity Based (top down)
• Task Based (bottom up)

Parametric
• Function Points
• Use Case Points
• Object Points

Both sets of approaches have some merit, but they are also have their limitations and are open to misuse and over reliance too. For instance Activity Based (top-down) estimating is the most commonly employed estimation approach, but has been found to be the least accurate. Capers Jones in his book “Estimating Software Costs” instead recommends task based (bottom up) estimating approaches that tend to yield better results by encouraging a more thorough investigation into the likely tasks.

Involving many stakeholders
We should ask the people who will be doing the work how long they think it will take. Not only are they closest to the technical details and therefore theoretically in a better position to create a better estimate, but also because of the psychological benefits also.

If someone just hands you an estimate for your work and tells you it should take two weeks, you can either comply and try to get it done in two weeks or rebel and either finish it early or explain why it will take much longer to illustrate the poor nature of the estimate. Even complying and doing the work in two weeks can be a problem; given two weeks work will expand to fill the time. If a solution is found early time will likely be spent finding a better solution or refining the existing one. We do not get enough of the early finishes to cancel out the late ones. As Don Reinertsen observes in “Managing the Design Factory” in engineering we get few early finishes.

Calgary APLN Planning Session

Last week we had the planning session for the 2007/2008 Calgary APLN Chapter. The goal was to create a prioritized list of topics to explore this season and demonstrate some of the values and practices of agile project leadership along the way.

We started by using the Speedboat game in small groups to identify impediments and propellers towards our goal of “Connecting, developing, and supporting great project leaders”. Speedboat is a group exercise for “Issue” and “Enabler” brainstorming that can be used with any group. It helps people to clarify goals, air their concerns, and suggest options for avoiding risks and moving forward. My colleague and co-host for the session, Janice Aston, wrote up these useful notes on using Speedboat and the outputs from the group.

Download Speed_Boat_Instructions.doc

Download Session_Results_10-17-07.doc

I previously wrote an account on Speedboat and other Innovation Games in an earlier post.

Following the Speedboat exercise we brainstormed presentation topics for the upcoming year. The thought process was: “Given the issues and enablers you just identified with agile leadership, what are the topics you would most like to see presented and discussed this year?”

Each group wrote ideas on sticky notes and we then posted them on the wall. Went through an affinity grouping exercise that sorted them into themed groups and removed duplicate suggestions. We all then went through a dot voting exercise where we assigned three votes among the topic suggestions. The topics and votes counts (shown in brackets) are shown below:

Agile In Atlanta – PMBOK to LWOK

I have just got back from the 2007 PMI Global Congress conference held in Atlanta, Georgia. It was a good conference and while I may question the applicability of traditional project management approaches for software development projects; for organizing a conference it is hard to question the results. I experienced no line-ups; good speaker support and a well thought out and organized conference.

My presentation on “Developments in Agile Project Management” was over subscribed and I was asked back to do an encore presentation which is a great endorsement for the level of interest in agile project management, especially from within the traditional PM community. When I presented on agile methods at the 2004 PMI Global Congress in Anaheim, I was the only presenter on agile methods there. Since then I have seen an increase year on year. Last year I counted four agile topics and this year six, which is a promising trend.

I met up with Mitch Lacey and Stein Dolan who were also presenting on agile methods at the conference and it was great to chat and discover we had a similar philosophy. This is that agile methods are merely additional tools for the project toolbox that work well given certain circumstances. They do not replace traditional methods, but instead can exist alongside them and can be used very effectively when the circumstances warrant. This is what Jim Collins calls” The Genius of the And” and the “Tyranny of the Or” by using a smart mix of traditional methods And agile we can better respond to project challenges and avoid the limitations of “either / Or” thinking.

It is good that the PMI is incorporating more agile content; lots of of today’s projects really need these techniques to be successful. Yet many agile practitioners are reluctant to take their message to the PMI, and prefer to focus on agile conferences. However as Henry David Thoreau reminds us “For every thousand hacking at the leaves of evil, there is one striking at the root” Not that the PMI is evil, but if we are to change the world of project management, then the PMI is a great place to start.

LWOK
My talk covered what’s new with Agile Project management and I was glad to be able to announce the Agile Project Leadership Network (APLN) LWOK program approved just a few days before.

While the PMI has its Project Management Body Of Knowledge (PMBOK) as its core set of agreed practices, little exists yet for agile project leaders. There are great resources scattered around different web sites, but no place we can point people to and say “go and start here, it will get you on your way”.

Right-Brain Project Management

Last week I attended an excellent presentation on “Right-Brain Project Management” by Dr Michael Aucoin. I attend lots of presentations during the course of a year, mainly at North America events but a sprinkling of international conferences too, and few presentations stand out as being excellent. This one was exceptional from the content (that connected some loose ends in my Agile-Leadership-Project Management mental model) to the materials and delivery.

So, what was so good about it and what does it have to do with Agile Leadership? Well it outlined a parallel view of project management that supports and reinforces agile leadership and fills in some gaps along the way.

Michael started off by talking about today’s Stretch projects. He defined a Stretch project as a project that causes traditional project management challenges. They are characterized by:

• Schedule challenges and resource challenges
• Ambiguous specifications
• Dealing with new technology, new groups, new people
• Dispersed teams
• Many mid-project scope changes
• Challenging people issues

In these circumstances the old project management approaches that are good for predictable projects break down. Michael did not use the words Traditional and Agile, but he might as well have been giving an agile presentation because through his research he had arrived at the same conclusions, but interestingly, offered additional insights.

Why Does Project Management Fail?
Many people are frustrated by the mismatch between project management theory and its application on real-life projects. This is due largely to trying to employ approaches designed for predictable projects on today’s Stretch projects and seeing them come up short.

Yet, in many walks of life outside of project management, people succeed in unpredictable environments everyday. Doctors, farmers, and teachers all work in difficult to predict environments yet, on the whole, are successful. So why do project manager’s struggle with stretch projects? There are three main reasons.

1. Mismatched project model and environment
2. Projects lack emotional involvement
3. Personal challenges created by stretch projects

Let's look at each in turn...

Agile Risk Management

Risk Management processes may have the air of a traditional, process-driven project management activity. However, agile methods are great risk reduction vehicles, and are actually very well aligned for rapid risk identification and reduction.

What is a Risk?
A risk is some event or circumstance that could transpire and impact the project. The PMBOK talks about good risks (opportunities), but most risk literature focuses on events with potential for negative impacts (project risks).

The risk management process outlined in the PMBOK is shown below:

Where’s the “Risk Response Doing” Step?
One step absent from this process is a “Risk Response Doing” step that focuses on executing the actions identified in the risk mitigation plan. In the defense of the PMBOK, these activities get moved to the project plan and scheduled with the regular work activities.

However the apparent lack of a doing step mirrors a problem seen on many projects. Namely, that risk management is undertaken as a separate (sometimes once only) passive activity that does not drive enough action on the project to prevent the risk happening. As a result we see risks occurring and can point to the risk list to where it was identified, yet not enough was done to prevent it happening.

Agile Exception Processes – What to do when bad stuff happens to good projects

When caught by a fire or other urgent situations it is useful to have emergency equipment on hand and know how to use it.  The same goes for Project Exception Processes, if something untoward happens then that is not the best time to be creating new processes to deal with the event and explaining how to use them. Emotions are high, people respond to bad news differently, and it is better to practice an agreed to procedure than figure out new rules.

Project tolerances and exception plans provide an agreed to emergency plan for when bad stuff happens to good projects. They act as guardrails to help prevent us going off track and provide a mutually understood and agreed to resolution process. So, just as during an emergency is not the best time to collaborate on improvising a rope ladder, nor is during a major project scope change the best time to define a resolution process between project stakeholders.

We will look at the two components (Tolerances and Exception Plans) individually and then examine how they work together. Project tolerances are the guardrails, the upper and lower boundaries the project stakeholders are willing to tolerate for a given project metric. Another way to think of it is how much slack rope we have as a project team to do our own thing (or hang our selves with). Tolerances can be set on a variety of metrics and the degree of variation will depend upon the individual risk tolerances of the collective stakeholders. Some projects might be very time critical, others more concerned with budget, or user satisfaction.

Developing Authentic Leadership

Last night I gave a talk on “Agile Project Leadership” at the Calgary Agile Methods User Group (CAMUG). I like giving these because the questions raised make me re-examine elements of leadership and last night was no exception.

One question raised was basically “We hear about these ideas and they sound good, but in our projects the same old stuff keeps happening. How do we get real results?” I responded with some explanation about encouraging servant leadership, but in retrospect I think the underlying question was more about making the switch to authentic leadership rather than shallow imitations that bring poor results.

 

Some subsequent discussions with a couple of attendees have helped me straighten out my thoughts on the issue further. “Cargo cults” is the term used to explain the phenomenon of blindly replicating outward behaviour with the hope that it will yield positive results. It originates from a few scattered instances of Pacific Island tribes recreating replicas of the war time aircraft runways, control towers, and radios out of wood in the belief that they would bring back the cargo planes that brought Western goods during the war.

 

The equivalent cargo cult leadership pattern would be to practice techniques like team recognition in the hope that it improves morale and productivity without understanding the work undertaken, or by presenting phony “well done’s” and insincere praise. People have excellent BS radars and phony praise is quickly recognized as attempts at manipulation and has the opposite effect as desired. Likewise mechanical-only attempts at creating a common vision, challenging the process, or creating empowered teams will fall short too. These activities require deep conviction or else they will falter and fade, making genuine attempts harder to introduce later as an “antibody effect” of mistrust develops in the team.

   

Popular Posts as PDFs - One year of LeadingAnswers

I have been blogging on this site for a year now and it has been lots of fun. With 82 articles and 33,000 visitors from 127 countries, I have made plenty of contacts that I would not have made otherwise and learned lots in the process.

A couple of people have commented that it is hard to print articles from this site and so I have created a separate page with some of the more popular posts as PDF documents for download or printing. Just click on the "Articles as PDF documents" link of the top right of this page.

Who knows what year 2 will bring, but I’d like to hear from you so I have added a “Suggest a Topic” email link too.  Drop me a line and if your topic catches my fancy I’ll write about it.

Thanks for reading.
Mike

How many volunteers do you have working on your project?

While your initial reaction may be “none”, I would assert that your whole team are actually volunteers and we can benefit from recognizing this and treating them accordingly. All that paying people does is ensure that they turn up (hopefully) and then once they are at work they must want to contribute or else very little will be achieved despite all the outward appearances of them “working”.

Attending the Agile 2007 conference in Washington and witnessing the passion of people engaged in something they truly care about and volunteering on programs with likeminded people got me thinking again about the productivity of volunteers and paid team members.

Team member contribution varies on a scale ranging from being a net drain on the project, all the way up to passionate innovation.

On the left hand side of this spectrum we have instances of people actually negatively impacting the project. Either intentionally or through misguided objectives and actions, their presence on the team actually has a net drain on project productivity.

The next region “Passive Compliance” people do generally work on to-do items, but without much thought and without any passion for the task or goal. Unfortunately “Passive Compliance” is an all too common category for team members in large organizations who feel like “cogs” in a machine they have very little say in.

Keeping Agile Real (and avoid losing people before you begin)

I went to see a bad chiropractor a few months ago and his approach diminished my (already quite skeptical) perception of this medical practice. His outright dismissal of conventional medicine and biased view that chiropractic treatment is the only true solution to all ailments turned me away from him and from any benefits I may have found by continuing with his treatment.

I am not comparing agile methods to alternative medicine, instead I’m just pointing out that zealots who fail to acknowledge alternative views can do a lot to damage their profession. As proponents of agile methods, I believe we can make a stronger case for agile by acknowledging strengths of traditional approaches and explaining how agile can help common challenges, rather than by dismissing traditional techniques.

Encouraged by other recommendations, I visited a different chiropractor and received great benefit. He did not attempt to undermine traditional medicine, instead he explained how he might be able to help and we took it from there. My symptoms got worse before they got better, but I stuck with it since his explanations seemed reasonable. My “conversion” moment came when he also relieved some additional injuries I had been suffering with for many years.

I do not think I am alone in appreciating a considered approach. Most of the people I deal with in the business community are smart, conscientious professionals who are looking for successful projects. Yet, we see the actions of zealots and as a believer it is easy to be caught up in their damaging behaviour.

The following list outlines some common examples of how biased thinking can undermine the value of agile methods and offers some advice to ambassadors of agile methods for avoiding these pitfalls.

Dismissing the Waterfall Process
The waterfall process as originally outlined by Winston Royce in 1970 actually contains some really good advice. For a start it recommends that the waterfall process always be run at least twice for a project because you will not get everything right the first time. Also that there should be regular feedback loops and checks along the way to ensure things are working correctly. Take a look, here’s a reprint of the original 1970 paper, look at page 7.

Download original_waterfall_paper_winston_royce.pdf

Agile ambassadors could do better to offer agile as a solution to single pass waterfall challenges on software projects rather than a superior approach period.

Running down the PMI, PMPs and the PMBOK

New Agile Project Leadership Training Course

In September I will be co-instructing with Sanjiv Augustine the new course “Agile Project Leadership”. Sanjiv is a fellow APLN board member and author of the excellent “Managing Agile Projects” book. I’m really excited because a) we have an excellent course that will stretch attendees while engaging them, and b) co-teaching with Sanjiv will be a blast since he is such a knowledgable and personable expert.

Our first course offering will be in Manchester, UK on September 10-11th. You can find further details including a course outline at Agile University here