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?

Increased Focus on the Learner Experience
Work-from-home orders aside, organizations typically struggle to get staff motivated to learn, whether for new skills acquisition or compliance training (safety, HR policies, etc.). At the same time, training platforms are competing to win market share by creating the most engaging frameworks and enjoyable learning experiences.

The period from 2005 to 2010 brought YouTube, Twitter and iPhones. Searching for content and consuming videos would never be the same again. LMS (learning management systems) evolved to become LXP (learning experience platforms). These new platforms focus on content discovery, content recommendations, career paths, skills mapping and, in some cases, self-published content with automatic content indexing.

We will look at some project management-based examples shortly, but first, let's examine how these systems differ from old training platforms. What do people want from a modern learning experience?

• Mobile-first: Content must be formatted to work on mobile devices such as phones and tablets, as well as larger computer screens. Research^[1] from over 700 organizations indicates that employees typically only have 24 minutes a week for “formal learning.” Using a mobile device enables more learning opportunities.

• Streamlined, reduced time to find content: Searching skills catalogs and competency frameworks is a drag. People want curated playlists, channels, and “top-rated”/“others enjoyed” smart content suggestions that we see on YouTube, Netflix and Amazon.

• Personalized recommendations: Extending the easy-to-find concept, people want tailored recommendations based on their learning goals, career paths and current progress. These can be extended by AI-based suggestions and people's history of consumption.

• Video-centric content: Organizations used to be worried about video-based content. Would people learn anything? Is just watching active enough? The popularity of YouTube how-to videos is living proof of the format. From wiring a socket to rebuilding an engine, videos provide a rich, high-bandwidth learning experience. 

• Micro-learning: Just enough, just in time. Our brains do not learn over long continuous periods; instead, we learn incrementally. Often, the best motivation for learning is having an immediate problem to solve. Microlearning uses short-form modules of four minutes or less, often with a video component, to answer an “I need help now” problem. It also drops a lot of the preamble and “why” background to focus on the “how.”

• Micro-credentialing: Online assessment allows for awarding micro-credentials. These are smaller achievements, such as electronic badges that recognize achieving minor learning goals. Frequent small rewards closely linked to recent performance is more motivating than less-frequent large rewards. Computerized tests and credentials are cheaper to administer and reward than physical ones so that they can occur more frequently. Many people are motivated by collecting badges and can display them on portals like ProjectManagement.com and LinkedIn.

• Gamification: Micro-credentials tap into gamification, which is the neuroscience of rewards, motivation and psychology to encourage learning by making it more enjoyable. Other strategies include “keep the streak going” reminders, points, leaderboards and community features.

• Interactive: Watching videos, listening to audio and reading text is a one-way flow of information with a decreasing information-retention rate over time. Productive learning environments punctuate this flow with interactive exercises to reset our focus and hit the “save” button on content. The best platforms mix in visual and text-based activities to break up content delivery, test understanding beyond regurgitation, and reset our focus.

• Repetition and reinforcement: Unfortunately, our memory is weak, and retention fades over time. Studies on spaced learning and skills acquisition show we need to review content multiple times and apply it in various settings to retain it. Language learning platforms such as DuoLingo does this well, requiring repetition and reinforcement in different contexts to ensure we master content.

• VR/AR: Some platforms use virtual reality and augmented reality to make training more relevant. For instance, oil rig workers can practice evacuation drills wearing headsets to show what they would see when navigating an emergency. Likewise, engineers can use augmented reality to identify aircraft parts and show torque settings and service recommendations using AR-equipped glasses.

Project Management Examples
Today, we can see instances of these new learning trends in products such as PMI's Snippets and the training elements of StandardsPlus. These tools offer short-format, video-first, micro-learning options on project management topics. They are focused on explaining how-to content and incorporate some of the gamification and content curation features described.

Learning Cycles and Choices
Micro-learning modules can seem fragmented to people used to full-length textbooks and traditional multi-day training courses. Like perpetually snacking instead of having proper meals, it may feel unorganized, trivial and too random. However, we need to remember that before COVID-19, employees often only experienced minimal periods for their on-the-job training.

Micro-learning fits the time-pressured need, but there is still the market for longer macro-learning. Traditionally, this was at the beginning of careers or new roles and then supplemented by micro-learning while on the job (as pictured below):

Now, with a work-from-home reset for many of us, maybe it’s an excellent time to insert some new opportunistic macro-learning as well as micro-learning (perhaps to learn about program management, Kanban or leadership—whatever you have hoped to achieve).

Macro-learning is the longer format, more focused training that often comes to mind when we think about learning a new skill. It includes multi-day courses and in-depth study with practice.

