LeadingAnswers: Leadership and Agile Project Management Blog

Agile Adoption Anti-Patterns

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

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

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

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

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

Agile Communications

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

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

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

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

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

New Postings

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

PMBOK 5 - Rejected

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

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

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

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

New “Agility Now!” Newsletter

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

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

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

Agile Preservation or Progression?

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

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

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

There were plenty of other learnings after this as the methods grew from collective lessons learned, and now I have no qualms adapting process based on circumstance and feedback. This of course is not unique to DSDM, all methods evolved this way. When I took Scrummaster training with Ken Schwaber in 2004, Sprints were 30 days long, no discussion; now two weeks is more common. Good on the Scrum folks for seeing the light and adapting.

Agile methods have come a long way since 1994 (for a start we did not call them “agile” until 2001) and with their widespread use has come some widespread misuse and failure. I found this a little sad until I discovered Sarah Sheard’s “Universal Technology Adoption Lifecycle” and realised it is inevitable.

 

All ideas get carefully replicated at first, then copied, then misused, unfairly blamed, criticized and rediscovered, and we should get used to it.

“If you want to make enemies, try to change something.” - Woodrow Wilson

Lots of people are very passionate about protecting agile methods. So now we see large camps of agile purists and ScrumBut bashers wanting to preserve the faithful reproduction of proven practices. They are in disagreement with agile pragmatists, happier to substitute and adapt. It is a tricky subject, and as always, the there is truth in the extremes and the middle of the arguments

As Ron Jefferies says “Agile ain’t just any damn thing” and I think most people would agree with this. There has to be some common framework, values, and principles present otherwise the boundaries blur indefinitely and the name becomes valueless.

Kent Beck warned us that XP practices are a balanced, self-supporting network and removing some will cause the others to fail.
 

Again, great advice, people really must know how the plain vanilla process works before removing things or inventing new flavours. This is backed up by Alistair Cockburn’s “Shu”, “Ha”, “Rei” model based on Zen Buddhism. Progression moves from obeying the rules (Shu – to Obey), consciously moving away from the rules (Ha – to Break), and finally unconsciously finding an individual path (Rei – to Separate).

Recently Kanban has emerged as a potential agile supplement or replacement (depending on where you sit) and a section in David Anderson’s new Kanban book that caught my eye said:

”Kanban gives permission to create a tailored process optimized to a specific context... You have permission to try Kanban, You have permission to modify your process. You have permission to be different. Your situation is unique and you deserve to develop a unique process definition tailored and optimized to your domain, your value stream, the risks that you manage, the skills of your team, and the demands of your customers.”

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

As agile becomes the default approach for IT projects we can be sure that many projects will fail using it. This is simply because many projects are ill conceived, doomed from the beginning, poorly executed, funded, or supported. Before we rush to defend the method we should remember that a fool with a tool is still just a fool and no method is likely to change that. Also, many projects are high risk and a certain percentage of these high risk endeavours will fail.

“Failure is not fatal, but failure to change might be.” - John Wooden

So the question becomes how do we allow good changes to occur, like Scrum’s move from 30 day Sprints to two weeks, and poor choices like collaborative architecture, or random acts of laziness to fail? I think the answer is pretty simple. Try the change, evaluate it, validate it, adopt successful practices noting circumstances where they work, and stop doing failing practises in your circumstances.

“Nothing is complete and thus nothing is exempt from criticism.” - James Luther Adams

The one thing we must not do is think that we are done with the development of agile methods and now all we have to do is execute them. That is when learning stops and methods stagnate, only to be replaced by the next set of foreword thinkers. I had a good discussion with Jonathon Kohl a few years back about agile methods evolving to embody new practise vs remaining a static model to be replaced by the next better thing. Link Here Whether under the “agile” banner or some other name, we both agreed that progress and change are essential.

 

“If you don't like change, you're going to like irrelevance even less. “ - General Eric Shinseki

I think it is worth reiterating that we have to keep on learning and improving our skills, since standing still is the recipe for becoming obsolete. Nobody wants a mummified manifesto or petrified principles that are no longer relevant. I am very encouraged by the complimentary dialog about agile and kanban (Link) I think this is one of the more promising areas of potential growth seen in recent years.

 

“Talent ... is most likely to be found among non-conformists, dissenters, and rebels.” - David Ogilvy

