Announcing “PM Illustrated” – The Fun Way to Prepare for Your PMP® Exam

PM Illustrated - Banner 800

I know, “Fun” and “PMP Exam” are rarely used in the same sentence. When I studied for my PMP credential in 2001, materials were text-based, process-focused, and dry! Unfortunately, not much has changed since then.

However, fun is a serious business in adult learning, it boosts retention and cuts study time. We recall facts about our favorite hobbies and sports teams much easier than boring information because our brains prioritize fun experiences for recall. It is why good trainers who can make a topic enjoyable are so valuable.

Visual Learning

90 percent visual - 400

The other secret weapon in slashing our study time is Visual Learning. Research into visual thinking by David Hyerle, reports that 90% of the information entering the brain is visual. 40% of all nerve fibers connected to the brain are connected to the retina, and a full 20% of the entire cerebral cortex is dedicated to vision - so let’s use it.

Using a combination of cartoons, images, mind maps, and explanations, we can engage the right and left hemispheres of our brain to build stronger comprehension and better recall. Tests show most people only remember 10% of what they heard three days ago. Add an image to the message, and this figure jumps to 65%.

Images Increase Retention

 

Why Animal Cartoons?

Made to stickBecause they are cute, funny, and memorable. The memorable part is valuable for exam preparation. Images that are surprising for the context, such as using animals to show project management topics, are “stickier” in our brains. In the book “Made to Stick”, authors Chip and Dan Heath explain we remember things that are simple, unexpected, and emotional.

Animal cartoons about project management do all three.

Support Diversity and Inclusion(Here, we see the herd welcoming the zebra who is a bit different, but it is all good.)

Our brains are lazy and filter out the ordinary or familiar. Recall vacations, often the first few days are memorable because everything is new and different. Then the last few days seem to pass quickly in a blur. Our brain skips the usual stuff, presumably saving space for valuable fresh information.

To help us study for exams more effectively, we can trick our brains into marking everything as new, unusual, and needing to be stored away by associating it with the unfamiliar. 

Value Servant Leadership(Be the bridge to success for others)

The good news is you will find recall much easier. The bad news is you might try and thank a snake instead of avoiding it.

 

Beta testerLooking for Beta Testers

The website is not finished yet but is mostly functional now. If you are a visual learner looking for a new way to study project management with the following features:

  • See the big picture – Navigate the scope of the PMP Exam Content Outline (ECO) via three different roadmaps
  • Chart your own adventure – travel through the topics in any order
  • Gamification – Track your progress by earning digital badges with optional leaderboards
  • Self Assessment – Check your understanding at the end of each module

I would love to hear your feedback, whether “Too many pictures”, “Too weird,” or “Awesome!” please let me know. Your feedback is valuable and review contributors will be acknowledged in the upcoming book version.

Here’s the link: PM Illustrated – A Visual Learner’s Guide to Project Management - while it works on mobile, it works best on desktop devices.

Managing projects is anything but dull, studying how to do it should not be dull either.


Agile Benefits Management

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:

Agile Benefits Management

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.

 

Continue reading "Agile Benefits Management" »


PMI-ACP Training in Calgary

CalgaryI 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 9th 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.


Second Edition of My PMI-ACP Book is Now Available

2nd EditionEven though several people reported receiving their books last week, Canada Post takes a little longer, but today I got my first look at the second edition of my PMI-ACP Prep book. There is more coverage of Lean, Kanban and Scrum. It has been restructured to match the new PMI Exam Content Outline domains and has a new section on Agile Mindset. These changes along with more practice questions increases the page count by some 85+ pages.

It’s a hefty text book now, but the extra material is support, more explanation and feedback suggestions from hundreds of readers of the first edition. The exam content was restructured but did not change that much. So it is not that there is now more to learn rather more material to help you on your way to earning the PMI-ACP credential.

RMC has a 30% off early-release offer right now that can be found here.


Agile Talent Management

Talent ManagementTalent 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”. 

Continue reading "Agile Talent Management" »


Agile Innovation

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.

Continue reading "Agile Innovation" »


Agile and Strategic Alignment

This month’s theme at ProjectManagement.com is “Strategy Alignment/IT Strategy.” This can seem at odds for agile teams who organically grow solutions towards evolving requirements. Where’s the strategy in that, and how do we promote empowered teams while preventing chaos? Most organizations spend considerable time and effort developing strategic roadmaps and they don’t want this work undermined by unordered development.

Fortunately, hope is at hand with some well proven models. While the common kernel of agile practices make little mention of strategy or architecture, many of the supporting guides and scaling approaches handle the topic well. So, when faced with a criticism of no place for IT strategy or struggling to link an existing strategy to an autonomous team we can turn to these agile “wrappers” for inspiration and guidance.