However, this does not mean giving up on the learner experience trends discussed earlier. Options such as LinkedIn Learning uses many of these learning experience concepts and bundles micro-learning modules into more extensive courses and more substantial credentials.

Other offerings in the macro-learning space include EdX, Coursera, Udemy, Udacity and NovoEd. Like most platforms, they contain some great content taught by experts—and some not-so-great content. However, with the option to read reviews, sort by top-rated courses and try free samples, much of the risk of choosing a poor curriculum can be avoided.

So, if you have some time to gain new skills, do not settle for old LMS platforms with tired and uninspiring learning experiences. Lifelong learning should be fun and rewarding. Explore some of the latest offerings. Maybe the new formats, gamification or social aspects will be just what you need to stay focused and get more out of the process.

References

1. Learning in the Flow of Work by Josh Bersin

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here]

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

Once we see projects as puzzles with more puzzles within them, we realize the importance of practical problem-solving.

Rarely do project managers have all the answers or the best answers. So we need to share the problem and collaborate on developing a solution. This is why being able to visualize problems is so important.

Visualizing a problem helps us understand it ourselves and then gain consensus with others on it. It also allows us to determine if we are all seeing it in the same way. Drawing something also lays it out spatially, allowing people to see relations, sequence and connections, or whatever we want to depict.

Here is the structure of this article as a list of bullet points:

• Introduction
• Why visualizing is helpful
• An example from a real project
• Ways in which we can visualize
• Wrap up and recommendations

Here is the same information as an image:

Research into visual thinking by David Hyerle, creator of Thinking Maps methodology, reports that 90% of the information entering the brain is visual.

Also, 40% of all nerve fibers connected to the brain are for the retina, and a full 20% of the entire cerebral cortex is for vision, so let's use it.

Creating a visual helps us to tackle a problem in steps. Having a spatial reference allows us to park some elements until later. We can say: "Yes we still need to solve the atmosphere re-entry problem, that's shown over here; but right now we are tackling the launch problem." Separating components in this way allows us to focus on one element at a time.

A Real-Life Example

I once took over a struggling project that was using a complex combination of proprietary hardware, software and vendor products. It mixed in-house developed software and cloud-based services—and was difficult for me to comprehend. I went through all the documentation but struggled to see how the elements worked together. To get up to speed, I knew I had to draw it all out to understand it.

I met with stakeholders, asked about how their part worked and drew it out with them. They provided lots of corrections and additions. I then showed the whole thing to the team, and they found even more omissions, which I filled in. I felt like they were humoring me, helping me get my little project manager brain around the complex system they had spent years developing. However, then they announced they had never seen it all mapped out in a single (very large) image before.

We ended up using the diagram repeatedly going forward within the team to discuss issues and to onboard new members. I also used simplified versions and zoomed-in portions for explaining elements of the project to the steering committee.

If you are missing a big picture view of your domain, you probably need to make one. It is a great way to surface misunderstandings and gain alignment on thinking.

Luckily, we do not need to be artists—or even competent at drawing. Stick figures, boxes and lines are all we need. Yes, it is pleasing to have a well-drawn vision of strategy poster, but for most instances, basic drawings are just fine. If we need a professional looking image, there are always graphic artists we can engage. Here is how I show some of the roles of a PM:

The images are not well-formed or accurate, but convey more meaning than words would alone.

Books such as Visual Collaboration walk readers through the drawing process. They show how to create simple but powerful graphics to help direct meetings, ask powerful questions, and create clear strategies.

Using images sounds like a luxury, right? "I do not have time for that!" Maybe, but are your messages getting through?

Using images helps people retain information. Most people only remember 10% of what they heard three days ago. Add an image to the message, and this figure jumps to 65%.

So, if we are going to the trouble of interrupting people from their work, we owe it to everyone to make it worth their time. Better to spend the extra time and create a visual than disrupt them six times with the same message to achieve similar retention.

In a team setting, we can use images when capturing opportunities and threats. The sailboat exercise allows people to record and place threats, opportunities and issues on an image with sticky notes:

We use anchors for threats that could impede progress and depict opportunities as the wind in the sails to propel us forward. Cheesy? Yes, but providing spatial separation and getting people up on their feet, contributing and generating an image they are more likely to remember is worth the cheesiness.

Finally, hand-drawn and group-generated images are more personal, more human and more uniting. They are ours; we created them, and we are more invested in achieving their goals than outcomes shown with generic Gantt charts or schedules. Involvement increases commitment, and human is more approachable than automated.

Final Recommendations
Here are some tips for problem-solving with visuals:

