As a kid, I grew up in Cornwall, UK surfing the cold Atlantic coast beaches of Newquay and Porthtowan. Next week I am excited to be in Los Angeles presenting on waves of change and hybrid approaches.

This talk is particularly poignant since it will be 20 years since I gave my first PMI Global presentation on hybrid techniques, which was also in Los Angeles (Link). It’s like coming full circle from talking about something new to returning to see it mainstream.

Of course, it was not really new in 2004. People have been combining agile concepts with more plan-driven approaches for much longer. Tom Gilb was doing this in the 1980s. In 2000, I helped co-author what I think was the first hybrid white paper (Link) on using an agile approach (DSDM) with a structured project management approach (PRINCE2)—and this was a year before the Snowbird meeting and the creation of the Agile Manifesto.  

Combining agile techniques with more plan-driven approaches has always interested me. It helps us link valuable techniques to the real world, which has many non-agile aspects. The very best teams I have worked with (including a winner of a PMI Project of the Year award) used hybrid approaches, which I documented in my Beyond Agile book on situational agility.

When I made my original presentation, I knew I could either lay out my proposals for agile integration and hope people listened or be a part of the integration process.

Inspired by quotes like “For every thousand hacking at the leaves… there’s one striking at the root.” – Henry David Thoreau, and “The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.” - F. Scott Fitzgerald I knew this meant working with PMI to add these concepts.

Another concept I like is Jim Collins’ “Genius of the AND versus the tyranny of the OR,” which suggests that there is often more power and utility in using elements from multiple approaches than choosing approach A or B.

We have seen lots of changes at PMI since that initial presentation, including:

• Agile courses in PMI Seminars World (now PMI Training)
• Forming the PMI Agile Community of Practice
• Having Agile mentioned in PMBOK 5th Edition
• Launch of the PMI-ACP Credential
• Creation of the Agile Practice Guide in partnership with the Agile Alliance
• The DA Acquisition
• Agile content being added to the PMP Exam and PMBOK 7^th Edition

Yet I am sure these changes will seem trivial compared to how project management will change in the next 5 years, let alone 20 years. My presentation is about more than just hybrid. It covers the convergence of three transformative waves.

1. Artificial Intelligence
2. Hybrid Approaches
3. Remote Teams

Like agile entering project management, these waves are impacting project management whether we like it or not. We can learn to surf or be left spluttering for relevance. After all, "In an environment where everyone else is moving forward, standing still has the same effect as moving backwards."

So, given that these changes are coming with or without us, we can engage and help shape them or be passive and let them shape us. My talk outlines practical steps to stay abreast of these changes, learn to utilize them and thrive on the rising tide of change.

If you attend the conference, it would be great to see you there, session 320.

Suitability filters are models that offer simplified views of a decision-making process. They help people identify and discuss the variables at play and make a recommendation. The British statistician George Box said it best “All models are wrong, but some models are useful.”

A good model provides insights, usually a basic view of how something works or the interactions between variables. From this perspective, models are interesting and can speed up our comprehension of something. However, the greatest benefit of models is as a group alignment tool.

Visual Models Create Group Consensus

Much of today’s work is knowledge work. Subject Matter Experts (SMEs) contribute their expertise and collaborate to solve problems or build new products and services. This work is largely invisible and intangible. There are few physical or visible increments in the process. So, when someone describes a requirement, decision, or problem, there is a high chance that other people interpret that description differently.

The Telephone Game and Tree Swing cartoon are classic examples of how even well-meaning interpretations can be distorted, leading to bad outcomes. Left unchecked, our mental models of a product, project or process can diverge from our teammates. This is where visual models offer significant benefits.

Models visualize the previously invisible and, if dynamic, allow us to manipulate the intangible. In doing so, they bring SMEs together by pointing at and discussing the same variables, goals, and interactions we see.

Since knowledge work is now pervasive, tools that can get people on the same page are incredibly useful. This is why I created PMillustrated.com to explain project management to visual learners, and I am a fan of the PMI product Wicked Problem Solving (WPS). They illuminate the invisible and allow us to manipulate the intangible nature of knowledge work. Models unite stakeholders and help avoid divergence.

Some Example Models

Project Plans, Release Roadmaps, and Kanban Boards are examples of familiar visual models designed to help get people on the same page about timelines, what will be released, and work in progress. They are all simplifications since listing every task or feature for non-trivial projects or products would not be practical – yet they are still valuable.

Project plans and release roadmaps are mainly static. While we can edit them to pull and push at the variables (scope, people, estimates), it is generally discouraged since we quickly lose the original view created by the project manager or product owner. Kanban boards are deliberately more interactive. Team members move their own tasks, select new items to work on, and we can see the impacts on queue length, WIP and maybe cycle time or throughput.

Models that invite more people to interact, capture more diverse insights, facilitate better conversations, and generate stronger consensus to the final configurations. So, ideally, good models are interactive, easy to reset and invite manipulation and conversation.

“Good models are interactive, easy to reset, and invite manipulation and conversation.”

Approach and Life Cycle Suitability Filters

I have long been a fan of approach suitability filters. Not because these are infallible or inherently superior to letting people discuss how to undertake something. Instead, because they make the invisible factors visible and get people talking about what common aspects are significant.

Without suitability filters, people can be stuck in old ways or recommend unsuitable approaches because “that’s just how we do things here”, “what our standards say”, “a cool new approach I just read about”, etc.

My first exposure to suitability filters was in 1994, working on the DSDM Project and Organizational Suitability Filters. I have written about the evolution of suitability filters several times on this blog. This comprehensive list post dates from 2007. More recently, I created the Agile Suitability Filter for the Agile Practice Guide by synthesizing elements from Boehm & Turner’s model, DSDM’s Organizational Suitability Filter and new elements.

The trouble with these models was that they were published as Standards, books, or static web pages. This meant people had to print and hand them out or implement them as spreadsheets to share for use and get feedback. These clunky implementations hampered the quick reset and shared manipulation we want from a good model. DA also has some good material around scaling factors, but they are currently static models with links to static pages of text. There is no interactivity or feedback gained from manipulating values.

Web-Based Interactive Tools

Web-based tools are less likely to get lost or need preparation before use. Anyone with a web browser can access them, so they promote use by many stakeholders. Plus dynamic web controls also allow users to interact and manipulate the model parameters and see, then discuss, how the model responds.

1) The Beyond Agile Model

<Link to Beyond Agile Model>

The Beyond Agile Model is a web-based tool initially sparsely populated with suggestions for approaches, training, webinars, etc. Dragging the Project Characteristics sliders expands or contracts the dotted-red line depicting the Recommends Lens. Choosing the “Simple”, “Medium”, or “Complex” options from the Choose Model drop-down adds more sliders.

My book “Beyond Agile: Achieving Success with Situational Knowledge and Skills” describes the model, which is fully reconfigurable based on a public Google Sheet spreadsheet as a starting point. You can copy the sheet, amend it to your organizational needs, save it privately, and point the tool to this new private version. Then continue adding or amending Recommendation Types (Approaches, Training, Artifacts, etc) Recommendations (Team Charter, Release Roadmaps, etc) and Project Characteristics you wish to model (such as Team Size, Criticality, etc.)

Organizations use it to describe their proprietary approaches or create hybridized implementations of DA and SAFe with other techniques. You can read more about the Beyond Agile Model here and here and here and here, or just get the book for all the info.

2) Agile Suitability Filter

<Link to Agile Suitability Filter>

This is a pilot implementation of the Agile Suitability Filter published in the Agile Practice Guide. Making the model available online makes it quicker to share, easier to reset and open for all to play with and discuss as a group.

3) Citizen Developer (CD) / Low-Code No-Code (LCNC) Suitability Filter

<Link to CD Suitability Filter>

This is a new pilot filter based on the existing Citizen Developer suitability assessment 2x2 matrix and personal experience. Are the assessment parameters complete?  - Probably not. Are they helpful in discussing with stakeholders about the risks and opportunities of using LCNC – Probably.

What factors do you assess when determining if a product or problem is a candidate for LCNC? I would love to hear from you and create alternative models for testing.

Likewise, what are your thoughts on dynamic models to help facilitate better conversations and decisions? What models do you use, and what would you like to see developed?

Communicating project issues is challenging. Exactly when should we escalate? Who to, and how much of a chance to correct things should be given first? This is why some projects create control limits around critical parameters and develop escalation plans to communicate exceptions and agree on the next steps.

However, on most small to medium size projects, these escalation plans are often missing or left to the project manager's discretion. This creates further problems if the response is too late, not far-reaching enough, or not aligned with sponsor expectations.

Also, what are the expectations for communicating delays, risks and issues at the team level? Do we want to hear when something takes a couple of hours longer than planned (probably not), a couple of days (probably, yes), or a couple of weeks (no, we should have been informed much earlier!)

A "Definition of Broken" (DoB) helps identify and trigger previously agreed exception plans. It is a list of events that allows us to flag and start addressing a problem without the emotions and delays of arguing if it is significant, warrants immediate action, whose responsibility it is, etc.

Just as you do not want to invent a fire evacuation plan during an actual fire, so should exception plans be created before problems arise.

Origins

Agile approaches often use a "Definition of Done" (DoD) to describe the attributes that constitute acceptable. For an increment of software, this may include items such as:

• Coded
• Tested
• Refactored
• Integrated
• Reviewed
• Accepted by customer
• …

Some teams also use a "Definition of Ready" DoR to describe the desired state of requirements. For example, this could be an appropriately sized user story that meets the INVEST mnemonic attributes. Similarly, “Goldratt’s Rules of Flow” describes creating a Full-kit that lists all the items required before starting work on something. Then a sprint or iteration transforms the selected items that meet the DoR into increments that satisfy the DoD.

A Definition of Broken (DoB) is a shorthand way of referring to tolerances and exception procedures. Creating a DoB allows us to objectively describe future issues and resolutions before the stress of a problem clouds people's judgment. I have used DoBs with teams for over ten years and found them valuable shorthand terms for significant impediments.

PRINCE2 popularized tolerances and exception plans procedures in the 1990s. While PMI literature does reference risk tolerances and escalations, the PRINCE2 coverage is much broader. Tolerances can be set up around spending trends, quality metrics, sponsor confidence, widget output, or any project parameter you like. The example below shows a tolerance range around projected spend at +10% and -20%.

So, tolerance is an agreed range of variation, like a control range. However, unlike control ranges, tolerances are paired with an exception procedure to be executed if the tolerance range is breached.

The Downsides of Tolerances and Exception Plans

While it would be helpful to create tolerances and exception plans for a wide variety of project variables, project managers typically do not have time to document them all and get approval from the necessary stakeholders.

As a result, the good practice of defining tolerances and exception plans is often omitted from projects that do not mandate them for safety, regulatory compliance, or quality reasons. Project managers are too busy to create them, and sponsors don't want to review a long list of "What if this happens…" procedures.

Definition of Broken (DoB) Can Help

This is where a Definition of Broken (DoB) comes in, as a lightweight pre-approved emergency response plan. Without all the documentation and signoffs, critical issues that would require sponsor or steering committee intervention can be agreed to in advance. Then, should any of these events occur, there is much less debate before action is taken. This pre-approved action plan speeds remediation and increases the likelihood of recovering from a significant issue.

A Couple of Examples

On a project to implement a 3^rd party membership management software package and write new custom code to link the membership system to various in-house developed systems, DoBs were created for likely but high-consequence scenarios. These DoB situations triggered an escalation report to the project steering committee and automatic inclusion as a discussion item at the weekly sponsor review meeting.

Example 1: Vendor Schedule Delay

The vendor's implementation plan showed the core member billing module configured, installed and tested by the end of May.

DoB Trigger: "Billing module not operational on June 30^th" 