You do not have to be using these approaches as standards at your organization to make use of the integration points and approaches they recommend. Instead see how strategy and architecture are handled and then apply a similar approach in your project and organization.

DSDM

Dynamic Systems Development Method (DSDM) is an agile approach that started in Europe and covers a broader project lifecycle timeline than most agile methods. It starts early with Feasibility and Business Study phases goes beyond deployment to handle Post Project work. Unlike most agile methods that don’t mention architecture DSDM has an architectural deliverable called the System Architecture Definition (SAD) that is created early on in the Business Study phase.

Agile projects struggling to appease architecture groups and facing criticisms of lacking strategic alignment, could look to the DSDM System Architecture Definition as a template for an early project, light-weight solution. DSDM also fits well with The Open Group Architecture Framework (TOGAF) standard and there is a White Paper on DSDM and TOGAF Integration White Paper here.

SAFe

The Scaled Agile Framework (SAFe) is a knowledge base for implementing agile practices at enterprise scale. It presents this information through a Big Picture View that shows how the work of agile project teams can be rolled up into programs with their own program backlogs. Then explains how programs fit into larger portfolios that implement product investment and strategic themes.

Continue reading "Agile and Strategic Alignment" »


Agoraphobia: The Fear and Loathing of Open Space Offices

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.

Continue reading "Agoraphobia: The Fear and Loathing of Open Space Offices" »


PMI-ACP LinkedIn Group Growing

Last week we passed 500 members for the new “PMI-ACP Exam Prep with Mike Griffiths” LinkedIn Group.

That is a great start and plenty enough to begin discussing topics about the exam for people studying for the credential and those already with it. I have just posted a new discussion on the suitability of the PMI-ACP curriculum you can join the group and see it here

Text_illustration


PMI-ACP LinkedIn Study Group

PMI-ACP Study GroupI have created a LinkedIn group for readers of my PMI-ACP Exam Prep book. The group combines the features of a study group and Q&A forum along with exam taking tips. Once we have critical mass I will focus on a chapter for 2 weeks discussing topics and answering questions.

I would also like to hear from people after they take their exam to get feedback on how using the book worked for them and any suggestions for the second edition. If you are interested, please help me in spreading the word and join the group Here.


Big Agile, the Route Less Travelled

Scaling Collaboration not Process is the Key to Enterprise Agility.

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

Continue reading "Big Agile, the Route Less Travelled" »


LeadingAnswers in 2015

PathwayI am well overdue for posting to this site, but it is not through lack of interest or ideas. There is an inverse relationship between postings and with how busy I have been. When I have time to post here it generally means I am getting some spare time. When you see nothing for weeks (or months) it means I have been busy doing “real-work” which I guess is a good thing. Since I last published some articles here I have been working with APMG on a PMBOK and DSDM Cross Reference and White Paper. This prompted me to update my “PMBOK Guide to Agile Mappings” and bring it up to the latest PMBOK V5 Guide version.

I have been doing some PMI-ACP Exam Prep training courses and taught a Collaborative Risk Management workshop. I gave a keynote presentation at an excellent PMI Conference in Poland and have been working with the PMI on the next version of the Exam Content Outline for the PMI-ACP exam refresh. I have also been teaching at the local university, writing for Gantthead (ProjectManagmeent.com), moved house and doing my regular day job.

These activities have provided me with lots of things to write about here and over the next few weeks I hope to post more regularly and share some cool new content. Thanks for your patience and stay tuned for some more articles soon.


Thinking Tools for Scaling Frameworks

Light bulbsScaling 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]


Agility as an Enabler for Local Intelligence

Team intelligenceMuch 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)


Mike Griffiths Receives “PMI-SAC Fellow” Award

Fellowship AwardOn November 12, 2013 Mike was presented with a PMI-SAC Fellow award at the PMI-SAC Awards Gala. The Fellow Award recognizes and honours members who have made sustained and significant contributions to the project management profession and the Institute for more than a decade.

Mike was recognized for his work developing agile project management techniques and promoting agile project management including:

Mike is very grateful to receive this award and hopes to be active in the next 10 years of project management promotion and development.


Overdue Update and Designing the Pontiac Aztek

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

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

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

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

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

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

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

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


Next PMI-ACP Exam Prep Class with Mike Griffiths

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

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

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


Methodology Wars – Contradictory Constraints or More Options?

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

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

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

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

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

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

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

DiSC 1

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

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

The assessment also pointed out some potential negative traits including:

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

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

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

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

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

The new PMBOK v5 Guide processes:

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

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

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

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

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


Promoting Shared Leadership

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

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

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

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

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

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

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

Continue reading "Promoting Shared Leadership" »


An Antidote to Velocity Obsession

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

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

A Measurement Parallel

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

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

Continue reading "An Antidote to Velocity Obsession" »


PMI-ACP Exam Prep Class with Mike Griffiths

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

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