• Find ways to visualize the overall project problem; this allows people to see the big picture.
• Break down the interim puzzle pieces to show relationships, sequence and solution alternatives. Use these visuals to encourage collaboration and build support for group-generated solutions.
• Don't be shy about your amateur art. Your chicken-scratch stick people demonstrate a vulnerability that increases empathy and encourages others to have a go. Starting with a fancy image may inhibit people from contributing as they do not want to spoil your picture.

While rough-and-ready visuals are suitable for working sessions, there are times when you will want to invest more time and effort. Externally facing artifacts such as plans, roadmaps and product visions will benefit from the best images you can create.

I sometimes create project milestone posters for stakeholders to recognize their contributions and the obstacles we have overcome together. These work well for thank-you cards and foam-board plaques. Here are a couple of examples:

I like to embed insider jokes and references to some of the issues we faced.

Projects are adventurous journeys we share with our stakeholders. Just as we would use maps and take photos on physical trips, we can do the same for our project endeavors to recognize and remember the venture. So be brave and get visual!

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here.]

Copyright © 2020 Mike Griffiths, Leading Answers Inc.

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:

• E1: Decompose by performance results and stakeholders –  Break down the work into small (weekly) value delivery steps
• E2: Do high-risk steps early – Prioritize the work based on risk
• E3: Focus on improving your most valuable objectives first – Also prioritize the work based on business value

These ideas became the concepts embodied in backlogs by today’s agile approaches and frameworks.

So, we can trace each approach back to around the same time and also be confident these ideas were firmly established long before that. Building the pyramids and Roman cities required multiple levels of planning, work decomposition and task coordination. There is little point in arguing whether WBSs or backlogs came first since it was clearly lots of other things.

These days, the PMI Practice Standard for Work Breakdown Structures defines a WBS as “…a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the desired deliverables.” The Scrum Guide defines a product backlog as “an ordered list of everything that is known to be needed in the product.”

Are they really so different? They both help with forming an agreement on scope. Yet, due to how they are often used, they are viewed as quite different by many people…a viewpoint I would like to change.

WBS and Backlog Similarities and Differences
Work breakdown structures are often defined upfront and supported with a WBS dictionary. They can be used to form statements of work and contracts. If these deliverables are useful for your projects, then great, create them. However, understand we could create the same deliverables from a product backlog also.

Yet, on agile projects, we typically do not because these environments tend to be more dynamic so these deliverables would soon be out of date. Instead, we create iteration plans, release roadmaps and work from the top of the backlog while the product owner manages the backlog with evolving priorities and change requests. These deliverables are easier to update as changes occur. The differences we see in action stem more from the characteristics of the work environment than the WBS or backlog tool in use. Both help us define and discuss scope.

Visual Benefits
Both are visual and allow us to point at items as we talk about them. This is critically important. Visual depictions of work allow us to collaborate more effectively. When two people face a task board or WBS diagram, they can collaborate with less contention. Visualizations help us build shared understandings and avoid confusions such as having two similar items being considered the same thing or assuming one solution fits two scenarios when it does not.

Depicting scope visually also allows us to shade and color items to indicate type, ownership, risk and completion status.  Visualizing work is a major component of lean thinking. When we visualize something, we also process information using more of our brain—and much more quickly compared to reading and interpreting written information. This is one reason we have road signs with images and not descriptions to read. It is the difference between decoding and understanding meaning in 150 microseconds (roads signs) versus 6,000 microseconds for reading:

Product Backlogs as a form of WBS
The third edition of the Practice Standard for Work Breakdown Structures talks about backlogs as a form of WBS. Many people think only tree structures of boxes and lines are work breakdown structures, but they can actually take on many forms including tabular backlogs or even mind maps.

I can imagine some purists shouting “No, that’s not a WBS!” as I type this, but go check it out for yourself if you do not believe me. The Practice Standard for Work Breakdown Structures WBS is a free download for PMI members. 

I participated as a reviewer for the standard and was pleased to see its coverage of agile scope decomposition using epics, features, user stories and tasks as candidate WBS elements. One thing that puzzled me that I am hoping a reader of this article can help me with is the inclusion of sprints or iterations as potential WBS elements.

My confusion stems from the logical definition of work in section 2.1 that says “… work refers to outputs, work products, or deliverables that are the results of effort, not the effort itself.” – that makes sense. Then in section 2.3.1.1 on WBS rules it says “WBS elements do not account for time or sequence.” Again, that seems reasonable.