(This was a month after the vendor planned to do it. So the vendor was happy to agree to the DoB trigger. Predictably, come June 30^th, the billing module was installed but still not operational. Having the DoB clause with an approved escalation plan meant no debate or weaseling opportunities for the vendor. The item was escalated, bringing in new vendor staff to expedite the issue resolution.

Example 2: Integration Team not Available

Since the micro-services group was a critical dependency, it seemed prudent to get pre-approval to resolve any delays.

DoB Trigger: "The project team waits more than two weeks for an integration or test- environment to be created."

(In this event, the issue will be raised with the Integration director and escalated to the steering committee. Due to many projects requiring work from the Micro-services team, this happened on three occasions. Fortunately, the team anticipated the delays, and the escalation resulted and quicker turnarounds than other projects experienced.

How is this Different from Basic Risk Management?

DoBs certainly overlap with risk management. The critical difference lies in the socialization and pre-approval of the escalation procedures to expedite action. Having a risk occur and turn into an issue then requires communication and issue escalation.

Using the risk response route is akin to sending a high-importance email to everyone at the affected location that there is a fire and they must evacuate. Then hope they read it, take it to heart, and act on it with the appropriate urgency. Having a DoB with a pre-approved escalation plan is more like sounding the fire alarm. It has been discussed and approved before; now we just need to do what was agreed. Since issues are like fish smells (they get worse the longer you leave them), things we can create upfront to speed resolution are often worthwhile. 

How to Implement DoBs

First of all, we need to be realistic about the effectiveness of DoBs. If we try to create too many, we will not gain the agreement or buy-in for the resolution we need to make them effective. I suggest no more than 5-10. Likewise, they need to be based on critical-consequence threats, not minor impact problems. If we cry-wolf too often, we will be correctly ignored. So, only use them for issues that would threaten the success of the project.

For serial, plan-driven projects, DoBs can be added to the project charter and updated at phase boundaries. Wording can be as simple as:

"The following Definition of Broken (DoB) items identify scenarios that would trigger immediate escalation to the sponsor and addition to the issues list reviewed at biweekly steering committee meeting:

• Building permits not obtained by June 15^th
• The pumping station is not operational at full capacity by year-end
• Telemetry software not completed and accepted by Feb. 28^th“

For hybrid and agile projects, DOBs can be drafted alongside the Definition of Done (DoD) and reviewed and updated at retrospectives as necessary. They can be recorded in the team charter you posted somewhere visible. "Our Definition of Broken (DoB) items that signifies immediate team resolution comprises:

• Customer satisfaction ratings less than 80%
• Servers not installed and acceptance tested by May 1^st
• Page load speeds over 3 seconds
• Critical bug cycle time > 2 days
• Team eNPS below 30”

Parting Thoughts

If the Definition of Done (DoD) is a broadly accepted and understood concept in your organization, consider discussing a DoB. Maybe it makes sense to try them? The criteria can be agreed upon with vendors and team members, product owners, business representatives and any group with a stake in the project.

The goal is not to set traps for future punishment but to promote constructive dialog and consensus about what constitutes a significant problem. Then collaboratively define the escalation procedure and gain agreement to expedite these issues, should they ever occur.

The process has a subtly different effect than documenting risks which is often not a collaborative process agreed to by both the triggering and impacted stakeholders. Creating a list of DoBs and making it visible can change behavior and impact outcomes.

Also, discussing issues and escalation plans with sponsors can uncover priorities not identified in the chartering process. The more we learn about what constitutes success, acceptable variation, or failure, the better we can navigate project decisions and direction to better outcomes. 

Note: I first wrote about the Definition of Broken (DoB) in my book Beyond Agile.

I'm excited to announce that the new PM Illustrated Audio/Video Book is now available! It's an excellent resource for visual learners studying for the PMP exam who would rather watch and listen to content rather than read it. It was a pleasure to partner with Barb Waters on this initiative. Her narration is excellent, and she brings the PM Illustrated book content to life.

If you are a visual learner preparing for your PMP exam or know someone who might benefit from this different learning mode, please head to PMillustrated.com to check it out. There is also a free sample with three videos and >30 minutes of content to get a feel for the format and content before buying.

Project management is a dynamic, vibrant career, so don't study for the PMP exam with dry, boring content. Our comprehension and recall are much stronger for fun and engaging topics. So, use PM Illustrated's visual learning tools as your Guide on the Side for deeper understanding.

See the video book and free samples.

On Friday, September 30, I will be presenting a session on Beyond Agile at the HTEC Project Management Virtual Conference. The session is free to attend and is part of a program that also features Scott Ambler, Sanjiv Augustine, Nader Rad, and Frank Turley. You can register here.

“Yes, And, And”

A colleague recently described Beyond Agile as a “Yes, And, And” toolkit, and I thought it was a great way to summarize the two elements of combining hybrid agile with the Theory of Constraints, and value stream view.

“Yes, And”

“Yes, And” is a term from improv comedy that refers to the idea of not undermining what has come before and adding valuable new elements. For example, we can say, “Yes, Scrum has been tremendously popular partly because of its initial simplicity, And when we add ideas from emotional intelligence, it can be even more effective.” We acknowledge the strengths of Scrum And add valuable extras.

The First “Yes, And” – Welcome Hybrid

Beyond Agile takes a “Yes, And” approach to hybrid agile. It acknowledges that agile approaches are a great place to start for knowledge work projects, And adds that sometimes, traditional approaches can bring useful elements for risk management, dependency analysis, etc.

Of course, Beyond Agile does not just add traditional approach elements to agile. It also adds ideas from leadership and emotional intelligence, along with recognizing the need for industry knowledge. These elements form the 4 overlapping circles of ideas in the Beyond Agile Model.

The Second “And”

The second And in “Yes, And, And” is the removal of insufficiently performing process. So, Yes, we use a hybrid of approaches And relentlessly remove processes that no longer justify their expenditure. This is the elastic property of the Beyond Agile Model Recommendations lens. It is always trying to contract and asking us to see what we can do without, so we focus more time and effort on value delivery.

The Beyond Agile Model defaults to a small set of recommended practices. We must manipulate the project characteristic sliders to open the recommendations lens to suggest more processes. Then we are always asking:

• What can we drop?
• What is no longer worth the effort?
• Can we try without X for a week and see what happens?

For most teams, this takes conscious effort. We get used to activities and events, so asking if we need them or if they are worth it seems unnatural. However, we carry the time and concentration burden of all processes, so asking if they deserve space in our ways-of-working backpack is valid.

Techniques such as visualizing our work time help us see the weight of our processes. It is an application of the Lean concept of removing waste. Any process that costs more than it delivers is wasteful, and the team should ask if they can get the same or similar benefits for less expenditure.

Ultimately we should expand our toolbox with as many valuable techniques as we can since knowledge is weightless. We can hone our skills through training and progressively larger-scale practice. Then become agnostic; it should not matter what camp the tools and techniques come from if they are valuable. Finally, we focus on value delivery, which means relentlessly removing excess process (agile or otherwise.)   

 “Yes And, And” captures the hybrid and value delivery focus nature of Beyond Agile. I look forward to explaining the concepts further on Friday and discussing case studies from teams that have used them. Please join us if you can, or sign up for the event so you can view the recording later.

This article talks about adding tools to the servant leader toolkit.  However, let’s start by examining what servant leadership already contains.

 Servant leadership was popularized by Robert Greenleaf and described as a mindset and set of practices.  It flips the power pyramid, so instead of the team working to serve the leader, the leader supports the team.

Servant leadership is a mindset and value system which recognizes that the team members deliver the project benefits.  So, the best thing a scrum master or project manager can do is serve the team and help them succeed.  This maximizes the amount of value they can produce and increases the capabilities and capacity of the group.

Scrum masters and project managers can practice servant leadership by shielding the team from interruptions, removing obstacles from their path,  and ensuring the team has what they need to encourage growth.  Let’s review each competency in more detail.

1) Sheild the team from interruptions – A leader's critical role is to let the team do their work.  Distractions and low-priority interruptions can come from many places.  They might be requests from superfluous sources or demands for low-priority admin work.  Even quick interruptions cause task-switching and interrupt the flow of the team.

Special-ops and Skunkworks teams have been effective and highly productive partly because they were separated and shielded from interruptions.  So, see what you can do to protect the team from low-priority or non-value-adding activities.

2) Remove Obstacles – Clearing the path of impediments, obstacles, and constraints is a vital role for a servant leader.  It involves both observing the team and listening to them report issues, concerns or frustrations.  Then, remove these blockers and ease the constraints so that team members can be more effective and deliver value.

For example, during a daily standup meeting or team meeting, someone reports delays due to a slow-performing tool and delays from a vendor.  The Scrum master or project manager can take on the role of investigating tool upgrades or following up with the vendor.  This is serving the team, doing what we can to assist with the smooth operation and maximum throughput of work.

3) (Re)Communicate the project vision - a critical role of a project leader is to communicate and re-communicate the project vision.  By creating a clear image of the completed solution and project goals, stakeholders can check and align their decisions and work towards the common project objective.  This is the “Reveal a beckoning summit towards which others can chart their own course” idea.  Put simply, a shared vision helps keep people pulling in the same direction.

When busy executing a project, it is common for divergent views to develop between well-intentioned team members.  Team members' desires for simplicity or to try new technology can diverge from business requirements.  Quality analysts’ desires for completeness and conformance can separate from the sponsor’s wishes for rapid progress and completion.

In Good to Great, Jim Collins writes that a trait of Level 5 Leaders (the most effective leaders of great companies) dedicate a much higher percentage of their work time to communicating and re-communicating project and corporate vision.  Kouzes and Posner believe it is almost impossible for leaders to over-communicate project vision, which is a critical step for effective leadership.

So, don’t have just one vision exercise at project kick-off and then assume you are done.  Continually look for opportunities to communicate the project vision and new ways to illustrate and reinforce that vision.

4) Provide fuel and encourage growth - People need encouragement and support to try new things and deliver in challenging environments.  Servant leaders provide what they need, whether that’s help with a new tool, an introduction to a customer, or just some kind words of encouragement.  Help make them successful as best you can.

We must celebrate small victories (and, of course, major accomplishments) as we go.  It is tempting to save the project celebrations to the end, but we may never meet a successful end without some regular recognition.  Celebrations and recognition are momentum-building exercises.  We must practice them frequently so obstacles can be broken through and the final project goals accomplished.

Servant leaders look for opportunities to grow the capabilities of the team members.  This may be through mentoring, training or providing a safe environment for people to try new skills or roles.  Two powerful benefits occur when we show an interest in our team members' long-term success.

First, the team members will appreciate the interest in them beyond just filling a role.  When people see the opportunity for personal growth, they are far more likely to be motivated to contribute.  Second, by growing the team's capabilities, we are increasing the organization's capabilities and worth.  Subsequent projects and operational work will benefit.

Putting these roles together, servant leaders facilitate rather than manage.  They shield the team from interruptions, clear the path for the team, frequently remind everyone of the destination and provide encouragement and sustenance for long-term success.

Host Leadership

Host Leadership, as explained by Mark McKergow, extends servant leadership with additional roles and activities.  It involves stepping forward to invite the right people and create a productive work environment, and stepping back to allow team members to contribute.

As described by Mark McKergow, It’s about “Engaging a community into facing up to complex, collective problems.”

Many of today’s challenges are fuzzy, ill-defined, interconnected and messy - not single-person-led endeavors.  Think of the race to develop a COVID vaccine.  It was a complex, multi-national, multi-disciplinary collaboration beyond the scope or control of a single manager.  However, a host leader can create a collaborative environment, invite the right participants, and help them do their best work.  This is the role of a host leader.

Host leadership draws on the dinner-party host metaphor to describe roles and positions.  It uses terms such as “working with the guests” to describe learning about the team and their work.  Along with “working in the kitchen” to explain the work behind the scenes to get things ready, maintain supplies, and work one-on-one with people.

I see Host leadership as a complementary set of tools to add to servant leadership.  It provides concrete names and guidance on activities to expand and improve servant leadership.  The stepping forward role also adds a more directive component when it is helpful.

The Six Roles of a Host Leader

The Initiator role is being moved to take action.  Seeing the need for change and stepping forward to do something about it.  The endeavor can be as large and bold as Greta Thunberg’s or as mundane as deciding its time to clean the lunch room.  Leaders step forward and make the first move.

The next role is Inviter.  We need to enlist and motivate the right contributors.  This is a balance of skill and motivation.  The best-qualified people without motivation won't be much help.  We might be able to train well-intentioned incapable people.  However, those we really want Get-it, Want-it, and have the Capacity to Do it.

If we reach out and people do not accept, that’s likely a sign our proposal did not land well and needs to be rethought.  Thinking invitationally is reaching out in a way that invites, rather than insists, people join us on our project or initiative.  It’s about seeing participation as a gift, rather than a contract of their employment.  

The Space Creator role describes constructing the environment where people can contribute.  It includes both tooling (collaboration environments, regular touch points, communication technology) and psychological safety.  Timothy Clark outlines a simple model for understanding psychological safety in his book The 4 Stages of Psychological Safety.

1) Inclusion Safety is the basic human need to belong and be accepted by a group.  People must feel safe to be themselves, including any unique or peculiar attributes.  Without inclusion safety, people feel excluded from the group.

2) Learner Safety is the encouragement needed to learn, experiment and grow.  It requires us to feel safe when asking questions, getting feedback, trying things out and making a few mistakes along the way.  Without learner safety, people will be unwilling to try new approaches.

3) Contributor Safety is having the autonomy needed to build something valuable and make a difference—the feeling of safety required to contribute something and have it judged by others.  Without contributor safety, people will guard their work for too long, waiting for it to be perfect and miss out on early feedback.  They will also not feel like they are making a difference.

4) Challenger Safety is having the permission and “air cover” necessary to challenge the status quo, question why things are done that way, and suggest ways to make something better.  Without challenger safety, retrospectives and improvement initiatives will suffer since no one will be willing to speak up and discuss what is wrong.

The concepts of inclusion, encouragement, autonomy and “air cover” associated with the four levels of psychological safety play an essential role in Space Creator for successful agile teams.

We can help establish this psychological safety by modeling the desired behavior.  Admitting our mistakes, asking basic questions and generally “learning out loud” to show people we do not have all the answers, and it is okay and encouraged for people to be open.

The Gatekeeper role covers the work of establishing team ground rules, operating guidelines and boundaries on scope, tolerances and escalation procedures.  We need to be clear on the norms and expectations that apply.

Team values and ground rules are helpful to capture.  Just as we often develop Definitions of Done, we should talk about Definitions of Broken.  What behaviors or situations would trigger an intervention, review or need to take disciplinary action?

The Connector. A good host helps people meet other guests.  They make introductions and maybe share common topics.  On large teams, we often need to connect people to encourage dialog and early progress; waiting for people to meet and collaborate on their own can take too long.  There is also skill in knowing when to step back after an introduction, getting out of the way to let the magic work and possibilities emerge.

Also, we should try to connect ideas too.  Visualizing concepts, models and constraints can help people see connections others might not immediately find.  The concept of Make Work Visible is powerful and should be encouraged.

The Co-Participant role acknowledges the host leader as a contributor.  Often when the other functions of a host leader are not occupying their time, they can participate on the initiative themselves.  At a dinner party, once the guests have arrived, with people introduced and settled, we expect them to eat too.  So it is with host leadership.  They step back into the mix to participate in the work when their other duties are done, or there is an opportunity.

The Four Positions of a Host Leader

In addition to considering how we spend our time as a leader, it’s helpful to consider where we are.  This does not mean in the team room or our home office, but the positions we take up concerning others.

Sometimes, as leaders, we are in the spotlight.  At the kick-off meeting, explaining the vision or facilitating a workshop are all activities where the leader is front and center and gives off messages.  We need to be comfortable with this or at least tolerant of it.  Sometimes we need to step forward to help explain the goal, the way to it, or the mud slowing our progress.

Going back to the hosting a party metaphor, a great host understands the value of spending time with the guests.  It involves spending time with people individually, asking how they are getting on, and learning about their interests and motivators.  Taking the time to enquire and remember individual goals and interests is a great motivator.  People appreciate it when we recall their ideas, passions, and shared information.

The gallery is a high place above the action.  Somewhere we can observe the action without the distraction of being in the discussions (for now.) Time in the gallery is when we observe from above.  In our team environment, this might include:

• Taking a 30,000 ft view of our progress, speed, and the challenges ahead
• Going for a walk and assessing priorities, opportunities, and new allies
• Pausing to look at the big picture, how will our outcomes help the organizational strategy?

As a host, we sometimes retreat to the kitchen.  A more private place where preparation is done but most of the guests are steered away from.  It is a place we can work in private, reflect and review.  Some family members may come and go – our most trusted colleagues we can confide in and share with, maybe get some coaching.  Scheduling an hour a week in the kitchen can be a valuable experience.