Continue reading to see further details from the Course Outline

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


How Will Agile Be Remembered?

RememberIn the future how will agile methods be remembered by the project management community?  It seems history has a way of distorting the facts and simplifying concepts out of context. Here are a few examples:

1)    In the original Waterfall Software Development Process paper written by Winston Royce in 1970, after presenting the lifecycle diagram on page two, the author states “I believe in this concept, but the implementation described above is risky and invites failure”. Royce then spends the remaining nine pages outlining feedback loops and “Do It Twice” recommendations since there would be things missed in the first pass through. Read in its entirety, it outlines a fairly robust, risk tolerant approach to building systems that features multiple iterations and opportunities for learning and adaptation.

Yet, waterfall is thought by many to be a single pass lifecycle with all the associated problems. It is as if the project management community latched onto the lifecycle diagram depicted on page two and chose to ignore all the more difficult to implement yet critical steps described in pages 2-11. Read the original Waterfall paper here.

 

2)    Henry Gantt’s project management research and work actually focussed on retrospectives, diagnostics and optimizing work flow. Yet people remember him for the Gantt chart. The funny thing is that he did not even invent what we call the Gantt chart today; that was Joseph Priestley 100 years earlier.

Gantt’s charts were far more complex diagrams that were created after the work was completed and then used to identify waste and improve the process. While he started with scientific management of Fredric Taylor, his research went far beyond charting and optimizing labor. He was a harsh critic of ineffective management and promoted many Lean and Theory of Constraint like values such as “Increased production not through speeding up workmen but by removing the obstacles which prevent them from doing their work”, “Reduced costs, because of the elimination of idleness and waste as well as improvements in process”, “Men interested in their work not only because of the wages but because they have an opportunity to increase their knowledge and improve their skills.

 We often characterize Gantt with tracking charts, but that’s a faulty summary of a talented systems thinker; for more information on Henry Gantt, his real charts and work see Henry L Gantt 1861-1919 Debunking the Myths.

 

3)     The Manhattan project is often attributed as the origin of modern project management and phase gated approaches, however it actually pursued concurrent development. The Manhattan project to develop a nuclear bomb in the 1940s, certainly displayed the modern project management principles of organization and planning, but also high rates of trial-and-error and multiple parallel streams attempting to solve the same problem.

There was just so much uncertainty surrounding how to create a bomb, knowledge was theoretical and incomplete. The project manager, Leslie Groves, said: “The whole endeavour was founded on possibilities rather than probabilities. Of theory there was a great deal, of proven knowledge, not much. There was simply no ready solution to the problem we faced.” So, Groves and his steering committee decided to explore and implement different solutions in parallel. This approach (well multiple approaches) and willingness to modify and add solutions mid-course, led to technical breakthroughs that had been thought impossible by most three years before.

This was 30 years prior to Toyota’s “Set based engineering” but very similar in its pursuit of multiple parallel approaches. Yet today we most often hear of the Manhattan project as the birth of the phase gate approach, this is too bad, they did so much more.

 

4)     Lastly, the Polaris project that was attributed as the origin of Critical Path Method (CPM) and PERT was actually about gaining First-To-Market intellectual property share.  The Polaris project developed the first submarine-launched ballistic missile (SLBM) carrying nuclear warheads. These offensive weapons, almost impossible to track and attack, became a key element of nuclear deterrence.

The Polaris project is today credited with developing the “scientific approach to project management” with the first large scale application of computerized planning techniques, particularly CPM and PERT. A big part of the project was about “getting a share of the ballistic missile pie” away from the newly formed US Air Force that was receiving most of the Pentogon’s money. Admiral Burke astutely believed that “The first service that demonstrates a capability for this is very likely to continue the project and others may very well drop out”. The result was a clear prioritization of schedule over cost and specification; and a willingness to experiment and change specifications over the course of the project.

Trial and error led to two deployed tests in the early 1960’s and PERT served “…less for improving project control than for offering technological pizzazz that was valuable in selling the project. (Since) The image of efficiency helped the project. It mattered not whether parts of the system functioned or even existed, it mattered only that certain people for a certain period of time believed they did.” For more information on the fascinating truth of the concurrent development, experimentation, iteration, and adaptation that really underpinned the Manhattan and Polaris projects see Lost Roots: How Project Management Settled on the Phased Approach (and lost its ability to lead change in modern enterprises).

 

So, given waterfall was iterative, Gantt focused more on the theory of constraints not Gantt charts, the Manhattan project was Lean not Phase Gated, and the Polaris project was about rapidly gaining mindshare through iteration, I don’t really hold out much hope for agile methods to be remembered accurately in the future.

The glass half-full view of these history lessons shows that smart, resourceful people have been tackling complex project problems for centuries and our ideas such as lean-startup, Kanban, behaviour driven development, etc are likely not new.