However, the examples for agile projects include a WBS with level 2 items showing “Iteration 1,” “Iteration 2,” etc. containing work. This seems to violate the deliverables versus effort definition of “work and no-time” rule. We would not have a WBS element called “September,” so why call out some arbitrary time box? Iterations are just time constructs, and you might choose to use them or work without them as a continuous pull of features from the backlog.

Likely I am interpreting the work, deliverables and no-time rules too literally and, like debating which approach came first,  it probably does not matter. If having iterations shown helps you share your plans and have meaningful conversations about scope, then go for it. I would imagine it would result in having to refactor the WBS frequently as stories get shifted between iterations as priorities change and throughput varies, but maybe not.

The more important idea is that we visualize and discuss project scope with a wide variety of stakeholders to surface and correct misunderstandings. The good news is that product backlogs are a legitimate form of WBS and more of a sibling than a distant cousin. A couple of great quotes from the WBS Practice Standard reiterates the value and applies equally well to backlogs and release roadmaps:

“The WBS provides the foundation for a visual representation of the scope of work…Research demonstrates that communication is one of the project management disciplines with the highest impact on project success. The WBS serves as a critical project communication mechanism that helps convey the scope of the project through its graphical depiction.”

So let’s get graphical and keep communicating.

[Note: This article first appeared on ProjectManagement.com here. For more articles from Mike Griffiths check his blog www.LeadingAnswers.com]

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

Learn how people want to work and agree on how things should be done and how issues should be handled.

As a group, develop the group rules that will be followed. By being involved in the creation of the team norms, people are much more likely to feel ownership and commitments towards them. Telling people how we should work is much less empowering than engaging those people in jointly developing their own framework.

Task 2 – Help develop technical and interpersonal skills

Encourage the development of technical and people skills so everyone is equipped to work effectively.

Knowledge work requires two sets of skills. The first is to do the technical work as a subject matter expert (SME), the second is to work productively with other SMEs and stakeholders, including the business and customer. The job of learning and honing these skills is never done, and we should always be improving our technical and collaboration skills.

Team Empowerment

Task 3 – Encourage generalizing specialists

Encourage people to have a broad range of skills, not only deep, narrow ones, so that as workload varies people can help other team members out.

The concept of “T” shaped people rather than “I” shaped people captures the idea of having skills in surrounding fields of work, in addition to a specialization. To maximize the value delivered we want global rather than local optimization. This means focusing on overall throughput of value over people-utilization efficiencies. T-shaped people are valuable for optimizing value since they allow us to share work to reduce bottlenecks.

 Task 4 – Empower team members

Encourage people to step up for new roles. Allow them to make their own decisions. Put them in charge of many elements of their job.

We want people to take ownership of their work and start to make their own improvements. So encourage people to look for opportunities for improvements and take initiative to make them happen. These are forms of emergent and shared leadership. Subject matter experts know their domains best, so empower them to manage complexity and create solutions to the problems they face.

Task 5 – Proactively manage morale

Learn what motivates people and provide that motivation in their workplace.

Frequently observe and ask team members about what motivates them individually and as part of a team. Also, learn what demotivates or upsets them. Then try to find ways to improve the work environment to foster happiness, productivity, and satisfaction.

Team Collaboration and Commitment

Task 6 – Encourage ongoing communications

Encourage dialog and technology that helps share information.

Usually, the best way to help communications is to physically co-locate with the people you need to communicate with. Nothing beats seeing them and talking with them. It allows for the richest exchange of information accompanied by body language and emotion.

When colocation is not possible, provide the best tools you can to keep people in communication. Monitor communications and look for ways to reduce miscommunication or address missing communication. This helps reduce costly and wasteful rework caused by miscommunication.

Task 7 – Protect team from distractions

Shield the team from interruptions.

Distractions and low-priority interruptions can come from many sources. They might be requests from superfluous sources or demands for low-priority admin work. Even quick interruptions cause task-switching and interrupting flow.

Special-ops and Skunkworks teams have been effective and highly productive in part because they were separated and shielded from interruptions.

Task 8 – (Re)communicate the vision to align the goal

Show the end goal and how people’s contributions help get us there.

People should understand how their work contributes to the end goal. So we need to align the team goals with the product or project goal and show the connections and steps along the way to our final destination.

Task 9 – Measure performance to help forecasting

Encourage people to measure and share their performance so we can get better at forecasting at a high level.

In order to improve our ability to forecast, we need to track how things actually turned out. If we keep making estimates without checking actual performance, we will keep making the same estimation errors. Tracking velocity and work delivered helps create a more accurate view of the team’s true capacity for future work.

I hope you enjoyed these samples from my most recent book. It was a fun project for me and my wish is that people find it an easy introduction to agile values.

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!