New Ideas or Just Good Leadership Repackaged?

There are no revolutionary new roles or practices being suggested in Host Leadership.  It’s not a radical reversal of thinking or something that requires organizational restructuring to implement.  Instead, the ideas of recognizing some activities need stepping forward and others require stepping back, coupled with the six roles and four positions, are more like thinking tools.  

This makes them more useful.  These ideas can be applied in any organization without special structures or permission.  As a scrum master, team lead, or project manager, we can use them to help us better serve our existing teams.

Early in a project or product life cycle, we can think about the Initiator, Inviter, and Space Creator roles.  Using these personas to up our game and create better-engaged teams.  As the work starts, the Gatekeeper, Connector, and Co-Particpant roles help remind us how we can add more value to our teams.

Knowing about the four positions of being In the Spotlight, With the Guests, In the Gallery, or In the Kitchen can help us reality check where we are spending our time.  If we spend the majority In the Spotlight or In the Kitchen, there is probably a problem that needs addressing.  

Learning More about Host Leadership

My experience with host leadership is drawn from experiments on a couple of software projects.  For much broader coverage, I recommend The Host Leadership Field Book, a compendium of host leadership case studies.  They include education, social care, coaching, and organizational change, among many others.  You can also visit www.HostLeadership.com for newsletters, videos, and other resources.

To read more about the general role of Leading a Team, see task 1.2 Lead a Team at PMillustrated.com

This is part one in a series on leading agile teams from the Beyond Agile book. We will examine what leadership entails and how it applies to agile teams. Then discuss the transition from servant leadership to shared leadership.

EQ as a Foundation for Leadership

As we saw in the previous articles about Emotional Intelligence (EQ), leadership is built on top of EQ. We need good EQ to be able to recognize and manage our own emotions. This is a prerequisite for others to consider us credible and worth listening to. So, a firm grasp of EQ, either gained intuitively or improved through study/training, brings us to the starting line with engaged stakeholders. Then leadership involves bringing this collective willpower to bear on a vision or a journey to our project or product outcome.

We can create backlogs and release plans all we like, but until there is a motivated team with a shared vision of the end goal, it is like trying to push a rope—ineffective. Leadership is focused on creating the pull from the team and giving the team the goal and tools to overcome obstacles.

Leadership is a Huge Topic

Leadership has been around far longer than project management (which primarily grew from the Industrial Revolution.) Leadership goes back as far as people have lived together and worked together to achieve common goals, whether invading a neighboring tribe, traveling to new lands, or building a large structure.

There are over 70,000 published English-language books on leadership. If you read one daily, it would take you 191 years to finish them (by which time there would likely be 70,000 new ones to read). With such a deep history and broad scope, we need a focus to best direct our guidance toward knowledge-worker team execution.

So we will take a product-focused view toward leadership and concentrate on the leadership traits and steps necessary for building and leveraging high-performing teams in complex knowledge-work environments. Unlike many leadership books available, we will not cover leading companies or organizational change; instead, we will focus on leading projects and programs to deliver desired outcomes.

What Leadership Is Not

Unfortunately, there are many myths and misconceptions about what leadership means. So, before we get into how to become a better leader, we should dispel some of these myths that are common barriers to understanding.

The best metaphor I’ve heard for dispelling leadership myths is the “Cowboy leader” by Pinto et al.  When we think of a cowboy, we often picture the lone-wolf movie character who acts independently, often above the law, thinks on his feet, and saves the day. He cuts through bureaucratic red tape, circles the wagons, and rallies the people to overcome the bad guys. Then our hero rides off into the sunset with the pretty schoolteacher and onto his next adventure.

Yet this is just a movie-star definition of a cowboy, portrayed by the likes of John Wayne, Roy Rogers, and Clint Eastwood. Do you know what a real cowboy does? They lead cows. They use their dogged determination to turn and drive bovine herds toward the desired goal. I am not trying to be derogatory here, comparing your company’s staff to unintelligent cows; I am making the point that real cowboys do not typically do a lot of shooting of bad guys and rescuing damsels in distress.

Also, John Wayne, Roy Rogers, and Clint Eastwood are Hollywood actors, not cowboys. They live in big, fancy houses and do not spend much time around farm animals. Would you really trust them to look after cows? Your cows?

The term leadership is often loaded with this romantic notion of a swashbuckling go-getter with a larger-than-life rockstar personality. Yet, in reality, some of the best leaders are quiet, introverted people who care deeply for their teams and stakeholders and quietly grind away toward a common goal.

Real leadership is based on sound theory. It can be learned and exercised on a small scale before being brought to bear on larger groups. Authentic leadership is practiced on mundane things, yet when more significant events occur, the skills and trust of others can be used to overcome significant hurdles.

Additional leadership myths include the beliefs that leadership needs to reside in a single person and that all groups need leaders. Quite often, leadership roles are shared between team members. In fact, it is unlikely that any one person would be solely equipped to lead a team in all circumstances.

Establishing environments where people can step up to lead when the need arises creates resilience and competitive advantage. Likewise, some small teams without the need for high-consequence decision-making can operate just fine without a leader.

What Leadership Is

So, having established that leadership is not swashbuckling behavior or an innate quality of character, let us look at what it is. There are many different leadership models, but the same roles crop up repeatedly. Listing them is the easy part. We will then focus on the more difficult topic of how we achieve them, given all the challenges of project constraints, opposing demands, and people conflicts.

Leaders exhibit the following attributes:

1. Vision
2. Good communication skills
3. Ability to inspire trust
4. Ability to empower
5. Energy and action orientation
6. Emotional expressiveness and warmth
7. Willingness to take personal risks
8. Use of unconventional strategies

Let’s look at each of these characteristics in turn.

Vision - The ability to create and describe an exciting view of the future state. This includes what success looks like and the benefits it will bring to the sponsoring organization, the users of the end result, and the team members who created it. It provides a common goal to guide the team in times of questioning and decision-making. It is what we are aiming for.

Good communication skills - A vision, support, and guidance are useless unless we have a way to communicate them to people. Communication skills are required to inspire, inform, and advise stakeholders. They are also crucial for receiving information and quickly building rapport with a wide variety of groups and individuals.

Ability to inspire trust - Studies show that the greatest attribute people look for in leaders is honesty and trustworthiness. Working for someone we do not trust undermines our feelings of self-worth and respect in the long run. To be an effective leader, we must act honestly and with integrity—otherwise, people will not work with us.

Ability to empower - We should make use of people’s knowledge and skills by trusting them to do a good job. We must also be able to make the team feel capable and develop team members to their fullest potential.

Energy and action orientation - Effective leaders have elevated levels of energy and enthusiasm for work, which is contagious. We must understand that it is impossible to inspire others if we are apathetic or lukewarm in our reaction to the challenges.

Emotional expressiveness and warmth - Leaders must be able to express their feelings openly, but without venting or alarming people. They should not keep others guessing about their emotional state, but instead, be approachable and warm cheerleaders for the endeavor.

Willingness to take personal risks - It is desirable to have some skin in the game, to be personally invested beyond just a role, and to have some reputation or repercussion invested in the outcome. Like successful entrepreneurs, leaders are not risk-averse.

Use of unconventional strategies - Leaders must think creatively and not be constrained by conventional approaches. They are happy to model the desired behavior by trying new techniques and experiments.

These characteristics are the goal; things get more difficult when it comes to achieving them under challenging circumstances.

Shared Leadership: Primary Colors® Model

The Primary Colors Model of leadership was one of the first to recognize that it is extremely difficult, if not impossible, for any individual to possess all the attributes needed to be a complete leader. Instead, it recommends leaders build leadership teams that comprise all the necessary skills.

The Primary Colors Model offers ideas similar to those found in “In Praise of the Incomplete Leader,” a 2007 paper published in the Harvard Business Review. Its authors suggest that successful leadership comprises four capabilities:

1. Sensemaking: Understanding the context of the company and how people operate. Having a talent or knack for explaining these complexities to others.
2. Relating: Being able to build trusting relationships with others.
3. Visioning: Creating compelling images of the future by collaborating with others on what they want and then explaining it.
4. Inventing: Developing new ways to bring the vision to life.

The Primary Colors Model contains three intersecting domains of strategy, operations, and interpersonal skills. It also uses a human-anatomy metaphor to explain these functions and how they interact. The strategic domain is like the head, responsible for thinking; the operational domain is the hands and legs, responsible for getting things done and moving the organization or product forward; and the interpersonal domain is the heart and deals with forming relationships, motivation, and EI.

These domains and functions are shown in figure 11.2.

FIGURE 11.2 The Primary Colours Model of Leadership

In this human-anatomy analogy, the Primary Colors Model places leading at the center, like a central nervous system. It senses, balances, and coordinates all the other functions.

At the intersection of these overlapping functions are three key roles of a leader. Creating alignment is at the intersection of strategy (head) and interpersonal (heart) since it deals with creating a rational and emotional commitment. Team working, the skill of getting things done, is at the intersection of operational (arms and legs) and interpersonal (heart) since it deals with work and motivation. Finally, planning and organizing is at the intersection of strategic (head) and operational (arms and legs) since it deals with planning the work that needs to be done.

Now we know what functions need to happen and that it is unlikely that any single person has all the necessary skills. So, the next logical step is to assess our own skills, recognize our gaps, and go find people with the skills to fill those gaps. This is another instance where having diversity on the team is helpful. Diversity is Darwinian: The greater the diversity in the resource pool, the greater the range of external events that can be responded to successfully.

Tom Peters, author of In Search of Excellence, once joked, “If you find anyone in your organization who agrees with everything you say, fire them! Why pay twice for the same opinions?”

So, diversity is good, but how do we measure it? A simple approach is to assess people’s affinity for or attraction to different work types. Vocation-planning tools used in schools try to determine likely “fit” by assessing people on two ranges. The first range is things or people, and asks if individuals are happier working with things (be they animal, vegetable, mineral, or machine) or happier working with people. People who are interested in things enjoy collecting, constructing, and categorizing them, and analyzing them and their functions. People who prefer people enjoy emotions and idiosyncrasies; they are drawn to people for stimulation and support.

The second range is data or ideas, and asks if people prefer working with data and facts or with ideas and possibilities. People who prefer facts and data tend to be practical, data-analytics types. They are persuaded by logical, here-and-now facts and data. People who are drawn to ideas, possibilities, and theories enjoy what-if scenarios and are divergent thinkers. They may be thought of as creatives or dreamers.

Assessing people on these two ranges helps us determine where we fit and where others on our teams fit. The ranges and categories of preferences are shown in figure 11.3.

FIGURE 11.3 Two Dimensions of Vocational Preference

Here we see three roles and their positioning based on work preference. “Strategic” indicates someone who leans more toward the ideas end of the data-to-ideas spectrum and who is happy dealing with ambiguity. ‘Operational/Technical” shows someone who leans more toward the data end of the data-to-ideas spectrum and toward the things end of the things-to-people range. Finally, “Interpersonal/Supervisory” shows someone who is more comfortable with people than things and who prefers data over ideas.

Incidentally, full personality assessments such as Myers-Briggs, Belbin, or the Big Five typically take about an hour or so to administer. But having team members indicate where on this chart they rate themselves is quick and makes a great retrospective or team-building exercise to illustrate and respect diversity.

In figure 11.3, it is difficult for people to move between these roles as it requires major shifts in focus and interests. The nearer people are toward the center, the easier it will be for them to move into each of these roles.

Combining the Primary Colours Model of leadership with these personality traits reveals additional useful ways to categorize the functions and roles of leadership. Figure 11.4 shows the two models superimposed.

FIGURE 11.4 Primary Colours Model Combined with Personality Traits

Here we see the two job-preference dimensions of things/tasks to people on the x-axis and data/ present to ideas/future on the y-axis. Also shown are ovals representing the personality traits of the people who operate well in that domain and boxes representing the classical elements of air, fire, earth, and water.

Does your team have people that can assist in the roles of Influencer, Relationship Builder,  Implementor, or Strategist? Of course it does, so tap into those abilities. Lean thinking tells us that Non-utilized Talent is a form of waste, let’s not be wasteful and instead increase the team’s effectiveness and the likelihood of success.

The Primary Colors Model is powerful for several reasons. First, it legitimizes the idea of shared leadership and the need for collecting a set of competencies from the team and distributing power. Second, the human-anatomy metaphor creates an easily understood structure for uniting the skills and functions necessary for leadership, which are often described as discrete, unconnected, or vaguely connected elements in other models. Finally, it aligns well with vocational preference models and work types.

Key Takeaways

• Leadership can be shared.
• People have distinct preferences for dealing with things or people, hard facts or ideas.
• Holistic leadership needs to address all these dimensions.

<This is an excerpt from Beyond Agile. In future posts, we will explore additional shared leadership examples and introduce Host Leadership as a framework for implementing shared leadership in an agile team setting.>

• Looking for some PDUs to renew your PMP credential?
• Curious about the agile content added to the PMP exam since you took yours?
• Like to try a gamified, visual-learning experience?

In partnership with Peak Business, this 35-module micro-learning suite provides comprehensive coverage of the new PMP® Exam Content Outline (ECO) and an excellent overview of today’s current project management topics for those looking for a refresher.

Self-Directed Learning

Chart your own adventure through topics and let the platform track your progress via self-assessment quizzes and achievement badges. Starting from a one-page, birdseye overview of the whole curriculum, select topics, master domains, and see your progress via our custom Achievements Grid.

Track Your Progress

Using graphical summaries, cartoons, and humor, we make ideas “stickier” in our minds. Badges, points, ranks and optional leaderboards help provide the motivation and nudges needed to keep you engaged. Work smarter, not harder. Engage the visual, right-side of your brain as well as the list-making, left-side to cut your study time in half and have fun in the process.

Textbook vs. Visual Learning

By using images, we build spatial context and connections between topics. Then, to help us retain it, we can trick our brains into marking it as new, unusual, and needing to be stored away by associating it with the unfamiliar. We still fill in the details with explanations, but the whole concept is sticker in our memory.

For information about this PDU bundle product, visit Peak Business. For details about visual learning for project management, see the main PMillustrated site.

