Overdue Update and Designing the Pontiac Aztek

PDCI have had a busy autumn and it has been too long since I posted here. I did some consulting in Europe and attended the PMI Global Congress in New Orleans to present on “21st Century Risk Management” with Dennis Stevens.

More recently our local PMI Chapter won the “Chapter of the Year” award and held their excellent Professional Development Conference that I gave a couple of presentations at. The first on “PMO Evolution: Frameworks for Integrating Lean, Agile and Traditional Projects” and one on “Surviving Agile Projects” aimed at traditional project managers transitioning to manage their first agile project.

The consulting and conference interactions led to a number of ideas for application on agile projects that I will be sharing here in upcoming posts. At our local PMI conference in Calgary last week Bob Lutz, Retired Vice Chairman of General Motors Corporation gave a great talk on design and project management.

He was discussing the importance of defined, repeatable process for efficient, high quality production. Strict compliance and rigorous process controls certainly help improve the manufacturing process. What was interesting was his cautions about applying defined, repeatable processes to design work. He said it flat out does not work and can lead to terrible products.

Bob recounted how upon rejoining General Motors in 2001 he asked Who the hell designed the Pontiac Aztek?(which appears on many Top 10 worst car design lists and is generally slammed from a design perspective – although liked by some loyal owners.) The Pontiac engineers were very defensive claiming that in fact the design of the Aztek was one of the best executed vehicle design projects that had run, hitting each of its targets and assessment milestones during the process. Lutz went on to say while some processes need rigour, design processes need collaboration, feedback and frequent verification to ensure we are on the right track.

As we execute our projects I think there is great value in determining if we are designing something or manufacturing something. The creation of software solutions is like car design, we are trying to understand the problem space and create candidate prototypes for evaluation and evolution towards the best available solution. This requires collaboration, feedback and frequent verification.

Other projects like upgrading servers and training 500 people are more defined, repeatable activities that can benefit from well defined process and strict controls. Most projects I have worked on have elements of both work types mixed together. An important skill for project managers is to know when to employ strict process and when to encourage less structured collaboration where designs evolve based on build-feedback cycles.

I really enjoyed Bob’s talk; he is an engaging speaker who tells things as he sees them and I look forward to reading his latest book “Icons and Idiots”. Over the coming weeks and months I intend to post here more frequently and continue the dialog on the smart application of process and pragmatism.


9 Ways PMOs Can Help Agile Projects

Agile PMOIt may not always be apparent but the goals of the Project Management Office (PMO) and agile teams are well aligned. Both groups want to get to the same destination: namely successful projects and happy stakeholders. However, things often come adrift as soon as the best direction to travel in to get there is discussed. The PMO might expect lots of planning and some documentation to confirm everyone understands the approach. An agile project team might want to build some proof-of-concept models to test feasibility and get confirmation of understanding. So, very quickly the two groups can disengage and have difficulty generating alignment again.

This is one reason agile teams don’t always see the Project Management Office (PMO) as a source of assistance. All too often a traditional PMO can Present Multiple Obstacles, but it does not have to be that way.

First let’s examine what PMO’s are supposed to do. The old roles of: “Rules”, “Tools” & “Schools” goes some way to describing their functions, but a more complete set of offerings was provided in the 2010 PMI Project Management Journal article “Identifying Forces Driving PMO Changes”. These are:

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

1. Monitor and control project performance – Help teams track their velocity. Assist with tracking team and sponsor satisfaction ratings. Look out for and alert teams of dangerous velocity trends, check backlog size, and offer reviews of iteration and release plans.

2. Develop and implement standards – Provide templates for user stories, test cases, cumulative flow diagrams, etc. Provide agile PM tools, educate supporting groups on iterative development concepts.

3. Develop personnel with training and mentoring – Provide agile training courses, coaches, and mentors to help project mangers transition to agile projects and upgrade their skills. Send people to local agile events.

4. Multiproject management – Coordinate between agile teams, communicate between projects including items such as outlining progress, issues and retrospective findings. Help manage Release Trains at the program level and Investment Themes at the portfolio level using frameworks like the Scaled Agile Framework (SAFe).

5. Strategic management – Identify projects with opportunities for early ROI or competitive advantage.

6. Facilitate organizational learning – Gather project velocity profiles, capture, store and index retrospective findings. Include perceived PMO cost vs. value in project metrics.

7. Manage Stakeholders – Provide Product Owner training, guidance on acceptance testing and how to evaluate and give feedback on systems. Champion the importance of Subject Matter Experts (SMEs) to projects.

8. Recruit, select, and evaluate project managers – Develop guidelines for interviewing agile project managers.

9. Execute specialized tasks for project managers – train and provide retrospective facilitators, create agreements with agile project trouble shooters, provide mentors and coaches.

Understanding the role of a PMO and translating the goals into an agile setting helps create alignment rather than conflict between the groups. These items may sound a tall order for your average old-school PMO. However PMO’s are under pressure to remain current and demonstrate their value in a climate of fast moving projects, cost cutting and increased scrutiny.

In the September 2009 PMI Community Post magazine Jack Duggal published an article called “Teaching PMOs to DANCE” that dealt with the issue that many of today’s projects are moving quicker than PMO’s can respond. Many PMO’s struggle assisting projects that DANCE:

Dynamic and changing

