My first opportunity to create and run a large agile team did not start well. Having had good successes with small to medium sized agile teams I was keen to unleash the benefits on a bigger scale. I was working for IBM at the time and was able to persuade my account manager to pitch the approach on one of our government projects. A clean-sheet development opportunity with a smart team and engaged business group – what could go wrong? As it turns out, plenty due to my ill-advised approach.

It was the early 90’s and we were trialling techniques that would later become the agile approach DSDM (Dynamic Systems Development Method). Taking ideas like James Martin’s RAD (Rapid Application Development) and active user involvement from Enid Mumford’s Participative Design Approach, we had already dramatically reduced development time and improved acceptance rates on several projects. I was convinced collocated teams with short iterations of build/feedback cycles were the future. We were all set for a big client success and who better than the British Government for good publicity! My enthusiasm was about to be tested.

I was given a full rein of the project, or as I would later realize, just enough rope to hang myself with. Having struggled to get dedicated business input on previous projects I commandeered a large boardroom to collocate the development team and business subject matter experts (SMEs). It was awesome, everyone was together in one room and we had direct access to the business representatives for requirements elicitation, clarification, and demo feedback. We were working hard and getting lots of features built but the business representatives hated it.

At first, I thought they hated me. I think that is a common mistake, we internalize changes in behaviour as attacks or criticisms of ourselves. What have I done? What did I say to upset them? - all of them! I recall wanting to write on my internal project status report to the IBM PMO that “the business is revolting”. However, that is what occurred, starting as cordial and helpful, the business SMEs became less helpful, then uncooperative, and finally hostile. I had a revolt on my hands that I did not understand.

This was my first introduction to organizational change. Luckily for me, I had access to many people in IBM smarter and more experienced than I was. I was given a book called “How to Manage Change Effectively: Approaches, Methods, and Case Examples” by Donald Kirkpatrick that changed my career. In it Kirkpatrick outlines circumstances where people will resist change. These include:

1. When people sense loss in: security, pride and satisfaction, freedom, responsibility, authority, good working conditions, and/or status
2. It creates more problems than it is worth
3. Extra efforts are not being rewarded
4. Lack of respect for those initiating the change
5. The change initiative and its implications are misunderstood
6. Belief that the change does not make sense for the organization
7. Change is misdirected, current state or alternatives are better
8. A low tolerance for change in our lives
9. When change violates a principle or commitment that the organization must stand by
10. Exclusion from the change initiative
11. Changes viewed as criticism of how things were done in the past
12. The change effort occurs at a bad time, other issues or problems are also being handled

Something I was not aware of at the time is how the career development process works within the government. The most junior new hires work in open-plan cubical offices. Then as you get a promotion you get moved to bigger cubicles with higher walls that are more like mini-offices. Next, you get promoted to a real office, then an office with a window, and eventually a corner office. In short, your workspace defines your status, responsibility and authority.

By bringing these business representatives into a shared boardroom to work on the project I had unwittingly generated change resistance scenarios 1-3 and probably triggered many others also. Making them sit and work together like the most junior recruits had caused a loss of good working conditions, status, freedom, pride, satisfaction, and perceived authority. A bad idea when hoping to develop a productive working relationship with someone.

Luckily for me the Kirkpatrick book also lists circumstances when people do accept change, which unsurprisingly are the opposite conditions and include:

1. When change is seen as a personal gain: in security, money, authority, status or prestige, responsibility, working conditions, or achievement
2. Provides a new challenge and reduces boredom
3. Opportunities to influence the change initiative
4. Timing: the time is right for organizational change
5. Source of the change initiative is liked and respected
6. The approach of the change and how it is implemented appeals to us

So, equipped with these ideas we changed our approach. Instead of the business SMEs being collocated with us they returned to their fancy corner offices, long lunch breaks, and afternoons spent reading the newspaper - none of which they could do when they all sat together. Instead, we reserved their mornings for questions, review sessions, and demonstrations. This was better received because their morning calendars were blocked with important project meetings, but we rarely called on all of them at once unless it was for a business demo.

Now they had their offices back, a little more free time, and were engaged in a more respectful way. The team were sceptical at first. However, it really is much better to have one hour of someone who is cheerful, engaged, and helpful than eight hours of someone who is bitter, obstinate and causing issues. The project went much smoother after these changes and it taught me an important lesson in never trying to introduce a process or practice without considering the people elements first.

We completed the project early, largely due to the input and hard work during acceptance testing of the business SMEs, and IBM got their successful case study. I learned to temper my enthusiasm and consider other stakeholders who will undoubtedly have a different view of the project than myself. Individuals and interaction are indeed more important than processes and tools, even if they are your own pet agile processes and tools.

[I first wrote this article for the Government themed November issue of ProjectManagement.com, available to subscribers Here]

I have just returned from the Dubai International Project Management Forum (DIPMF). It was a very enjoyable and impressive conference, focussed on innovation in project management.

Mark Langley, president and CEO of the PMI, gave a keynote presentation on the importance of innovation. Mark explained he visits Dubai 3 or 4 times a year since it is where many of the major construction projects are occurring along with innovations in project management. His presentation featured the 2017 PMI Thought Leadership Series publication “Achieving Greater Agility” and he highlighted the Agile Practice Guide that was released with the latest PMBOK® Guide.

Visiting Dubai and seeing the scope and pace of construction development is impressive. I have written about my interest in architecture before and was thrilled to see each of the Top 15 wonders of Dubai. The conference also organized field trips to several building projects including the Burj Khalifa, the tallest building in the world. I was too late in signing up for those, but booked my own visit up the Burj Khalifa and really enjoyed it.

This year at the conference featured the first Hamdan bin Mohammed Awards for Innovation in Project Management. The awards were created to recognize contributions and innovation in project, program and portfolio management at the individual, team and organizational levels. With more than half a million dollars in prize money, they attracted some serious contributions and winners included: a Hyperloop project team, a UNICEF children’s project, and a large reservoir project.

Audacious multi year projects against a backdrop of shifting economic cycles are difficult to pull off. The financial slow down of 2008 -2009 saw its share of cancelled projects in Dubai. In the last several years many have been restarted or replaced by equally daring projects. With the upcoming Dubai 2020 Expo there is now another burst of ambitious Dubai mega projects.

My contribution to the conference was on a much smaller scale. I gave a presentation entitled “Agile: Panacea or Hype?” that dealt with the alignment of agile approaches with other ideas such as Theory Of Constraints (TOC) and intrinsic motivation. It also covered applicability concerns, suitability filters, hybrid approaches, and my new Beyond Agile Model.

This Beyond Agile Model is a framework I have been working on this year and the subject of my next book. I have given previews of it at the Agile 2017 conference in Orlando and the PMO Symposium two weeks ago in Houston. They have been well received and I hope to outline it here soon along with the developing website that supports it.

I am very grateful to the organizers of the DIPMF conference for inviting me to present. I enjoyed it immensely, it was a great mix of new world-class keynotes like Magnus Lindkvist (who was fantastic) and known talent from old friends like Jack Duggal who I used to train alongside during my PMI SeminarsWorld courses many years ago.

In the last couple of weeks, I have had the pleasure to attend and present at the PMI Global Conference in Chicago and the PMO Symposium in Houston. This week I am off to present at a PMI Chapter conference in Saskatchewan and then the Dubai International Project Management Forum (DIPMF) in Dubai.

Once I return I will post some accounts and observations from these conferences. As agile approaches mature and spread beyond software the project management landscape continues to evolve. I always learn lots attending these events. Sometimes it is about perceptions and acceptance, sometimes new skills and techniques.  Please check www.LeadingAnswers.com for updates.

I have an old-fashioned Edison bulb desk lamp. It’s to remind me to focus (and because I like steampunk, industrial design). A 40-watt incandescent bulb will barely light a room, but a 40-watt laser can cut through aluminium, leather, and wood. It is the same amount of light energy, just focussed instead of being diffused.

The same principle applies to our attention, work and teams. Diffused and scattered there is not much impact. Focussed and concentrated that energy is very impactful. Removing distractions and focussing on a single deliverable at a time allows us to complete our work faster with fewer defects.

Aligning a team to a common vision and purpose directs their energy towards it. No longer diffused to fulfil a dozen competing demands, effort is channelled to the shared goal. Distractions come in many forms. Fancy tools, cool architecture, requests from different groups. If we do not pay attention to focus, our laser beam team becomes an Edison bulb, it is busy and glowing, but not very effective.

So, be cautious of distractions. Monitor time and energy directed to the project goal compared to energy directed to peripheral activities. Work life is like a greased pole with a 40-watt Edison bulb at the bottom and a 40-watt laser at the top. We must always be striving upwards to focus because as we relax we slide down towards distraction.

(Also visible in the picture is my “Do The Work” Post-it. another reminder to focus and a pointer to work on the same topic by Seth Godin and Stephen Pressfield. I guess I could get a 40-watt laser too, but that would scorch the cat rather than amuse it. Plus yes, it is snowing here and yes, my windows are old)

Next week the PMI launches the 6^th edition of its Guide to the PMBOK. Changes for this edition include an Agile Appendix and Agile Introductions to each of the Knowledge Areas. I hope people find them useful. I co-wrote them with Jesse Fewell around this time last year and we have been waiting for the guide to make its way through the PMI standards publication process that includes translation into 11 languages.

I believe some agile approaches can be used on every project. These include more frequent: communications, validation of solution increments, and review and adaptation of process. However, not everyone shares my view and so the agile coverage in the PMBOK Guide – 6^th Edition is focussed in the Appendix and Knowledge Area Introductions, leaving the bulk of the guide unchanged with its coverage of single-pass, iterative and incremental approaches to projects. Yes, the PMBOK Guide already talks about iterative and incremental approaches, if any critics would read it.

Anyway, for people looking for additional agile coverage, the PMI in partnership with the Agile Alliance is also publishing an Agile Practice Guide that is referenced by the new PMBOK Guide. This dedicated book for project practitioners who are implementing agile (quite often in traditional, plan-driven environments) aims to provide additional practical guidance. I was honored when the PMI and Agile Alliance asked me to Chair the author group for writing the new Agile Practice Guide. It’s not often you get an opportunity to lead a group of industry experts in creating a new guide that will be used by thousands of practitioners.

We had a great set of authors including: Jesse Fewel, Becky Hartman, Betsy Kaufman, Stephen Matola, Johanna Rothman, and Horia Slusanschi we also had a very helpful research and guidance team including: Karl Best, Alicia Burke, Edivandro Conforto, Dave Garrett, Roberta Storer, and Stephen Townsend.

From August to December last year we wrote the new Agile Practice Guide as a team. Meeting face-to-face a few times and pairing to write and review each chapter. Collaborative writing like this is slow and sometimes painful as we all have our own styles, pet peeves, and limited availability for volunteering time on unpaid efforts. When you multiply these foibles by the 7 authors and overlay everyone’s time availability to discover little or no common time slots, the challenges of writing anything become clear.

Another challenge was pleasing our sponsoring groups. The Agile Alliance understandably wanted to ensure we did not attempt to document some incremental-waterfall abomination that missed the agile mindset and values. Likewise, the PMI was keen to ensure we did not denigrate plan-driven approaches, contradict elements of their other standards, or define terms differently than the PMI Lexicon of Terms. We also had to align with the upcoming BA Standard and writing style standards. Luckily people could see the potential help such a guide would bring and the credibility of an Agile Alliance and PMI sponsored collaboration. If it was easy it would likely have been done already.

At the end of December 2016, we sent a draft out for Subject Matter Expert review. Around 60 people split equally from the agile community and the project management community reviewed our little book and sent in an unexpectedly high (over 3,000) number of comments. Some were high praise “At last a guide to bridge the divide, great job”, some were not so kind “This section is hippy BS”, most were genuine feedback like “In section 3 you said first consider doing x now in section 5 you are suggesting first doing y”.