The glass half-empty view is that agile methods will be erroneously summarized to tangential concepts,   such as “individuals without tools”, or “leave no documentation”. However, smart people will continue to be successful in managing challenging, audacious projects and terms are really just labels that matter less than the methods they describe or results they enable.

Maybe we have better collective knowledge these days and we will not repeat the same erroneous summarization and labeling of take away ideas. Lenfle and Loch, the authors of the “Lost Roots…” paper, assert that the loss of trial-and-error and strategy-making focus from popular project management, that was clearly present on these early projects, restricts the usefulness of project management today. Agile and lean approaches rediscovered this science and are attempting to merge it back into mainstream project management, but are up against a generation of resistance from those who were taught projects can plan out variability.

From an evolutionary perspective it is an encouraging sign that techniques that were lost through poor reporting have re-emerged elsewhere to exploit project environments that have high levels of uncertainty. Regardless of their names or origins, let’s hope they persist and get incorporated in mainstream project management, not to be lost again.

This article first appeared in ProjectMangement.com here. Bio: Mike Griffiths is a project manager experienced in traditional and agile methods who reads about project management much too much - you really don’t want to get stuck with him at a party!


PMI-ACP Exam Prep 3 Day Course

PMI-ACP Training CourseI am pleased to announce / preview the first public offering of my new 3 day PMI-ACP Exam Preparation course. This is my second generation PMI-ACP Exam Prep course, with new content and updated material based on a year’s worth of feedback from my PMI-ACP Exam Prep book. Participants will receive a copy of my book (or a discount if they already have it). The structure mirrors the book flow, providing in-depth explanations, examples and new sample questions for all the material in the PMI-ACP exam.

The course will provide the 21 Contact Hours of training required to take the exam and uses a small class size format so everyone’s questions can be answered. The first course will be held in Calgary in the April / May timeframe with full details and pricing to be announced soon. If you are interested in receiving further announcements contact [email protected] to be added to the mailing list.

An outline of the course can be viewed here.

"Software Extension of the PMBOK Guide" Open for Review

Software ExtensionThe “Software Extension to The PMBOK Guide” is available for public review here. It is a PMI hosted site, but you do not need to be a PMI member to access the draft. This is the first full exposure of the draft. It was completed earlier in the year and sent to some subject matter experts for review, but has not been made publicly available before. So, if you have an interest in how the PMBOK Guide should be augmented/modified for software projects take a look and submit you comments.

As a parallel, the Extension to the PMBOK Guide for Construction, has been available for a number of years and it offers guidance to project managers in the construction business. The role of the Software Extension, is to fulfil a similar role, but this time for managers of software projects that often face changing requirements, evolving technologies, and bringing together divergent knowledge workers to collaborate on challenging problems. For these project environments the Software Extension describes a spectrum of Predictive, Adaptive and Agile Lifecycles that may be used and more people based, as opposed to process based, development strategies.

I know asking how the PMBOK Guide can best be changed for software projects will likely prompt some colourful suggestions, but that’s half the fun. We will have to review all the suggestion and having the odd passonate suggestion brightens up the review process. I once worked with a developer who used a copy of the PMBOK Guide to raise the level of his monitor to approximately the same height as his other monitor. When he heard I was working on the next version of the PMBOK Guide he said that he uses his copy every day, and it was indispensable, but could we add another 10-15 pages to the next version (so his monitors would be perfectly aligned).

So, please take a look, we really do value your feedback, both good and bad. The role of the Software Extension is to modify and extend the PMBOK Guide recommendations for project managers in the software industry. It will be published in mid/late 2013 with your feedback incorporated or politely passed over, as we see fit.

Linking Agile to HR Theory

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

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

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

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

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

Continue reading "Linking Agile to HR Theory" »


PMBOK v5 Guide is Good to Go

PMBOK v5The PMBOK v5 Guide draft text has been approved by the Consensus Body. This is the PMI appointed group of industry consultants, government representatives, and academics who vote on the final content, and they have reached agreement on the ultimate text to use. Some of the appendices are still being finalized, but the main text is complete and set.

My contributions were on chapter 6 and while I had submitted corrections and updates to the PMBOK Guide before, this was the first time I had worked on a Chapter Core Team. On the plus side it provides first kick at suggesting updates, but on the negative side you then have to reconcile the thousands of review feedback suggestions.

My hope was to get more agile content into the PMBOK v5 Guide since 65% of PMI membership work on IT projects and agile has penetrated the IT industry. This means for many readers the previous PMBOK Guide seemed oddly deficient in its coverage of common practices. We got some agile coverage included, but it was much smaller than I hoped for. Yet perhaps it opens the door for future expansion in later versions.

I am glad it is finished; it was a very large volunteer time commitment with many periods requiring 10-20hrs per week. As with any volunteer work, the cause, the people you “meet”(this was all remote work), and what you learn are the real rewards. The PMBOK v5 Guide will be available in January 2013 and will drive the update cycle of offerings like PMP Certification and associated PMI standards.