Ambiguous and uncertain

Non-linear and unpredictable

Complex

Emergent nature of projects that causes instability

The agile community calls projects like these “a good fit for agile” and this is the synergy. When we can explain agile approaches are not just non-conformist, ill-planned projects, but instead a proven approach for these tricky new project types then a win-win is possible for both camps.

Jack Duggal also gave a presentation at the 2011 PMI Global Congress entitled “Reinventing the PMO which was quite agile manifesto like. Jack outlined a need for PMO’s to shift:

1. From Delivery of Projects to Benefits Realization and Business Value
No longer is delivery of on-time, on-budget projects considered successful. It is necessary but not enough. PMOs need to cultivate a mindset to shift to a benefits and outcomes focus and establish measures to ensure benefits realization and achievement of business value.

2. From Delivery to Adoption and Usability
Typically, PMOs are focused on improving execution capabilities. Projects are implemented well, but often the outputs and deliverables are not used or adopted. With a shift to an adoption and usability mindset, PMOs can promote and plan for adoption throughout the project lifecycle to ensure intended realization of projects’ benefits and value.

3. From Diffused and Disjointed Focus to Holistic and Balanced Adaptive Approach
Often PMOs are pulled to address the current pain or fix the problem of the day. This results in a diffused and disjointed PMO focus and limits the ability of the PMO to provide a balanced approach.

4. From Change Management to Change Leadership
Change management in the PMO realm has focused on configuration management and procedural changes. Evolving PMOs understand the need for organizational and behavioural change and get involved in change-readiness assessments and preparation. PMOs can play a key role in understanding, leveraging and leading change.

The “Next Generation PMO” as Duggal names it will have a mindset viewing the organization as a complex adaptive system. The PMO’s purpose becomes more focused on linking tactical & strategic help with business value. Success will be measured via benefits realization and business value rather than project delivery. All of which are very much aligned with agile concepts.

So, rather than PMO’s being unsupportive of agile, I have found most to be very co-operative when alignment with agile helps them address challenging projects, deliver value and stay current. Also as project managers experienced in agile take roles in the PMO I think this transition will accelerate. With some education and buy-in a good PMO can Provide Many Opportunities for agile teams.

(This article first appeared at projectManagement.com here)

Next PMI-ACP Exam Prep Class with Mike Griffiths

PMI-ACP Prep BookMy next PMI-ACP Exam Preparation course will be November 18, 19, 20 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at historic Fort Calgary which is close to downtown on 9th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book).

The course has a 100% pass rate and uses Turning Technologies audience response technology. Following the course each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.  To reserve your place or ask questions please contact Training@LeadingAnswers.com.


Methodology Wars – Contradictory Constraints or More Options?

Methodology WarsSome rifts are occurring in AgileLand - a world supposedly driven by cooperation, trust and appreciative inquiry! Debate is arising about first generation agile methods (XP, Scrum) and newer upstarts like Kanban and the Scaled Agile Framework (SAFe). Perhaps because market shifts carry training and consulting revenue with them, but a few people don’t seem very happy, as evidenced by some recent blog posts.

Ken Schwaber’s UnSAFe at Any Speed article describe SAFe as a RUP based dinosaur focussing on processes and tools rather than individuals and Interactions. Ian Mitchel summarises the Scrum vs SAFe debate well in his piece Method Wars and speaks to his own SAFe experiences.

David Anderson wrote a post on how Kanban is Anti SAFe in the way the two methods approach adaptation for an organization. He describes SAFe as a collection of (somewhat outdated) software development best practices that you engage an expert or team of experts to tailor for your organization. Kanban on the other hand is based on the idea that knowledge workers know more about their domain than their supervisors or outside experts do and should therefore be the people selecting and tailoring the approach.  So, instead of using experts to select and tailor process, the team does this work as part of the innovation culture fostered by Kanban.

Alan Shalloway describes Why Net Objectives Supports SAFe; they are a SAFe Silver partner organization, and believe it offers a proven, documented approach to scaling agility that is underpinned by sound lean and agile principles.

When I read these different accounts I find myself agreeing up to a point with each perspective. I don’t go quite as far in my beliefs as each author, but if I was talking to the authors I’d probably just nod and bite my tongue for the small portion I feel they are pushing too far. So does that make me a hypocrite, or an easily persuaded novice?

Feeling a little uncomfortable, but not caring enough to worry about it too much since I’d rather be solving business problems rather than debating religious wars that rarely deliver much value, I found an explanation from an unlikely source. A friend had sent me a link to a DiSC Leadership profile tool, it asks a series of questions about your preferences in a leadership role and generates a nice report on your Leadership style.

My assessment indicated a “D” Dominance preference for Getting Results, Taking Action and Offering Challenge.

DiSC 1

 The tool lists some good tendencies of having a strong drive to:

  • Achieve results
  • Overcome  obstacles
  • Get things moving
  • Work towards challenging goals
  • Convincing others

The assessment also pointed out some potential negative traits including:

  • Problems following strict rules and protocols
  • Performing routine tasks
  • Getting bogged down in inefficient procedure or meetings
  • Things that slow down your pace
  • Dealing with people who don’t meet your standards