We spent several weeks reviewing and applying the feedback comments and the guide improved tremendously as a result. With the handoff date for publication looming we did not have time to apply all the suggested comments so we prioritized them, met and worked through as many as we could up to the ship date, retaining the remainder for the next edition. The Agile Alliance Board of Directors and PMI Management Advisory Board (MAG) reviewed it and gave us the all-clear to release (after a few more tweaks). We had our Minimum Viable Product (MVP).

Not everyone who reviewed the final draft was happy. Some “agile enthusiasts” thought we went too far discussing the application of hybrid approaches. Some “traditional enthusiasts” thought we undermined plan-driven approaches too much. I saw this as validation of us hitting our target market of practitioners just trying to be successful with agile teams in sometimes less-than-agile-friendly traditional environments. Our task was an analog of theirs. When we managed to annoy both ends of the project execution spectrum to about equal degrees we had arrived right where we needed to be!

I am used to having my work criticized. I stopped trying to please everyone years ago and now write my true convictions and they seem to resonate with a few people which is great. I felt bad for the other writers though, especially those that had not published many articles before. Representing the Agile Alliance or PMI and being part of a contentious guide is a daunting task. Publishing something for general use takes courage and exposes your thoughts and work. So, you want your first publication to be accepted not criticized. We had a challenging timeline and set of constraints and am very proud of what everyone produced. It is v1 of the guide and we are looking for volunteers to implement many of the other great suggestions we did not get time to implement and to further the guide with their own suggestions.

The PMBOK Guide - 6th Edition will be available as a free download for PMI members and to purchase in paper form. The new Agile Practice Guide will be available as a free download for Agile Alliance members and PMI members and also to purchase in paper form. Both are available on September 6^th.

I will be speaking at two presentations at the Agile 2017 Conference next week in Orlando. I am looking forward to catching up with old colleagues and meeting new practitioners, it looks set to be a great event.

My first presentation is called “Bridging Mindsets: Creating the PMI Agile Practice Guide” and is an experience report that tells the story of creating the Agile Practice Guide. This is a new book, sponsored by the Agile Alliance and the Project Management Institute that will be published September 6^th. I was Chairman of the writers group and along with Vice-Chair Johanna Rothman we will explain the inputs and constraints to the guide along with our iterative, pair-writing process.

My second presentation is called “Integral but Insufficient: Why the Future Needs More than Agile to be Successful”. This one is a little more controversial, claiming large complex projects are rarely successful using agile alone. It is based on my 23-year experience of working on successful and not so successful agile projects, particularly one team that won a PMI “Project Of The Year” award.

It introduces some core observations such as good answers are rarely simple, and processes carry weight while knowledge is weightless:

Along with suggestions for a more cohesive, comprehensive model that will be the focus of my next book. I am looking forward to sharing these ideas with people and hearing their reactions. I hope to see you there.

April’s theme at ProjectManagement.com where I write a monthly column was “Consulting” and in this article, I examine the world of Agile Consulting and coaching. I distinguish consulting as providing advice, solutions and information; whereas coaching is more asking (hopefully insightful) questions and leading clients to find their own answers and grow in capability.

Depending on where people are in their careers, their agile adoption and their corporate culture, some people want a consultant, others a coach and sometimes they want a blend. The goal is to add more value than you cost and help organizations be successful by avoiding common pitfalls and accelerating their success.

Getting Started
Personally, I was hesitant to get into agile consulting and coaching. Despite being involved in the creation of DSDM in 1994, the more I read and practised, the more I discovered every organization and every project is very different. It felt like I had much more to learn before declaring myself an expert for hire. As your knowledge increases, so too does your exposure to all the things currently just beyond your proficiency that you do not know yet and should learn next.

So, the more I learned, the more I discovered there was so much more to learn! However, there comes a point when you realize that you already know enough to be helping people that are less experienced—and that helps overcome your inertia.

The Work: Helping your Clients
Agile consulting involves instilling and applying a few lean thinking concepts such as:

• Prioritizing for value
• Limiting WIP
• Visualizing the work
• Minimizing waste
• Optimizing for throughput and flow, not resource utilization

Each are very simple concepts that only take 5 to 10 minutes to explain. The challenge comes in making them work in large, complex environments that have competing demands. That’s where the bigger set of skills around change management and emotional intelligence that take a lifetime to learn come into play.

Every industry has plenty of people who understand how things should be done in the ideal world. Consultants add value by finding ways to get there, step by step, unpicking knots in process, dismantling barriers to change. They often act as an independent third party to validate a change that groups know they want to make anyway, sometimes playing the role of devil’s advocate, questioning processes that internal staff should/could not ask; sometimes acting as the scapegoat when someone must explain why/who thought this experiment would be a good idea.

Consultants help clients by working with them to bring meaningful improvements. It usually involves working with people who are busy trying to get their jobs done using some process they were told to use rather than had a hand in designing. Growth involves changing how people work and interact. This can be slow going or painful, and usually both. It is almost always people focused, and why the skills of empathy and influence are critical.

Sharpening the Saw: Building Your Skills and Knowledge
In addition to organizational change management, consultants need ready access to credible research that supports their ideas—along with frameworks, training materials and exercises to perform that reinforces this work with a variety of stakeholders.

In the agile consulting domain, many consultants use lean terminology when discussing concepts with executives, terms friendly to A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) like progressive elaboration and rolling-wave planning when working with PMOs, and XP and Scrum terminology when working with team members. This is not being duplicitous or manipulative, it is just understanding your stakeholders and using appropriate ideas and terms to explain the same things.

It does mean though that consultants should be familiar with as many layers of agile integration as possible. You could well be answering a CFO’s questions about EBITDA and capitalizing prototype work in one conversation, mapping story points completed to earned value in another with the PMO, and talking to developers about NUnit test code coverage in another. There is always lots to learn, and it keeps on evolving.

Then you change industries and start from square one, learning about a new business domain. As such, consulting is very rewarding for life-long learners. People are always developing innovative ways of describing agile techniques, and we can share the best with our clients. Industries, technologies and approaches are constantly changing, too.

Learning and keeping up to date with these skills takes time and introduces a dilemma: How much time do you send productively working, and how much do you spend actively learning? How to best balance production with building capability? Some people use gaps between engagements to gather and hone new skills; others schedule some of their own time each month for learning and professional development.

Personally, I am lucky to have no interest in Facebook or other social media sites that can consume a lot of time, but a passion in learning about leadership, teams, agility and innovation. I find reading books on these topics interesting and volunteer my spare time on standards and collaboration efforts—all of which I learn from. Others take training courses, and today we have access to great information online such as courses and blogs. There are lots of options; the important thing is to find a way of staying current and bringing valuable information, ideas and resources to your clients.

The End Game
What comes next after being a successful consultant? Does there have to be a “next thing”? Many people consult until they retire and, if you enjoy it, are adding value to your clients (and they appreciate it). What more can you ask for?

Others build consulting practices, hiring associates, admin and sales people. They may continue to consult themselves part-time, or move into account management and consultant management. This is fine, too; just understand the skills and motivation to succeed at building and managing a consulting practice will be different than those you first employed. Instead of fixing issues in large organizations, you will now be responsible for developing an organization, hopefully without its own inherent issues (similar idea but subtly different).

Then, of course, you could join one of the companies you consult with or start a new business entirely. One of the great aspects of consulting is that it exposes you to a wide variety of people and business models. Some might resonate or illustrate the need for something new that you get excited about.

Final Thoughts
Like most things in life, consulting is what you make of it. Approach it with humility, hunger and “people smarts,” and you can create a rewarding career. Approach it as a ticket to making money by replicating a formula, and you will likely be in for a rude awakening.

The concepts you aim to instill will likely be deceptively simple, and you might feel uneasy about making that first leap. However, do not underestimate the work required to change how people think and behave. Focus your effort here; after all, the concepts around healthy eating and exercise are also very simple. Just eat fewer calories than you use, move and exercise more…but we seem to need help with that more than ever.

Agile consultants and agile coaches seem an oxymoron—agile is simple, you should not need a coach to be agile. However, healthy eating coaches exist. Exercise coaches exist, not just at an elite level, but also at a domestic level. To some degree, this is where the real challenges are—making changes with modest budgets, pre-existing conditions, in unsupportive environments. It is not easy, but it does provide a great buzz from solving problems and helping people.

[I first wrote this article for ProjectMenagement.com here]

The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the most important part, which is we now need to learn something.

Learning involves several steps. David Kolb, an educational theorist, describes a 4-step learning process:

1. Concrete Experiences (What we already know)
2. Observation and Reflection (What our retrospectives help us identify)
3. Abstract Conceptualization (Thinking about the problems and designing potential solutions)
4. Active Experimentation (Trying something new)

These stages act as part of an experimental learning cycle. The last step, Active Experimentation, creates new concrete experiences and builds on what we already know.

It is easy to confuse the retrospective actions of Observation and Reflection (Stage 2) as gathering lessons learned. However, this is not the case, instead it is just one step in the process. We then need to determine a solution (Stage 3) and run experiments to learn from them (Stage 4). Only then might we actually learn something.

To remind us that simply gathering ideas and suggestions for improvements is not the same as learning, I suggest we stop using the term “Lessons Learned” and instead use “Lessons to be learned”.

I am pleased to announce the availability of my new PMI-ACP Workbook. This new workbook focusses on a smaller subset of 50 key topics.   My original PMI-ACP Exam Prep book distilled all the relevant content from the 11 books on the PMI-ACP recommended reading list in a common voice. The workbook is also different by providing lots of exercises and many situational questions like you will find in the exam.

So, while my PMI-ACP Exam Prep book covers all the background and theory – ideal for a comprehensive coverage of everything in the exam, the new PMI-ACP Workbook is a practical, hands-on study tool that focusses on the core topics needed to pass the exam. If you already have your CSM credential or 3+ years of agile experience you likely know the agile mindset, values and principles material already. However, you may not have the lean, kanban, and team development knowledge needed to pass the PMI-ACP exam so the workbook can fill those gaps.

To help determine which book is best for you I created the following flowchart:

Hands-on learners and people who do not want to read all about how the approaches fit together will find the 50 key topics of the new workbook a simpler way to navigate the material. Also, since the content is arranged by topic alphabetically you can easily jump around and create your own study plan based on just the topics you need.

While the workbook coverage of topics is less than the prep-book, the emphasis on exercises and situational questions is much higher and accounts for the slightly higher page count (457 pages). There is white space for writing notes and the whole thing is spiral bound so it lays flat when you are working in it. The content changes are summarized by these rough page count graphs:

I think it fills an important need. A workbook for hands-on learners looking to build their own study plan and gain access to high-quality situational questions. It also provides access to a free online quiz. Readers can order and get an early-bird discount from RMC here.

I will be presenting at the PMI EMEA Congress May 1-3 in Rome on “PMI’s Agile Future”.

2017 marks an important year for embracing agile approaches by the PMI. The PMBOK® v6 Guide, set to be released in Q3 will have agile accommodation guidance for each of its Knowledge Areas and an Agile Appendix. I wrote these sections with Jesse Fewell and hope they enable practitioners to see how techniques can be tailored for agile environments.

Synchronized for release with the PMBOK® V6 Guide is the new Agile Practice Guide. A collaboration between the Agile Alliance and the PMI to create a guide for project practitioners working in the “messy middle-ground“ of agile teams and plan-driven environments.

I am chair of the author team for this book and just returned from our final meeting to edit the first draft of the guide. We had a huge number of comments from our SME reviewers. Some agile enthusiasts believed it was too lenient to tolerate hybrid approaches as a temporary stepping-stone to fully agile approaches. Some plan-driven enthusiasts believe it was too dismissive of plan-driven approaches to be endorsed by the PMI.

I think if we can equally upset “enthusiasts” at both ends of the agile and plan-driven scale we have probably found the sweet-spot for pragmatic practitioners looking to navigate the very real in-between world we often occupy.