Concentrate on developing features the business asks for: This is how we can get the best benefits for the business and support for the process. Projects are hard to cancel or deny requests from when they consistently deliver business results.

 2 – We deliver reliable results by engaging customers in frequent interactions and shared ownership.

When planning interaction with the business, try to be more like the good neighbor you see frequently and can easily call upon rather than the intrusive relative who moves in for a while and then disappears for a year. We want regular and engaging business interaction, not a huge, upfront requirements-gathering phase followed by nothing until delivery. Frequently show how the system is evolving and make it clear the business drives the design by listening to and acting on feedback.

3 – We expect uncertainty and manage for it through iterations, anticipation, and adaptation.

Software functionality is hard to describe, technology changes quickly and so too do business needs. Software projects typically have lots of unanticipated changes. Rather than trying to create and follow a rigid plan that is likely to break, it is better to plan and develop in short chunks (iterations / sprints) and adapt to changing requirements.

4 – We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.

We manage property and lead people; if you try to manage people they feel like property.

Projects are completed by living, breathing people, not tools or processes. To get the best out of our team we must treat them as individuals, provide for their needs and support them in the job. Paying a wage might guarantee that people show up, but how they contribute once they are there is governed by a wide variety of factors. If you want the best results, provide the best environment you can.

5 – We boost performance through group accountability for results and shared responsibility for team effectiveness.

Everyone needs to share responsibility for making the project, and the team as a whole, successful. We can help by empowering the team to make their own decisions. When people are more engaged in a process, they are more committed to its outcome and success. In short, people care more about things they had a hand in creating than things given to them or imposed upon them.

6 – We improve effectiveness and reliability through situationally specific strategies, processes, and practices.

Real projects are complex and messy. Rarely do all the ideal conditions for agile development present themselves. Instead, we have to interpret the situation and make the best use of the techniques, people, and tools available to us. There is no single cookbook for how to run successful projects; instead, we need to adjust to best fit the project ingredients and project environment we are presented with.

The next post will feature another random excerpt from the book “Agile Illustrated: A Visual Learner’s Guide to Agility”. If you liked this sample please consider buying the Kindle book available on your local Kindle store – here’s a link to the Amazon.com store.

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.

Many developers are detail-oriented and process-driven. While these characteristics are often highly beneficial, they can also mean the developer’s focus is easily distracted from the real reason they are undertaking software projects—to write valuable software. So, this emphasis on valuing working software over comprehensive documentation acts as a useful reminder of why these projects are commissioned in the first place—to build something useful. Documentation by itself, or at the expense of working software, is not useful.

Value 3 – Customer collaboration over contract negotiation

We need to be flexible and accommodating rather than fixed and uncooperative. This involves tradeoffs between the development team and business rather than reverting back to contracts and statements of work. We could build the product exactly as originally specified, but if the customer’s preferences or priorities change, it would be better to be flexible and work toward the new goal.

It is difficult to define an up-front, unchanging view of what should be built. This challenge stems from the dynamic nature of knowledge work products, especially software systems. Software is intangible and difficult to reference: companies rarely build the same systems twice, business needs change quickly, and technology changes rapidly.

We should recognize at the start that things are going to change, and we’ll need to work with the customer throughout the project to reach a shared definition of “done.” This requires a more trusting relationship and more flexible contract models than we often see on projects.

Value 4 – Responding to change over following a plan

The quote from scholar Alfred Korzybski, “The map is not the territory,” warns us not to follow maps if they do not match the surroundings. Instead, trust what you see and act accordingly.

In modern, complex projects, we know our initial plans will likely be inadequate. They are based on insufficient information about what it will take to complete the project.

Agile projects have highly visible queues of work and plans in the form of release maps, backlogs, and task boards. The intent of this value is to broaden the number of people who can be readily engaged in the planning process by adjusting the plans and discussing the impact of changes.

The next post will feature another random excerpt from the book “Agile Illustrated: A Visual Learner’s Guide to Agility”. If you liked the sample, consider buying the Kindle book available on your local Kindle store – here’s a link to the Amazon.com store.

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.

A couple of people have reported “not available in this region” messages and I am working with Amazon to fix these. The issue seems associated with the large file size due to all the illustrations. It should be available soon, I appreciate your patience.

People have also requested a physical version. On-demand color printing increases costs but if it can be made available, still at an affordable cost, I will and let you know here.

Thanks again for the support and great feedback.

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.

This book is ready now and readers of this blog can get special pre-release pricing of $4.99 for just 1 week (normally 8.99) here. Please let me know what you think of it and create an Amazon review, that really helps promote the eBook within Amazon search results.