Generally I am not a big fan of personality profiles, perhaps I hope to be not as stereotyped or easy to categorize as they suggest. I like to think people are unique and multifaceted, but this DiSC Leadership assessment summarized my tendencies very well and helped me understand why I feel the way I do about agile, Kanban, SAFe and even the PMBOK Guide.

Basically I am more results driven and will employ and adapt whatever tools and processes I think will help me achieve those results. As I have said before, if abandoning agile principles and instead wearing silly hats got my projects done better, I would be all for it. Instead however building motivated, empowered teams and championing smart behaviour from all stakeholders through servant leadership and savvy project management is the best I have so far.

So, when I look at the SAFe framework I don’t see too many problems, but instead tend to employ the elements I think suitable to solve my current project’s issues. Due to my “Problems following strict rules and protocols” I probably would not engage SAFe consultants to guide its implementation, but instead discuss the framework with the team and gain consensus for elements to incrementally trial. Being told “That’s not how we do it” or “The PMO has a different standard” tend to fall into my blind spot of “Getting bogged down in inefficient procedure or meetings”, “Things that slow down your pace”, and “Dealing with people who don’t meet your standards” etc.

I do see that these are weaknesses I should work on, but I am hired to get results and deliver value. When this occurs without breaking too many rules or upsetting too many people I call it a good day. I see bending rules and flexible interpretations of process as an enabler of value delivery. For example, in the recent upgrade from the PMBOK v4 Guide to the PMBOK v5 Guide some new “Subsidiary Management Plans” were introduced, but I see this as a boost for adaptability not more control or rigor to follow.

The new PMBOK v5 Guide processes:

  • 5.1 Plan Scope Management
  • 6.1 Plan Schedule Management
  • 7.1 Plan Cost Management
  • 13.2 Plan Stakeholder Management

These could be interpreted as more Draconian control of how we manage scope, schedule, etc. However I see them as my opportunity to tailor the process and define a more lightweight, adaptive approach.

Since the goal of “5.1 Plan Scope Management” is to “… describe how the project scope will be defined, developed, monitored, controlled, and verified” here is my opportunity to explain that we will be using  a vision statement and prioritized feature list instead of a WBS to better support reprioritization and accommodate changes.

Likewise, the new process “6.1 Plan Schedule Management” is a great place to explain the use of release plans, iteration plans and story maps. In my half-full world, these new processes are there to help us be more agile or whatever we need to be (perhaps more structured for your project) in order to be successful - they support tailoring and specialization.

So, where does this all leave us? Well, I found a way to justify my methodology indifference and explain my disregard for rules or process. Maybe your DiSC profile can help explain your feelings towards these recent methodology debates. Likely if you are more of a DiSC "CS" style you would have a different view and very strong opinions about their importance.  Please let me know what you think.


Summer Slowdown

Apologies for the slow rate of articles here at LeadingAnswers.com recently, but I moved to Canada to enjoy the outdoors and it is prime hiking and biking season. Normal posting frequency (which is still not that frequent) will return after our all too short summer.

Meanwhile I will repost some articles I wrote for ProjectManagement.com to fill the void. First a couple of pictures from last weekend’s 24 Hours of Adrenaline bike race in Canmore.

Continue reading "Summer Slowdown" »


Agile For Oil and Gas - mixing lifecycle models

Considering Alternative LifecyclesIntroduction

This post is about Implementing agile at the organizational level across multiple technical domains. I was in Bogotá, Colombia recently working with an oil and gas company to introduce agile to their organization. They were not looking to improve their IT delivery, they were seeing if it could bring benefits to their whole business value stream. Since moving to Calgary 13 years ago I have worked with many oil and gas companies, they are the major employers here and the predominant industry. Lots of energy companies employ lean approaches to exploration, facilities creation and operations to maximize efficiencies and optimize the value stream.

Applying agile techniques to lean processes are a natural compliment and fit especially well with the unique problem solving and collaboration needed to undertake complex projects. Yet, oil and gas projects present a mixture of both these knowledge worker challenges that are a great fit for agile, and industrial engineering that requires traditional approaches. The real benefits come in knowing how to mesh these approaches together and provide some mental models to facilitate planning and problem solving. This is still an emerging field and I don’t think we have all the answers yet, which makes it challenging and rewarding. At the end of the post I outline some questions that I am trying to solve.

The Bigger Picture

Oil and gas development is a long value chain engaging many different groups with unique specializations. Like designing a new car, bringing it to market, producing it, selling and then sustaining it, the skills needed along the way are diverse and often conflicting. Oil and gas development includes the following disciplines:

  • Surveys – identifying areas with favourable geological conditions.
  • Surface Rights Negotiation – arranging for land access with land owners, environmental surveys, native and community outreach.
  • Exploratory Drilling – verifying the presence or absence of hydrocarbon reserves and quantifying the reserve.
  • Facilities – creating the infrastructure for oil or gas extraction, initial processing and transportation to market.
  • Operations – managing the safe extraction and operation of the well and associated facilities. Performing maintenance and projecting production declines and decommissioning work.

Oil Lifecycle

 Mixed Project Types

Some of these activities like the collaborative work of the G & G groups (Geologists and Geophysicists) are classic knowledge worker activities. Here specialists with subject matter expertise come together to share information and as a group and build consensus on the most likely areas for further exploration. No two regions are the same, no two geological formations are the same, and just like software teams use agile methods to collaborate on solving complex problems and gain consensus on the direction to move in, so too do G&G teams.