Also, out this year is the BA Standard and BA Guide, similarly with agile coverage. I am grateful to Joy Beatty, chair of the BA Standard and Cyndi Dionisio, chair of the PMBOK® v6 Guide for the support they provided at the Agile Practice Guide - Development Workshop we ran at the PMI Global Congress in San Diego last September.

My “PMI’s Agile Future” presentation for Rome is not just a list of PMI agile products. Instead I will be telling the story of how people have managed uncertainty and complexity through history. I hope to dispel some myths around phase-gates, PERT, Gantt charts and waterfall lifecycles and introduce some unsung heroes of adaptive planning.  Then, to stay on track, I will introduce PMI’s agile developments and link them to the future trends indicating the importance of being able to manage uncertainty and complexity.

I am really looking forward to the event and particularly enjoy talking to people afterwards. Please bring your questions and I’ll see you there.

Lean Thinking, described and popularized in the book “Lean Thinking” by James Womack and Daniel Jones, is summarized as: “focusing on delivering the most value from a customer perspective, while reducing waste and fully utilizing the skills and knowledge of those doing the work”. These are all relevant goals for today’s Project Management Office (PMO) and the reason that increasingly organizations are using Lean Thinking to boost value and reduce waste in the PMO. 

Lean Thinking embodies a wide range of principles and techniques. I like to think of it as a philosophy plus a toolbox of techniques. For this article, we will focus on applying some basic principles for delivering value and identifying wastes to avoid within the PMO.

It’s about people first.

Unlike some other project management approaches, lean is human-centered not process-centered. Two overarching themes prevail over all the practices: 

• Involve everyone – Always make sure everyone involved, impacted and perceived to be impacted is consulted and engaged in the process. This does not mean every font change of a Project Charter template needs CFO approval, but it does mean that all plans, initiatives and work are open and available for contribution or comment to anyone who is interested. Basically, be open and transparent, you never know who might have a great insight or spot a flaw before it impacts performance.

• The Customer Defines Value – Rather than automatically acting to minimize costs or reduce time to market, lean specifically adds the step of asking the customer to define what value means to them. Some groups may focus more on quality at the expense of time or costs, others may value time-to-market and happily sacrifice some scope or cost over runs to get there. It sounds like common-sense, but all too often people get disappointed with a group because of mismatched values. Adding the “customer defines value” step helps avoid those mismatches before the can occur. 

Lean Thinking Principles and the PMO

Lean Thinking suggests five principles as starting points for a continuous cycle of delivery and improvement. Let’s review them one-by-one and see how a PMO can embody the concepts they represent: 

• Specify what creates value from the customer – This principle takes the “Customer Defines Value” theme we just talked about and bakes it right into the first step of the process. PMO’s understand they serve multiple customers, typically including their sponsoring group who pays to put PMO’s in place. 

Value for the PMO sponsoring group likely includes helping projects be successful, ensuring good practices are followed, providing objective evaluation of performance and risk signs, providing help/training where required, etc. Another group of customers is the project teams and team leads / managers. These customers typically want low overheads for PMO compliance and timely responses to requests for support, training, etc. Both of these groups (and any others that apply) must be canvassed to determine what value means to them. 

• Identify all steps - value adding and non-value adding across the whole value stream that bring a product or service to the customer – This is the process of analyzing how things actually operate to get work done. Some activities are necessary value-adding tasks, such as performing a review, while others will be non-value adding activities, like waiting for feedback. 

Lean thinking provides tools such as Value-Stream-Mapping to analyze processes and categorize value-adding and non-value-adding tasks. It also allows us to calculate metrics like cycle time and process efficiency. Using these tools to look at the current-state and future-states of PMO processes, groups can analyze and optimize how to best deliver value. 

• Establish flow – The continuous movement of products, services and information from end to end through the process. Moving large batches of anything, whether its requirements in a specification document or artifact templates to a standards library creates consumption and improvement problems. 

It is better to move smaller batches more frequently. That way there is not a large delay while things are consumed and processed, also if defects or areas for improvement are found in an early batch the information can be sent back to the producing group and the issue addressed in later versions. Establishing flow improves efficiency, quality and the ability to manage changes. PMO’s can support this by encouraging the small batch flow of user stories and retrospectives vs specification documents and project lessons learned reports. 

• Implement Pull – The idea that nothing is done by the upstream process until the downstream, customer signals the need. Stock piling products or service offerings ready for consumption or in-hope that they are consumed is wasteful. It consumes time and energy with in-progress work that has not yet delivered value and often people will want something slightly different. 

A preferable approach is to spend this effort on getting good at rapidly delivering what is asked for. Then establishing signaling mechanisms so that the need (or imminent need) for a product or service triggers its creation. With a stock pile of zero the next item you get is perfectly made for you rather than the next available.  PMO’s can embrace this principle by providing just in time reviews rather than standard readiness assessments. They can also create, say, charter templates based on project characteristics not boilerplate, also Steering Committee updates based on current questions not standard templates. 

• Work to perfection – The goal is the complete elimination of waste so that all activities create value for the customer by continuous improvement. While perfection may be unreachable, the goal of this principle is to instill the idea that improvement is an ongoing process that does not stop. People should always be looking (and encouraged) to improve the delivery of value.

PMO’s can embrace and model this continuous improvement principle by highlighting their ongoing work in a “What’s New” section of their intranet site. They can help projects and teams by attending project reviews and retrospectives to endorse these activities, provide support and distribute the outcomes to a wider audience. Anything that promotes and encourages the continual pursuit of improvement. 

Eliminating DOWNTIME - The Common Forms of Waste

Lean thinking identifies 8 common sources of waste in an organization. Groups, including PMOs should be on the lookout for these forms of waste and avoid or reduce them wherever possible. This is not a one-off activity like a yearly Spring-clean of processes. Instead, it is an ongoing vigilance like work-site safety or maintaining a respectful workplace. People are encouraged to always be looking for forms of waste and then eliminating them if possible. 

Lean thinking has its roots in lean manufacturing and so several of the common forms of waste have titles that are associated with physical production, such as Over Production, Inventory and Transportation. However, versions of these wastes also occur in knowledge worker projects that are more commonly associated with manipulating ideas and information rather than physical goods. Listed below are the 8 common sources of waste and a description of how they apply to knowledge work projects along with advice on how PMOs can help reduce them. The forms of waste can be remembered by the relevant mnemonic DOWNTIME that stands for: 

1. Defects
2. Overproduction
3. Waiting
4. Non-Utilized Talent
5. Transportation
6. Inventory Excess
7. Motion waste
8. Extra processing  

Let’s look at each in a knowledge worker setting and see what PMO’s can do to help. 

1. Defects – Flaws in deliverables that create work to correct information. PMOs help project teams get things right the first time to avoid making defects. They can also help by providing extra tools and support when defects are found. Since Waste = Impact-of-defect X Time-defect-lies-undetected the timely resolution of defects is in everyone’s best interest. 

PMOs can also help address excessive defects by providing standards and quality control guidance and training.

2. Overproduction – Extra features or extra process that do not add sufficient value. We should always be asking “where is the next best dollar spent?” in other words, what should we do next to best add value.

PMO’s should reinforce this view by reminding people to ask: “Where is the next best dollar spent?” and avoid producing features or processes that are unlikely to be widely used or never completed. Likewise building things that are cool (resume architecture) or “might be needed” are forms of overproduction also.

3. Waiting – Delays for approvals, waiting for projects to start or resources to become available are all forms of waste. They cause people to task-switch which is inefficient and a contributor to defects. 

PMO’s should see if they can reduce waiting by scheduling a better alignment of project authorizations and start-up activities. Also, rather than waiting for team to form, consider bringing new projects to existing high-performing teams. Waiting delays strain learning loops as things get forgotten and it is better to seek out feedback early and apply it as soon as possible. 

4. Non-Utilized Talent – the waste caused by underutilizing people’s skills, talent and knowledge. Assigning staff to the wrong sort of tasks for their skills and experience results in a lack of engagement. PMOs should work closely with teams to determine not only what experience and skills people have, but also what they would like to try. Then working with projects leads to find a way to give people exposure to these new roles. 

Timeboxed iterations provide a great risk-limited approach for trying new roles and building new skills. If the new roles work out then great do some more, if it does not work out then we learned something and should now try something else. 

5. Transportation – In knowledge work projects unnecessary handoffs are like transportation waste. They create delays and slow down value delivery. Handoffs also always result in the loss of tacit knowledge. Like the Telephone game, when a message such as “Jon picked an apple from a tree” becomes “Joan licked Adam by the sea” after a few handoffs; details become lost in translation. 

PMOs can reduce transportation waste by eliminating unnecessary handoffs and ensuring information is gathered at source, not relayed through different groups. 

6. Inventory excess – This is partially done work that represents effort invested with no return yet. Generally, we should try to minimize work in progress (WIP) since managing that status of work and keeping it up to date gets in the way of doing other work. 

PMO’s can help by encouraging and supporting the transition from large batch flow (a single large specification document for a project) and a large analysis and design deliverables to small batch flow, for example just the requirements for the next two-week iteration. 

7. Motion waste – this unnecessary movement in the knowledge worker world often presents itself as task-switching. It occurs whenever we ask someone to stop what they are doing and work on something else. Team members working on multiple projects must task switch frequently. Each time they have to finish and mentally park what they are working on, move to the other project and reorient and then restart the activities they were doing there. Studies show a significant reduction in productivity and a dramatic increase in defect rates. 

PMO’s can eliminate task switching motion waste by first demonstrating the desired behavior within the PMO. Instead of having a dozen initiatives on the go at once with people splitting their time between them, prioritize and execute them sequentially. Having firsthand experience of increased productivity the group can more credibly help spread the word to project teams and into the portfolio and program planning activities that spawn so many simultaneous projects in the first place. 

8. Extra-Processing – This waste on knowledge work projects often takes the form of relearning. Poor knowledge capture leads to people having to go through the same pains and rediscovery rather than asking people who know. Other instances stem from poor instructions, and reassigning people too frequently. Finally, extra-processing can also take the form of overengineering a solution or demanding too high of a quality for the use of the product at hand. 

PMO’s can help by looking at the common questions they get asked or the common omissions they see on projects and then providing information and materials to address those shortcomings in future. Using the “Where is the next best dollar spent?” question can also help diagnose where overengineering and too high quality investments are being made. When you consider all the things we need to fix and where we are trying to get to, should we really be spending more time on X or working on some other initiative? These techniques and questions can help PMOs avoid Extra-processing wastes.

Take Aways

Lean thinking focusses on serving customers by adding value and eliminating waste, which is well aligned with PMO goals also. PMO’s can learn lots from applying lean thinking principles to not only increase the value of the projects they support, but also increase the value of the group itself.

Does this question sound familiar? If you get asked it regularly then you may be part of the mainstream transformation from software projects to products. It’s coming and it's going to turn many roles, certifications and in some cases entire companies on their heads.

The last couple of software projects I worked on were large, multi-year endeavors to build in-house systems that add competitive advantage for the sponsoring business group. It did not take multiple years to build the initial product, instead after delivery the business wanted more functionality, more integration, more automation.

The “When will you be done?” issue

The success and reliance on the new system bred further investment. The fact that business sponsors wanted to continue development was a good endorsement for the value being delivered. Yet there was a conflict at the steering committee level and PMO level. “When are you people going to be finished?” was the common question.

Answers like “never” or “when the business unit stops innovating and enters a decay phase” are generally not acceptable. Things are made worse by the teams being staffed, in large part, by expensive contractors. To the CFO or VP who does not use or see the benefits the system delivers these successful in-house products seem like make-work exercises or country-clubs for development teams that have become all too familiar with the business units they are embedded in.

This is not a problem, this is the future

However, we are not witnessing a problem, we are witnessing the future. Software is becoming more critical to business and projects are ending (or will never end) as we take more of a product vs project view of software.

This article aims to dispel the myth that agile projects somehow magical manage risks for us, and outlines a couple of practical tools that can be used to start improving risk management approaches. 

Agile is Not a Risk Management Approach