Thanks to Improving for inviting me to speak at the recent Improving Edge Summit. It was a great conference dedicated to leadership this year. A topic near and dear to my heart and the focus of my Leading Answers blog.

My talk was on the Evolution of Leadership and featured ideas from my Beyond Agile book about how organizations are moving from Agile’s empowered-teams/Green/values-driven leadership model to Organic/plural/Teal/shared and host-leadership models.

The session was recorded and I will make it available here at www.LeadingAnswers.com when it is available. We had some great attendee suggestions for the true role of leadership and explored how agile’s servant leadership can be augmented with newer shared and host-leadership approaches.

We mapped agile transformations to the Orange to Green shift from Frederic Laloux’s Reinventing Organizations book and saw how today’s leading, distributed structure companies such as Haier, Burrtzorg, and Irizar use Host Leadership to create organism/community-based self-managing groups.

Many of today’s problems are too fuzzy, ill-defined, interconnected, and messy to be solved or led by a single person. Instead, they require a pooling of ideas and sharing of leadership responsibilities. We discussed the creation of the COVID vaccine as an example. Host leadership outlines roles and stances to develop environments where people co-create and co-lead the development of solutions for today’s wicked problems.

Improving - thanks for hosting me, it was a blast. Improving Edge attendees – thanks for your insightful participation. Readers here - stay tuned for the recording.

Agile approaches "Crossed the Chasm" a decade ago. The organizations we see adopting it today are in the "Late Majority" and "Laggard" categories of Geoffrey Moore's Technology Adoption Life Cycle.

As companies adopt agile because they have to / it's now expected / the industry norm / required to stay competitive / <insert your own reason>, we see more push-back and failures than ever.

Doing something because you have to, rather than because you want to, leads to shortcuts and the wrong mindset. The image below, from Ahmed Sidky, shows agile as a mindset.

In the image above, agile is a mindset described by four values, defined by twelve principles and manifested through an unlimited number of practices.

The correct way to learn agile is to start on the left of this image and learn about the four agile values in the mindset. Then learn about the twelve principles that define agile. Once you understand those, you will see all the agile practices are just implementing agile principles and values in various scenarios to solve different problems. This is the correct, Left-to-Right agile adoption.

Unfortunately, many organizations reluctantly adopting agile are impatient. Mindsets and values sound like unnecessary fluff. "We are serious engineers and don't have time for that kumbaya nonsense. Our people are smart, just show us the practices, and we will figure out the rest." So they start on the right-hand side, and adopt a set of agile practices, not appreciating the values and principles necessary for them to work.

Some practices work; others do not. They struggle to get whole-hearted buy-in and see only patchy pockets of success. Some teams continue trying agile; others revert back to how they were. They become an "Agile? Yeah, we tried that, but it did not work well here" shop. They experienced the right-to-left copying of practices without understanding the mindset, values or principles.

Incorrect Right-to-Left adoptions of agile (or anything) fail because they copy behavior without understanding the supporting structures. The practices we see agile teams undertake are just the visible components of a much larger ecosystem. This is known as the Agile Iceberg.

Supporting the visible practices above the water line is a larger, more significant commitment to the mindset, values and principles below the water line. Without investment in the below-the-waterline components, any attempts to copy and duplicate agile practices will sink and be dropped from practice.

Cargo Cults

Another analogy used to depict right-to-left attempts to cut and paste agile is the Cargo-cult. "Cargo cults" is the term used to explain the phenomenon of blindly replicating outward behavior, hoping that it will yield positive results. It originates from a few scattered instances of Pacific Island tribes recreating replicas of the wartime aircraft runways, control towers, and radios out of wood on remote islands, believing that they would bring back the cargo planes that brought Western goods during the war.

The islanders did not know how control towers or radios worked; they just copied what they had seen, hoping it would bring the benefits they had also seen. Implementing sprints, demos, and daily stand-up meetings without valuing individuals and interactions over processes and tools is just as ineffective as an all-wood radio. All it achieves is to frustrate people and give agile a bad name.

The Solution

Like anything worth achieving, the solution requires some thought and hard work. We need to work one-on-one with people and provide maps, not pamphlets, of how agile works so people can make their own informed decisions at the junctions on the pathway to value delivery.

This may sound like a lot of work, but it saves time and reduces workload in the long run.

Making Sense of Agile

There are thousands of agile practices documented in books, blogs and presented at agile conferences every year and likely many times more that never get reported. We do not need to learn them all; because once we understand a core set, we will see the themes, grasp the goals, and help teams create their own tailored ways of working that support the agile mindset.

Let's review some popular techniques often seen on Scrum teams.

Daily Stand-up meetings – These are the quick, inter-team coordination meets held daily where team members share with their colleagues:

• What they have been working on (or completed),
• What they plan to work on next,
• If any issues or blockers are hampering their progress.

Agile Concepts:

• The team owns the work – team members report to each other, not the Scrum Master or some project manager authority role
• Transparency – openly share information, good and bad, so people stay informed and can make better decisions

Sprint Demo – At the end of every sprint (usually one or two weeks long), the team demonstrates what has been built to the business and confirms what to work on next.

Agile Concepts:

• Frequent delivery – Deliver working software frequently. Working software is the primary indicator of progress.
• The team owns the work – It is the team that demos the work, not the Scrum Master or Product Owner. This demonstrates and builds ownership of the evolving solution.
• Focus on business value – Since the backlog is prioritized by business value, the team should be demonstrating the highest business value work items completed. Also, the discussions on what to work on next also focuses work by business value.
• Transparency – Openly share information, good and bad, so people stay informed and can make better decisions.

Product Backlog – The ordered list of work for the project/product. Prioritized by the Product Owner based on business value. Creates a single queue of work items to focus on.

Agile Concepts:

• Focus on business value – The product backlog is prioritized by the product owner, usually a business representative, not the Scrum Master or other team member, to ensure the project focuses on business value.
• Transparency – By putting all work items in a single, highly visible queue, everyone can see the full scope of work to be accomplished. This (hopefully) eliminates side-agreements or under-the-table agenda items being worked on. Also, since change requests are prioritized in the backlog, they bring visibility to these elements and likely completion dates.

Release Planning – The process of the product owner and development team collectively meeting to discuss, prioritize and estimate features for the next release. By engaging the do-ers of the work in the planning process, we simultaneously: 1) get better insights into technical work involved, 2) generate better buy-in for the estimates created and a stronger commitment to meet them.

Agile Concepts:

• Focus on business value – The business (through the product owner role) drives the planning process.
• Transparency – Features and stories from the product backlog are refined and estimated to create a release roadmap that illustrates target dates for key components of the product or service being developed.

Sprint Planning – This is the planning process one level below release planning. The product owner and development team collectively meet to discuss, prioritize, and estimate the next one or two weeks' worth of development.

Agile Concepts:

• Focus on business value – Work is prioritized by the product owner.
• Engage the team in decision making – The team makes local decisions about how best to undertake the work, how to self-organize, and in what order to undertake technical tasks.
• Transparency – All estimates and progress are discussed openly within the project team. Details about progress, issues, or setbacks are discussed daily at the daily stand-up meeting.

Retrospective – A workshop held at the end of each sprint/iteration to review progress, process and people aspects of the project. These regular inspect, review and adapt sessions typically result in suggestions of things to try differently in the next sprint/iteration. By conducting frequent, short-scale experiments, teams can inspect, adapt and improve rapidly throughout delivery.

Agile Concepts:

• Inspect and adapt – At regular intervals, the team reflects on becoming more effective, then tunes and adjusts its behavior accordingly.
• Engage the team in decision making - The best architectures, requirements, and designs emerge from self-organizing teams. Continuous attention to technical excellence and good design enhances agility.
• Transparency – Be open to talking about issues and ways to improve. Acknowledge there are constantly ways to get better. Recognize and thank teams for looking to improve their delivery capabilities.

Kanban/Task Boards – These are large publicly accessible displays of work done, in-process, and waiting to start. Kanban boards make the team's work visible.

Agile Concepts:

• Transparency – It shows what is being worked on, what has been completed and what is coming next. This information is not the domain of just the project manager, everyone benefits from knowing about it.
• Engage the team in decision making – By sharing the project plan visibly, team members can better alert us to potential problems and solutions.

Seeing the Agile Matrix

In the sci-fi movie "The Matrix", the hero, Neo, develops the ability to "see the code of the Matrix." This is the computer simulation he is living inside. Once he sees this, he understands how things work and can move faster and is more powerful than ever before. It is an "a-ha" moment; now things make sense, and he can see his world's structure and patterns and manipulate them.

It is the same with developing an agile mindset. Once you realize agile is based on a few core concepts, you see them repeated everywhere. These concepts include:

• Focus on delivering value
• Build incrementally
• Gather early feedback
• Inspect, adapt and learn as you go
• Let the team decide as much as possible
• Be transparent and show progress, good and bad

With these ideas in mind, practices such as estimating via planning poker make more sense. We are engaging the team in defining their estimates. We are using a visual, transparent process. It is iterative and incremental. There is inspection and the ability to adapt the estimates if outliers are found.

Everything agile teams do reflects these values. Information radiators are about being transparent and visual. Voting on decisions is about letting the team decide. We do not need to learn every agile practice because we will quickly be able to understand any of them once we recognize the agile mindset, values, and principles.

When making decisions, we can apply these agile concepts. Engage the team, be transparent, focus on value, get early feedback, etc. These are not complex concepts to grasp and are what many of us intuitively try to do anyway. That's why agile, for many people, feels like common sense.

However, it can be quite different from traditional project management's analytical world, which aims to specify everything up front before executing a detailed project plan. It is a mindset shift for some people, but one worth making if your work is complex, uncertain, and frequently changing. Here a Left to Right adoption of the agile mindset, values, and principles is the way to go.

<This article is an excerpt from PM Illustrated: A Visual Learners Guide to Project Management. If you are a visual learner who likes clear explanations, check out PM Illustrated here.>

<This is post 3 in a multi-post series about EI and leadership taken from my book Beyond Agile. Check out Post 1 and Post 2 first if you have not seen them. In this article, we will dive into personal growth and the power of discovering the space between stimulus and response.>

EI’s origins - Mayer and Salovey Four-Branch Model

The precursor to Goleman’s EQ and Bar-On’s EQ-i models was created by John Mayer and Peter Salovey, who published their research in 1990. The Mayer and Salovey model extends the maturing idea we looked at in post #2 and adds layers of sophistication. It is called the Four-Branch model because it describes four branches of emotional skills, going down the table vertically in terms of sophistication and maturity, and moving from left to right horizontally as a timeline from childhood to adulthood.

This is post #2 in a multi-post series about EI and leadership taken from my book Beyond Agile. Check out Post #1 first, if you have not seen it already. In this article, we will explore what EI is and why it’s often such a tricky topic to define due to the proliferation of different models with similar-sounding components.

EI - Better Results by Becoming More Effective

Let us start the EI exploration journey with a process we are all familiar with, growing up and becoming independent adults. Stephen Covey talks about a progression of maturity and effectiveness that people go through as they get older.

We start as children, dependent on our parents for food, shelter, and support in life. How effective we are at accomplishing things grows, as we do, and eventually, we need less support. When we become teenagers and young adults, we become less dependent on adults and more independent. We eventually get jobs, move out of our parents’ homes (hopefully), and are more effective at accomplishing things in life than when we were children. Our level of effectiveness increases as we move from dependent to independent.

Covey says this is as far as many people progress. They learn how to be independent and contribute at an individual level. However, they are missing out on a further, more effective and productive stage called interdependent. This is what can be achieved when we partner and work with other people. When we learn how to collaborate and work with others, our personal limitations no longer hold us back. Other people can overcome our shortcomings.

So, if Mary is great at generating innovative ideas but lacks the patience or due diligence to see them through to fruition, she can partner with Dave, who thrives on detail and can transform ideas into completed products. When they can find ways to work together, they are both more effective than when working independently.

The bridge from the state of being dependent to being independent is called maturity. Parents, high schools, and the school of hard knocks move people from dependence to independence. Hopefully, there are several family members who can help with that transition.

The bridge from Independent to Interdependent is emotional intelligence. Learning how to interact, cooperate, and collaborate with others is not emphasized nearly enough. These practical life skills are hidden behind the unappealing label of emotional intelligence. There is much written about the process, but few people think to investigate further, at least at first. Often, family members possess it intuitively, but lack frameworks or words to effectively describe it.

I am long overdue for posting to LeadingAnswers.com. I have been busy finishing the content and games over at PMillustrated.com. While explaining project management through cartoon animals is fun, I wanted to post some meatier content here.

This is the first in a multi-post series about emotional intelligence (EI) as the foundation for team leadership. The material comes from my Beyond Agile book and explains why a firm basis of EI is critical to becoming an effective Scrum Master, team lead, or project manager. This first post introduces EI and explains its significance.

Leadership and EI work together to create cohesive, cooperative teams. The two approaches support each other and enable organizations and team leaders to build teams that overcome problems and achieve amazing results. However, to understand these topics properly, we need to decompose the system, see how the parts fit together, then tackle them in a logical sequence, which may, from the outset, seem counterintuitive.

Emotional Intelligence

Emotional intelligence (EI) involves learning how to understand ourselves, which in turn helps us work well with other people. It concerns how to communicate, support, empower, and motivate people. It’s important to understand self first, because we are not going to motivate or empower anyone by being a bully, a jerk, or getting flustered.

So, while our end goal is effective leadership, which is like an electric motor that drives high-performing teams, we first need to understand that it is powered by EI—the electricity that powers the motor. For this reason, we will start with EI (which starts with ourselves) and then work up to powering the leadership engine.

Why EI Is More Important than Intelligence Quotient (IQ)

To take advantage of our intelligence, our IQ, we first need good emotional intelligence EI. Regardless of how intelligent or gifted we are, if we turn others off with our offensive or abrasive behavior or cave in under minimal stress, no one will stick around long enough to notice our IQ.

A quick exercise to illustrate the importance of EI over IQ is to think of a mentor who has had a significant impact on your career. List five properties that made that person such a valuable influence for you. Now examine the list and categorize the properties as EQ or IQ related. Items such as caring about you, taking an interest in your development, and demonstrating integrity and honesty are all EQ factors. Items such as master strategist, guru-level coder/architect/statistician are more IQ based.