Further down the chain though, some pieces of work can be more traditional in nature. After determining an area to explore, the execution of a seismic survey might involve mobilizing a large workforce of several hundred people and scheduling constrained equipment. While this can be done in an iterative, prioritized manner, many of the benefits of short iterations, reviews and adaptation are diminished so a hybrid approach is preferable.

Agile Processes

Surface rights negotiation and exploratory drilling are very much expert driven, collaborative problem solving exercises. Starting the process with incomplete information and uncertainties is the norm. There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty. Activities progress with the acknowledgement of ambiguity and proceed through stages of:

1) Embrace ambiguity – getting stakeholder agreement of areas of uncertainty

  • List areas of uncertainty
  • Discuss and agree known scope boundaries

2) Sense making – collaboratively forming consensus on exploratory work to undertake

  • Agree information gathering steps
  • Prioritize sense-making exploratory work

3) Iterate through cycles of Plan, Explore, Learn, Adapt – Learn by doing rather than speculate via planning

  • Plan – agree and assemble work plans, guidelines, objectives
  • Explore – undertake short period of exploratory work
  • Learn – collaboratively analyze findings and gather results
  • Adapt – retune upcoming work plans, incorporate learnings

4) Maximize value – once it is agreed that the “Next Best Dollar Spent” is elsewhere on the project AND the iterative learnings have been maximized, finish the experiments

  • Gain consensus that the exit criteria has been reached
  • Articulate findings, learnings and decisions

Agile Lifecycle

Continue reading "Agile For Oil and Gas - mixing lifecycle models" »


Promoting Shared Leadership

GeeseAgile methods suggest replacing top-down, command-and-control management with empowered teams and shared leadership. That all sounds nice, but what exactly is shared leadership and how do you get it to happen?

Katzenbach & Smith authors of the book “The Wisdom of Teams” explain that shared leadership can occur “where a small number of people with complementary skills who are committed to a common purpose, performance goals and approach for which they hold themselves mutually accountable” - in other words, when we have a well formed team with a strong sense of commitment. In these circumstances team members know that they possess the technical knowledge necessary to make the best local decisions and will self-organize and encourage each other to achieve results.

Examples of effective shared leadership include the Orpheus orchestra that I wrote about in 2008. The Orpheus orchestra has no assigned conductor, instead performers rotate the role, providing unique perspectives and also broadening their experience. Unlike your first guess, this conductor-less orchestra does not sound terrible, but instead have won a number of Grammy awards and perform to sold-out audiences worldwide.

The other classic example is geese flying in “V” formation that reduces drag and extends daily flight range by up to 50% compared to individual birds. All birds take a turn on the front, maintaining direction and parting the air for the following birds. The rest of the flock “honk” encouragement at the lead bird to keep up the speed and when it tires it returns to an easier position in the “V”. If any bird gets too weak or injured, usually two other birds will drop out of formation to rest with it and form a new “V” once it is ready.

These examples are used because they easily show the advantages, but they do not hint at how to transform a dysfunctional group or even normal team into a high performing team using shared leadership. The good news is that providing you have some patience the process is achievable and within your control.

We have to start by understanding and believing in the benefits of leadership ourselves. Jeffery Pinto author of “Project Leadership: From Theory to Practice” describes these core leadership practices:

  • Willingness to challenge the status quo – Search for innovative ways to change, grow and improve, experiment and take risks by constantly generating small wins and learning from mistakes
  • Creating and communicating a vision – sharing your ideas of where we could be
  • Modeling desired behavior – acting honestly, admitting where we lack information, being passionate
  • Enable others to act - Foster collaboration by building trust and strengthen others by sharing power
  • Encouraging each other - Recognize contributions by showing appreciation for excellence and Celebrate the values and victories by creating a spirit of community

Continue reading "Promoting Shared Leadership" »


Agile for Fragmented, Part-time Teams

VolunteersI have a client who uses lean and agile-like processes outside of IT on research and development projects. They have been doing this for a number of years to help optimize constrained tools (drilling platforms) and resources (specialist inspectors). They like the agile concepts of prioritizing based on business value, working in short cycles, expediting rush jobs and frequently validating results and adaptation.

Recently they asked for help with some improvement initiatives that use multi-disciplinary teams to investigate and improve cross-department processes. These groups are staffed by senior engineers who volunteer to help make improvements, but the work is low priority and their time extremely limited. They are also geographically dispersed. Obviously that creates problems for agile practices like daily standups if team members get on average of two to four hours per week to contribute on an initiative.

At first I saw lots of challenges--agile promotes dedicated teams (co-location where possible), daily conversations with business stakeholders, etc. These groups had none of those things, yet three months later they were pleased with the successes they had. It seems when you are trying to coordinate the work effort of distributed, low-availability resources, the structure and visibility of tasks that agile brings is a great strength.

This somewhat counter-intuitive application makes more sense when you consider how such improvement committees traditionally function. Historically, similar work groups had faltered and failed to deliver benefits. The company was mature enough to look for inter-departmental improvement opportunities, but because it was no one’s full-time job (and they spanned departmental jurisdictions), work started but then failed.

Continue reading "Agile for Fragmented, Part-time Teams" »


An Antidote to Velocity Obsession