Some people believe agile approaches with their short cycles and regular feedback have a risk management approach naturally built into the process. It is easy to see why, the building blocks and attachment points for plugging in an effective risk management process are certainly present, but unfortunately just building something iteratively or incrementally does not ensure risks are managed. 

It is all too easy to develop iteratively missing opportunities to actively address threats or exploit opportunities. Many agile teams also fail to actively look for risks, discuss and decide on appropriate actions, undertake those actions and reassess the risks and evaluate if the risk management process is even working. 

It is a shame because in many ways agile methods provide an ideal framework for introducing effective risk management practices. They have short timeframes, active reprioritization of work, frequent review points, high team member and business engagement in planning, etc. However, similar to having a group of people to help you find something, “a beach-party is not the same as a search-party”. We need a conscious effort, coordination and cooperation to make it effective.

Consciously Adding Risk Management to Agile Approaches

The good news is, that when organizations and their participating teams decide to layer risk management onto agile approaches there are many self-reinforcing cycles and mechanisms to make use of. For instance, the frequent consideration of change requests and reprioritization of work in the backlog makes the insertion risk avoidance or risk mitigation tasks an easier process to handle. 

Likewise, the regular retrospectives that review progress and process are great points to examine the effectiveness of risk management strategies and take corrective actions. Daily standup meetings that surface issues and blockers can also act as early warnings for potential new risks, etc. 

For anyone interested in linking agile approaches to risk management steps, here’s a White Paper on Collaborative Games for Risk Management that was presented at the 2012 Agile conference and PMI Global Congress. These ideas and their development more into Opportunity Management were explored at this 2015 Agile Conference Session. However, the mechanics of doing the work and linking it into an agile lifecycle are the easy parts, getting people to take a risk-based view to project work is where the real work is needed.

Thinking about Risk Management

Education and acceptance are the keys to successfully adding risk management to agile practices. We need to get people engaged in the process and instill a common understanding of threats as the possibility of negative value. Once people understand this they can answer the question “Where is the next best dollar spent?” more effectively. It might not be on building the next feature from the backlog, but instead avoiding a risk or exploiting an opportunity. 

Disclaimer: This article is based on my personal experience of software project development work over a 25 year period running a mixture of local projects, outsourced projects and hybrid models. The data is my own and subjective, but supported by 1,000’s of industry peers I question while delivering training courses for the PMI. I do not work for a local based or outsourcing based company, I have nothing to gain from favoring either approach, but I hope these thoughts are useful for determining some of the pro’s, con’s, true costs and circumstances when outsourcing is better or worse than local development.

To the uninitiated, outsourcing seems like a great idea. Software engineers are expensive in many countries but much cheaper in other parts of the world. So, since software requirements and completed software can be shipped free of charge via email and web sites, why not get it developed where labor rates are much lower?

Coding vs Collaboration Costs

The flaw in this plan comes in the execution of it when it becomes apparent that software development projects typically entail more than just the development of software. Writing code is certainly part of it, but understanding the problem, agreeing on a design, discovering and solving unforeseen issues, making smart decisions and compromises to optimize value and schedule are big parts of it too. This is the collaboration effort part of a project. Also, while the coding part might represent 30-50% of the overall project costs, these shrink to 20-30% when a 3-year ownership cost view is considered that includes support, maintenance and enhancements.

Sticking with just development costs for now, let’s examine a scenario. The business case pitched to executives by outsourcing companies initially seems very compelling: Project Alpha needs 9 months of software development by a team of 5 people. If you work in an expensive labor market, like North America, we can assume fully-loaded hourly rates of $100 per hour, yet highly qualified consultants from our fictional outsourcing country of TechLand cost only $25 per hour. So, the project for 9 months x 160 hours per month x 5 people at $100 per hour in an expensive market costs $720,000. For a TechLand team this would cost 9mths x 160hrs x 5pl x $25hr = $180,000, that’s a cool $540,00 saving, right?

Let’s revisit this scenario based on the acknowledgment that the actual software writing part of a project is closer to a 30-50% of the total effort. This leaves the remaining 50-70% of the work as the communications heavy collaboration part. It should come as no surprise that separating people via distance, time zones, and potentially language and cultural barriers increase communications effort and propagates issues up the cost-of-change-curve. 

So, when 50-70% of the communication-heavy collaboration work takes longer, how do we quantify that? Agile methods recommend Face-to-Face communications because it is the quickest, conveys body-language and provides an opportunity for immediate Q&A only for the issues that need it. Switching from Face-to-Face to video, conference call, email or paper create barriers and adds significant time and opportunity for confusion. A 2-3 X increase in effort likely downplays the true impact when considering the costs of fixing things that go awry because of inevitable misunderstandings, but let’s use that number.

Redoing our project Alpha costs with, say, 40% as the actual coding effort and 60% effort communications heavy collaboration work that takes 2.5 X as much effort we get: 9mths x 160hrs x 5pl x $25 hr x 40% = $72K Coding + 9mths x 160hrs x 5pl x $25 hr x 60% x 2.5 = $270K Collaboration giving $342,000 in total. However, this is less than half the costs of the $720,000 locally developed project so we are still good, right?

The Compounding Costs of Delay

An error in the logic applied so far is that this 2.5 X communication and collaboration penalty on 60% of the work can somehow be magically absorbed into the same 9 month timeline. In reality these outsourced projects take longer because of the increased communication and collaboration effort and 2.5 x 60% = 1.5 X as long is consistent with my experience from 25 years of mixed local and outsourced projects.

Is it just me, or does Bimodal IT sound like a mental health condition? Unfortunate name aside, it has been adopted by companies reluctant to embrace agile but looking for a halfway-house / best-of-both-worlds solution.

In my last post I reviewed some of the issues I see with Bimodal IT; these include promoting a segregation of techniques when companies really need integration and recommending sequential lifecycles for complex projects. While it is easy to poke holes in ideas, it is more useful and rewarding to fix and improve things. So, let’s help organizations using Bimodal IT improve.

First, we should acknowledge the elegance of its simple design and understand why organizations are drawn to it. The simplicity of an If-This-Then “A”, If-Not-Then “B” approach is appealing and it allows companies to try agile-like approaches without making a full commitment. There is a refreshing clarity and simplicity in a simple two-way model. However, true to its namesake personality disorder, organizations using Bimodal IT exhibit large swings in the execution approach that are not natural or optimal.

Diagnosis: Tyranny of the OR vs. the Genius of the AND

In the book “Good to Great” Jim Collins popularized the idea of the “Tyranny of the OR vs. the Genius of the AND” to explain the problems of being forced to choose from alternatives and the potential in choosing a better third alternative – even if it takes more effort.

The “Tyranny of the OR” part describes having to choose from two seemingly contradictory strategies – either Mode 1 which is traditional and sequential OR Mode 2 which is exploratory and nonlinear. The “Genius of the AND” part refers to instead embracing both ends of the continuum and simultaneously making the best decision for the unique circumstance at hand. Most organizations are ruled by the tyranny of the “OR”, whereas Great organizations find a third way to satisfy both and leverage the Genius of the “AND”.

Jim Collins linked the ability to leverage “AND” thinking to high performing companies, but this third alternative or “Middle Way” has been around for a long time. I wrote about it in 2008 here, and my favorite quote relating to it is: “The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.” - F. Scott Fitzgerald.

Treatment: Mix Models, Engage the teams and Innovate

An example of applying the AND mentality to Bimodal IT would be to execute a couple of Mode 1 and Mode 2 projects and then get the teams together for an improvement workshop. We could ask them about their experiences and suggestions for cross-pollination of the best techniques. Maybe Mode 1 projects could benefit from a monthly Show-and-tell review of project outputs and planned work for the next period with the wider project community? Maybe Mode 2 projects would benefit from the development of RACI charts before distributing work between team members and part-time supporting roles?

I am not suggesting these are universal enhancements Mode 1 and Mode 2 projects, they are just examples of things that might be suggested. The real power of the process comes from getting people thinking about how to improve the process and caring about the outputs. Giving people input into how we undertake work and the ability to improve it moves them from un-invested-followers of a process to engaged-workers with some autonomy and say in how things get done. Guess which group enjoys their work more? Guess which group tries harder to overcome problems and deliver results?

I am in favor of using established and proven development approaches, they leverage good practice and help prevent common pitfalls. However, since organizations vary in function, organization and culture it is naïve to assume different companies should use the same one (or two) processes to execute their projects. The impacts of failure in air traffic control are quite different from pop-culture web sites and they should use different development approaches.

As Alistair Cockburn and Jim Highsmith have been saying for decades, we really need a methodology per project. Or as the Declaration Of Interdependance (DOI) say an approach that is "Situationally Specific". If this all sounds too hard or complicated it need not be. There are lots of free frameworks available to engage their team members in continuous improvement of their methodology. Doing so also increases ownership, support and engagement.

The continuous improvement model used could be one already in place at the organization or one that best fits with the mindset or culture. It could be PDCA, Six Sigma or Kaizen, they all share six common principles.

Summary

Gartner did a great job creating a framework that is appealing and accessible to organizations slow to adopt adaptive lifecycles. If they were to now follow it up with some guidelines for tailoring and evolution within organizations adopting it they would have a winning strategy for engaging participants and driving better results.

Gartner’s Bimodal IT approach has been gaining momentum for the last 18 months. It promotes the adoption of a twin track approach to methodology selection. In Gartner’s words “Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed.”

On the one hand I applaud any approach that helps bring the benefits of iterative methods and increased collaboration to organizations, especially those that have previously resisted them. On the other hand, I have some reservations with a model that polarizes guidance, categorizing projects into either traditional/sequential or exploratory/agility, when projects exist on a spectrum and the best approach is likely a smart mix of techniques.

It’s a Continuum Not an “A” or “B” Decision

If your project is simple, visual and being undertaken by a small, co-located team then an agile approach is likely a good fit. However, big, complex, embedded systems undertaken by large and distributed teams also benefit from an iterative approach to the early identification of risks, confirming true requirements and surfacing gaps in understanding.

Also, given the complexity of large systems, the chance of getting something complicated done right through a sequential process is very small. Likewise, we cannot expect a project manager to understand all the technology portions, project dependencies and estimation outliers. Engaging the team more through collaborative practices to better estimate, plan and identify risks produces much more robust plans. Then through the iterative approach of developing real, executable slices of the application, the validity of these estimates can be checked and refinements made to model the likely outcomes.

These benefits coupled with others around an increased sense of ownership and accountability by the team for having been involved more in the planning and ongoing steering of the project, I believe large complex projects need agile techniques more than small simple projects.

I am not saying large projects should be run purely with agile methods, they need additional layers of rigor and communication, but there are some great scaling frameworks like Disciplined Agile Delivery (DAD) that do this without losing the benefits of iterations, adaptation and empowered teams. However, Bimodal IT steers companies away from many of the tools ideally suited for large projects.

“Bargaining” is the Next Step after “Denial” and “Anger”

Change acceptance, like grief, goes through stages. The first stage is Denial, we refuse to believe this is real, is happening to us, or applies to us. Traumatic loss or change is often accompanied by a surreal, outside-observer feeling as we struggle to accept what has happened or is happening. At a level of significance down from trauma, denial is expressed as rejection. “Agile does not apply to me!” Next comes Anger “You can’t make me use agile! I have been managing projects with a sequential process for 30 years, and I will not change now.”

The next stage after Denial and Anger is Bargaining, where people try to avoid or minimize the impact of a change by making some highly visible or not really substantive bargains. For example, “OK, I will use an iterative approach, how about I make my iterations 6 months long?” Here, the resistor is negotiating or bargaining terminology “I will use an iterative approach when…” for an excuse to continue operating pretty much as they were before.

This is where I feel Bimodal IT resides and in part it explains its gain in popularity. It appeals to organizational leaders who do not really understand or believe in the benefits of an agile approach, but are under pressure to keep up with the times, offer agile projects to their teams, appear responsive to their business community. By publicly adopting Bimodal IT, they can push the small, trivial projects through an agile methodology - appeasing critics while clinging to their more comfortable traditional, sequential model. Since most organizations have significantly more small projects than large ones it may even appear that half or more of the projects being undertaken are Mode 2, agile projects when this represents only a small proportion of the project work being undertaken.