Calgary Presentation - Working Effectively with Off-Shored IT Resources

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

Presentation Outline:

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

About the Speaker:

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

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


PMI-ACP Sample Questions

PMI-ACP ExamListed below are 20 sample exam questions, which are aligned with topics on the PMI-ACP Exam Content Outline. People studying for the PMI-ACP exam should find them useful practice. The answers and accompanying explanations are provided at the end of this post.

1) Which of the following is an Agile Manifesto principle?

A) Welcome changing requirements, early in development. Agile processes handle changes for the customer's competitive advantage.

B) Welcome changing priorities, early in development. Agile processes harness change for the customer's competitive advantage.

C) Welcome changing priorities, even late in development. Agile processes handle changes for the customer's competitive advantage.

D) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.



2) When managing an agile software team, engaging the business in prioritizing the backlog is an example of:

A) Technical risk reduction   

B) Incorporating stakeholder values   

C) Vendor management   

D) Stakeholder story mapping   



3) Which of the following items is not a benefit associated with product demonstrations?   

A) Learn about feature suitability   

B) Learn about feature usability   

C) Learn about feature estimates
   
D) Learn about new requirements   

Continue reading "PMI-ACP Sample Questions" »


Free PMI-ACP Webinar

PMI-ACP HandbookPlease join me on Wednesday May 2nd for a free webinar on “PMI-ACP: Adopting Agile into the PMP World.” This is part of Rally Software’s webinar series and we already have >2,000 people signed up. The session runs on Wednesday May 2nd at 7am (PT) / 10am (ET) and then again at 1pm (PT) / 4pm (ET) You can sign up here

In the webinar I will be talking to Juie Chikering about the exam’s content, who it is aimed at, it’s positioning in the industry, and how it has changed since the pilot last year, amongst other things. There will be interactive poles and questions from the audience, so it should be an interactive and informative event.

I will be presenting the webinar from the RallyOn Conference in Boulder, CO where I am also speaking about agile PMOs and on a panel with Dean Leffingwell, Johanna Rothman, and Alan Shalloway about the future of agile. I am really looking forward to it and also spending some more time in Boulder which I especially enjoy.


PMI-ACP Book Discount

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

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

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


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

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


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

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

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


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


Unlikely Origins

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

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

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

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

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

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

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

Continue reading "Unlikely Origins" »


PMI-ACP Book Coverage

PMI-ACP BooksI finished my PMI-ACP Exam Preparation book a couple of weeks ago and now it is with the publishers for reviews and final edits. It turned out larger than expected, but I think better for the extra exercises and sample exam questions.

When designing the PMI-ACPSM exam, we needed to base the content outline on existing books and resources so that candidates would understand what the exam would test them on. When choosing the books, we went back and forth on our decisions of which books to include, since there are so many good resources available. And while we recommend that people learn as much as they can, we also had to recognize the need for keeping the exam content—and the preparation process for the exam—reasonable. In the end, we selected the following 11 books:

  1.    Agile Estimating and Planning, by Mike Cohn
  2.   Agile Project Management: Creating Innovative Products, Second Edition, by Jim Highsmith
  3.   Agile Project Management with Scrum, by Ken Schwaber
  4.   Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen
  5.   Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn
  6.   Becoming Agile: ...in an Imperfect World, by Greg Smith and Ahmed Sidky
  7.   Coaching Agile Teams, by Lyssa Adkins
  8.   Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and James R. Trott
  9.   The Software Project Manager’s Bridge to Agility, by Michele Sliger and Stacia Broderick
  10.   The Art of Agile Development, by James Shore and Shane Warden
  11.   User Stories Applied: For Agile Software Development, by Mike Cohn

Reading all of these books takes some time, since the 11 books add up to more than 4,000 pages. The books also cover a lot more material than you need to know for the exam. From each book, we extracted the portions that best covered the exam content outline topics, and the exam questions were then targeted at those specific sections.

Continue reading "PMI-ACP Book Coverage" »


PMI-ACP Exam Prep Material

PMI-ACP Study GuideMy PMI-ACP Book is coming along nicely and today RMC released some more content including sample questions and walked through explanations of the answers. Visit the RMC Site to access it and also sign up for future previews and special discounts.

Now if I could only write this stuff as quickly as they are giving it away, I would be doing OK! 


PMBOK v5 Update.

PMBOK Guide - Fifth Edition

I am overdue for providing an update on how my work on The PMBOK v5 Guide is going. Well, it is on its way. The process is slow (sometimes painfully slow) but this is because of the number of people involved and the review process used. To give an idea, here is the plan for the next 6 months:

*  17 February – 20 March 2012: the exposure draft PMBOK® Guide – Fifth Edition will be open for comments