Agile velocityGetting things done is great; to get things done is why we start things in the first place and why we follow through even when presented with obstacles and setbacks. We do things because they will (hopefully) bring us to some better state. So getting these things done quickly is good because we arrive at this better state sooner.  We track our rate of development (velocity) as a useful measure of progress and also as a leading indicator towards when we should be done. However focussing too much on velocity is dangerous; it leads to myopic mindsets and even moronic behaviour.

Yes, velocity is good, but not at the expense of quality, good-will, or noticing subtle changes in direction. At the Agile 2012 Conference Jim Highsmith and Pat Reed hosted a session called “Velocity is Killing Agility” which examined how velocity (which should be as much a measure of team capacity as it is a measure of their output) is being misused. When organizations overly publicize and analyze velocity, misguided attempts to “Go Faster” lead to gaming velocity scores and not project team improvements.

A Measurement Parallel

For the last 6 months I have been using Strava.com to track my running and biking exercise. It is a social web site for tracking and sharing workout performance data that creates maps, leader boards of hills climbed, point-to-point fastest times, etc. Using your phone or GPS device while out running or riding your performance is automatically recorded and then uploaded and compared to everyone else that has ever covered the same route. Individual rides and runs become virtual races against people you have never met. After posting the fastest time for a segment Strava will send you emails such as “Uh Oh, <fast guy’s name> just beat your record on Heartbreak Hill, go out there and get it back!” It can all get pretty competitive and silly if taken too far.

I have found Strava to be a fun, addictive work-out analysis tool that has led to a few special outings just to retake some records back and generally push harder to beat my own previous times. I have also met a few new people who run and bike locally and found some new trails by looking at the maps of where people train.  The trouble with obsessing on getting the fastest times for segments is that it can drive stupid, myopic behaviour. Stories of people barrelling down trails on mountain bikes at crazy speeds yelling “Strava, get out the way!” at people are getting more common.” Similarly, if you can’t ride the last technical descent on “Coal Chutes Drop” – then just throw your phone over the finish line and you should get a better time!”

Continue reading "An Antidote to Velocity Obsession" »


PMI-ACP Exam Prep Class with Mike Griffiths

PMI-ACP Prep BookMy PMI-ACP Exam Preparation course will be April 15, 16, 17 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at Fort Calgary which is close to downtown on 9th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book). To reserve your place or questions please contact Training@LeadingAnswers.com.

Continue reading to see further details from the Course Outline

Continue reading "PMI-ACP Exam Prep Class with Mike Griffiths" »


Project Zone Congress Discount Code

Project Zone CongressThe Project Zone Congress will be taking place in Frankfurt, March 18-19. I attended the Project Zone Congress last year and was impressed by the quality of sessions and access to speakers for Q & A. This year’s conference is set to repeat the format and has some great speakers including Jurgen Appelo author of “Management 3.0: Leading Agile Developers, Developing Agile Leaders”. I love this title and wish I’d come up with it myself!

Readers of LeadingAnswers can receive a 10% discount from the conference by using the code “PZ2012_MEDIA03B869C8” when they register. It promises to be a high caliber conference with sessions on practical agile, the PMO and agile, strategy and leadership, see the schedule for full details.


Linking Agile to HR Theory

Agile TheoryTo many people, agile is the opposite of sound theory. Instead of proceeding in a structured, well-planned manner, teams “self organize” and iterate through prototypes to try and create something. Ants can self organize and create transportation systems and large, complex community structures. Yet when people self-organize, we tend to get slum ghettos with no sanitation. Which outcome do your projects most resemble?

Planning is a slow, boring, unpopular exercise that attributes accountability to the planning group; if something goes wrong, we know who to blame. If everyone has a go at creating something and it does not turn out, then the blame is harder to pin on someone; excuses can be made around the project being complex and requirements not clearly articulated, etc.

So, is it laziness and dodging accountability that drives the huge growth of agile approaches, or is there something else to it? The Standish Group, which studies software project failure and success rates, recently reported:

“The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.”[1]

They sound pretty impressed, so what’s behind it? It turns out there’s plenty, but in the human resources domain, not the project execution domain. Projects are undertaken by people for people; they involve getting people to work together on things, collaborate, create consensus and sometimes compromise. As such, it is only right that the real key to project success should come from “people science” rather than “scheduling science”. Don’t get me wrong: work breakdown structures, Gantt charts and network diagrams have their place, but they are not the right place to start your journey for successful projects.

Continue reading "Linking Agile to HR Theory" »


Go Talk To Your Stakeholders

P4As a PM, what is the most effective thing you can do for your project in the next hour? (After finishing this article, of course!) I would suggest speaking to your project team members and business representatives about where their concerns lie and what they believe the biggest risks for the project are. The reason being that while tarting up a WBS or re-leveling a project plan might be familiar and comfortable (where you are a master of your own domain), it really amounts to nothing if your project is heading for trouble. Like rearranging deck chairs when you should be looking for icebergs, there are better uses of your time.

The frequency and magnitude of IT project failures are so prevalent and epic that people can appear in denial of their ability to influence, or “in acceptance” that a certain percentage of projects just go south. Does it need to be that way? If we spent more time asking people where stuff could go wrong rather than making ever more polished models of flawed project plans, could we change the statistics (even a little bit)?