Simplicity Sells

People seem to like simple rules, even if they represent a suboptimal solution. The Atkins diet was very popular because a rule like “No Carbs” is simple and people liked that. Ask a nutritionist though and they will do two things, first they will explain that while it has some truth to it, the real makeup of good nutrition is more complex and varies depending on a large number of factors. The second thing they will do is to start explaining the large number of factors and either confuse you, send you to sleep, or make you wish you never asked them in the first place.

The same is kind of true for the best approach for developing software. Simple rules like Mode 1 traditional and Mode 2 agile-ish are appealing since they are easy to follow. However, like any restrictive diet, they are at best an over simplification and at worst are potentially harmful.

As an example Gartner states their Mode 1 approach that is traditional and sequential emphasizes safety and accuracy, but I would feel much safer and confident in a system where the highest priority features were developed first and have been reviewed and tested in every iteration since, than an approach that had lots of careful planning and then testing performed towards the end of the project. Iterations drive use and uncover missed requirements and defects. You can plan in detail and analyze requirements with reviews and tools – I spent 10 years of my software career working on very formal military projects – but, I believe the best way to discover if software works is by working the software.

Gateway Drugs

For me there is just too much wrong with Bimodal IT to recommend its use. It polarizes project selection when we should be looking more at hybrid models for large projects. It promotes more of a bargaining adoption of iterative methods and empowered teams than a serious acceptance of where these approaches can help all project types. Finally, it propagates dangerous sequential process models for large and complex projects that really need iterations more than small, simple projects.

If it has a redeeming feature it is that it could lead to the introduction of some iterative based projects, that then open the door to more agile projects, in organizations that had up until then resisted agile methods. I think Gartner should not end with the Bimodal framework, but use it as a foot-in-the-door primer for the Next Steps of continued evolution. So, while it currently has some use as a gateway or stepping stone to deeper thinking about project approaches, it should not be considered a destination for IS policy as it stands today.

Benefits are why we undertake projects. Projects are expensive to undertake and have a risk of failure. So, we need to get benefits from them, or at least think we will get benefits from them, to start projects in the first place. Often the benefits of a project are not fully realized until after the project is finished. This is why benefits management is usually the domain of program management. Sitting a level higher than individual projects and operating over longer timelines, programs are better positioned to identify, track and transition benefits from individual projects or groups of related projects.

Agile approaches place strong emphasis on delivering business value. Work is prioritized with the highest business value items done early and definitions of “done” that focus on acceptance rather than completion of work help ensure benefits are truly delivered. This aligns them well for benefits tracking and management, but there is more to understand to truly integrate agile projects with effective benefits management.

First let’s take a peek at the established world of benefits management. The PMI’s Standard for Program Management has three program phases: 

1.   . Program Definition
2.     Program Benefits Delivery
3.     Program Closure

 These are shown below along with a breakout of Benefits Delivery steps:

It is interesting to note that sub-steps 2 and 3, “Benefits Analysis and Planning” and “Benefits Delivery” are iterative. So we can see, program management is focused on the iterative delivery of benefits; which is what agile is all about so why do agile teams often face challenges from traditional project managers and PMOs? 

Thick Sandwiches

This is an aside, but a repeating pattern we often encounter is something I call the “Thick Sandwich”. It describes the situation where workers want to do the right thing and executives and senior managers want business benefits, but placed between them is a layer of middle management who, while well intentioned, tend to obstruct common sense and efficient delivery. So, engineers want to be useful, sponsors want products, but project management as a discipline aims to bring order, predictability, measurement and controls tend to gum up the whole process. 

Middle managers and their processes are created to optimize the process, add rigor and controls, but often just hinder the process. Lean processes (including agile) run up against this often. Agile is well aligned at CMMI levels 1 (Initial), 2 (Defined) and 3 (Managed), it also perfectly aligns with CMMI level 5 (Optimizing) that focuses on process improvement but runs afoul on the documentation and controls layer of CMMI level 4 (Quantitatively Managed). Here again the well-intentioned layer of rigor and control can act as a value delivery inhibitor if we are not careful.

I am testing demand for another Calgary based PMI-ACP Exam Prep course. Please let me know via email to Mike <at> LeadingAnswers.com if you are interested in attending a 3-day Calgary based PMI-ACP Exam preparation course. 

Evolution of the PMI-ACP Credential

I ran a couple of Calgary based PMI-ACP courses three years ago when the exam first came out. Since then the certification has grown in popularity from niche to mainstream with over 10,000 people now holding the credential. This makes it the most popular experience based agile certification and the credential of choice for hiring managers looking for the rigor of a ISO 17024 backed PMI credential. 

In October 2015 the PMI rolled out the updated version of the PMI-ACP exam, based on feedback from hundreds of existing credential holders and agile practitioners. The new Exam Content Outline has been restructured with the addition of a new domain “Agile Principles and Mindset” to focus on thinking and acting in an agile way as opposed to simply implementing agile processes and hoping for improved results.

My Involvement in the PMI-ACP Credential

I was a founding member of the steering committee that designed and developed the exam content outline. We based the exam on what agile practitioners with a year or two’s experience should know to be effective. We wanted a methodology agnostic credential that captured the agile practices used on most projects most of the time. The exam covers Lean, Kanban and agile methods such as Scrum and XP. 

I worked with RMC to write their best-selling PMI-ACP Exam Preparation book. I recently updated this book to restructure it to the new Exam Content Outline. The book is currently available for 30% off from RMC here and is also included in the course.

Details about the Course

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 9^th Avenue and has free parking. It includes the second edition of my book, colour printed workbook, sample exam questions, and USB stick of additional materials. 

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 express an interest and get pricing information please contact Mike <at> @LeadingAnswers.com.

Talent Management is the science of human resource planning to improve business value. It includes the activities of recruiting, retaining, developing and rewarding people along with workforce planning. From an agile perspective much of what we do on agile projects helps with talent management. We encourage empowered teams and give people autonomy over how they work which improves satisfaction and motivation. We also promote knowledge sharing through a variety of collaborative practices which reduce the impact to the team of people leaving. 

However, these measures only address some recommendations for talent management. This article examines the ideas and project implications of the other recommendations. First, let’s examine why talent management is important and understand the labor cost vs opportunity cost differential. 

Recruiting costs

If we lose a team member and need to replace them; a job posting needs to be created and sent out to agencies and online forums. We then need to sift through replies and come up with a short list of candidates to consider further. Next comes reviewing candidates with the project manager, arranging interviews, interviewing candidates (preferably with team involvement), following up on references, salary negotiations and hopefully finally hiring someone. I went through this recently for a developer on a software project and estimated the total time to the organization to be 64 hours. At an average labor rate of $80/hr that is $5,120. Had our first choice candidate not joined or failed reference checks the total time to hire would be much higher. 

Getting up to Speed Costs

A point often overlooked is not this initial hire effort, but the subsequent, much larger learning cycle before becoming a productive team member. A convenient Tayloristic view of management believes one developer can be swapped out for another. However, for a large, complex project it often takes smart, motivated individuals 3 months of learning to get up to speed with the business and technical domain and a further 6 months before they become truly productive. In these first 3 months not only are they not contributing to net new functionality but they are spending 50% of their time asking questions of other team members – slowing their output too. 

These costs are huge, assuming a fully loaded developer rate of $80 / hour (typical for North American software engineering) 3 months of not contributing and slowing other developers by 50% full time equivalent (FTE) costs: 3m X 4.2wks x 40hrs x $80/hr + 50%(3m X 4.2wks x 40hrs x $80/hr) = $60,480.

Follow this with 6 months of increasing capability going from 0% productive (no longer a net drain) to 100% productive (up to speed) we can use an average figure of 50% non-productive so 6m x 4.2wks x 40hrs x $80/hr x 50% = $40,320 

So, the cost of losing a team member and having to recruit and train another could easily be $5,120 + $60,480 + $40,320 = $105,920. However it gets worse, whenever a high performing team loses a team member they move from the Tuckman “Performing“ phase to the ‘Storming” phase again as the team dynamics change and have to get back through “Norming“ to “Performing”. 

Psst, this is your conscious, I am here to remind you about something you have thought about, but then hid away in the back of your mind. Lots of this agile stuff is hypocritical, it preaches evolution and change, but then we ask the same old three questions at standup every day. Also, why must we have standup every day, isn’t that kind of prescriptive? Agile methods are supposed to facilitate innovation through iterative development followed by inspection and adaption. They practice the scientific method of measurement and feedback on products and team work; so why are the agile practices themselves magically exempt from this precious evolution?

I believe there are two main reasons; first off, it is to protect inexperienced agile practitioners from themselves. With a free rein to morph product and process there is a strong likelihood that by six months into a project the practices followed by the team would have deviated from the proven and tested methods of most successful teams. The risk of failure would increase and every project in a company would be using a radically different approach making integration, scaling and team member transfers a major problem.

The other reason is a little more sinister. Most of the creators, proponents and promotors of agile methods have interests in keeping the methods pure vanilla. This is so they can create training courses, certifications and web sites for them. While scrum, as one example, has its specialized ceremony names and products you can neatly market services for it. If you allow or encourage people to change it then the result is not so proprietary and more difficult to defend, promote and assert ownership over.

I am not suggesting we should be changing agile methods willy-nilly, I think a basic suggestion to try them out-of-the-box for a couple of years is sound advice. However, beyond that I believe there are great opportunities for growth and deviation outside the standard agile models for stable teams who want to evolve further. This article tells the story of one team that did just that and what other people can learn from it.

Agile methods like XP, Scrum and DSDM have been advocating co-located teams in open plan offices now for 20 years. The idea being that since face-to-face communications are the fastest and most efficient, teams should be established to work this way whenever possible. Also, software projects, where agile methods started from, build intangible, often new and novel solutions to problems; as such there are lots of opportunities for miscommunication about how these new systems should look and work. Having people working together makes it easier to surface these misunderstandings, collectively troubleshoot problems and collaborate on new solutions.

However co-location is not always possible and open plan offices can suffer from “noise pollution” and frequent interruptions. The following infographic was created by a Voice Over Internet Protocol (VOIP) provider so probably has some selection bias, but importantly draws its findings from over a dozen respectable sources including articles from Bloomberg, The Guardian, the Wall Street Journal and Fortune.

My presentation outline “Eat Risks for Breakfast, Poop Awesomeness All Day!” was accepted for the Agile 2015 Conference in Washington D.C., August 3-7. As much of the agile community seems engaged in scaling debates I am really happy to share some useful tools that can be used on any project, regardless of approach.

The learning objectives for the session are:

• See why project managers are the least equipped to effectively identify and manage project risks.
• Learn engaging ways to educate team members about risk management including identifying threats to avoid and opportunities to exploit
• Preview 5 collaborative games for effective threat and opportunity management from planning and identification, through management, to reporting and closure
• Understand the untapped potential of an increased emphasis on opportunity management
• Review case studies of projects teams that have been using these practices for three years and are achieving measurably better results than teams that do not

My other workshop submission for the Agile 2015 Conference is titled “The Evolution of Teams” and examines one team that stopped doing the traditional agile practices is more agile than ever.

Agile practices such as daily stand up meetings, sprint planning and retrospectives are great tools for encouraging team members to share information, collectively make decisions and improve. However, how do you maintain active participation for long periods without burn-out or boredom?

As companies recognize the productivity of high performing teams and bring new projects to established teams rather than disband and reform teams, how do we keep things fresh? My session is a case study of an award winning agile team that has been delivering projects for over 7 years. It examines how the original core practices that are familiar to any team starting agile have evolved into new practices while honouring the original values and goals.