Chances are your most influential mentor used more EQ skills than IQ—they nearly always do. That is who we are trying to emulate. It will not happen overnight, but it is better to be on the right road, heading in the right direction, than totally unaware of the destination or direction to get there. In the June 21, 1999, issue of Fortune, cover story “Why CEOs Fail” reported that unsuccessful CEOs put strategy before people issues, while the most successful CEOs used integrity, people acumen, assertiveness, effective communication, and trust-building behavior. Projects are like mini organizations and the same skills apply.

Team leaders rarely struggle with core competencies in planning, change management, or reporting, yet they often struggle with communications, failing to see other people’s perspectives, and understanding the impacts of their actions.

Tackling the “Emotional” Elephant

The term emotional intelligence needs a makeover, a rebranding. The word emotion has too many negative connotations, unbefitting for the rocket fuel, the “secret sauce” that it really is. It should have a cool, powerful name like “results multiplier”, “smarts accelerator”, or “team unifier” because that is really what it does.

However, we have inherited the term emotional intelligence and it seems to be sticking around for now. That is a shame because too many people avoid it and instead stumble around researching motivation and conflict-resolution topics, hoping to get better at dealing with people, when everything they are looking for is laid out for them in the domain of EI.

So, get over any notions you may have about it being soft or too feminine to apply to your projects. If your project involves people in any way, understanding EI will improve your results. The good news is that unlike mathematical, logic, and language intelligence, which are measured in IQ tests and usually peak around age eighteen, EI develops more slowly and typically does not peak until our forties or fifties.

<To read more about EI and its relationship to effective leadership look out for the remaining posts in this series, or get the book Beyond Agile for the complete picture and supporting detail.>

The next 7-week PMI-ACP Supported Study Group with Mike Griffiths is starting soon. Register by January 15^th for Earlybird pricing of just $99 (regular $199).

This live 7-week online book-club / self-study program works as follows:

• Read one chapter of my PMI-ACP Exam Prep book each week
• Join me for a one-hour Zoom call to review topics and ask any questions you may have
• Get access to a private LinkedIn group where you can ask additional questions and discuss topics with peers
• Receive exclusive chapter summaries, mindmaps, additional sample exam questions, and extra resources
• A small group capped at 25 people.

At the end of the 7-week program, we will have covered all the material, and you should be ready to take the exam.

I wanted to offer a more affordable option than online training for a small group of people who are willing to self-study. This option allows people to clarify topics with me and interact with others who are also preparing for their PMI-ACP exam.

Frequently asked questions:

• Q: Does the course include a copy of my PMI-ACP Exam Prep book? A: No, you will need to have or buy your own copy of my book. We will use the latest version, the “PMI-ACP Exam Prep: Updated Second Edition.” This can be purchased, generally cheaper than Amazon, at the RMC website.
• Q: Is the book available electronically? A: Yes, you can choose the electronic format or paperback.
• Q: When will the weekly Zoom calls occur? The Zoom calls will be on Saturday mornings starting January 22^nd at 11:00 Eastern Standard Time. See WorldTimeBuddy to convert to your local time.
• Q: Will the Zoom calls be recorded? Can I watch one later if I miss a session?: A: Yes, the Zoom calls will be recorded and available for participants to view later.

Introductory price $99. This price includes the weekly Q&A Zoom calls, LinkedIn support group, and exclusive resources (summaries, mindmaps, extra sample exam questions, etc)

If you would like to participate or learn more, please send me an email: 

Mike <at> LeadingAnswers.com.

Stefan Wolpers recently reposted his survey “Would you recommend SAFe®?” on LinkedIn and it prompted some excellent discussion. One comment I liked by Maxwell Lamers summarized a common view of SAFe® succinctly as “The framework itself is built on solid ideas, and there is nothing inherently evil about the framework. The trouble comes in the implementation.” Maxwell described problems when SAFe® is not fully implemented, but I think taking on too much process and training is a problem in its own right.

Process Has Weight, but Knowledge Is Weightless

Ceremonies and processes have weight and take time to undertake. This is okay if the process adds sufficient value to warrant the expenditure. However, often they do not add enough value, or the processes continue to be used beyond the point where they are still valuable and become a net drain on a team’s efficiency.

Knowledge, on the other hand, is weightless. There is no penalty for collecting knowledge. Understanding a wide variety of topics and techniques allows us to use only the most efficient and appropriate for our current circumstances.

We can visualize process as the baggage and tools we carry on our project journey. Like going on a hike, some small undertakings may require no additional support. We can just turn up and do them. As projects get longer and more complicated, just like a longer hike, we might be glad of a raincoat and some food and water for the trip.

Complex and hazardous endeavors may require sophisticated tools (and knowing how to use them). The goal is to take just what we need, understanding that the more we elect to bring, the better prepared we are, but the slower we will go. The more energy you use carrying a heavy backpack of tools, the less energy you have available to move toward the project goals. So, we need to balance responsible process with goal focus and progress.

Problems with Agile Frameworks

The agile community is abuzz with discussions of and promotions for scaling frameworks that claim to help organizations apply agile approaches to large, complex scenarios. These frameworks include SAFe, LeSS, and Nexus and offer reasonable solutions for common scaling problems. They are generally well researched and supported by a wealth of training courses, credentials, and certified consultants. However, they come with some fundamental problems as well.

• Agile Myopia - Agile scaling frameworks suggest agile approaches as the only solution. When you have only a hammer in your toolbox, all problems look like nails. However, sometimes the best way to deal with that traditional stakeholder who wants a WBS is to give them a WBS. Likewise, maybe some aspect of your project is defined and repeatable, so why not use a traditional plan-driven approach for it? It is both arrogant and ignorant to believe agile is always the best solution.

• Software Focused – The agile approaches, scaling frameworks, and tool kits grew out of the software development space. Unfortunately, they have not shed their software-focused roots and still contain concepts based on software architecture. That might be okay for consultants who can filter out these elements and convert the ideas to other industries, but it is an impediment to sharing ideas and getting a broad spectrum of stakeholders on board.

• Buffet Syndrome - When faced with a buffet of tasty-looking food, there is a tendency to take more than we need. With so much information available in these tool kits, most organizations and teams try to adopt too much process leaving too little energy for the actual project goals. It is fine to understand the theory (knowledge is weightless), but when you start using these rich frameworks, the process weight overwhelms most organizations.

Often, speed of delivery and the ability to quickly react to changes (key agile benefits) are lost by organizations now using overly heavy frameworks. As focus shifts to training, learning new terminology, and roles like Release Train Engineer, less effort is directed to project goals, with predictable results.

Agile approaches are not always the best tools for the job. Like any good tool, agile tools are great for their intended purpose but are no panacea or silver bullet. Also, the size and depth of scaling frameworks create distractions of focus and dilute team effort from project goals. So, avoid framework consultants, training, and certification programs; we cannot afford distractions from the fundamental goal of completing a project.

Beyond Agile Avoids Agile Myopia and Buffet Syndrome

Unlike the large scaling frameworks, such as SAFe®, Beyond Agile avoids Agile Myopia and Buffet Syndrome by being simultaneously broader and more selective in its recommendations.

Beyond Agile recognizes that processes carry implementation weight, yet knowledge is weightless. So, it recommends learning much and implementing little—just the most relevant to retain maximum team effort toward the project goal.

The dynamic model changes based on project and organizational characteristics, recommending the highest-value-added approaches for the situation at hand. Some key concepts:

• There is no single, simple model for complex projects.
• Process carries weight, but knowledge is weightless.
• Guidance needs to be dynamic based on project and organizational characteristics.

Chasing “Done” Drift

For most modern projects, the destination is a moving target, and it is usually moving away from us. The longer we take to deliver a project, the more likely the endpoint will move further away to keep up with new competitor products, industry expectations, sponsor requests, etc. I call this phenomenon “Done” Drift because what constitutes “Done” will likely evolve during a project or product life cycle. So, we want to get to the destination as fast as possible without diverting energy on nonessential work.

We need to analyze all activities and processes that do not contribute directly toward the project goal. In the figure below, 100 squares represent 100 percent of the team’s effort toward the team goal. If 5 percent of their time and energy is spent on non-value-adding process, such as excessive agile ceremony focus, they can only direct 95 percent net toward the project goal.

The more process we add, whether it is necessary corporate process or cool new team activities, the more delivery capacity we remove from the net vector of progress toward the end goal (that is always moving away from us). The final image above shows an additional 10 percent of corporate process, and the net vector of progress is reduced further.

These images illustrate the double whammy dilemma. First, the end goal is always moving away from us—the longer we take to get there, the more we will have to do to declare success. Second, every call on the team’s time takes away from their ability to make progress toward the goal.

The numbers in these examples are conservative. Think about how long you spend on your projects in value-adding activities versus non-value-adding company process, meetings, or producing three sets of time reporting, etc. All the time and focus not directed toward the end goal are distractions. Plus, when you give people enough distractions, they lose energy and start making mistakes because of the interruptions of constantly switching tasks.

Laser Focus

A 40-watt light bulb will barely light a room, while a 40-watt laser can cut through aluminum, leather, and wood. It is the same light energy, just focused instead of diffused.

So, while it is great to be aware of many different approaches, we must always be alert to the costs. Every interruption and call on your team’s time that is not directed at the project’s end goal is reducing their capacity.

While it is extremely valuable to look beyond agile for guidance, we need to maintain a strict filter on what and how much we use from any approach. So, expand your toolbox, hone your skills, become domain and tool agnostic, and then direct maximum effort toward the project goal.

This expands the familiar DevOps model:

With a further dimension or loop as shown below:

The challenge (and skill of being a good leader) comes in using the minimum amount of the most appropriate approach for the situation to get the job done.

The Stage and the Spotlight

So far, we have explored two core ideas of the Beyond Agile Model (BAM). The first is that the project characteristics define the size and scope of the recommended approaches, training, and artifacts to consider for that project type. This is akin to setting or defining the stage we are working on.

The second idea is to be careful and deliberate about what to focus our attention and our team’s attention on since we can easily lose focus on the project end goals. To extend our stage metaphor, this is the spotlight that suggests what we should focus on.

These two ideas are used together in the model to define the recommendations scope—the dotted red line representing the stage encompassing everything in scope for us to call upon. Then the goal focus would be a spotlight shining on that stage, illuminating what we are to focus on.

The aperture of the Beyond Agile recommended-approaches scope is elastic: it is always trying to shrink, returning to a state where less is included. Project and organizational factors stretch it larger but also create tension. As soon as the approaches no longer justify their expenditure, they should be eliminated or pared back.

The spotlight is controlled by our economic view of decision-making. This means we ask, “Where is the next best dollar spent for the project?” Should we be building features, responding to issues, or answering a stakeholder request?

As project lead, we continually evaluate priorities and readjust the focus to optimize value delivery and stakeholder satisfaction. It is no use ignoring stakeholders to focus on building features or diverting the whole team to explore every new question or request. Instead, we dynamically readjust the team focus of effort to bring the most valuable outcomes.

Expansive scaling frameworks may look appealing since they appear to hold all the guidance we need. Yet this masks two silent killers of performance Agile Myopia (the tool you might best benefit from using next lies outside of the agile toolkit) and Buffet Syndrome (trying to use so much stuff and train so many people in it all will kill off any ability to deliver meaningful value.)

The solution is simple to describe but requires discipline to implement.

• Start with agile but also look beyond it for your tools.
• Ruthlessly refactor and keep removing process to focus team effort on the goal

Essentialism

It’s the same core idea as described in the book Essentialism, just applied to teams and value delivery. The book summary site Reading Graphics has an excellent visual summary.

(Image Credit: Reading Graphics)

The Beyond Agile Model recognizes Agile Myopia and Buffet-Syndrome as real threats to performance and provides an alternative.

It is not a one size fits all solution. It cannot be boiled down and printed on a pamphlet for memorization or easy access. Instead, it is more like a map you consult on your team journey multiple times to make local decisions towards your goal.

See more in the Beyond Agile book.

Now that my Beyond Agile book has been published, I would like to thank people who helped shape its content and ideas. David Anderson has done much to popularize and explain lean and the Theory of Constraints thinking.

The Kanban Method can teach agile practitioners many useful ideas about incremental improvement, successful organizational change, and improved team performance. So, rather than considering it an alternative to agile approaches, I like to think of it as a compliment, another source for ideas, tools, and solutions.

We have a tendency to get attached to our personal favorite agile approach, whether that is Scrum, XP, or something else, and regard alternative approaches as somehow inferior or derivative. However, the Kanban Method has some useful additions, so let us see what it has to offer.

First, many people are confused between kanban and the Kanban Method, so it is worth some clarification. The Japanese word kanban (usually with a lowercase k) means “signal,” “sign,” or “large visual board.” Agile teams often use kanban boards to visualize their work. These kanban boards typically show queues and work in progress (WIP). They may also show WIP limits for activities and expedite paths for urgent work.

The Kanban Method (usually capitalized) is a complete process for defining, managing, and improving the execution of knowledge work. David Anderson developed it in 2007 and, like agile, has its own set of values, principles, and practices. More than just using kanban boards to track and manage your work, it is a full lifecycle approach for running and improving knowledge-work projects.

David and I worked together in the early 2000s on the Agile Project Leadership Network (APLN) board. He appreciated the concepts of agile and combined them with concepts from Theory of Constraints and lean design to develop a method focused on the flow of work that could be applied to any knowledge-work scenario. Unlike agile approaches that suggest a complete switch to agile work execution, Kanban starts with the process you have right now and provides tools to improve its service.

This makes the Kanban Method much easier to adopt, as no big upheaval, retooling or enterprise-wide training is required. Instead, the Kanban Method principles are applied to the way things are currently done.

Kanban Principles

• Change management
• Start with what you do now.
• Agree to pursue improvement through evolutionary change.
• Encourage acts of leadership at every level.
• Service delivery
• Understand and focus on your customers’ needs and expectations.
• Manage the work; let people self-organize around it.
• Evolve policies to improve customer and business outcomes.

Based on these principles, three parallel and ongoing agendas (themes of work) are employed:

Kanban Agenda

