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?

Please join me with Peak Business Management for a Free PDU webinar on April 12^th at 7:00 pm Eastern Time. Along with Barb Waters, I will be demonstrating the PMP® Exam curriculum from a visual learner’s perspective and giving a tour of PMillustrated.com. We will explore the videos, mindmaps, animations, and games that make learning fun and more effective. We will also be available to answer questions about the PMP® Exam, eligibility criteria, and what to expect in the exam.

Reserve your place now and automatically receive 1 PDU for attending the event. I hope you can join us.

Register Here

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

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

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.

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.

This article explains what a risk-adjusted backlog is, why they are useful, how to create one and how teams work with them.

What is a Risk-Adjusted Backlog?

A risk-adjusted backlog is a backlog that contains activities relating to managing risk in addition to the usual features associated with delivering value.

Agile projects typically prioritize the backlog based on business value or perceived needs. The Product Owner or business representative prioritizes the backlog elevating the highest value features to the top, so they get delivered first.

Taking an Economic View of Decision Making

Prioritizing based on business value is an example of the lean concept of 'Taking an Economic View of Decision Making.' In deciding which feature to develop first, those with the highest economic value are selected. Taking an economic view of decision making has a couple of advantages.

Dolphins are easier to track than submarines. They surface more often and are usually within view of where you last saw them. Subs, on the other hand, can disappear for months or years at a time, and it is difficult to tell where they have gone.

What does this have to do with project communications? Has Mike finally gone mad?

These are valid questions, so let me explain. Many traditional project management deliverables have agile alternatives. For instance, a product backlog is somewhat analogous to a work breakdown structure. A release roadmap contains many of the elements of a Gantt chart. Yet we rarely see agile communications management plans. Why is this?

Finished Netflix? Done with “doom-scrolling” social media? Maybe it’s time to gain those skills you have been putting off.

The expansion of online learning was booming before COVID-19 emerged. Now, with the rise of work from home and homeschooling, the switch to online study has been massively accelerated.

However, before enrolling in some uninspired port of traditional course content to an online platform, let's see what else is out there. What are the emerging trends and good practices? What can we look forward to seeing in the world of online learning for project managers?

Some people say we cannot manage what we cannot measure. I say we cannot solve what we cannot see, or at least visualize somehow.

Projects are problem-solving exercises. The entire project is one big problem. We might be building a new product; that's a problem to solve. Or we might be trying to create something well understood but within a challenging amount of time, to a tight budget, and demanding specification. Or we could be moving our organization forward through a change initiative. These are familiar project environments that are puzzles or problems to solve.

Then within this large problem environments, we have hundreds of everyday challenges to answer, too. "How are we going to manage without the installer today?" or "The pilot group has requested 400 changes, now what do we do?"

It’s easy to believe that work breakdown structures (WBS) have been around since the pyramids were built in Egypt, and that product backlogs are new inventions by youngsters in too much of a hurry to plan correctly. However, like most things, the truth is more complicated.

In 1957, the Program Evaluation and Review Technique (PERT) approach was created by the United States Department of Defense (DoD) and described organizing tasks into product-oriented categories. However, they did not use the term “work breakdown structure” or WBS until 1962 when DoD, NASA and the aerospace industry published a document about PERT that described the WBS approach.

Meanwhile, in 1960, Tom Gilb described his Evolutionary Value Delivery approach (or Evo for short) that is widely accepted to be a forerunner of agile approaches. Evo contains principles such as:

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

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.