A casual observer may be concerned: “What, no stand-up meetings, sprint planning meetings or retrospectives? You guys are not agile at all!” However teams can be agile without doing the traditional agile practices. Agility, after all, is a mindset not a To-Do list, and this session introduces the practices of “Show-and-tell”, “Tech-talk” and “Sense-Pull” amongst others.  They may not work for your team, but show the journey of one team’s progression through adaptation and refinement of process. (Along with all the bumps, set back and mistakes made along the way too.)

If the presentation gets accepted I will share the main topics of the session here for feedback before delivery.

I have submitted a presentation for Agile 2015 Conference about team based risk and opportunity management that may well get rejected based on its title alone!

It has always been a good practice to engage team members in the estimation process; then agile methods taught us how teams should do the local planning and decision making too. So it should come as no surprise that the best people to undertake effective risk management are team members. They possess the best technical insight and are closer to any execution issues than team leads or project managers.                                               

However, risk management as tackled by many organizations, is academic, boring, seemingly removed from real-work and it often ignores the maximization of positive risks (opportunities). My proposed workshop demonstrates how to turn teams into risk-consuming, opportunity-chasing beasts that that leave a trail of business value and delighted stakeholders.

At the Agile 2012 Conference I presented a session called “Collaborative Games for Agile Risk Management” that introduced fun, team based games to engage the team in risk and opportunity management. In the intervening years many teams have adopted these techniques and become much more effective at Risk Management. However it turns out I was focusing on the wrong end of the lever, the big news are the results teams are getting through Opportunity Management.

Teams using these approaches are not only driving out risks, but more surprisingly, building great inter-organization alliances, being given free passes on bureaucratic process and generally having an easier go of things. At first I was surprised at all the “good luck” these teams encountered but then I saw how small adjustments in team behaviour were being made towards freshly identified opportunities.

A little like the 18^th Century discovery linking germs to infections that gave rise to the introduction of hand washing in hospitals increasing survival rate dramatically. Putting teams in charge of opportunity management leads to changes in day to day behaviour that dramatically increased the execution effectiveness and success rates of their projects. 

Good leaders know the value of a powerful vision; it “Reveals a beckoning summit for others to chart their own course”. In other words once we know what our true goal is we can make our own micro adjustments. Getting teams to own opportunity exploitation causes them to behave differently and benefits start occurring all over the project.

My session proposal outlines the practices and reviews case studies so you can equip your team to be risk-consuming, opportunity-chasing beasts that leave a trail of business value and delighted stakeholders. However if the mental image of eating risks for breakfast and pooping awesomeness all day is too graphic to share in your organization, maybe a machine that harvests risks and opportunities and outputs business value is an easier sell, but not as much fun.

Related articles

"Solving Today's Complex Projects with Agility" Presentation

Next week, on February 18^th, I will be presenting on “Solving Today’s Complex Projects with Agility” at the Society for the Economic Promotion of Gran Canaria (SPEGC), co sponsored by ITProiectus. I have been working with ITProiectus for a while but this will be my first time to meet them and I am really looking forward to it.

The presentation will explain how today’s complex problems can be solved by collaborative teams that  better handle ambiguity than traditional plan-driven approaches. I will review some of today’s wicked project management challenges and show how agile methods, while they look deceptively simple, actually harness sophisticated approaches for generating consensus and driving towards high quality solutions. 

Scaling Collaboration not Process is the Key to Enterprise Agility.

Agile methods have been found to be extremely effective when used correctly. A reasonable reaction to witnessing any great performance in an organization is to demand more of it. So a tremendous amount of time, effort and resources have been expended over the last few years on scaling agile for the enterprise with all the new processes and models that can go along with that. 

I admire a lot of the work done to scale agile methods in the attempt to replicate the success of the initial `golden-teams` to all groups in an organization. Unfortunately these roll out attempts largely result in disappointment or failure because the investment and effort has been applied in the wrong place. It is not process we need to scale and duplicate, it is the art of collaboration.

Agile methods are successful when they equip motivated subject matter experts to collaborate in an effective way with minimal process overhead. In attempting to make agile methods scalable, it is tempting to add more process to assist larger scale coordination. However that is the last thing we should do. Not that we don’t add more process, just that we add it last, not first, after you have replicated and established collaboration models. Adding process first kills collaboration and then even the best intentioned and resourced development environment is doomed.

This phenomenon of process stifling smart behaviour was identified by Dee Hock, former CEO of Visa who said: `Simple, clear purpose and principles give rise to complex and intelligent behaviour. Complex rules and regulations give rise to simple and stupid behaviour.` The real path to scaling agile successfully is not choosing a scaled framework to implement, but focussing on replicating good teamwork and collaboration models and then adding minimal process.

The trouble is process and tools get all the press because they are more tangible and easier to describe. Plus vendors can promote and sell frameworks more easily than teamwork advice since they are proprietary and more marketable. So, a bit like diet pills and fitness gimmicks, we see more coverage of quick fixes that don’t really work than good (but less flashy) basic nutrition / teamwork advice that actually does work.

This article is less about agile techniques and more about the people related challenges of today’s agile projects. As work switches from industrial work to knowledge work, companies face a perfect storm of employee engagement and retention issues. On the one hand the time taken to learn a job is increasing as domains become more complex and new tools add layers of abstraction and integration problems. On the other hand the average time spent in a job is decreasing. Frequent job changes are now the norm and long term workers are a rarity. Two years is the new five years average tenure and six months is the new two years of young worker average placement. It may seem just as people become productive they leave and the training process has to repeat.

An additional problem is that it is often the best people who move on, since they are sought after by more organizations and there is now less stigma with short work assignments. Companies not paying attention to their workforce or offering appealing work environments find themselves subject to an involuntary Sedimentation-Effect as the best float to the top and depart leaving less capable people behind. The process has been accelerated by social media and online job sites that make finding good places to work and connecting strong candidates to great companies easier than ever.

Things are not going to get better any time soon either, as Baby Boomers and Gen X workers leave the workforce Generation Y and Millennial workers are entering the market place in increasing numbers and with new expectations. Paul Harvey, a University of New Hampshire professor says that Gen Y and Millennial workers “…have unrealistic expectations and a strong resistance toward accepting negative feedback" and "an inflated view of oneself." 

It is not all doom and gloom though; fortunately agile projects provide ample opportunities for tuning the workplace for better motivation and retention. Bill Pelster, principal of Deloitte Consulting, suggests that “Organizations need to understand that the world of work is changing. What millennials want — innovation, opportunities to grow and develop, mentors — aren’t overly demanding. They’re what every organization needs to succeed. All generations generally want what the millennials want, but what is different is the priority placed by millennials on development and core values versus, for example, a safe and secure job. Millennials are more inclined to take risks and change jobs much more quickly than other generations.”

In fact there are a number of things companies and managers can do to attract and retain the best talent.

Leaders, not managers - Forget trying to manage people, that’s too command-and-control and reactionary to cope with today’s speed of business changes, nor is it engaging. Today’s teams want leading. This involves communicating a vision of the desired end state, clearing the path of obstacles or bureaucracy, and providing mentorship with support.

There is a useful paradox that helps remind us of the leader role “We lead people by standing behind them” i.e. we back them up, provide support, encouragement, training and mentorship. Let them take any praise or glory and be a close, but in the background, supporting player.

Problems, not tasks – humans are hard wired to get a buzz from problem solving, that’s why many people play video games and do Sudoku puzzles in their spare time. Tap into this motivator and present the project’s goals as problems, don’t try to manage them away into tasks. Let the team see all the complexity then ask or challenge them to solve the project problems.

Engaged, self-organizing teams are incredibly resourceful and creative. The traditional model has solutions being designed by a small group of specialists and then selling the selected approach to the team for implementation. Agile leaders instead invert the model and engage the team in solutioning and have them “sell” their approach back to the project managers and business champions for approval.

This higher level of engagement builds a much stronger commitment to deliver and remove obstacles encountered along the way. It also taps into people’s reward mechanism of problem solving and helps build everyone’s sense of achievement rather than drudgery. Obviously some work will always be dull and we just have to grind it out, but that should be the exception not the norm.

Say “Yes” to time off requests – “kids school play”, “camping trip”, “whatever”,  if someone has enough of a reason to not want to be at work, especially contract staff who do not get paid when taking time off, why make them feel bad about asking or turn them down? The good-will and appreciation for having a flexible working environment ranks high among high achievers. Most people recognize when they have good working conditions and the small cost of reduced capacity is more than made up for by the benefits of retaining the best workers, reduced recruiting and training, etc.

Obviously if anyone abuses this goodwill guide and finds reasons not to work on a regular basis then there needs to be a separate discussion. Failing that I have only seen upsides from providing a very flexible work environment.

Leverage improv comedy’s “Yes, and…” – Responding to someone’s plan or suggestion with reasons why that won’t work here, or the famous “OK, but what about …” is demoralizing. “OK, but“ is often a thinly disguised “No” and after a series of these, people just stop suggesting ideas, shortly followed by stopping caring.  The first rule of improve comedy is build on ideas, not shut them down; it is the same with team work and co-creation in the work place.

So, if someone suggests an open house to demo the new system to customers, we can reply “Yes, and if we do a dry run with our business group first, we can iron out any kinks”. “Yes, and” promotes ideas and involvement rather than stifling them. We can always edit and improve plans later, but if the best suggestions never get made for fear of ridicule, no refinement can ever wish them into being.

Since collaboration and teamwork are so critical on knowledge worker projects, many forward thinking companies are looking to Improv training to help their employees. See these Forbes and FastCompany articles for more information.

Keep perspective and stay calm - remember our project issues are definitely first-world problems, a broken promise, buggy release, missed demo, or poor estimate are not worth getting truly upset about. Save the drama for where it is warranted, work compassionately and objectively.

Create projects, not roles – drawing from Deloitte’s Bill Pelster again: “It is important that organizations realize that millennials are looking to constantly gain new experiences and push their development. This means that organizations need to think through the velocity of developmental opportunities and the potential need to “re-recruit” millennials on a regular basis. Failure to do this will potentially lead to higher than expected turnover and more pressure on your recruiting organization to constantly source and on-board new talent.”

We can frequently re-recruit staff through exposing them to new projects with new problems to solve. Align people with key projects and mentors so that they are challenged and have an accelerated growth experience. This is good for the organization and their employees.

HippySh*t or Solid Sense?

To some people these recommendations may seem like indulgent panderings to a soppy workforce of over-entitled layabouts. They may seem to be overly generous, but the world is so connected now it is easier than ever for the best people to find good work. If your company undertakes industrial work involving the repetition of established process, you likely do not need the best and most talent workforce; instead reliable and cost effective staff are the way to go.

However if you are in the knowledge work space of solving novel problems then attracting and retaining the best staff you can is not a company differentiator, but the minimum required to stay in business. The suggestions outlined above, and others besides, do not replace standard work. Instead they get woven into our normal behaviour for leading teams, hopefully to effect subtle shifts towards a more desirable work place that retains the best talent and attracts more of the same.

The economics of compassion and empowerment might not sit easily with everyone from my generation. Like many people, I worked in junior, menial roles for decades before being given any opportunity to influence. But as the saying goes “If you don’t like change, you’re going to like irrelevance even less”. So, the question becomes what can we learn to stay up with the wave of change if we want to succeed?

Even though Mickey Mouse is the symbol of Disney theme parks he is not really what these locations are about. Agile methods are similarly known by their novel processes and team ceremonies but these are largely irrelevant distractions from the true focus.

Just as Disney is all about manufacturing a positive visitor experience through detailed buildings, social engineering and extensive staff “character” training; agile methods are really about creating a social framework where effective work can be accomplished. This social framework will vary from project to project and enterprise to enterprise. It is a problem solving exercise like building a custom galley kitchen inside a boat not a standardization exercise like force fitting IKEA kitchen cabinets.

I realize that by using analogies to Disneyland and IKEA so early in an article many readers may assume I have finally lost the plot but after 20 years of practicing agile I have had enough with rote methods implementation and attempts to scale through process training that fail. To me agile is about process as much as Disney theme parks are about Mickey Mouse. Yes, they are an easily identifiable symbol, a short cut to identification, but far removed from what the real focus is.