*  Late February 2012: team training for our adjudication processes

*  20 March 2012: our exposure draft period closes and comment adjudication begins

*  20 March – 28 April 2012: teams adjudicate exposure draft comments 

*  Early May – mid May 2012: core committee reconciles any comment adjudications that cut across chapters or where consensus has not yet been obtained

*  Mid May – early June 2012: appeals period for adjudication decisions; final draft QC and integration reviews

*  Early June – mid June 2012: appeals adjudication and resolution

*  Mid June – late June 2012: final draft cleanup and incorporation of QC comments

*  28 June 2012: core committee vote on finalized draft

The Exposure Draft process is a great mechanism for allowing members to review and comment on new material, but likely to generate a ton of review work for us. The Fourth Edition update, back in 2008 received over 4,400 comments during its exposure draft.  Since the membership of the PMI has increased significantly since 2008 we could be looking at close to double that figure.

That is a lot of suggested changes to review and I think March and April will be a busy time for me. Of course they will not arrive in one Word document, but I wonder what the PMBOK Guide would look like if we just did an “Accept All”? Right now it is the calm before the storm; I am going to make the most of it.


PMI-ACP Value Stream Mapping

PMI-ACP  Value Stream Mapping I have been away attending the excellent “Agile on The Beach” conference recently, but when I returned I had an email waiting requesting some PMI-ACP study help on Value Stream Mapping. So here is quick outline of the topic.

Value Stream Mapping – is a lean manufacturing technique that has been adopted by agile methods. It is used to analyze the flow of information (or materials) required to complete a process and to determine elements of waste that may be removed to improve the efficiency of the process. Value stream mapping usually involves creating visual maps of the process (value stream maps) and progresses through these stages:
1)    Identify the product or service that you are analyzing
2)    Create a value stream map of the currant process identifying steps, queues, delays and information flows
3)    Review the map to find delays, waste and constraints
4)    Create a new value stream map of the future state optimized to remove/reduce delays, waste and constraints
5)    Develop a roadmap to create the future state
6)    Plan to revisit the process in the future to continually tune and optimize

To illustrate lets optimize the value stream for buying a cake to celebrate passing your PMI-ACP exam with a friend. Let’s say this involves choosing a cake, waiting at the bakery counter to get the cake, paying for the cake at the checkout, then unpacking and slicing before enjoying the benefit of the process (the cake).

Continue reading "PMI-ACP Value Stream Mapping" »


Value Driven Delivery

(This post, a draft sample from my upcoming PMI-ACP Prep book, takes a look at the “Value Driven Delivery” domain.)
PMI-ACP
Value, specifically the delivery of business value, is a core component of agile methods. This concept is woven into the agile DNA with its inclusion in the Agile Values (“Working software over comprehensive documentation”) and the Agile Principles (“Working software is delivered frequently” and “Working software is the principal measure of progress”). The focus on delivering value drives much of the agile activities and decision making on a project, and it manifests itself in many of the Tools and Techniques (T&T) and Knowledge and Skills (K&S) used. The focus on value is such an essential component of agile methods that the “Value Driven Delivery” domain has the most T&T and K&S of any of the 6 domains. This means we are starting with the biggest section early in this book.

What Is Value Driven Delivery?
Let’s start by defining value-driven delivery. The reason projects are undertaken is to generate business value, be it to produce a benefit or improve a service. Even safety and regulatory compliance projects can be expressed in terms of business value by considering the business risk and impact of not undertaking them. If value then is the reason for doing projects, value driven delivery is the focus of the project throughout the project planning, execution, and control processes.

It is the big picture view, the wearing of the sponsor’s hat when making decisions. By the project manager and team assuming this viewpoint, there is an opportunity to incorporate unique technical insights, such as technical dependencies or risk reduction steps, into the selection of features for a release that the sponsor may not be aware of. However value driven delivery remains a guiding vision for much local decision making, the selecting of choices that maximize the value delivered to the business or customer.

Risks as Anti-value
Risks are closely related to value. We can think of project risks as anti-value, i.e., things that can erode, remove, or reduce value if they are to occur. If value is the heads side of a coin, then risks are the tails side. To maximize value we must also minimize risks, since risks potentially reduce value. This is why the Value Driven Delivery domain addresses many risk reduction concepts and techniques.

Continue reading "Value Driven Delivery" »


RMC's PMI-ACP Exam Prep Book

PMI-ACP I am excited to announce I will be working with RMC to create a PMI-ACP Study Guide book for the upcoming PMI Agile Certified Practitioner exam. When I was studying for my PMP exam many years ago, I used Rita Mulcahy’s PMP Prep Study Guide and was very grateful for the plain English explanations, exam guidance, and sample questions. So it feels right and a bit of a privilege to be working with the same company to help guide people for this new exam.