According to research by Roger Sessions of ObjectWatch, 66 percent of projects are classified as “at risk” of failure or severe shortcomings. Of these 66 percent, between 50 and 80 percent of these projects will fail. So, if 66 percent of projects are at risk, let’s say 65 percent of these projects will fail; that’s .66 x .66, meaning 43 percent of projects fail. (Despite the grim projection, these numbers are actually slightly better than the Standish Chaos report findings). What would happen if we could prevent just, say, 5 percent of those from failing?

The impacts would be huge, because the amount of money spent on IT projects now is truly monumental. Of all these failing projects, there must be many that flirt on the edge of success versus failure--wobbling between being able to be saved and past the point of no return. These are my targets--not the doomed-from-the-start death marches to oblivion but the appropriately staffed, well-intentioned projects that just don’t quite make it. I bet there was a point in the path to failure when some more dialogue around risks and issues could have provided the opportunity to take corrective action.

The trouble is that we don’t know if we are on an ultimately successful or unsuccessful project until its path may be irreversible. So we need to be acting as if we could be heading for trouble at regular intervals. We should also examine the economics behind this suggestion to change PM behavior. How much is it really worth to maybe sway the outcome of just 5 percent of the projects that are headed to failure?

According to The New York Times, industrialized countries spend 6.4 percent of the GDP on IT projects. Of that, 57 percent typically goes to hardware and communication costs and 43 percent to software development. Of these, 66 percent are classed as “at risk” and 65 percent of them ultimately fail. The cost of failed projects is two-fold: There is the direct project cost, but also a series of related indirect costs. These include the cost of replacing the failed system, the disruption costs to the business, lost revenue due to the failed system, the disruption costs to the business, lost opportunity costs, lost market share and so on.

An investigation into a failed Internal Revenue System project showed a 9.6:1 ration of indirect costs to direct project costs. For our purposes, we will use a more modest ratio of 7.5:1. Let’s see how these figure pan out:

IT Failure Costs

So it turns out that the failing SW projects cost the world about $6 trillion dollars annually, and over $1.3 trillion in the United States alone. That’s a chunk of change, and saving just the 5 percent of projects wobbling on the edge of failure in the States would amount to $1,336B x 0.05 = $66.8B (or $1.28B per week).

How do we do it? Well, socializing the problem is a start. Let’s talk about project risks more often and raise them from the clinical world of reviews and audits up to the more human, approachable world of predictions and wagers. Ask team members to predict why the project may fail or get stuck. Ask our sponsors where they think the biggest obstacles lie. Follow up with “How do we avoid that?” and “What would have to happen to prevent that?” type questions, and follow through on the recommendations.

Just the act of discussing these issues can influence behavior. Armed with knowledge of where the really large icebergs are, people tend to steer and behave differently. To reiterate, we are not trying to prevent all project failures; just keep an extra 5 percent on track through frequent, honest dialog about the issues and a broader stakeholder awareness of the major project risks is a great way to start. So what are you waiting for? 

(I wrote this article first for Gantthead, here )

 


Agile 2012 Conference Downloads

Agile2012Linked below are my presentations from the Agile 2012 Conference in Grapevine, Texas. My slides are really just prompts and pictures to accompany the explanations and stories I tell , but if you were at the conference you will get the idea. For the longer “Collaborative Games for Risk Management” session I have also attached a full 20 page White Paper explaining agile risk management, and the games involved in more detail.  

Thanks to everyone who attended my presentations and, as ever, you are always welcome to contact me if you have an additional questions.

Download File: "Cowboys Presentation"

Download File: "Risk Slides"

Download File: "Collaborative Games for Agile Risk Management - White Paper"


Calgary Presentation - Working Effectively with Off-Shored IT Resources

DiversityOn Monday June 25th Calgary’s Agile Leadership Network meeting with feature Dr. Lionel Laroche presenting on “Working Effectively with Off-Shored IT Resources” the session is free, so come along if you can. The slides will be made available to those how cannot attend after the meeting at the Calgary Agile Leadership Network website

Presentation Outline:

"On paper, off-shoring IT work is a no-brainer – the salaries of programmers in India, Panama or Romania are a fraction of the salaries of programmers in Calgary. However, as most people who have worked with off-shored resources have learned, things are not as simple as they may seem, because managing off-shored resources is not the same as managing Canadian resources. Because people in different parts of the world think, communicate and behave differently in the same situations, projects that involve off-shored resources often experience significant difficulties, particularly at the beginning. This presentation examines the root causes of these difficulties and provides practical tips and suggestions that participants can readily implement when working with off-shored resources."

About the Speaker:

Over the past 14 years, Lionel has provided cross-cultural training, coaching and consulting services to over 25,000 people on four continents. Lionel specializes in helping organizations and professionals reach their business objectives in culturally unfamiliar contexts. In particular, he has worked with organizations like Sun Life, CP Rail, Fujitsu, PwC, CGI, AMD, Microsoft, Gennum, and many other overcome the challenges associated with working with off-shored resources and reap the corresponding benefits. Lionel is the author of two books, "Recruiting, Retaining and Promoting Culturally Different Employees" and "Managing Cultural Diversity in Technical Professions"; he and his business partner, Caroline Yang, are working on a third book entitled "Turning Cultural Diversity into a Competitive Advantage."

To register for this even click here. After the event the slides will be posted here.