In fact Mickey Mouse cartoons kind of suck and most people would be hard pressed to think of a good one. However, luckily for Disney that is not the point, their real goal is to capture imagination and allow people to explore fantasy environments while spending lots of money, hopefully as part of a pleasurable experience so they will come back and also tell their friends.

Agile methods aim to shorten the time to value and build high quality, positively received products or services by intelligently adjusting behaviors and employing good construction practices. The activities commonly used to do this include:

Sense making – agree information gathering steps and prioritize exploratory work

Short Build / Feedback cycles – iterate through short cycles of Planning, Exploring, Learning and Adapting

Conesus gathering - collaboratively gain consensus on direction, approach and decisions

Prioritization – build mindful to risk reduction and business value

Results oriented reporting – use metrics based on accepted work that give meaningful indicators to likely completion rates

Respect and empowerment – engage in respectful practices that encourage information sharing and organizational rather than personal optimization

None of these things say we need two week iterations, retrospectives or daily stand up meetings. Those tools are suggested practices to start encouraging some of the right behavior, but pursuing them or measuring them misses the real point. Companies that attempt agile transformations through process training typically fail and it is like assessing a Disney theme park by asking “Does everyone have their Mickey Mouse ears?”

I am lucky to work with an agile team that has been together for 7 years. Not that it has taken us that long to finish a project, but instead the business sees the benefits of a high performing team and keeps bringing us new projects to undertake.

[The whole idea of bringing projects to established high performing teams could be the subject of another post . Instead of creating new teams per project and going through the Tuckman stages of Forming, Storming, Norming then hoping to get to Performing, using existing high performing teams bring many benefits.]

The team is the best I have worked with and won a PMI Project of the Year award for the first project they completed. Yet I cannot remember the last time we had a stand up meeting or retrospective. We dropped two week iterations in favor of a continuous pull of features and use cycle time in lieu of velocity or detailed estimation based on points or days. So is the team still agile? An outside observer looking for process or ceremonies might say No; I would say You Betcha! The team embodies the sense making, iterative, consensus driven concepts implicitly. Techniques like prioritization, results oriented reporting and empowerment are baked into every conversation and action.

It would feel weird to wait until the end of a sprint to discuss adaptation of process. In fact the notion of a sprint seems an artificially restrictive and wasteful construct to manufacture. Inter team communications are too important to wait for a daily stand up meeting and team members get an equal say in decisions and spend lots of time in healthy debate, both face to face and with remote team members.

The set up is not perfect and still has room for growth. We could do better at interacting with other groups and our tendency to “fly-under-the-radar” to avoid delays for approvals from other groups also means we miss opportunities to share success stories and spread effective practices to other departments as well as we could. Yet on the whole the group is very effective.

Skills acquisition is often described using the “Shu”, “Ha”, “Ri” progression. In this model new practitioners start with obeying the rules (shu, which means to keep, protect, or maintain), then consciously moving away from the rules (ha, which means to detach or break free), and finally unconsciously finding an individual path (ri, which means to go beyond or transcend).

My point is that agile is not process following. Success is not methods replication, it is not really gaining an agile mindset either, that’s too insular and individual; instead it is creating a working ecosystem for your environment. The ecosystem may have activities that could be labeled as “processes”, but true processes are designed to resist change, they are like robust pipes that force compliance on items that vary. Activities and behaviors are more open to change and support it where it makes sense.

There are some popular tests to gauge if a team or project is truly agile. The Nokia Test and the Scrum Test are good starting points but they still ask if ceremonies like daily stand ups and constructs like iterations exist. These questions miss the true intent of these practices and bring focus to the process. Yet the process is not important and may/should change over time as a team develops, or be adapted to better suit a client. So it is better to separate the process from the behavior we are really trying to assess.

The following questions do not dictate what process to use but look for signs of a healthy, productive project environment.

1. Does the business value what is being delivering and want to continue with the same group?
2. Is the team still improving and learning as it works?
3. Are the increments of delivered work frequent and of a high quality?
4. Is the project ecosystem healthy?
5. Is the system receptive to change?

Thinking of behavior and capability rather than process conformance will help organizations deploy and scale their agile adoptions. It might be easier to measure process adoption than underlying competency, but like associating Disney with Mickey Mouse it is not really about the process.

[I first published this article at ProjectManagement.com here]

Scaling agile is a hot topic these days. Frameworks like LESS (LargE Scale Scrum), SAFe (Scaled Agile Framework) and DAD (Disciplined Agile Delivery) are in the limelight as too are companies training up ‘’Agile Transformation Consultants’’ to transition entire organizations to agile. However, successful scaling is not easy, it is one thing to put a company through a week’s worth of training and mentoring, but another completely to make lasting changes to working practices and resolve all the issues that get surfaced along the way.

 The logic is simple, when executives see a successful agile project their initial thoughts are often: “Great, let’s do more of this!”, yet the solution is complex. Solving the simple question of “How do we reliably duplicate exemplary performance?” is anything but simple.  Moving from one or two successful agile projects to transitioning an entire organization to use agile methods is a challenging and daunting task.

Factors such as people who do not understand the problems with current practices and a lack of agile thinking are difficult issues to overcome. Strategies for transforming an organization to agile vary. Some favour a top-down education process, others a bottom-up, grass roots initiative.

Should the approach be Buddhist (teach the principles and allow local adaptations) or more like Catholicism (everyone must follow a strict standard protocol)? Insights into these concepts of scaling up agile can be found in the book “Scaling Up Excellence: Getting to More Without Settling for Less” by Robert Sutton and Huggy Rao. 

The authors describe this Catholic vs Buddhist split along with strategies for bridging the two. The In-N-Out Burger chain popular in California takes a very Catholic view to replication where common practices are replicated with very little deviation. This is akin to proclaiming all teams will follow Scrum by the book. The KFC food franchise on the other hand, allows lots of local customization and sells egg tarts and soy milk in its stores in China that are not offered in other countries. This is like explaining the agile manifesto values and principles and allowing variations in team implementation.

There are times when the need for local uniqueness is obvious. Stanford researches tracked a software company who opened offices in Silicon Valley and India. The Silicon Valley offices had bare concrete floors and rough unfinished surfaces to provide a funky, urban-contemporary look. Yet in India rough finishings send a different vibe and some locations have more dust and are impractical for women wearing long saris that quickly get dirty as they drag along the floor. So the company quickly dropped its Catholic approach and installed carpeting.

There are also times when people can suffer from “delusions of uniqueness” when they think they are “special” or more unique than they really are and miss out on some improvement. Brigham and Women’s Hospital had very high rates of doctor customization occurring in its selection of joint replacement products despite no evidence suggesting these new products were any better. It seems doctors just enjoyed trying out new technology - a problem common to many industries.

It is possible to bridge the two poles of Catholicism and Buddhism by using swappable sub-assemblies. Like reusable chunks of Lego, these proven successful components can be used to quickly get the benefits of some standard process while allowing for local customization.

In an agile setting this could be as simple as moving the 9:00am Stand-up meeting to 11:00 to ease co-ordination with a West Coast team, or more sophisticated such as swapping iterations for a continuous pull of features via kanban and DevOps in a high change environment.

When discussing the top-down education or bottom-up change, Sutton and Rao assert that success comes from a ground war not just an air war. During World War 2 commanders often called in bombing raids with the hope of devastating the enemy. Unfortunately only 20 percent of bombs dropped fell within 1,000 feet of their target. More recently with the advent of GPS and laser targeting it is easy to think air wars are now effective. However a review of NATO’s seventy eight day air war on Serbia to stop ethnic cleansing by Slobodan Milosevic concluded it was “a major blunder that the use of ground troops was ruled out from the beginning’’.

All the research and case studies in Scaling Up Excellence find that “Scaling requires grinding it out, pressing each person, team, group, division or organization to make one small change after another in what they believe, feel or do.”

Air assaults are often useful first steps, but are rarely long term solutions. More often, territory must be won inch-by-inch working through issues as they are encountered. This requires persistence, lots of work and slow progress to reliably instill a new way of thinking and working.

For these reasons we should be wary of “agile transformations” that claim to transition an entire organization over a 2 week or 2 month period. This is more akin to an air battle. Yes, maybe everyone in the organization was exposed to some agile training and this is a necessary step, but true understanding and adaption only come through use, failure, learning and growth which take much more time.

Before planning to scale agile (or any other approach) discuss the “Catholic vs Buddhist” and “Air-war vs Ground-war” concepts with those who will be engaged in the rollout. Learn to detect Delusions of Uniqueness and employ Lego Bridging Strategies. These techniques can avoid “Clusterfugs” - an enterprise friendly word used to describe a poorly received transformation and instead can pay huge dividends.

[I first wrote this article for ProjectManagement.com here]

On May 5^th I will be presenting at the PMI-NAC Conference on the following topics:

1. 21^st Century Risk Management: Supporting mathematical analysis with social influence
2. PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches

I am looking forward to the event and will share thoughts and feedback on the sessions here afterwards. Until then here are the presentation outlines:

Presentation 1: ”21^st Century Risk Management: Supporting mathematical analysis with social influence”

Today’s complex projects need proactive risk management to stand any chance of executing successfully. Yet, all the steps of: identifying, classifying, analyzing and prioritizing are for nothing if the risks cannot be effectively avoided, transferred, or reduced. These risk avoidance and reduction steps are largely human led activities with success criteria closely linked to social influence.

While the project manager is key to project co-ordination and success, they are rarely the domain experts and instead bring subject matter experts (SMEs) together to collaborate on novel solutions. These knowledge worker projects require a whole team approach to not only risk finding, but also risk resolving.

This session explains the need for proactive risk management and the importance of social influence on risk management. Using case studies, a team approach to risk management to collaborative workshops, new risk visualization techniques, and examples of team risk avoidance and risk mitigation actions are examined.

Presentation 2: ”PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches”

Agile, lean and kanban approaches are a part of the new project delivery toolkit, especially for projects with IT components. The PMBOK Guide v5 published in January 2013 now describes a lifecycle spectrum spanning “Predictive, Iterative & Incremental and Adaptive” approaches. The new “Software Extension to the PMBOK Guide” expands this model with further agile related guidance for project execution.  Gartner Research claims 80% of today’s software projects employ agile methods. So, is your PMO living in denial, or simply living in the past?

Fortunately, a new class of PMO has evolved to support a dynamic mix of traditional, agile and lean project approaches that we can learn from. Using case studies from award winning PMOs, this presentation examines how proactive organizations are tracking diverse project types with common metrics and enablers.

Virtual teams may well be the next step-change in the evolution of work. So it is interesting to ask if today’s management principles and processes are optimized to support them? To help answer this question let’s take an illustrated tour of work through the ages and also review how management has progressed along the way.

Work patterns have evolved through revolutionary and evolutionary waves. Some have brought major, irreversible shifts; others step-changes and refinements. Tens of thousands of years ago population densities were generally low as people worked at farming, fishing and still some hunting and gathering. You needed space to do this and too much local human competition was not helpful. Then, as crafts, trading and specializations emerged towns became useful hubs for exchanges and population patterns changed. Access to fresh food sources was still a major concern, but trading and money allowed for easier centralized living.

These were slow, likely imperceptible advances, quite unlike what happened next with the Industrial Revolution of the 1800’s. People were needed to work in factories and a major migration from rural to city living occurred within decades. Factory funded schools began focusing on time keeping, discipline and following instructions to better condition children as future workers. The Victorian work ethic promoted by many leading entrepreneurs was a useful conditioner for taking farmers, who were used to working following the daylight hours and seasons, and adapt them to a regular 7:00am to 7:00pm work days favored by factory owners.

How industry shaped cities is also an interesting topic. Steam engines where large machines that could only transmit power via shafts and belts over relatively short distances.  So early factories were tall, square buildings to maximize machine capacity within close reach of the steam engine. Electrification made power easy to transfer and factories became long, low structures that were cheaper to build and required less lifting of materials. As work patterns evolved so too did our industrial complexes from tall to sprawling.