Working with the other PMI-ACP Steering Committee members over the last couple of years on the Agile Community of Practice and to define the exam has been a great experience, but the hundreds of hours of unpaid volunteer time has to be made up somewhere so hopefully this endeavor will help out. Assuming people still buy books that is, I read this Guardian article today that made me wonder. Anyway, embracing today’s publishing ideas; I will be posting snippets here for anyone looking for taster portions. The big picture views, sample exam questions, and cheat sheets will be kept for the main book, but key concepts around the tools and techniques, knowledge and skill areas will be posted here.


I would love to hear your feedback on these portions, please let me know if they are useful, need more explanation, or you think I am missing anything. I can then develop additional material to improve the final product. To help collect all my PMI-ACP content together (and exclude it for those of you not interested) I have created a Category tag called “PMI-ACP” and you can use the Categories filter under “Recent Posts” in the right hand navigation on my LeadingAnswers.com home page to find content.


Agile Outside of Software

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

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

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

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

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

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

Continue reading "Agile Outside of Software" »


PMI Agile Update

Agile Certified Practitioner Here is an update on the agile happenings at the PMI that I have been involved with. The pilot program for the PMI Agile Certified Practitioner filled up fast. 2,649 people opened applications for the program, a record for the PMI, and the full launch in October is looking like it will be very popular. Item writing for the exam questions is on track and Registered Education Providers (REPs) are in high-gear readying their courses.

The PMBOK v5 Guide continues to move forward too. My work is on Chapter 6 (Time Management) and we recently reviewed and incorporated the second round of approved comments. There was a meeting this weekend to review all chapter comments along with the updated Inputs, Tools, Techniques, and Outputs (ITTOs). I have suggested some agile content I am not able to discuss under the NDA, but I am hopeful it will survive the approval process. Other Chapters have agile content being suggested too. This is a slow process though and the PMBOK v5 Guide is not expected until late 2012.

I was also recently contacted about working on an Software Extension to the PMBOK Guide. This really excites me and is something I looked into leading a few years back (before I discovered the full extent of the work involved). There has been a call for Agile experts to help develop the new extension.

If you have ever looked through the Extension to the PMBOK Guide for Construction, you will know that the extension does more than add a bunch of industry related practices. It also suggests changes to the existing PMBOK’s outlines. So, for instance, instead of creating a detailed WBS, we could suggest creating a candidate feature backlog. Many of the suggestions for change to the PMBOK Guide have to be tempered with the fact that the guide has to remain industry agnostic and suitable for any project manager. An extension for the Software Industry allows us to go much deeper into agile techniques. I am looking forward to this work and learning who else is involved.

Finally the PMI Agile Community of Practice continues to grow and develop. I learned that Michele Sliger’s recent webinar had over 500 people in attendance. This is great and a sign of the levels of interest for agile present in the ever expanding PMI community. Taking agile to the PMI that used to have this “evil empire” feel felt audacious eightr years ago, now it seems natural and if anything, belated. People have strong opinions and the PMBOK Guide work has shown me that many people still dismiss agile methods, but it feels like the tide is coming in and neither King Cnute or the diehard traditionalists will stop it.


Agile as a Solution for "Miscalibration Errors"

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

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

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

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

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

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


PMI Agile Work

San Antonio Riverwalk It has been a busy week for PMI Agile work. Last week I was in San Antonio with the PMI Agile Certification Steering Committee reviewing the latest market research and next steps for the certification launch. Things are also moving forward on the PMBOK v5 Guide with some more agile terms defined and content suggested for Chapter 6.

The PMI recently sent a detailed Agile survey out to a sample of its members and received feedback from >1,300 people. They were looking for feedback on the types of project managers using agile and their adoption of the domains and knowledge areas that comprise the Domains and Knowledge & Skills that will be in the exam.

Nearly 60% of the respondents were from the US with Canada, India, and Brazil being the next most popular. Not surprisingly the biggest industry sector was in IT, with Finance and Consulting being well represented. Most had 2 or more years’ agile experience and had participated in 4 projects or more in a leadership role. 80% held PMP certifications and nearly 30% CSM certifications.

One of the aims of the survey was to ask for rankings of the Techniques, Tools, Knowledge and Skills that will form the body of knowledge  that the exam is based upon. I would love to share these categories here but have been asked not to until after the official release on April 15th. This is understandable, and only fair, but once they are publicized I will have plenty to say about them.

I am sure the 1500 or so PMI Registered Education Providers  (REPs) along the Scrum CST’s who will be offering exam preparation courses will be having a busy Spring and Summer.