• Service orientation: Look outward and focus on performance and customer satisfaction. Ask How can we meet and exceed customer goals?
• Sustainability: Look inward to find a sustainable pace and improve focus. Make intangible work visible and then balance demand with capability.
• Survivability: Look forward to remain competitive and adaptive to more change. Scan for the emergence of disruptors and value diversity to better handle change.

Throughout all the approaches, a core set of values based on respect and collaboration is embraced. These are:

Kanban Values

• Transparency: Sharing information through straightforward terms improves the flow of work.
• Balance: The understanding that competing elements must be balanced for effectiveness.
• Collaboration: People must work together to be effective.
• Customer focus. We must know the goal for the system.
• Flow: The realization that work is a flow of value.
• Leadership: The ability to inspire others through example, description, and reflection.
• Understanding: Kanban is an improvement model that starts with self-knowledge.
• Agreement: The dynamic co-commitment to move together toward goals, respecting, and where possible, accommodating differences of opinion.
• Respect: Valuing, understanding, and showing consideration for people. A foundational value underpinning everything else.

We can use the Kanban Method to help introduce positive change into a team or organization. The “start with what you do now” and “agree to pursue improvement through evolutionary change” concepts are nonthreatening and difficult to argue against. So, if faced with an organization or department that is reluctant to change its ways, the Kanban Method is an excellent approach.

It also brings some great insights often missed in agile approaches. For example, since knowledge work is invisible, managers may not know how much work someone has on their plate. Encouraging people to make their work visible helps them show and explain their workloads to others. It also enables coworkers to see what people are working on and then pitch in where they can…”

Thanks, David, for your popularization of and explanations of Theory of Constraints thinking. They are more relevant today than ever as people in organizations everywhere look to transform their work.

Now that my Beyond Agile book has been published, I would like to thank some people who helped shape its content and ideas. Alistair Cockburn and Joshua Kerievsky helped me appreciate the balance between people-focussed activities and effective processes.

“...Agile approaches combine a mixture and equal balance of people and process approaches to delivery. One way to picture these interwoven elements is like the twin strands of DNA. In figure 4.1, we see a blue thread of people elements such as empowerment, collaboration, and team decision-making, mixed with gold process elements such as backlogs, prioritization, and short iterations.

If you have not noticed it before, agile approaches weave people elements and process elements together through the agile mindset, values, and principles. For simplicity of understanding,  we pull these elements apart to talk about them individually, but in reality, they are inextricably linked and self-supporting, like the blue and gold elements shown in figure 4.2.

The people and process elements are present in all views of agile, no matter how you slice it. Also, they are in an equal balance. This is not a matter of coincidence or hidden code, but rather the sign of a balanced system. Let’s look further.

The Agile Manifesto has two values focused on people and two focused on process:

When we examine the 12 Agile Manifesto principles again we see six focused on people (shown in blue) and a counterbalancing six based on process (shown in gold).

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable Sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams. 
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Let’s examine the frameworks of Alistair Cockburn’s Heart of Agile and Joshua Kerievsky’s Modern Agile, first looking at the original models and then superimposing views of people and processes.

In Alistair’s Heart of Agile model, the Deliver and Improve process concepts are complemented by the Collaborate and Reflect people-focused concepts. Likewise, Joshua’s people-focused Make people awesome and Make safety a prerequisite are balanced and complemented by the ideas of Deliver value continually and Experiment and learn rapidly.

Both models are evenly balanced between people and process advice; this fact, along with their clarity and simplicity, is what makes them both powerful and compelling.

We should always be aware of these two elements in the tools and approaches we use. Additionally, looking for a healthy balance of attention within teams is a useful diagnostic. People sometimes have a personal bias or natural aptitude for the people side of things, or for the process side of things. So why not ask the team if they think the system is in balance and, if not, what they suggest to restore to balance any imbalances?..."

Thank you, Alistair and Joshua. Your insights and skills in distilling ideas have helped many people increase their understanding of collaboration and teamwork.

Last month I did a 20-minute overview of my new Beyond Agile book for the Washington D.C. Lean-Agile MeetUp group hosted by Sanjiv Augustine.

I outline how Beyond Agile grew from studying high-performing teams and trying to distill what they did differently than most other teams. In the video, I cover Agile Myopia, Buffet Syndrome and the need to drop agile processes when they no longer bring enough value to warrant their use.

I would like to thank Sanjiv and the entire team at LitheSpeed for hosting me and allowing me to share this video with you here.

Anyone interested in my Beyond Agile book can get a paperback or electronic version here.

It has been 10 years since the PMI-ACP exam was created, and I published my PMI-ACP Exam Prep book. I recall the Steering Committee meetings where we discussed what we believed was necessary for agile practitioners and team leaders to have experience in and an understanding of.

Since then, the exam has been updated a couple of times based on Role Delineation Studies (RDS) and Job Task Analysis (JTA), which is how PMI surveys practitioners and asks what techniques are commonly used. However, the core content has mainly endured unchanged, which is testimony to its usefulness.

I remember discussing the scope and goals for the credential among the committee that comprised: Alistair Cockburn, Mike Cottmeyer, Jim Cundiff, Jesse Fewell, Mike Griffiths, Ahmed Sidkey, Michele Sliger, Dennis Stevens and PMI researchers.

In addition to an agnostic understanding of Lean, Kanban, Scrum and other agile approaches, we also agreed people should know about the basics of servant leadership, conflict management, team decision making, and coaching. So our scope included more than just Lean and agile; it had a little leadership and emotional intelligence.

At the time, someone suggested a three-tier credential consisting of something like Agile Basics, Agile Journeyman (journeyperson), Agile Consultant that mirrored Shu-Ha-Ri. PMI leadership rightly reined this in, explaining it was a good idea, but how about we just focus on getting the basic level credential created for now.

PMI was correct to focus on the universal fundamentals. As we get into more advanced topics, there is no single correct answer. So, topics like agile scaling frameworks, strategies for motivating teams, the pros and cons of different leadership approaches that get deeper into agile, leadership and emotional intelligence were never tackled but are topics that my blog readers know I care deeply about.

My new Beyond Agile book is my exploration of these topics (plus others.) I dig deeper into unlocking the power of individuals and teams. How can we encourage better engagement, focus on the project goals, and ditch non-value-add mindsets and processes? These are based on my experiences and research.

You likely won’t agree with everything I suggest, and that’s fine; not everything will work for your situation. However, I am confident you will find many valuable concepts and connections between ideas you thought about separately before.

As the book title suggests, it goes beyond agile. Sometimes the best way to tackle a problem might be with a plan-driven approach. Agile Myopia is the mistaken belief that every project situation has an agile solution.

I am more of a pragmatist. Sometimes, the best way to assess and analyze risk is with the risk management process from plan-driven project management approaches. We may then choose to implement the risk responses in an iterative, incremental way via our backlog and spikes, but that again is being pragmatic.

My previous post mentioned a disconnect between teams being agile and the highest-performance teams I was able to work with. These high-performing teams hardly discussed agile concepts or paid much attention to the agile ceremonies, although they lived the mindset emphatically. Often what set them apart was the deep industry experience and knowledge they had gained, making them trusted partners within the business groups they served.

I set out to define what sets high-performing teams apart and outline the steps to replicating them. There may be no formula but I did uncover a set of knowledge, skills and thinking tools people can use to chart their own course. It represents the What’s Next beyond the ideas in my PMI-ACP books and provides a broader landscape to explore. I hope you enjoy it.

I am excited to announce my new book “Beyond Agile: Achieving success with situational knowledge and skills“ is launching. It is available now from RMC in paperback or electronic form here. This post explains the name and motivation for the book. Future posts will profile the content.

Background

Since helping create DSDM in 1994, I have been working on agile projects for 27 years. In that time, I have personally been a member of around 30 teams, coached and consulted with about 400 organizations and taught agile to over 2,000 team leads and project managers worldwide. Statistically, most were around average, a few were really dysfunctional, and less than 10 were exceptionally productive.

Problems

Around 8 years ago, I noticed many capable teams were adopting agile but still not being very productive. They had embraced the mindset and were doing all the right things, but success still eluded them. As someone who had dedicated their career to spreading the word about agile and helping organizations adopt it, this was extremely concerning for me. What were they doing wrong? What was I doing wrong?

Researching Successful Teams

So I went back to study the small number of exceptionally productive teams to look at what they did differently. While they understood agile remarkably well, they did not emphasize its use. Instead, they used a clever mix of agile, leadership, emotional intelligence and industry-specific knowledge to get the work that needed doing today done.

Patterns and Results Emerge

Patterns emerged, and I explored further. Using these techniques, I was able to help organizations turn around struggling projects and programs. As a result, we outperformed expectations, delighted stakeholders and won a PMI Project of the Year award. One organization documented our approach and submitted it for tax credits in the Canadian research and development SR&D program. It was successful, and they received several millions of dollars in tax credits. The Beyond Agile Model was developed, and this book documents the components.

The Obvious, Non-Obvious Need to Remove Process

The Beyond Agile Model has agile at its core; it also layers in additional ideas while encouraging teams to discontinue practices that no longer add sufficient value. Since there are only so many hours in the day, focussing more effort on delivery requires dropping other activities - even if they are agile. It was obvious once I saw it. The most productive teams I studied spent more time delivering and less time on agile ceremonies and other tasks. The non-obvious part was learning what to drop since it varies from team to team, and the book explains the process.

In future posts, I will explain some of the core ideas. Until then, I just wanted to let you know the book is finally done and available here.

We intuitively know that a successful agile adoption requires more than copying agile practices. It needs more than just working in short iterations and having daily stand-up meetings. But can we label those missing ingredients?

You may have seen the “agile iceberg” model that shows the visible practices agile teams perform as the tip of an enormous iceberg supported by a mindset, values and principles. However, terms like “values” and “mindset” are intangible and difficult to reconcile with traditional skillsets.

Organizations fail when they try to switch to an agile way of working by just implementing the visible agile work practices without the invisible supporting components. They fail because they are missing two key elements:

Is infighting damaging your team morale and retention? Do you know what types of conflict are healthy and which are not? When you do intervene, do you have a strategy, or just ”wing it” and hope for the best?

People have different ideas; this diversity helps us overcome any individual shortcomings. It also means conflict is inevitable on projects. Whenever we have people contribute different opinions about a solution, there will be some level of conflict. Minor disagreement in the pursuit of a better solution is positive and welcome. Persistent bickering and personal attacks are destructive and need to be addressed. So how do we do that?

• Do you need relevant, high-quality articles for your corporate website?
• Are you looking for an expert in leadership, agile, or project management?
• Maybe you require some training materials, exam preparation support, or remote coaching?

I am available for remote work. If you like the ideas on this site or in my books, please get in touch, I would love to discuss opportunities to work together.

Details

Long before the COVID-19 crisis, I reduced traveling for consulting and training due to family health issues. I have worked mainly from home for the last five years and have been fortunate to stay busy. Now, because of COVID-19, a couple of my regular clients have suspended operations, and I have some spare capacity.

Please get in touch to discuss consulting, mentoring, courseware development, and writing opportunities. My email is [email protected]

In his best-selling book Drive: The Surprising Truth of What Motivates Us, Dan Pink explains three attributes (Autonomy, Mastery, and Purpose) that people need to feel satisfied and motivated at work. It is a great book, but we can do more. Drive only gets us started. As project managers, we can do more to help the people on the projects we manage.

Remember, Nobody Wants to Be Managed

This is the third sample from my new Kindle book “Agile Illustrated: A Visual Learner’s Guide to Agility”. The book is a graphical introduction to the agile mindset and servant leadership behaviors for working with agile teams. If you missed the first two samples you can find them here and here.

Also, just in time for Christmas, Agile Illustrated is now available as a physical paperback book. So if you prefer to hold a physical book rather than read a Kindle book you can now get your hands on a copy. Or, if you would like to give a copy to a manager or executive who is unlikely to read a normal length book on the agile mindset and how to support agile teams then buy them a copy as a gift.

At just 88 pages and mainly pictures it is a quick read that explains the agile values, principles and servant leadership behaviors needed to support agile teams. Available from your local Amazon online store, the US link is here.

Today we will review Team Performance. The Team Performance domain includes Team Formation, Team Empowerment, and Team Collaboration activities. (Anyone taking the PMI-ACP exam should expect to see 18-20 questions on this topic.)

Here is a mindmap showing all the tasks, we will then review them one at a time.

 Team Formation

 Task 1 – Jointly create team norms

Organizational agility is the ability of an enterprise to change direction, realign and succeed in volatile, uncertain business environments. It requires sensing emerging trends and actively listening to customer requests, then acting on this information and making the changes required to position the organization for where it needs to be in the future.

Small organizations can change direction quickly because they have fewer people or processes to change. Most medium to large-scale organizations have considerable mindset inertia in the form of strategies, multi-year plans, in-flight programs, and projects, etc. When fundamental change is required, it can be difficult to turn these large elements that have gathered their own momentum through the day-to-day behaviors of staff.

Here is the second sample from my new Kindle book “Agile Illustrated: A Visual Learner’s Guide to Agility”. The book is a graphical introduction to the agile mindset and servant leadership behaviors for working with agile teams. If you missed the first sample on the Agile Manifesto, you can find it here.

Today we will revisit the Declaration of Interdependence. A lesser-known cousin to the Agile Manifesto, the Declaration of Interdependence was created in a few years after the Agile Manifesto to describe how to achieve an Agile Mindset in product and project leadership. It describes six principles essential to agile project teams. We will review them one by one.

 1 – We increase return on investment by making a continuous flow of value our focus.

Amaze your customers; keep giving them what they ask for!

Over the next few weeks, I will be featuring samples from my new Kindle book “Agile Illustrated: A Visual Learner’s Guide to Agility”. The book is a graphical introduction to the agile mindset and servant leadership behaviors for supporting agile teams.

Let’s start with the Agile Manifesto:

The Agile Manifesto was created during a meeting in February 2001 that brought together a number of software and methodology experts who were at the forefront of the emerging agile methods. Let’s look at the values one by one.

Value 1 – Individuals and Interactions over processes and tools

While processes and tools will likely be necessary, we should try to focus attention on the individuals and interactions involved. This is because work is undertaken by people, not tools, and problems get solved by people, not processes. Likewise, products are accepted by people, scope is debated by people, and the definition of a successfully “done” project is negotiated by people.