Shown below is a picture of the moving production line at Henry Ford’s Piquette plant completed in December 1913.  This approach to manufacturing, generally known as progressive assembly, heralded a major increase in productivity that was adopted by most manufacturing industries. It was inspired by the time-in-motion studies done at the Bethlehem steel plant by Fredrick Taylor which showed increases in efficiency for specialized labor. Ford was the first to employ moving production lines and specialized labor on a large scale to increase productivity and drive down costs.

Photo Courtesy: Ford Motor Company

We still see examples of these decomposition principles today when software project work breakdown structures reduce complex systems into small components and assign “Developer 1” and “Developer 2” type resources.

The next photo shows the Tesla production facility at Freemont California.

Photo Courtesy: Tesla Motors

The Tesla factory has a rich history of manufacturing and management evolution. Starting out as a General Motors Freemont Assembly plant in the 1960s it embodied the modern interpretation of production line thinking. A downside of working in a specialized labor role in a highly mechanized environment can be a feeling of being a machine yourself and the plant suffered many worker disputes and union clashes during the 1970’s and 80’s. There were reports of deliberate protests and cars being sent out with Coke bottles in the doors to rattle and annoy customers.

Relations broke down and the plant was closed in 1982 only to be reopened in 1984 as a joint Toyota / General Motors plant known as New United Motor Manufacturing Inc (NUMMI), rehiring many of the same disgruntled workers. Toyota introduced lean manufacturing processes including respect for staff and empowered workers to stop the line if problems were encountered. The Japanese / American relations during these transition years created many stories and was the motivation for the comedy movie “Gung Ho” that Toyota later used in training sessions of how not to motivate American workers.

The switch from traditional manufacturing using production lines and large inventories of materials and sub assemblies to lean, just in time (JIT) production systems was driven by new philosophies of management. Lean and JIT techniques follows the work of James Womack, Peter Senge and Eli Goldratt who reposition management from schedulers and task masters to identifiers and removers of impediments to workers. They encourage and reward team problem solving and promote continuous improvement.

As capitalism and the pursuit of labor cost reduction continued, many manufacturing plants moved to cheaper labor markets. North American and other previously industry focused countries saw a rapid drop in local production. In their place however we saw an increase in design, finance, research, health and education services. This was the birth of what Peter Drucker called the Knowledge Worker – professionals with subject matter expertise that work together to solve new or novel problems.

These three big shifts in work are shown below:

Picture Courtesy: www.LeadingAnswers.com

In 2009 the joint venture between GM and Toyota at the NUMMI plant ended and neither company could find a suitable use for it. In 2010 Tesla, then a startup Electric Vehicle research and development company struck a deal with Toyota and bought the 380 acre site previously valued at $1Billion for just $42M. Toyota also invested $20M in stock of Telsa and some of the Toyota staff were rehired as more traditional industrial work gave way to newer exploratory knowledge work.

Agile methods are very effective for knowledge worker projects. They provide Sense-Making activities for gaining consensus from diverse stakeholders during the early stages of projects where uncertainty is high. They also provide tools like short iterations of build / feedback cycles to help reduce risk, prove approaches, and surface deficiencies in designs when tackling novel problems or using new technologies. Finally, they have process adaptation and goal seeking reviews built into their operation that helps teams refine their approaches and work more effectively.

Yet the changes have not stopped. Now with the widespread adoption of email, video conferencing, real-time chat and an emerging workforce who “grew-up-digital” and fully embrace these technologies, virtual teams are poised to revolutionize work once again. We just discussed the car industry, but it is telling that for the first time ever fewer teenagers who are becoming eligible to drive are buying cars, the cost of ownership is perceived as too high, but don’t try and take away their smart phones! Maybe since communications are so easy and prevalent, texting your friend is easier than driving to see them?

One thing for sure is that talent is distributed and technologies for finding and linking teams is improving rapidly. If I want a logo designed or web site built I can log onto a freelance site like Guru.com or Elance.com and access a global marketplace of talent showing examples of their work and hourly rates. Escrow services exist to ensure work and payments occur fairly and help with arbitration if the need arises. Or, if I want a custom door handle or even a titanium bicycle I can download the design and print it in my home or at a local 3D Printing shop.

What these technologies mean to how we work and live in the future remains to be seen. Alvin Toffler wrote about the “Electronic Cottage” in his 1984 book The Third Wave that describes people living where they want in a future paperless society and communicating electronically. Many of the technologies we need for wide scale virtual teams working are in place but we need to overcome the C.U.T.E. problems:

• Communications – how do we meaningfully communicate complex issues across geographically dispersed teams with different languages, time zones and cultures? How do we clearly articulate requirements, issues and feedback in universally understood ways?

• Unity – How do we instill a sense of team in people who have never physically met? Why would people be motivated to go beyond their regular roles to help out people they have only seen on a computer screen? Remote working is easier with people we have previously worked with physically, but such relationships may be the exception in the future.

• Trust – How do we build trust that people are working when remote? How do we strike the balance about remote work monitoring tools and trusted, empowered teams? How do we overcome differences in laws and ethics on a world scale?

• Economics – How do we fairly compensate team members based on their skills and contributions? How do we effectively price, tax, invoice, collect payments and pay contributors on projects that may only take days or hours to perform?

The building blocks of each solution are already available. Video conferencing with real time translation, peer based endorsement networks, community voting, and bitcoins all might play a role. However what about our project management tools? Where do Microsoft Project plans, PMBOK Guides and Stage Gates fit travelling at the speed of trust?

In a poetic twist of fate, just as Victorian classrooms were engineered to condition children to the discipline of working in textile factories, maybe the Instagram, Facebook and text messages of today’s school children will shape the workforce and workplace of our future. Using these tools and their replacements, virtual teams will be the norm, today’s CUTE problems will be overcome and a new era of work practices introduced. If the past is anything to go by these changes can happen quickly so we should keep our eyes and options open!

[Note: This article was written by Mike Griffiths and first appeared on ProjectManagement.com here]

Much has been written about agile processes, how they can better respond to changing requirements and be used to tune approaches over time through retrospectives and adaptation. While this is true, it masks the importance of human involvement. It is people that respond to change and teams who update and tune their processes. Agile methods give more freedom and autonomy for teams to do the right thing, but it is the team members that act intelligently to improve things.

Understanding this distinction that agile methods don’t directly help much, instead it is the actions of agile team members, allows us to better explain why some agile projects go well and others do not. Agile processes are an enabler for intelligent action, but not a guarantee of it. Teams that are asked to follow agile methods, but not motivated or equipped to improve the project environment will likely fail.

This is why we often see some agile project teams do very well and others struggling to produce results within the same organization. If you look at the processes both teams are following they look the same. They might both be doing daily stand up meetings, iteration planning sessions, backlog prioritization, demos to the business and retrospectives. However, these processes don’t ensure success; it is the local decision making that comes from them (which we observe in different ways) that lead to successful projects.

The concept of “Local intelligence” is described nicely by Malcolm Gladwell in his book “David and Goliath: Underdogs, Misfits, and the Art of Battling Giants”. Gladwell tells the story of Lawrence of Arabia, an archaeologist conscripted into the British Army in World War 1 who led the Arab revolt against the Turkish army occupying Arabia.

Lawrence’s goal was to destroy the long railroad being built to set up operations deep in the Hejaz desert. The odds were against him, the Turks had a modern army and Lawrence commanded an unruly band of Bedouin nomads who were not trained in combat. However they were mobile and self sufficient they travelled extraordinary distances, attacked quickly and were gone before major battles ensued.

Lawrence is best known for leading a daring attack on the port town of Aqaba. The Turks expected an attack to come from British ships offshore, but Lawrence attacked from the unprotected East desert during summer, leading his men on a 600 mile loop no one thought possible and to anyone but the Bedouin nomads likely fatal.

His success was attributed to a number of factors. First, as a historian and archaeologist he had little regard to traditional military order or standards and that helped with unconventional thinking. Second he made great use of the local intelligence of his men who were very self-reliant and skilled in dessert survival and travel to mobilize and do the right things to be successful.

This enablement of local intelligence is the key to agile success too. The agile process is only a framework, the real work happens in the discussions and decisions made by the team. I used to be concerned by how much time some teams spend talking about work compared to actually doing work until I saw a correlation with project success. The teams that spend lots of time discussing options, priorities and business requests were actually thinking and refining strategies to be more effective. They were using local intelligence to be more successful and it showed in their results.

When my current team stopped holding daily stand-up meetings I was a little concerned. I wondered if we were getting lazy. If the process was devolving and should I intervene? However I trusted they must have had the same thoughts and the frequent discussions both face-to-face and online for remote members negated the benefit in these daily updates. To them these meetings felt unnecessary and low value. So, stand-ups became three times a week then twice a week then more sporadic. We have not had a daily standup meeting for three months now and things are going great.

One practice we are doing extra is a weekly technical show-and-tell meeting so developers and QA’s get to see what people have been working on and ask more technical questions ahead of, and separate from, the bi-weekly business demonstration. I am not suggesting that agile teams drop daily stand-ups and adopt weekly technical reviews. For most agile teams the daily stand-up is core and critical for effective communications between team members.

Instead, my point is that success is more closely aligned with the application of local intelligence from the team members than adherence to agile process. What works for one team may not work for another. As leaders of agile teams we should not be looking for conformance to process but signs of effectiveness and the application of local intelligence. High levels of “productive work related discussion” appear a good sign.

By “productive work related discussion” I mean new discussions that cover fresh ground and solve issues, not Bill and Ted having the same argument about architecture X or tool Y. Ask if the discussions result in solutions, are they business results focused, and inclusive to all team members that want to participate? These are indicators that they are productive.

In addition to productive discussion, team led modification of process is another sign of local intelligence applied. The fact the team diagnosed, discussed and agreed on an amendment to regular working process is a good indicator that they are applying local knowledge. Alistair Cockburn’s Shu, Ha, Rei model, describes a progression from obeying the rules (Shu, which means to obey, or follow), consciously moving away from the rules (Ha, which means to break or change), and finally unconsciously finding an individual path (Rei, which means to separate, or release).

Organization adopting agile and teams using agile methods are encouraged to first “use it out of the box” i.e. without modification. Then, only when everyone understands why things are as they are might we want to change process. Many of the agile processes balance each other. Rigorous testing allows for light documentation for instance. Dropping one without addressing the other and you could be headed for trouble.

However, in my view agile processes are a default starting point for teams. They work well and cover all the basics. Yet if the team sees a problem, or an opportunity for improvement then we should not stop them trying to become better. Iterations provide short test cycles to try new approaches and revert back if they are not working or build on success if they are.

When leading teams look for and encourage high levels of engaged debate and productive discussion. Support team based process adaptations and change. They are both signs of an engaged team applying local intelligence to improve their ability to deliver. Agile methods should be enablers of change not strict frameworks to work within. Our goal is performance not conformance so we should provide support and encouragement accordingly.

When asked if my team is agile I answer “kind-of, “mostly” or “predominantly” depending on the formality of the question. However I don’t really care about the label, they are kicking butt and delivering a ton of high quality software the business loves, which is my real focus and measure of success. Methodology labels help shorten conversations about process but are of a lower importance than results, we should act accordingly and spend more time encouraging local intelligence - a critical key to success for today’s knowledge worker projects. 

(Note: This post was first written for ProjectManagement.com here)

I 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 “21^st 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.

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

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.

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.

My 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 9^th 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 [email protected].

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

 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.

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.

Introduction

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.

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

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

Getting 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!”

My 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 9^th 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 [email protected].

Continue reading to see further details from the Course Outline

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

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

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

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 )

Linked 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"

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

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

I picked up a copy of my PMI-ACP^SM 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 code “XTENMGBD”, you can get the additional $10 discount up until May 18th 2012. This is a 25% reduction on the retail price.

Forbes 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?