Meanwhile on the PMBOK v5 Guide, each of the chapter teams are busy completing the initial chapter re-writes ahead of integration and review. I have been surprised at the rigour and constraints imposed on the writing. Due to the guide being translated into a dozen languages, readability and consistency is key. As, for instance, on our latest effort one PMI reviewer commented that the Microsoft Word 2007 Readability Statistics show a Flesch Reading Ease score of 26.6, which is considered to be "very confusing" and "not easily understood by college graduates". A score between 60 and 70 is largely considered acceptable. So we have rewritten chunks and tried to simplify.

The increased accommodation of agile content is great, not just in my chapter, but I am  hearing  about agile content for the other chapters too. When the call for feedback goes out we will get to see what has been incorporated. I will publicize it here and encourage people to review the new PMBOK v5 Guide for agile content and suggest where more can be added – if appropriate.

That’s the update for now, stay tuned for more on the certification categories after the PMI reveal. Rest assured since we had a great mix of Agile Manifesto authors, PM experts, and pragmatic agilists working on it I don’t think people will be disappointed.


Functional Teams

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

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

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

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

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

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

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

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

Continue reading "Functional Teams" »


PMBOK Guide: Highway Code or Highway Map?

PMBOK Guide Most people studied the Highway Code before taking their drivers licence exam. They had to learn (enough of) it to pass the exam, but then most likely did not reference it again, except until helping a friend study for the exam. Maps on the other hand, in printed paper form, or digital like GPS, are referenced much more frequently. Maps help us plan, track progress, and get to our destinations and we refer to them often when travelling anywhere new.

So, is the PMBOK Guide like the Highway Code or a map? Do we only read it to pass our PMP exam and then it gathers dust, maybe picked up again to lend to a friend? I think for many this is the case. Maybe for the first couple of projects, people may refer to it for guidance on how to undertake a task or process, but just a soon as people have a few real world examples they no longer refer to the guide.

Recently I have spent hours revisiting Chapter 6, the Time Management chapter as part of the PMBOK Guide v5 update. It has got me thinking about “who reads this stuff?” and I expect mainly people studying for the PMP exam. So maybe some jokes would be in order, to lighten up the learning experience? “We now break from 6.4 Estimate Activity Durations to tell you about the two project managers who walked into a bar…” but I somehow think this would not get past the review committees and proof readers.

Because many people find exams stressful and unpleasant we tend to lump things associated with that stressful experience as unpleasant also. If you pick up a Highway Code book from a dusty bookcase many years after passing your test and leaf through it, it can bring back emotions of learning about road signs and stopping distances. I wonder if this is why many people never return to the PMBOK Guide, too many stressful memories.

So could the PMBOK Guide be more like a map, a useful resource we return to time after time before planning our project journey? How would it need to change, maybe with some checklists and how-to steps? Yet, for an industry agnostic guide aiming to apply to construction projects, IT, and bio science, how could these guides apply beyond the most generic items?

Continue reading "PMBOK Guide: Highway Code or Highway Map?" »


PMBOK 5 - Accepted

Acceptance Well, what an on / off / on-again relationship this has turned out to be. After explaining how I was rejected from the PMI PMBOK v5 initiative previously, I received news this week that I have been accepted onto the content creation group for the next version of the PMBOK v5 Guide.

I am not sure if this is a result of me expressing my concern to the PMI that the roughly 60% of PMI members who are engaged in IT likely want some better agile project management guidance and there seemed no one on the committee to provide that. Or simply the ripple down selection of more candidates inthe content creation categories. 

Anyway, I am grateful for the opportunity and am looking forward to contributing wherever I can, because here’s the kicker, I have been accepted onto the group to rewrite Chapter 12 on Procurement. This is odd because when volunteering to contribute we had to rank which chapters we would most like to work on. Given my agile designs on planning, scheduling and estimation these are the areas I ranked highest, ranking Procurement as the lowest.

Now, perhaps I got my high / low ends of the scales mixed up and I accidently voted Procurement highest, but I do not think so. Perhaps the selection committee thought fine, if we have to have this agile windbag onboard, put him over in Procurement where he can do least damage! Or perhaps simply not many people volunteered for Procurement and so that’s where the only opening was. I have sent an enquiry into the PMI, but am not holding my breath for a reply.

Anyways, so now I need to determine how to best influence the Procurement process with an agile perspective. It is quite applicable as I am currently going through an RFI and RFP process with my main client and last year, at the Agile Business Conference in London, I was in discussions with the developers of the new Agile Contract group which may have a tie in.

So, not the role I was looking for, but perhaps a small foot in the door, time will tell and I will keep you posted.

Agile Communications

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

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

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

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

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

Continue reading "Agile Communications" »


PMBOK 5 - Rejected

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

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

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

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

New “Agility Now!” Newsletter

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

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

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

Agile Preservation or Progression?

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

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

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

Continue reading "Agile Preservation or Progression?" »


Decisions: Delayed, Dated, or Done?

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Motivation 3.0 for Agile Teams

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


Smart Metrics Slides

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

Continue reading "Smart Metrics Slides" »