Reading the forum discussions about purists and pragmatist is interesting, but I try not to get sucked in, and I thought twice about posting these thoughts. It is so easy to spend huge amounts of time defending a point in a discussion where both parties are somewhat correct. I’d rather be learning what people are trying, maybe struggling with; this the breeding ground of the next great idea.

The upcoming Agile conference has many great sounding research papers and presentations that seem to be stretching the envelope. There is several sessions on Behaviour Driven Development and sessions such as “Is It Time to Ditch Your Product Backlog? Using Story Maps to Visualize Backlogs” sound really interesting.

I think we need to carefully innovate to ensure we get the useful changes (30 day Sprints changed to 2 week Sprints) and always be on a the lookout for evolving and improving. And remember: “Change is inevitable, except perhaps from vending machines.”

Decisions: Delayed, Dated, or Done?

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

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

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

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

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

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

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

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

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

PMBOK v5 – Raise a Little Hell

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

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

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

Agile Pendentives

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Motivation 3.0 for Agile Teams

High Performance Team

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

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

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

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

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

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

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

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

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

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

A Peek at Personas

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

Title: "Using Persona to Move Your Project Forward"

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

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

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

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

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

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

Location: Fifth Avenue Place (Conference Room) Map

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

Starting an Agile Project within a Traditional Framework

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

 
 

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

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

 
 

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

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

 

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

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

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

Smart Metrics Slides

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

 

2010 Training Courses and Events

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


March 10-11 Anaheim, CA

April 13-14 Scottsdale, AZ

September 15-16 Las Vegas, NV

November 10-11 Scottsdale, AZ

December 15-16 San Diego, CA

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

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

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

Are Your Metrics Dumb or Smart?

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

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


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

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

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

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

Registration Link

Building Trust and Respect

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

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


 

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

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

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

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

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


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


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


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

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

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

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

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

PMI Agile Survey

It is time to tell the PMI what Agile project management resources they should be developing. Please take a moment to answer this 7 question survey and help direct the PMI in 2010.

In 2009, the PMI Agile Community of Practice was launched to “equip PMI members with agile skills and knowledge”. To accomplish that goal, several services were offered to project managers of all walks interested in agile project management. All responses are anonymous, and all results will be publicly distributed.

PMI Agile Survey

Six Project Trends Every PM Should be Aware Of

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

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

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

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

Project Progress, Optical Illusions, and the Simpsons

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

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

So a standard Parking Lot diagram like this...

becomes a scaled Parking Lot diagram like this...

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

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

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

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

Parking Lot Diagrams Revisited – Using Area to Show Effort

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

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

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

The Science of Empowerment

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

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

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

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

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

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

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

Hiring for an Agile Team

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

 

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

Characteristics of a high performing team:

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

Detecting these characteristics:

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

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

Zombieland Project Management

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

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

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

• The Insecurity Complex
• The Goal Obsession

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

The Insecurity Complex

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

Scrum, Bikram Yoga and The Attention Economy

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

 

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

 

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

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

 

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

 

Scrum

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

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

Bikram Yoga

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

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

The Attention Economy...

Agile Business Conference 2009

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

 

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

PMBOK v4 and Agile mappings

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

 

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

 

Cautions

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

 

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

Calgary APLN Social

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

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

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

Passion and Talent

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

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

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

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

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

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

PMI Agile Launch Event

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

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

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

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

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

Small Books on Big Ideas

Life is short, people are busy. We don’t get time to read as many books as we would like to. Yet we could probably miss a TV show now and again. Here are a couple of really short reads (1 hour or less) on the big ideas in leadership.

Leadership: A Practical Guide to Leadership Principles and Strategies - by Dan MacDonald and Carmen DeLisle.  

 

This super small book is a no frills summary of the transition from manager to leader. It covers:

Back Blogging Again

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

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

 

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

Launch of the PMI Agile Community

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

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

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

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

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

2004 PMI Paper - Using Agile Alongside the PMBOK

2007 PMI Paper - Developments in Agile Project Management

Agile Project Management Viewed from Behavioral Science

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.

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.

The Simple Guide to Earned Value

I have written a couple of posts now on agile alternatives to earned value, but lots of people still do not understand traditional earned value. So here is a simple worked example and a one page .PDF summary...

Let’s imagine our project is to build a wall around a garden. 
 
  

For simplicity, let’s assume 4 equal sides and a budget of $200 per side. Our schedule is one side per day so we should finish in 4 days with a cost of $800.

Here is how the project progresses:

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.