Agile Risk Management – Harnessing the Team

Team ideasLast month we looked at how agile methods provide multiple opportunities for embracing proactive risk management. The prioritized backlog, short iterations, frequent inspections and adaptation of process map well to tackling risks early and checking on the effectiveness of our risk management approach.

We want to overcome many of the correct-but-not-sufficient aspects of risk management seen too often on projects:

    Poor engagement - dry, boring, academic, done by PM, does not drive enough change
    Done once – typically near the start, when we know least about the project
    Not revisited enough – often “parked” off to one side and not reviewed again
    Not integrated into project lifecycle – poor tools for task integration
    Not engaging, poor visibility – few stakeholders regularly review the project risks

This month’s article extends risk management beyond the project manager role and introduces the benefits of making it more of a collaborative team exercise. Next week we will walk through the team risk games one by one.

First of all, why collaborative team games? Just as techniques like Planning Poker and Iteration Planning effectively make estimation and scheduling a team activity and gain the technical insights of engaging people closer to the work. So too do collaborative games for risk management; after all, why leave risk management to the person who is furthest from the technical work – the project manager?

"...why leave risk management to the person who is furthest from the technical work – the project manager?"

Before I upset project managers worried about erosion of responsibilities we need to be clear on what the scope is here. I am advocating the closer and more effective engagement of the team members who have insights into technical and team related risks. I am not suggesting we throw the risk register to the team and tell them to get on with it. Instead we are looking for better quality risk identification and additional insights into risk avoidance and mitigation, not the wholesale displacement of the risk management function.

So why should we bother to engage the team? Why not let them get on with doing what they are supposed to be doing, namely building the solution? Well there are some reoccurring problems with how risk management is attempted on projects. Most software projects resemble problem solving exercises more than plan execution exercises. It is very difficult to separate out the experimentation and risk mitigation form the pure execution. Team members are actively engaged in risk management every day. We can benefit from their input in the risk management process and if they are more aware of the project risks (by being engaged in determining them) how they approach their work can be more risk aware and successful.

The benefits of collaboration are widely acknowledged, a study by Steven Yaffee from the University of Michigan cites the following benefits:

Continue reading "Agile Risk Management – Harnessing the Team" »


PMI-ACP Book Discount

PMI-ACP Exam Prep CoverI picked up a copy of my PMI-ACPSM Exam Prep book on a visit to RMC Project Management over the weekend. It was good to see it printed up for the first time, and with all the exercises and 120 sample exam questions, it was thicker than I expected at over 350 full-size pages.

The extra weight also comes from the case studies of agile projects I have worked on over the years and the additional materials I included to link the exam topics together. These items that are not in the exam are clearly marked so you can skip over them if you want. However, I am sure some people will find they add value by making the ideas more real. These additional materials also supply useful information to allow readers to fully understand the topics, rather than just memorize the information for the exam.

I am very grateful to the staff at RMC for pulling together my thoughts and ideas into this book, and for the people who reviewed it. Alistair Cockburn and Dennis Stevens were particularly helpful, and after reviewing it, they wrote the following quotes for the cover:


“As one of the authors of the Agile Manifesto, I am delighted to see this book by Mike Griffiths. It is great that such an exam guide was prepared by someone with a deep understanding of both project management and Agile development. Personally, I hope that everyone reads this book, not just to pass the PMI-ACP exam, but to learn Agile development safely and effectively!”

– Dr. Alistair Cockburn, Manifesto for Agile Software Development Co-Author, International Consortium for Agile Co-Founder, and Current Member of the PMI-ACP Steering Committee.


“This is a VERY enjoyable book to read, due to Mike's firm grasp of the underlying concepts of Agile, and his articulate and entertaining writing style. My favorite part is the fact that it is organized into a framework that helps all of the Agile concepts hang together, so they will be easier to recall when taking the PMI-ACP exam.

But Mike's book is more than just the best PMI-ACP prep book out there. It is also the best consolidated source of Agile knowledge, tools, and techniques available today. Even if you are not planning on sitting for the PMI-ACP exam in the near future you need to buy this book, read it, and keep it as a reference for how to responsibly be Agile!”

Dennis Stevens, PMI-ACP Steering Committee Member, PMI Agile Community of Practice Council Leader, and Partner at Leading Agile.


Thanks to you both, working with you over the years has been a blast. I would also like to thank the visitors of my blog here, too, for reading my posts and submitting insightful comments that kept me motivated to write. RMC has provided me a limited time promotion code that gives readers a further $10 off their currently discounted price for the book. If you follow this link and enter promo codeXTENMGBD”, you can get the additional $10 discount up until May 18th 2012. This is a 25% reduction on the retail price.


Unlikely Origins

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

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

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

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

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

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

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

Continue reading "Unlikely Origins" »


Wednesday’s ALN Talk – Training in Teamwork

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

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

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


Agile Interruptions

By Mike Griffiths

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

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

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


Task Difficulty

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

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

Work Productivity and Enjoyment

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

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

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

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

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

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

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

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

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

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


Using ANT to Measure Project Success

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

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

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

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

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

Continue reading "Using ANT to Measure Project Success" »


Agile Outside of Software

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

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

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

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

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

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

Continue reading "Agile Outside of Software" »


PMI Agile Cert to be called “Agile Certified Practitioner”

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

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

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