What will help set up a project for success is an early focus on developing the individuals involved and an emphasis on productive and effective interactions. Processes and tools can help, yet projects are ultimately about people. So, to be successful, we need to spend the majority of our time in what may be the less comfortable, messy, and unpredictable world of people.

Value 2 – Working software over comprehensive documentation

This value speaks to the need to deliver. It reminds us to focus on the purpose or business value we’re trying to deliver, rather than on paperwork.

Thanks to everyone who downloaded my new eBook “Agile Illustrated: A Visual Learner's Guide to Agility” you made it #1 Amazon Hot New Releases for “Technical Project Management”, along with #1 Amazon Best Seller in “Computers and Technology Short Reads”, and even #1 Amazon Best Seller in “PMP Exam” - which is odd because it is not even about the PMP exam.

I am excited to announce a new eBook “Agile Illustrated: A Visual Learners Guide to Agility”.

It is a short, graphical overview of agile and agile team leadership published as an Amazon Kindle eBook.

Using mind-maps, cartoons, and short summaries it covers the agile manifesto, the declaration of interdependence for agile project management, and each of the 7 Domains and 60 Tasks covered in the PMI-ACP exam.

It is short and light read but a powerful study aid for anyone preparing for the PMI-ACP exam. It also serves as a great executive summary for instilling an agile mindset and teaching the leadership behaviors to serve agile teams. With over 70 illustrations, mind-maps and cartoons it engages spatial and visual memory making the points easier to recall and explain to others.

If you think in pictures and like to see how ideas fit together this will be a valuable resource.

Phew, the wait is over! I have been wanting to talk about this for what seems like ages and now the official announcement is out! If you have ever been frustrated by the PMBOK Guide now here’s your chance to fix it.

We are looking for volunteers to write and review the next edition of the PMBOK Guide. However, this will not be just an update, instead a radical departure from all previous editions aligned with PMI’s new digital transformation strategy. That’s all I can explain for now, but more details will be announced when I can say more.

Meanwhile, we would like people with knowledge of the full value delivery spectrum (waterfall, hybrid, agile, lean, etc.) to participate.

Now that a software “Done” Milestone is more like a Tombstone

If you work in an industry that has digital products and services then the Product Development trend will impact you. As software becomes more critical to business operations and product offerings we are seeing that software projects do not end.

Many organizations are transitioning to become software focussed organizations that offer specialized services. Amazon is a software company with retail (and cloud) offerings. Banks are increasingly digital companies with financial services. The same with insurance, travel, music and even commercial goods. The cost of developing the software in new vehicles is now greater than the cost of the engine. It has become the single most expensive component, even in internal combustion engine vehicles with no autonomous driving features.

These websites and software services will only be “done” development when the company stops being competitive, offering new services or keeping up with technology evolution. At one time getting to "Done" on your software project was a relief, a goal, a milestone, now it is more of a tombstone. It means the product is no longer competing or actively being maintained as technology continues to evolve.

Switching from projects (that are temporary in nature) to products that are designed to be ongoing sounds easy enough - just keep funding the team, but for many organizations it is not that simple. Also, organizations that embrace the whole digital product view still need help governing the ongoing process.

Expansion and Contraction

Project management requires the combination of technical skills, people skills and industry-specific knowledge. It is a true hybrid environment. This knowledge and its application also forms a beautiful paradox. Our quest to gain skills is never complete and always expanding, but the most effective tools are usually the simplest. Smart people do very simple things to achieve desired outcomes. Yet, they probably considered fifty alternatives before choosing the most effective, simple approach. You must know a lot to be confident your choice is apt.

Knowledge and experience in project management follows the same pattern. Learning about project management, how to work effectively with people, and our industry domain is never complete. We then use this knowledge to choose the best action, which for ease of understanding and implementation, is usually a simple course of action. I call it Expansion and Contraction, but there is probably a simpler name I will learn about one day.

We are a generation who stand with one foot in the outgoing industrial era and one in the knowledge-based future. Training and education that prepared us well for careers in the past will not work in a faster-moving future. Now, we need to be not just lifelong learners, but engaged, active lifelong learners.

The move from industrial work to knowledge-based or learning work can be difficult to see because change does not happen uniformly. Instead, some organizations push ahead, while others lag behind. However, all industries are changing and terms like “Retail Apocalypse” are invented to describe the trend in just one sector.

Predictions like “AI will take our jobs” sound scary. However, long before our jobs as project managers are taken, AI will help us. In fact, it already is, and we don’t think about it much. While writing this article, AI in Microsoft Word and the add-in Grammarly helped protect you from the bulk of my spelling and grammar mistakes. This is how AI will help us first, by doing small things we are error-prone with, before tackling larger tasks.

Like me, do you spend time booking meetings, finding rooms, and distributing information? Do you analyze backlogs and scope outlines for potential risks, or review estimates for commonly missed activities? Artificial Intelligence (AI) can help with these tasks and many more.

Imagine having a non-judgemental expert monitoring everything you do (and do not do) at work and making helpful suggestions to you in private. This expert is constantly learning, is plugged into all the latest research and works for free. This is the not too distant future of AI assisted project management.

June was Technology month at Project Management.com, and there have been a few articles about AI taking away project management jobs. This article focusses on ways AI can help project managers which will happen as AI develops and before it can replace jobs. It deals with automating the process and science parts of project management, leaving people more time to focus on the relationships, leadership, storytelling, empathy and emotional intelligence side of projects that are harder to tackle and are (currently) best done by people.

AI has come a long way since Microsoft rolled out the annoying and not so helpful “Clippy” Office Assistant tool in 2003. It was never tuned for project managers, but it if were it might have looked something like this:

Instead, AI is becoming more sophisticated and useful. Gmail will remind you to attach a file if you mention “attach” in the text of an email that has no attachment. Most people use personal assistants like Siri and Cortana on their phones, or Alexa in their homes. Voice recognition and comprehension are steadily increasing. Google recently demonstrated their new Google Assistant calling and interacting with a hair salon to book a haircut. Clearly, these tools will soon be ready for prime time and their use will be widespread.

Kevin Kelly, futurist and founding executive editor of Wired magazine, says in his TED talk: “Everything that we have electrified, we are now going to cognify”. In other words, we will add intelligence to devices and products. Kelly went on to say, “I would suggest that the formula for the next 10,000 start-ups be very, very simple: take X - and add AI.”

To understand how AI can help project managers, let's examine its basic capabilities.

• Knowledge Based Expert System (KBES) – these work from decision trees of IF - THEN statements to provide expertise. Gmail’s attachment reminder works with similar IF body_text includes “attach” AND Attachment = False THEN issue a warning.

• Artificial Neural Network (ANN) – these systems model our real brains and consist of networks of weighted connections. They can be programmed to learn, recall, generalize and apply fuzzy logic. So, if we teach it someone 4ft high is Short and someone 6ft high is Tall it can generalize that someone 4ft 6 is “Not very tall”. Being able to make these types of generalizations are important for realistic interactions with people, such as Google Assistant making a hair appointment.

• Machine Learning – this builds on Knowledge Based Expert Systems and Artificial Neural Networks to create predictive analytics that can provide validation and advice. In the project management space, this is the technology that can help with checking for missed risks, rebaselining plans, recalculating the Cost of Delay for waiting initiatives, etc.

• Chatbots - AI powered programs designed to simulate a conversation with humans. Chatbots use artificial neural networks and machine learning to combine domain intelligence with natural language processing. This gives the impression of interacting with a (currently somewhat) knowledgeable person.

If these technologies sound far-fetched in the project management field, consider the quote “The future is already here — it's just not very evenly distributed”. Agile tool vendor Atlassian, already provide project assistants that help with budgets, estimates, and sprint management. They also have chatbots to share project information and remind team members for estimates and status updates.

Moving forward, these tools will be expanded to help check our work for common mistakes, just as Word checks for common spelling errors. Every industry has catalogs of defect origins and removal methods (here is one for software projects) AI assistants can apply this knowledge and suggest steps to help avoid or reduce these risks. It is not an exact science and as a project manager, I may choose to dismiss potential risks flagged. However, having assistants available to highlight these risks or list the top 10 estimation omissions in my field is probably better than not having them.

AI assistants can also alert project managers to slowly developing trends that might otherwise go unnoticed. The old saying that projects become late one day at a time is very true. Optimistic project managers with “Can-do” attitudes often underestimate the impact of small setbacks and or hope that teams will “catch-up” later.  This hardly ever happens, and AI assistants can be programmed to alert early and avoid hope-based-planning.

Over-Reliance?

There is a risk that with expert knowledge systems, organizations may be tempted to use inexperienced project managers. Or project managers become reliant upon these tools and not think as deeply as they may otherwise. Like any technology, a fool with a tool is still a fool. However, tapping into standard risk lists from your industry, that gets augmented with those from previous projects in your organization is a smart move.

Having calculators has likely reduced our ability to perform long division calculations manually. However, I don’t want to go back to self-calculation just because I fear an over-reliance on technology. Instead, I want to use technology where I can and free up my time and mental capacity for other work.

Higher Value Work

The PMI Talent Triangle is a good model for thinking about all the work a project manager does. It includes: 1) Technical Project Management – the project mechanics described in the PMBOK Guide and Agile frameworks, 2) Strategic and Business Management – your industry-specific work, and 3) Leadership – the people dynamics of projects.

If we squash the triangle out and lay the pieces in order of how much impact the project manager’s contribution has towards project success we get: Technical, then Strategic, and then Leadership. By this sequence, I mean that if the basics of Technical Management are met then Strategic and Business Management work is more significant. Furthermore, good Leadership has an even greater impact on overall project performance than Strategic and Business Management Work, and Technical Project Management.

This sequence is shown below:

The good news for us as project managers is that (currently) AI is best suited for the lower value end of this work spectrum. It is already capable of assisting and saving us time with Technical Project Management work. Next, it should soon be commonplace to get AI assistance with Strategic and Business Management tasks. This will involve accessing machine learning focussed on our industry domains, like ROI models, common risks, and estimation omissions.

The last area AI will move into is the Leadership domain. Machine learning requires deep data sets in a consistent form to draw reliable conclusions. The people dynamics of motivation, conflict management, and negotiation are harder to classify and rank.  Currently, most people would rather work with a real person to solve issues or discover their calling. Who knows, maybe in future people will prefer to interact with chatbots who’s decision parameters can be shown to be neutral and fair. This might be preferable to dealing with people with all their inherent bias and gaps in knowledge.

All I know for now is that I currently welcome any AI assistance I can use. It is likely to safeguard me from making basic technical project management errors or omissions. It should also be helpful soon in providing industry knowledge and best practice – like having a seasoned professional in the industry available to look over your work. However, AI tools will check in real-time before you commit that decision or share a plan.

This leaves me more time to focus on the people. The people sponsoring the project, those working on it, and those who will be impacted by it. They will have their own AI assistants too. Booking meetings, getting rooms, and sharing ideas should become frictionless leaving us to work on the more significant issues.

My recommendation is to stay abreast of AI developments and remain open to trying the tools as they emerge. Standing still in an environment that is moving forward has the effect of moving backwards -which is not good. Where I should probably be more worried is in writing articles like this. It seems like a blend of domain-specific Strategic work with some Leadership based storytelling. Likely a candidate for an AI takeover long before the project manager. (My plan is to get in on the research and get a Chatbot writing this stuff for as long as I can get away with it!)

References:

1. How AI could Revolutionize Project Management, CIO Magazine, Mary Branscome, January 12 2018
2. 3 ways AI will change project management for the better, Atlassian Blog, April 7, 2017
3. Artificial Intelligence in Project Management - Is Your Company Ready for it?, Teodesk Blog, Minja Belic, January 22 2018
4. AI will Transform Project Management. Are You Ready?, PWC White paper, Marc Lahmann, et Al, 2018
5. Artificial Intelligence in Project Management, Khaled Hamdy, March 2017

[Note: I wrote this article for ProjectManagement.com, it first appeared here – free membership required.]

I am gathering names for my next Calgary based PMI-ACP Exam Prep course. Please let me know via email to Mike <at> LeadingAnswers.com if you are interested in reserving a spot on the next 3-day Calgary based PMI-ACP Exam preparation course held late May / early June 2018. We can do Wed, Thu, Fri or Thu, Fri, Sat – let me know your preference.

Evolution of the PMI-ACP Credential

Popularity has grown in the PMI-ACP from niche to mainstream with over 20,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. 

On March 26, 2018 the PMI updated the exam to align it with the lexicon of terms used in the new Agile Practice Guide. The course features updated materials and the new Updated Second Edition of my PMI-ACP Exam Prep book as an accompanying textbook.

My Involvement in the PMI-ACP Credential

I was a founding member of the steering committee that designed and developed the exam content outline for the exam. 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 approaches such as Scrum and XP along with servant leadership and collaboration. 

I worked with RMC to write their best-selling PMI-ACP Exam Preparation book. I recently updated this book to align it with the March 26, 2018 lexicon harmonization and change the chapter review questions to situational questions. The book is available from RMC here and is also included in the course.

Details about the Course

The course will be capped to 20 people for better Q&A and will likely take place at historic Fort Calgary which is close to downtown on 9^th Avenue, has great catering and free parking. It includes the new Updated Second Edition of my book, colour printed workbook, sample exam questions, and additional materials. 

The course has a 100% pass rate and uses Turning Technologies audience response (clicker) technology to privately track your strength and weakness areas as we go. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

When I travel I often meet people who say they used my books or other training materials to help them pass their PMI-ACP exam. Plus, I’m also asked by others how to get permission to use my book as the basis for their own PMI-ACP training courses.

So, I am excited to announce the new PMI-ACP Training Partner Program from RMC Learning Solutions. For an introductory low price of $500 per year you receive:

1. Use of a slide deck (290 slides) from our PMI-ACP® Exam Prep, Second Edition book

Note: These slides are an outline of our book. Our Training Partners use them as supplemental, reference slides as they develop their own course.  You can use some, or all, of these slides in your course.

2. One Instructor License for the PM FASTrack® PMI-ACP® Exam Simulation Software – v2 (Downloadable exam simulator. This is a $199 value)