Agile Certified Practitioner 6

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


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

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


Agile as a Solution for "Miscalibration Errors"

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

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

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

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

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

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


Training in New Orleans - Updated: Now Full

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

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

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

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

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


Agile Mythbusters

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

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

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

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


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

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


Functional Teams

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

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

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

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

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

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

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

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

Continue reading "Functional Teams" »


Customer Engagement

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

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

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

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

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

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

Continue reading "Customer Engagement" »


Agile Star Quiz

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

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


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


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

Continue reading "Agile Star Quiz" »


Agile Project Wins PMI Award

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

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

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

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

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

  • Enhanced Business and IT relations – against a backdrop of varying degrees of business / IT co-operation, the project stood out as an example of completing a long and challenging project through close cooperation. The stakeholders were practical and pragmatic about decision making and priorities. The increased trust built on this project has been useful for launching subsequent projects.
  • Business Benefits – the business benefits of creating a single, integrated pipeline system are numerous. User configurable calculations, better data quality, faster calculation speeds, and improved reporting are just some of the tangible benefits.
  • Improved resilience and support – The IPS project moved the Pipeline group from a set of unsupported, legacy systems to a new platform of state of the art .Net and Oracle 11g solutions. User developed spreadsheets with questionable data integrity were also replaced.
  • Project Objectives met – The project delivered all the requested functionality within the defined project schedule. This functionality was delivered to a very high level of quality, and while there have been some changes and minor fixes since April 2010, there have been no production outages. The project finished just under the $6.1M budget frozen in 2006 despite having to incorporate late breaking business changes in 2009.

Continue reading "Agile Project Wins PMI Award" »


Aligning PMOs using Game Theory

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

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

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


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

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

Continue reading "Aligning PMOs using Game Theory" »


Ultra Agile

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

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

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

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

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

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

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

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

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


Traditional and Agile PM Integration Pains - a Positive Sign?

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

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

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

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

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

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

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

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

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


Agile Communications

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

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

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

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

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

Continue reading "Agile Communications" »


Agile Preservation or Progression?

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

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

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

Continue reading "Agile Preservation or Progression?" »


Decisions: Delayed, Dated, or Done?

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

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

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

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

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


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

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

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

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

PMBOK v5 – Raise a Little Hell

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


The PMI is calling for volunteers to help write and shape PMBOK v5 Guide Link. Here is your chance to inject more recognition and support for agile methods. I was involved in The PMBOK v3 Guide rewrite and got two small changes accepted in 2004 when agile methods and the PMBOK were hardly being talk about and I was a bit of a lone voice at the party.
 
If you don't like what you see
Why don't you fight it
If you know there's something wrong
Why don't you right it

 
Since then the tides have changed and now the PMI Agile Community of Practice is the largest and fastest growing PMI community. In the last PMI Network Magazine sent to members there were two full articles on Agile project management. Of the PMI’s 340,000 members an estimated 65% are in IT and the demand for agile guidance that has proliferated in other disciplines of IT (development, analysis, QA) is very apparent to the PMI, who need to serve their members.

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

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


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

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

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

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

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


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

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

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

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

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

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

Motivation 3.0 for Agile Teams

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


High Performance Team

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

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

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

Why So Successful?

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

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

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

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

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


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

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

Continue reading "High Performance Team" »


Starting an Agile Project within a Traditional Framework

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

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

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

Start Up Activities
 
 


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

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

Agile Early Process
 

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

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

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

2010 Training Courses and Events

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


March 10-11 Anaheim, CA

April 13-14 Scottsdale, AZ

September 15-16 Las Vegas, NV

November 10-11 Scottsdale, AZ

December 15-16 San Diego, CA

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

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

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

Are Your Metrics Dumb or Smart?

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

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


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

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

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

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

Registration Link

Building Trust and Respect

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

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

Trust and Respect Lifecyle
 

While this is common sense stuff, what I liked about the workshop is the Howard Jackson Model for systematically building trust and respect. It is a repeatable series of steps that build on from each other in sequence to establish better collaboration.
 
Respect Pyramid
 
In this model we start at the bottom of the pyramid with Straight Talk, and move through the steps of Listening for Understanding, Making Commitments, being Reliable, creating Trust, and then finally earning Respect.

Straight Talk

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

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

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

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

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

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

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

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

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

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

Six Project Trends Every PM Should be Aware Of

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

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

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

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

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


Project Progress, Optical Illusions, and the Simpsons

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

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

So a standard Parking Lot diagram like this...
Parking Lot Diagram


becomes a scaled Parking Lot diagram like this...

Parking Lot Diagram Scaled

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

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

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


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

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


The Science of Empowerment

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

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

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

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

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

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

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


Hiring for an Agile Team

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

 

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

Characteristics of a high performing team:

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

Detecting these characteristics:

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

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

Continue reading "Hiring for an Agile Team" »


Zombieland Project Management

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

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

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

• The Insecurity Complex
• The Goal Obsession

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

The Insecurity Complex

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

Continue reading "Zombieland Project Management" »


Scrum, Bikram Yoga and The Attention Economy

Yoga

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

 

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

 

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

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

 

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

 

Scrum

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

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

Bikram Yoga

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

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

The Attention Economy...

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


Agile Business Conference 2009

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

 

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

Continue reading "Agile Business Conference 2009" »