Note:  This exclusive Instructor License allows you to use pre-configured exams to focus on/test a specific knowledge area.  The Instructor License is not available outside of RMC and our Training Partners.

3. Discounts of 35-55% off the List Price of selected RMC LS products you order at one time

Note: This enables you to include our training materials in the price of your course. It also includes discounts on my brand-new PMI-ACP Exam Workbook.

Maybe you already use one of my books for teaching PMI-ACP courses, or maybe you are looking for slides on which to base a course? Either way, getting professional materials aligned to the PMI-ACP exam content outline is much easier than building them all yourself. Also, you can rest assured that the permissions are all in order and everything will be updated as the exam changes.

If you would like to learn more about this program and take advantage of savings of 35-55%, please contact Marcie McCarthy at [email protected]

On September 6, 2017, the PMI published the new PMBOK® Guide 6^th Edition and the accompanying Agile Practice Guide. As co-author of the PMBOK® Guide agile content and chair of the Agile Practice Guide, it was great to see these projects finally come to fruition. They represent hundreds of hours of unpaid volunteer work by everyone who worked on them.

However, anyone considering taking their PMP or PMI-ACP is probably wondering if / how these new releases impact their study plans? The good news is, minimally. Since while the PMBOK® Guide sees some significant changes such as a new appendix on the use of “Agile, adaptive, iterative and hybrid approaches” the Exam Content Outlines for the PMP and PMI-ACP are not changing anytime soon.

What many people do not know is that it is the Exam Content Outline, not the PMBOK® Guide, or other publications, that dictate what is tested for in the exams. The Exam Content Outline for the PMP credential is created and published by the PMI. It is available for download here. The Exam Content Outline for the PMI-ACP credential is available here.

Each question in the PMP or PMI-ACP exam is based on at least two source publications. For the PMP exam, the PMBOK® Guide is frequently one source publication. For the PMI-ACP there are a dozen reference books, listed in the PMI-ACP Reference List.

So, the PMP and PMI-ACP exam questions are influenced by the Exam Contents Outlines more than the reference publications. Questions do have to be based on the reference publications, but only on the scope that is defined by the Exam Content Outline.

The image below depicts the process

Of all the project practices that are in use, (1) the Exam Content Outline acts like a filter (2) that limits what scope goes into the item writing (question writing) process. Only topics defined in the Exam Content Outline will be tested on the exam. Item writers (question writers) create multiple-choice questions (4) based on two or more reference publications (3). It is entirely possible to write a question that maps to the exam content outline and is backed by two other books and not PMBOK^® Guide. In this way, it’s meant to test experience and application of knowledge rather than test the content of any one book. The references are utilized to ensure questions aren’t based on peoples’ opinions or biases—rather they are based on best practices.

In the image above the shaded portion of the reference sources represent just the scope of those books that apply to topics in the Exam Content Outline. When the PMI recently published the PMBOK® Guide 6^th Edition and the Agile Practice Guide they added to the Reference Publications.

These new publications contain additional content, but until the Exam Content outline is changed through a process called a Role Delineation Study none of the new content will be tested.

So, yes, the new publications contain additional information, and yes, the exam questions are based on these publications. However, since the Exam Content Outline has not changed, none of this new material will be on the exam.

What Is Changing for PMP and PMI-ACP?

A lexicon harmonization process is occurring. This means questions will be checked and updated to use words consistent with the latest standards and guides. Both the PMBOK® and the Agile Practice Guide has a Definitions section that defines the terms they use located just before the Index. It is recommended candidates read the updated definitions to make sure they are familiar with the terms and descriptions of them.

The PMP does not currently use the APG as a reference source so it’s unlikely that PMP aspirants need to learn any new terms from the APG at this time. (However, the Agile Practice Guide does contain lots of practical guidance for project practitioners using agile and hybrid approaches.)

Likewise, the PMI-ACP Exam does not use PMBOK® Guide as a reference source so people are insulated from any terminology changes there. (However, the PMBOK® Guide 6^th Edition contains guidance for tailoring approaches for agile lifecycles, so you might want to check it out.)

CAPM

The only Exam that will be impacted shortly is the CAPM exam. The CAPM is based solely on the PMBOK® Guide and a Role Delineation Study for a new CAPM exam is underway. The PMI will be announcing when the CAPM Exam is changing too soon. Exams taken after the change will be based on the PMBOK® Guide 6^th Edition.

Summary

If you are studying for a PMP or PMI-ACP credential, the recent publication of the PMBOK® Guide 6^th Edition and the Agile Practice Guide should have only a small impact on your study plans. You should familiarize yourself with the terms used in these guides, PMBOK® for PMP, Agile Practice Guide for PMI-ACP. However, since the Exam Content Outlines are not changing in the short term, there is no requirement to learn any of the new material at this time.

Candidates studying for the CAPM whishing to take their exam in Q1 2018 or later, should switch their study source to the new PMBOK® Guide 6^th Edition. The CAPM is based solely on the PMBOK® Guide and this certification is having its Exam Content Outline updated. For the latest announcements for CAPM aspirants check the PMI website here.

[I originally wrote this article for ProjectManagement.com and it is available for members here]

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

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

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

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

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

I will be in Chicago this weekend for the PMI Global Conference. It’s going to be a busy couple of days with a presentation on Saturday chronicling project uncertainty and solutions. Then on Sunday a deep-dive workshop with Jesse Fewell into the new Agile Practice Guide. I’ll also be doing a couple of podcast interviews and helping at the PMI Poster session and the RMC booth.

I am looking forward to the conference and keynotes from Tim Berners-Lee on the Future of Tech. There is also Nicholas Epley presenting on Mindwise: How We Understand What Others Think Believe, Feel, Want. Finally, Mercedes Ramirez-Johnson provides the closing keynote on: Get it Right Today, Not Tomorrow about the need for urgent action and living with intention.

I’d love to chat to anyone who knows me, has used my books, or has questions about the PMI-ACP or the new Agile Practice Guide. Please drop by my sessions or look for me at the RMC booth. Being tucked away in a small Canadian ski town is great for outdoor activities but not so good for networking. So, I am really looking forward to it.

“Knowledge work is learning work.” That was the message delivered by Dianna Larson’s keynote presentation at the Agile on The Beach conference held in Falmouth, England earlier this Summer. Dianna explained that anyone involved in today’s collaborative, problem-solving projects such as new product development need to be learners. We all need to learn how to learn new topics effectively and get used to lifelong learning to stay useful and relevant.

Technology evolution and disruptive business changes are happening at such a high rate now that we can no longer rely on the theories and techniques we gained at university to see us through our professional careers. Instead, we must learn on the job and in our own time to stay current. How much we learn and how quickly we can learn new skills become our competitive advantage.

“Learning is not compulsory… neither is survival.” – W. Edwards Deming

By learning new skills, we increase our adaptability and usefulness in the marketplace. It creates resiliency to becoming obsolete and provides more career options. Like many things, this is not a zero-sum game; it is not just about us learning things faster than other people to stay employed. If we can increase our team’s ability to learn also, it will be more successful and so will our organization.

For on-job learning to occur, we need three attributes:

1. Courage
2. Compassion
3. Confidence

To be effective leaders and help promote learning in our teams and organizations, we must embrace and model these desired behaviors:

1. Courage: It takes courage to be okay with not knowing something. It takes courage to be wrong and fail as we try to gain and apply new skills. It requires a willingness to be curious and a willingness to tolerate the messiness of trial and error that comes from learning. So check your ego at the door, get over yourself and admit what you do not (yet) know.

2. Compassion: We need a safe space to learn. Also (and this is a surprise to some people), the transparency of showing what we do not know is motivating to others. When leaders learn out loud, it creates compassion toward them. So, create a secure place for people to learn on your projects. Provide psychological safety and encourage learning by doing it yourself in public.

Since we learn in the direction we ask questions, we should frame work as a series of learning problems, not execution problems. For example, instead of explaining the task of porting a system from .NET to Android, explain that our success is linked to our ability to learn Xamarin, our selected tool to port .Net to Android. Clearly explaining we want people to learn new skills is often the approval enabler they need to dedicate themselves to being more useful.

3. Confidence: We need confidence to try and we need to understand our confidence levels. When we learn anything new of significance, our confidence will likely move through the stages depicted in the Satir Change Curve. Think about when you learned to drive, play a musical instrument or learn a foreign language. First, our confidence is high at the prospect of gaining independence, becoming a rock star or traveling with ease. This is illustrated by the initial high score of confidence/comfort at point 1 on the graph below:

Then we start our learning and we quickly realize that driving, playing the guitar or learning Spanish is difficult and we are not as good at it as we are at all the familiar things we do every day. This is the confusion/loss period of the Satir Change Curve shown as point 2. Many adults who have not had to learn significant new skills for many years find this very uncomfortable.

Next, comes the “groan zone” of turmoil and despair, where some days go well and some days go bad and you seem to be moving backwards (point 3). Understanding that this is perfectly normal is a great relief for many learners. It is helpful to just point to the graph and explaining it is okay to feel bad because they are in the turmoil/despair phase of learning a new skill, and it will be followed by growth and confidence if they just stick with it.

Finally, with perseverance and practice, we acquire the new knowledge or skill and our confidence and comfort rises above our original level (point 4) along with our usefulness.

Summary
Learning and the need to learn are not identifiers of a junior employee anymore. They are the hallmarks of the professional knowledge worker. We need to move beyond the stigma of not knowing all the answers and embrace the learning path that comes with not knowing, making mistakes and asking for help.

When leaders model the learning mindset of curiosity and the courage to learn out loud, they pave the way for faster organizational learning and increased competitive advantage.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This post is a follow-up to my Agile DNA webinar I hosted a couple of weeks ago. This was my first webinar for RMC and we had a great attendance with over 2,000 people registering for the event. The recording is available now,  see below for details of how to access it.

The webinar was entitled “Agile DNA, the People and Process Elements of Successful Agile Projects” and the DNA theme came from the twin strands of People and Process guidance that run through all agile approaches and make agile uniquely what it is.

In case you have not noticed it before, Agile approaches weave people elements and process elements together through the agile mindset, values and principles. For simplicity of understanding we pull these elements apart to talk about them individually, but in reality, they are inextricably linked and self-supporting.

I have taken on an exciting new part-time role with RMC Learning Solutions as their Agile Practice Lead. I worked with RMC to create my PMI-ACP Exam Prep book and their ACP training offerings. So, I am really looking forward to working with them further. Previously, as a one-person company with a full-time contract job, I had more ideas for books, web sites and articles than I ever had time to develop. Working with RMC who have dedicated production staff, web developers and editors, I hope to get a lot more content available for a larger audience.

For the last 16 years, I have been pursuing my agile writing in my “free” time. I moved to Canmore a few years ago, and love the location, but the commute to Calgary further ate into that time. Working 50% of the time for RMC from home will free up more time for writing and occasional training and consulting. My challenge will be to stay focused and not use all the extra time for biking, running and skiing.

For RMC, my year kicks off with an introduction to agile webinar called “Agile DNA”, sign-up here. Then an e-learning course and a new book I have been working on will be announced with more to follow. Stay tuned for updates and more articles; heck I might even upgrade my LeadingAnswers.com website to be responsive and searchable – or go fat biking.

For anyone studying for their PMI-ACP exam, I have created a mind-map of the PMI’s Exam Content Outline and my book contents. So here it is, on a single (large) page all the topics within the exam and the second edition of my book.

Mind-maps show relationships between topics and provide hierarchy and structure. It could be used as a study check list – print a copy and cross off topics you are comfortable with leaving the topics to study. Or an everything-on-one-page view of the content in the exam – like a packing list for a trip, you can refer back to it and reassure yourself you “have” everything.

Anyway, if you find it useful you are free to use it for you own personal study. I hope it is helpful in an: “OK, I have got this” kind of way and not scary as in an: “Oh no, look at all the stuff in the exam!” kind of way.

I think it is interesting to understand why laying things out spatially helps with comprehension and recall from memory. It allows us to tap into our spatial awareness and engages the right hemisphere of the brain and that makes us less likely to forget them. (Assigning things we want to remember to a location is a memory aid that many memory-improvement techniques use. Probably using skills developed back in our hunter-gatherer days when our survival relied upon remembering where to find food and water, we have better recall of things assigned a physical location.) This is the reason today’s military still use visual tokens to represented enemy forces, despite having access to the world’s most sophisticated tools. The impacts of forgetting about them can be fatal; fortunately, exams are less critical, but we can still benefit from tapping into our spatial recall circuits.

Use the link below for the high resolution version.

Download PMI-ACP Book Mind Map

As you probably know the Exposure Draft of the PMBOK v6 Guide is making its way through review at the moment. I have been working with the PMI on some iterative, adaptive and agile content and look forward to when the non-disclosure agreements are lifted and I can tell you all about it. I think I can state, without saying too much, that people can expect to see a natural evolution of mainstreaming techniques that are now considered common practice.

Looking through my web site visitor statistics it is clear that one of the popular resources is my PMBOK v4 Guide to Agile mappings. These were created many years ago to support a training course I used to run for project managers operating in environments governed by PMBOK v4 Guide processes.

A couple of years ago I updated the "Agile Guidance for the PMBOK V5 Guide" but did not share it publicly because it is just as easy to misuse it as use it. It is NOT a how-to-do-agile in a PMBOK based company, a project executed only through the steps discussed in the guide would be a nasty Franken-process that is neither agile or plan based. Instead, it is a thinking tool and discussion guide only for people operating in environments with both plan-driven and agile type. With that prefix and warning, my agile discussion of the PMBOK v5 guide can be viewed and downloaded here: Download Agile and PMI PMBOK v5 Guide Alignment.

Following the update to the PMI-ACP Exam with the addition of the new “Agile Principles and Mindeset” domain I updated my PMI-ACP Exam Prep book and have now just finished the new questions for FASTrack Exam simulator. Feedback from people taking the exam indicated more difficult and more scenario based questions were wanted.

Well, you asked and we listened. The new FASTrack exam features over 500 PMI-ACP questions with answers and explanations to get you ready for passing your PMI-ACP exam as quickly as possible. The FASTrack exam simulator complements the book and provides references to which page in the book to read if you need more information about a topic.

As an early release bonus you can receive 30% discount off my book and the FASTrack exam simulator.

To give you a taste here are 20 sample questions: