Agile Illustrated - Sample #2

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.

 

DOI1

 

 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.

 

DOI2

 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.

 

DOI3

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.

 

DOI4

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.

 

DOI5

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.

 

DOI6

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.


Agile Illustrated – Sample #1

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

 

M1 - sample

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.

 

M2 - sample

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.

 

M3 - sample

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.

 

M4 - sample

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.


"Agile Illustrated" - Update

Confirm business participationThanks 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.

Amazon sales stats

Manage risk proactivelyA 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.


Help develop technical and interpersonal skillsPeople 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.

Encourage generalizing specialists


Announcing "Agile Illustrated" Book

Agile Illustrated - Cover small

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.

Gain concensus on acceptance criteria

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.

Tailor process to environment

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.

Agile Manifesto - Agile Illustrated


PMI Organizational Agility Presentation

PMI Organizational Agility Conference

Please join me on Thursday, September 12th for the PMI Organizational Agility Conference. This free, online event for PMI members awards viewers PDUs. I will be presenting on the topic of becoming a Change Resilient Professional.

 

As rates of change increase, building strategies and skills for adapting to change are becoming more important than ever. We will explore beyond agile models and the power of a “Yes, and…” mindset. I will be profiling the increasing pace of change and what the best organizations are doing to keep up with it, drive it forward, and future proof their employees.

 

There is a great lineup of presentations scheduled for the day. Check out the full program and register here.

OrgAgility19_792x200

 


Innovation: Running Experiments and Learning

Experiment DesignIn my last article on Incubating Innovation, we explored the culture and mindset of accountable experimentation. This article focuses on actionable tools and approaches.

Within agile frameworks, the team retrospective is the primary workshop for planning and evaluating experiments. Yet most team retrospectives I see are broken.

Teams spend too much time recording viewpoints and information—but not enough time reviewing or planning experiments. It is common to see the majority of the time spent gathering what went well, what did not go well, and appreciations. Yet where’s the focus on experiments, the learning process and trials for the next iteration?

To make things worse, some teams do not take the retrospective seriously. Maybe after the potential stress of the sprint review, the largely internal retrospective is a relief. A chance to chill out, maybe share some food, and pat each other on the back. However, innovation and learning take conscious effort, forward planning and accountability.

As I work with organizations, I often sit in on retrospectives. Of all the regular workshops/ceremonies, these sessions are typically the least prepared for and worst executed. I often see lazy retrospectives where a basic lessons-learned format is used, but timings are not managed and the recommendations for the next sprint get skimped as they run out of time.

The pie chart below shows a typical planned allocation of time—and the reality of how time is actually spent:

R1

In these lazy retrospectives, people are slow to start, spend longer on recording what went well than what could be improved, and then try to cram the recommendations for experiments (the most important part) into the last few minutes. As a result, experimentation suffers. Few experiments are scheduled for the next sprint, and those that are run are not evaluated properly.

This is not how agile retrospectives are supposed to operate. An excellent guide to running effective retrospectives is Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. In it they describe a five-step process:

  1. Set the stage – Help people focus on the task at hand; check that people are ready and willing to contribute. Outline and gain consensus on the process we will use. Techniques we can use include: check-in, working agreements, focus-on/focus-off (see the book for full descriptions of these techniques).
  2. Gather data – Create a shared view of what happened during the sprint/iteration. When completed, we should have a common understanding of the observations and facts. Team activities we can use include: timeline, mad-sad-glad, team radar.
  3. Generate insights – This focuses on understanding the implications of our findings and discussions. We need to see the impacts of the problems we are faced with before trying to solve them. Techniques we can use include: five whys, fishbone analysis, dot voting.
  4. Decide what to do – Now we move from thinking about the iteration that just ended to what we should try next to improve things. We identify the highest-priority action items, create plans for experiments and set measurable goals to achieve the desired results. Techniques we can use include: SMART goals, circle of questions, short subjects.
  5. Close the retrospective – Here we reflect on the retrospective process and express our appreciations. We may summarize what we have decided to keep or change and what we are thankful for. Team-based activities we can use include: plus/delta, return of time invested (ROTI), appreciations.

This is a more useful format. However, despite people having access to good retrospective advice, poor implementations are still common. Teams continue to attend late, start slowly and run out of time or rush the agreement on what experiments to run.

R2

The recurring theme is poor experimentation design and restricted learning. Gunther Verheyen summarized the problem nicely in his recent post entitled “Inspection Without Adaptation Is Pointless.” Gathering data and deciding what to do is pointless if it is not acted upon. We are doing most of the preparation work but not getting any of the benefits.

Experiment Design to the Rescue
Fortunately, there are some good models we can use. We need to manage time and effort more effectively and use retrospectives to plan and evaluate more experiments. We should spend only 50% of the available time on gathering information and the remainder reviewing the results of past experiments, making wins part of our process, designing new experiments and learning from inevitable failures.

We can help the time management problem by assigning work to be done in advance. People should be thinking about issues and potential solutions independently. There are benefits of group discussion and consensus gathering on agreed experiment design, but observation and idea generation is best done individually.

The New Yorker magazine [3] describes numerous studies that show how brainstorming groups think of fewer, lower-quality ideas than the same number of people who work alone and later pool their ideas. There have been numerous reports on the downsides of brainstorming ideas as a group. Groupthink and the halo effect stifle idea generation. So, ask for people to come with ideas, then use the group setting to vet and vote for them.

Visualizing the ideas and experiments is an effective way to bring collective attention to them. Trent Hone and Andrew Jarding developed the “Ideas and Experiments board” pictured below. It shows the progression of ideas through experiments and their success or abandonment:

Experiment Board

Ideas and Experiments Board (Image Credit: Trent Hone and Andrew Jarding, MindSettlers)

As discussed in the last article, by design, 50% of our experiments should fail since we are trying to maximize our learning, not validate things we already know. So I would expect to see an equal number of abandoned experiments as successful ones.

However, this format (or a slightly modified version that represents an experiments Kanban board) is a useful tool to bring the focus for retrospectives to the experiments being run and considered. With some pre-work on idea generation and an increased focus on experiments, we can structure more effective retrospectives.

R3

This retrospective format saves some time by assigning idea generation as pre-work; this also helps avoid the groupthink pitfalls. It furthermore places emphasis on the experiments—the inputs for learning and innovation.

I have experienced pushback from teams about the goal of 50% experiment failure. People understand it optimizes learning—but say it sets people up for too much failure. I understand the sentiment but counter with two perspectives.

First, these are experiments; they should be dispassionate explorations, not evaluations of the people undertaking the work. We need to be professional and try to overcome habits of internalizing results. I know this is easier said than done, so also offer a second reason: We need to kill bad ideas early to save time and money for better ones.

In the article “The Hard Truth About Innovative Cultures,” Gary Pisano describes how killing bad ideas is critical. He profiles Flagship Pioneering, a Massachusetts-based R&D company. It uses a disciplined exploration approach to run small experiments minimizing expenditure. Instead of running experiments to validate ideas, it designs “killer experiments” to maximize the probability of exposing an idea’s flaws. The goal is to learn what went wrong early and move in a more promising direction.

Other useful ideas from the paper include:

  • Tolerance for failure, but no tolerance for incompetence – Hire the best people you can. Explain the goals clearly and let go of those that do not perform.
  • Psychologically safe, but brutally candid – Encourage frank but respectful two-way dialog. It may feel uncomfortable, but it can prevent issues or concerns from going unreported.
  • Collaboration—but with individual accountability – Encourage discussions, but avoid groupthink and hold people accountable for decisions and outcomes.

These are all great concepts and align with the frustrations I experience when I see teams not taking retrospectives seriously—or following through on conducting experiments. I realized I needed a better model for discussing the problem. Fortunately, I found the field of collaborative problem solving (CPS).

CPS is the study of how we work together in groups to solve new problems, innovate and build products. The innovation process and retrospective workshop fall squarely within its scope. CPS skills are quite separate from individual task-focused skills, meaning people can be great at working individually but poor at working together.

A good introduction to CPS frameworks can be found in the article “Advancing the Science of Collaborative Problem Solving.” One model they feature is the “PISA 2015 Collaborative Problem-Solving Assessment.” Unfortunately, like many academic models, the degree of difficulty goes downward, which may make sense as you read down through more advanced stages. However, I think graphically, so I have redrawn the model to show degrees of completeness and difficulty radiating up and out from a 0,0 origin, as shown below:

PISA 1

Along the X-axis, we see three categories of collaborative problem-solving competencies. These are:

  1. Establishing a shared understanding
  2. Taking action to solve the problem
  3. Establishing and maintaining team organization

Up the Y-axis, we have four categories of problem-solving:

  1. Understanding the problem
  2. Representing the problem
  3. Planning and executing
  4. Monitoring and reflecting

Within the body of the model, each square is labeled with the column number and row letter, and describes the tasks that occur in that space.

The model provides a diagnostic tool for identifying broken and lazy retrospectives. The poor engagement and weak follow-through I see in many Scrum teams is characterized by an incomplete execution of column 1 and only half-completion of columns 2 and 3 (as shown by the red outline below):

PISA 2

Teams are not spending time in “(D1) – Monitor and repairing the shared understanding,” nor are they getting to the “(C2) Enacting plans,” (D2), (D3) and (C3) areas to follow through on plans and hold each other accountable for actions and results.

What we want is a complete execution of all the collaborative problem-solving competencies; only then is the framework complete (along with the feedback mechanisms to keep things in check and moving in the right direction):

PISA 3

Summary
Innovation involves combining the right mindset and philosophy with tools and practical steps to ensure its execution. Motivation and attitude are paramount; people have got to want to do this work, enjoy it and create a pull demand for the tools and process that enable it. Trying to foster innovation with demotivated teams is like trying to push a rope.

When motivated and happy people create a strong pull demand for innovation, we need to be ready with the right tools to support the process and keep the momentum going. This includes designing experiments to maximize learning and killing bad ideas quickly—all while demanding competence, accountability and candor.

It is not easy to master the combination of soft skills and techniques required for successful improvement and innovation. However, organizations that succeed can respond to market changes faster and are poised to exploit new technologies and opportunities. Ideas and inventions are spreading quicker than ever. Learning how to build collaborative, innovative teams has become a critical skill.

References

  1. Book: Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen
  2. Article and video: “Inspection Without Adaptation Is Pointless” by Gunther Verheyen
  3. Article: “Groupthink: the Brainstorming Myth” by Jonah Lehrer
  4. Article: “The Hard Truth About Innovative Cultures” by Gary Pisano
  5. Article: “Advancing the Science of Collaborative Problem Solving” by Arthur Graesser, et al.

[Note: I first wrote this article for projectmanagement.com here]


Let’s Rewrite the PMBOK

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

The full details of volunteer opportunities and entry requirements can be viewed at the PMI VRMS site Here.

I will be acting as Co-Lead for the initiative, which is like a co-chair role. However, Chair and Co-Chair sounds too hierarchical so we switched to Lead and Co-Lead role to match the new structures we will be embracing.

If we want to change the future of project management I believe the best way to do that is from the inside outwards by doing the work - not from the outside inwards just criticizing. Longtime readers may recall my 2010 post Raise A Little Hell when the PMBOK v5 Update was being commissioned. Since then we developed the PMI-ACP, PMBOK Agile Appendices, and the Agile Practice Guide.

This is going to be different!

Click here to see full volunteer role details.


Incubating Innovation

InnovationIf success goes to those who can innovate the fastest, how do we nurture innovation? The basics are simple to understand—but difficult to implement and stick with in the face of adversity. We need to create an environment that encourages experimentation while also tolerating, investigating and learning from the inevitable failures.

It may sound easy, but executives and shareholders demand results, not “learning opportunities.” We need an approach that fosters experimentation and learning in a defendable way, with a bias for results. To innovate faster than our competitors, we need to maximize our learning potential. This means that by design, 50% of our experiments should fail since we are seeking knowledge expansion, not validation of things we already know. The trick is keeping people engaged and motivated when half of their experiment time is spent failing.

It starts with leadership and cascades down to a shared mindset of team members. Leaders need to be transparent about their own mistakes and learning moments. They need to model the desired behavior, share what they have learned and their new plan of action.

These can be strategic learnings (“Our European market testing has been poor, we are reworking the price options”) or personal (“Feedback on my presentation to investors indicated I was too technical; I need to find simpler ways to describe our technology”). Until team members see transparency in common use, they will be reluctant to practice it themselves for fear of reprisal or criticism.

We Are in the Maze-Solving Business

Maze 1
Developing new products or services is a maze-solving exercise. Nowadays, it is also a race. We need to find a workable solution faster than our competitors. There will be obstacles and dead-ends along the way, and that is okay. We must not let them demoralize us; we just need to learn from them, not repeat them, and keep going.

The process of learning starts with understanding the knowable and then adding to this through experiments and new learnings. So, we start with smart people who understand their industry domain, technology and the business goals. We then need to create an environment with a dual track of product development and experimental learning.

Organizations that run more experiments and iterate faster also learn faster. Scientists studying inheritance use mayflies because they reproduce and provide experimentation results so quickly. The more experiments you can run in a year, the more you can learn.

Our Mazes are Really Big

Maze 2

Developing a new product does not happen overnight. Outside of movies, rarely do lone geniuses develop a marketable product themselves. Instead, it takes teams of subject matter experts months to create proof-of-concepts and multiple iterations of tweaks to complete a viable product. These teams need support and coordination services throughout the process.

Sponsors, executives and shareholders need plans, projections and updates. Product managers, project managers and team leaders all play an important role in keeping the maze-solving teams motivated and moving in the right direction. They also need to keep funding and support going while providing inputs about changing market demands and conditions.

It sounds a difficult balancing act, but approaches such as design thinking, lean startup and agile provide stewardship models for development with inbuilt experimentation, observation and learning. What gets less attention is motivating teams to persevere despite the many failures encountered when experimenting for learning, not just validation.

The “Success Leads to Happiness” Fallacy
Most people start their lives with the mistaken view that success leads to happiness. Our internal dialog creates a series of “if/then” scenarios:

  • IF I pass this exam, THEN I will be happy.”
  • “IF I get this job, THEN I will be happy.”
  • “IF we finish this project on schedule, THEN I will be happy.”

However, the brain has a knack of moving the goalposts. We might be happy briefly, but then we quickly focus on the next exam, an even better job or a more ambitious project.

While it is good to progress in life, we should not connect achieving a goal with achieving happiness. Instead, we need to understand that happiness is only 10% extrinsic (external things that happen to us, like success) and 90% intrinsic (how we think and feel about things).

A Happy Brain is a Productive Brain

Dopamine

Happy workers are more productive and creative than stressed or unhappy workers. In our brains, the chemical dopamine is the neurotransmitter responsible for sending reward-motivated happiness signals. Put more simply, dopamine is a happiness chemical—it gets released when we are happy. Interestingly, dopamine also switches on more learning circuits in our brains.

Research [1,2,3] shows that happiness improves work performance. Happy people are 31% more productive, happy doctors are 19% more accurate at diagnosing correctly, and happy salespeople are 37% better at sales.

This intuitively makes sense. When we are unhappy or stressed, the brain prioritizes circuits for survival. If you spot a sabre-toothed tiger, it is probably best to focus on escape rather than contemplating the interplay of sunlight and shadows through the leaf canopy. Yet when searching for an innovative solution, we want all these extra brain circuits engaged. This brings us full circle on the “I’ll be happy when I am successful” logic. It turns out, being happy actually activates more of the brain to help us be successful.

Success Fallacy

Nurturing Happy Teams
So, if the smartest workers are happy workers, how do we make them happy? Well, we don’t “make them happy” at all—that would be trying to force it in externally, using weak extrinsic motivators. Instead, we equip them with the tools to help build intrinsic happiness themselves.

This might be sounding more touchy-feely than you are comfortable with. However, hard economics show that happy workers also persevere with problems longer, take less sick days, quit less and sue for wrongful dismissal much less, too…so let’s suspend the cynicism for a moment.

The good news is that with as little as 30 minutes a day, measurable increases in dopamine levels are achieved in three weeks. So, if we can encourage these behaviors and turn them into habits, we get happier, healthier, smarter and more productive workers.

These 30-minute exercises don’t even require expensive equipment or management consultants. They are simple, backed by research and include:

  1. 3 Gratitudes – a daily recording of three new things you are grateful for [4]
  2. Journaling – recording positive experiences from the past 24 hours [5]
  3. Exercise – increases blood flow to the brain and helps eliminate toxins [6]
  4. Meditation – resets multi-tasking fatigue and helps with concentration [7]
  5. Acts of Kindness - helping others and saying “thanks,” which makes us feel better [8]

Organizations spend vast sums of money hiring smart people and providing them with complex tools and training. In comparison, the cost/benefit potential in investing and encouraging team happiness is extremely compelling. As project managers, team leads and executives, we need to be conscious of the behaviors we model, because people are watching us.

If not already doing so, we can use these techniques ourselves to improve our own happiness and productivity—then share and encourage others to make use of them. A great benefit of intrinsic motivators is that they can be applied anywhere. It does not matter if you work in a toxic environment or report to a jerk. There is likely nothing stopping you making sure the first email of the day you send is to thank someone for their help or contribution. Also, no one will know if you make notes about positive experiences.

People with budgets and hiring authority do know that yoga instructors are much cheaper than labor relations consultants and HR lawyers. Longer lunch breaks and fun team activities may require some explanations, but improved problem solving, fewer sick days and better ideas are definitely worth it.

Don’t wait until project completion to celebrate team achievements. That’s too little, too late—and our brains have moved the goalposts to be thinking of the next project. Instead, celebrate the little things that recognize effort, persistence and displaying a good attitude.

Obviously, it is not as simple as “happy people are the perfect innovators.” There are some concerns that people characterized as “happy” might be less likely to spot certain types of risks. Optimism needs to be tempered with realism. However, given the variable success rates of helping people become happier (“leading horses to water,” etc.), there will still be some pessimists; but on the whole, it creates a positive change that is worth the risk.

Summary
Smart companies know the future belongs to the best innovators. Building and maintaining teams of productive innovators requires investment in tools, techniques and people. We need to have the right tools and be using today’s techniques such as the design thinking, lean startup and agile approaches. Then it comes down to our people. An appreciation of what truly makes us happy—and its effects on success—is a great starting point.

Most organizations are not R&D labs, so we need to balance innovation with everyday production and service. The mindset and changes described here may feel uncomfortable (or even unprofessional) at first. However, a quote from Eric Shinseki explains that “If you dislike change, you're going to dislike irrelevance even more.” It reminds us that the business landscape is changing faster than ever—and that we need to change with it to stay valuable.

References

  1. The Happiness Advantage
  2. The Benefits of Frequent Positive Affect: Does Happiness Lead to Success?
  3. Happiness and Productivity
  4. Counting Blessings Versus Burdens
  5. How Do I Love Thee? Let Me Count the Words, The Social Effects of Expressive Writing
  6. Behavior Matters
  7. One Second Ahead
  8. Interventions to Boost Happiness and Buttress Resilience

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


Review of Product Development Books

Product Development CycleNow 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.

This is where product development books can help. They describe the factors at play and provide ideas for guidance around planning, funding, staffing and governance. As I was working with clients experiencing the transition from projects to products I was lucky to engage with several authors of product-first, #NoProjects books and chat about the challenge areas and potential solutions.

I have written about #NoProjects a few times before:

 

Then when I recently read a third book about product development shift I thought it could be useful to review some of the books in the market. A neat aspect of these books is that they all present different views on the project to product mind-shift and journey.  

Continuous Digital

 “Continuous Digital: An agile alternative to projects for digital business

Allan Kelly, Software Strategy Ltd.; October 2018

Allan’s book was the first I read about switching to continuous product development. I had been following his blog for a number of years and was familiar with his work. However, it was not until reading the book that I saw his points laid out in order with full explanations.

It is a great read, it makes a compelling argument for why a project view of software projects is a flawed model. I loved the explanation on the diseconomies-of-scale for software and why it is actually cheaper in small batches – unlike physical goods.

It offers the best explanations I have heard into why a continuous delivery of features by a stable team is preferable to using conventional project models. It nicely describes the team aspects of knowledge work and offers some good suggestions around funding and governance models.  

Any change in mindset has to happen internally first before we can help others adopt it. Continuous Digital cemented my own thoughts about why good software projects never end. It explained the “Why?” questions at the heart of any shift in thinking and behavior. In the same way, we have to understand the agile mindset before generating any kind of commitment towards it. This book helps set the mindset and Why of #NoProjects so we can start our journey.

 

Noprojects book#noprojects: A Culture of Continuous Value

Evan Leybourn, Shane Hastie, lulu.com; July 2018

I read an early draft of Evan and Shane’s #noprojects about 6 months after I started reading Allan Kelly’s LeanPub drafts of Continuous Digital. While Kelly’s Continuous Digital and his spin-off book Project Myopia focus on explaining the Why with some How topics, #noprojects has more of a team focussed view.

It talks about the history of software development. It explains how we came to run software development with project structures and the inherent issues that came with them. It then outlines the case for continuous development with all the arguments for retaining knowledge, reducing handoff and dependences, etc.

I think it is a great follow-on from Continuous Digital. Obviously, it is designed to be a stand-alone text but, for me, Kelly explains the Why of product development better. Then #noprojects fills in some additional background information and focusses more on the team level implementation. It might just be because I read Kelly’s book first but if you are looking to convince others in your organization about the need for transitioning to product development it is the go-to source. Reading both will provide a great foundation to understand and transition from projects to products.

 

Project to ProductProject to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework

Mik Kersten,  IT Revolution Press; November 2018

I first came across Mik’s work via a podcast he did with Shane Hastie. In the podcast, Mik explained that technologies often follow 50-year cycles and then transform through a tipping point into the next evolution in the way of working.

Organizations that try to continue operating with the old model flounder and fail. Moreover, it is now about 50 years since NATO held the first conference on software engineering and the age of software began. Mik explained he believes we are at that tipping point and transitioning to product delivery will be part of the differentiator for the next wave of successful organizations.

I have an interest in technology evolution stories and learning how ideas spread and then transform our lives. So, the 50-year cycle piqued my interest and I ordered the book. The book delivers and not only does it explain the tipping point we are living through right now, but it gives the best explanation of the digital revolution and need for digital transformation I have read to date. Kudos to Mik. If you want to explain why a digital transformation is necessary, and the implications of ignoring it, Project to Product is a brilliant source.

After this great introduction, the remainder of the book explains the Flow Framework Mik helped develop and promotes through his company Tasktop Technologies. The Flow Framework provides metrics and tools for tracking and managing product development. This is useful because while the project management world has a wealth of information about tracking and managing projects, organizations that switch to product management often experience a void or competing recommendations.

The Flow Framework is useful for explaining what we should pay most attention to tracking. Namely features, defects, risks and debts. It recommends a business outcome set of measures that include: value, cost, quality and happiness. The framework employs a lean inspired set of metrics that include flow velocity, flow efficiency, flow time, and flow load.

It is in the rebranding of tradition lean metrics that I struggle to recommend the book wholeheartedly. By prefixing the normal throughput based lean metrics with the word “Flow” Mik is able to define  specific versions of the terms that are often implemented slightly differently from organization to organization. I can see the advantage of that, but it seems an unnecessary name-grab or overloading of lean terms to create trademark-able terms.

That’s a minor quibble though and what Flow Framework does provide is a good mental model for organizing, executing and tracking your product development process. It nicely extends the pattern of books started with Continuous Digital that explains Why product development. Then #noprojects that provides some team-based and stewardship elements. Finally, Project to Product provides solid How To ideas for ongoing governance and improvement.

 

Summary

These three books form a useful progression for anyone wanting to learn about the product development trend. They each provide valuable ideas to help with understanding, practicing and then managing successful product delivery.

Product Development Books Progression

The books allow readers to understand and internalize the need for a product development mindset. Then how to practice on a small scale before encouraging others to try and providing ways to measure and manage it.

Obviously, you do not need to read all three of them, or in this sequence. Any one of them is a good read and source for practical ideas. However, I found that they build nicely upon each other and thought people would be interested to consider them as complementary.


Agile 2019 Presentations

DC ConferenceI learned this week that two of my presentation submissions for the Agile 2019 conference in Washington D.C. August 6-10 have been accepted. I was very lucky to get two accepted as they received nearly 2,000 submissions for around 250 slots. It should be fun and I am really looking forward to it.

My talks will be on moving beyond agile approaches and case studies in transitioning from projects to products.  Here are the outlines:

 

The Future Looks Awesome, and Moving Beyond Agile - The Future of Agile Software Development (IEEE Software) track. The Future is Awesome

“Agile approaches succeeded and changed the way we work. They brought the philosophy and tools previously used by only the high performing teams to the majority of organizations. Now it is time to move beyond them and embrace a new wave of emerging ideas and approaches.

It is short-sighted and self-absorbed to imagine agile approaches represent the best way to execute all work types. As new technology, products, and services emerge, we need new ways to deliver them. Likewise, as organizational structures evolve to use this technology and integrate the aspirations of next-generation workers - who grew up in a digital world, our approaches much evolve again.

Fortunately, patterns are emerging from new organizational structures and the lessons from failed agile transformations. Agile’s “Family” mindset of empowerment and values-driven culture is being overtaken by “Organism” and “Community” mindset organizations embracing Holacracy and Teal Organization ideas. People are also realizing not everyone wants to adopt an agile mindset and we need better ways of integrating with more traditional models that remain that way for their own advantages. The future involves further expansion and integration, not more fervent conceptual conversion.

Come and examine the future beyond agile and hybrid agile. Explore the trends in corporate structures, career aspirations, engagement models, and the technology that is making it all possible. The future is exciting, dynamic, and decidedly less agile – but in a good way.”

It will be a fast-moving presentation recapping the rise, role, and results of agile approaches before moving onto emerging trends. Through case studies of successful organizations, we will explore new patterns in work, the worker, and the workplace.

Agile approaches play an integral role and will continue to in the future. However, they are already being augmented and extended by additional models and techniques. Using a “Yes, and…” mindset of combining approaches we examine emerging trends and what they may mean for the future of collaborative work.

 

PotholeSpeed-bumps and Potholes on the Road from Projects to Products - Experience Reports track.

“Transitioning from projects to products made perfect sense for my client. Much of the business was digital and their websites / online-services would not be “completing” or going away soon. Development was deliberately continuous, and executives embraced this as both inevitable and desirable. However, just because it was the logical thing to do, it did not mean it was easy.

Maybe if we did not have over 100 inflight projects executing simultaneously, we could have picked an easier starting time? Maybe if there were not so many dependencies between teams, work would have been easier to untangle? Maybe if they were not in the midst of transitioning to microservices and new hosting technology, the technology challenges would have been easier to resolve?

Most organizations considering the transition from projects to products have similar challenges. By definition, “transitioning” means doing things mid-process; otherwise, it would be “starting fresh with product development” – and where’s the fun in that?

This experience report recounts the story and transformation from slick PowerPoint slides to people problems and development difficulties. We did survive the journey and arrived in the land of continuous digital delivery, but we took some detours and lost some paint along the way. If you are considering the switch from projects to product development, maybe we can help you avoid some potholes and speedbumps along the road. Being forewarned is to be forearmed, but each journey is different, and as they say, your mileage will vary.”

It recounts my experience as a consultant working with the leadership team and development teams. There was general agreement that a shift to organizing around products made sense, but disagreement on the best way to get there. Rather than a big-bang changeover, we adopted a ripple-out, incremental approach. This allowed us to review and monitor for issues before spreading approaches to more teams. Naturally, the executives wanted everything done at once and the teams wanted to be left alone until after the next release.

Not being able to please everyone, we developed a workable plan and rolled out the changes to teams, technology, and supporting groups. We experienced many obstacles such as having to rewrite vendor contracts, get exceptions from accounting for budget processes and from HR for reporting changes.

More details about the Agile 2019 conference in Washington D.C. can be found on the official website.


New PM - The What?, Why?, and How? of Project Charters

Project CharterCreating a great project charter is an art and a science. Anyone new to the profession of project management needs to learn how to create a project charter. It is not only an important early project deliverable, but it also sets the tone and lays out the foundation for the rest of the project.

While we can spend our careers improving our ability to craft effective project charters, we can get to a 70% good-enough state by addressing some basic topics. This article explains those basics.

Context is Crucial
First, it is critical to understand that context matters. The definition of what makes an acceptable—or great—project charter will vary from organization to organization. It will also be driven by factors such as project size, criticality, type, approach, etc.

The project charter for kicking off a safety-critical public works project will be very different than a charter for a small internal project to, say, build a tool to recover disk space used by duplicate files.

Large, critical projects will require large comprehensive charters. These can take teams of experts weeks or months to create. Small projects will likely have their three- to eight-page charter written in a day or two by the project manager. When creating (or reviewing) project charters, we need to understand this context. Ask, what is appropriate? What level of rigor and detail does this effort require and deserve?

To start the chartering process, we first need to understand a few things about the project goals and our internal processes.

  • For the project, we need to understand the business case and an outline of the desired scope.
  • For our organization, we must understand any strategic plans we need to align with, our standards and processes, contracts to use, and any relevant external factors like market conditions and industry standards.

Once we know these things, we can start writing our charter.

Make it Clear
I am a simple person and like simple ideas and definitions. I probably miss subtle nuances but have learned that most people appreciate simple, clear documents. The style points we lose for a lack of sophistication are made up for by improved comprehension and clarity. So, my definition of a project charter is a document that authorizes the project and explains the what, why, where, when, who and how aspects of the project.

We can call the whatwhywherewhenwho questions W5 and add a “+” for the final how question. Provided the project charter answers the W5+ questions and provides approval to start the project—all at the appropriate level of rigor—it’s a winner. So, let’s get started by reviewing each question…

What?
In your project charter, you will not call the section “What?” It will likely be called “Scope” or something similar. The “W5+” idea is just a tool to make sure we address the important sections. So, in the scope section, we would describe or list the major deliverables or high-level functionality the project should deliver. People need to understand what we are talking about before they can appreciate further details such as schedule and approach.

When defining what the project will deliver, it is also useful to state what it will not deliver. So, a list of “out of scope” items is also valuable. It is better to have sponsors or user representatives complain now rather than halfway through the project (or worse, at completion when there is nothing we can do about it) that their anticipated element will not be delivered.

Why?
The why of a project is described in a “Problem Statement” or “Business Need” section. Some people put this section before the what. That is fine; follow your organization’s standard, or the preferred sequence of who approves project charters (or failing those, your own preference). Just make sure the what and the why are addressed early on.

People need to understand why this project is important. What new revenue will it bring? What problem or legal requirement does it serve? What new opportunities, new products or new customers do we hope it will attract? Projects are expensive and risky endeavors, so we better have a good reason to undertake one. The business case or problem statement is where we describe it.

It needs to be clear and compelling. It may reference a separate business case or return on investment analysis. If these components are necessary and not in separate documents, include a summary in the charter body and put the details in an appendix. We don’t want people to stop reading our project charter because they came across pages of calculations.

Where?
“Where?” can seem a strange question, maybe inserted just to get the “W” count up to five. However, think broader. Which markets, products, and departments are we impacting? Where is the project going to touch our organization, customer base, and market segment?

Remember: The project charter normally provides approval for a project to start. We need to provide the relevant context so people are thinking appropriately before they approve, reject or request changes be made.

This information may be contained in a section called “Organizational Impact” or form a sub-section of the scope section. It also explains how the project is aligned with the organization’s strategic plan.

When?
This is where we describe the “Project schedule”—not only when we plan to start and (hopefully) complete the project, but also major steps along the way.

Being a project manager writing a charter, it’s easy to get caught up in the apparent importance of your project. You might assume that once approved, the organization will rush full-steam ahead into kickoff and execution. We need to inject some caution and realism. What seems important and obvious to us is often low priority for the sponsors or those already over capacity in executing existing projects and operations. Things might take a while to get going.

So, do not build a schedule based on starting work immediately after approval. That just sets everyone up for failure. The most common source of late project completions is not poor estimating or a lack of risk management, it is late starts. Every late project I have reviewed had a late start. They may also have been terrible at estimating and blind to common threats, but late starts are very common. We need to explain that real end dates are driven by real start dates.

Projects get delayed for a host of common reasons. We were delayed in getting our team, we were delayed in finding a space, we were delayed in accessing funds. So, do yourself (and everybody else) a favor and explain that the project will likely take three weeks, months or years from having the requisite start conditions.

We also need to be realistic about uncertainty. The uncertainty associated with our estimates needs to be reflected (to some degree) in our schedule. It is probably not acceptable to say, “We have no clue when we will be done.” But do not commit to completing within a certain timeframe unless you have a realistic and robust plan for achieving that.

Robust means including contingency to address uncertainty. Be open about it, such as, “We included a 15% buffer for unanticipated work.” You might get asked to remove it and “work smarter” or “find a way, damn it!” and that is fine. You reflected the uncertainty inherent with the work. Depending how supportive the sponsors are, we could consider explaining that removing contingency is accepting the risk of an overrun due to learning in the future things that we do not know today.

Plans and estimates created at the beginning of the project are, by definition, the least reliable because that is when we know the least about the project. It is only when we begin to execute that we learn about its true complexity and the actual abilities of the team, vendors and supporting groups. Sponsors usually don’t want to hear this kind of smartass insolence from the project managers. PMs are hired to deliver projects, not tell them how to set stretch goals or run a business.

There are other ways to shorten a schedule. We can cut the scope of what is delivered. This could allow us to hit a deadline and maybe have a follow-on release for lower-priority work. It is not ideal and is really wriggling out of the defined scope. However, for software products, where must-have and nice-to-have features are more fluid, it could be a viable option.

We can also add more people to the project. This works great if you are undertaking simple work like digging ditches or building pyramids. For anything more complex that involves problem-solving, idea sharing and collaboration, books like The Mythical Man-Month explain that adding people to a project that is late will make it later (while spending more, too).

For these reasons (and others learned the hard way), make sure schedules clearly contain contingency to reflect uncertainties. Also, ensure that schedules work from a project start date that is contingent upon having prerequisite project conditions in place. Yes, they might both get ignored, but it is the responsible thing to do—and you can bring them up at steering committee meetings when asked why the project is behind.

Who?
The who question represents the “Team” and “Stakeholder” sections of a project charter. It is normal to show org charts of core project roles and list known team members and open positions. RACI charts can be used to list who is responsible, accountable, consulted and informed (RACI) for work and deliverables.

We should understand that the term stakeholder encompasses not only the people working on the project and sponsoring it, but also everyone it will impact. This extended family of project influencers include suppliers, customers, and even the general public if the project is likely to draw public opinion. Obviously, we do not list these broader communities by name, but we should identify them and assign a contact within the project for managing that group.

The PMI definition of a stakeholder includes not only those impacted by the project, but even those who perceive they may be impacted by the project. This is important—the scope of people who may influence development is wide. It is better to have a plan for engaging or at least monitoring these groups (be them environmental, minority or special interest) before they can blindside the project. Inventing a fire-response plan is always easier to do before you also have a fire on your hands.

How?
The how question reminds us to explain the “Project Approach.” We should describe how the project will be executed. Will we be following the standard corporate project lifecycle? Are we trying a new approach? Are we outsourcing portions?

People need to understand how the project will be executed before agreeing to fund it or participate in it. If they think the project has merit but we are suggesting to go about it all wrong, they will want the ability to influence the approach used.

When we are following a standard approach, it is sufficient to just name it. When we are proposing something different, we need to describe it in more detail. This could be a reference to another document or pointer to an appendix in our project charter.

Approval
The charter describes the project from a holistic perspective by addressing the W5+ questions; it also provides the approval/authorization to start work. In most organizations, approval of the charter triggers a request for funds or authorization for expenditure (AFE). For this reason, we need some formality around the approval and sign-off of the charter. It is normal to have a signature section for sponsor, division leads and other steering committee members.

The approval circumstances are rarely as simple as either approved or not approved. It is usual to have definitions of the various options that the steering committee may use. Common status options include:

Approve – Looks good, let’s get started
Approve with modifications – Will be okay if you make these changes (provide some space in the signature area to hand-write requested changes and then get signatures)
Request changes – Major changes are required and a new charter will need to be submitted
Defer – Not at this time, keep on hold
Reject – No, do not proceed

What about agile projects that do not have charters?
Today’s agile projects produce fewer documents. However, since charters often authorize work to start and trigger the release of funds, we still sometimes see them used in hybrid traditional/agile environments. If project charters are not used in name, typically a lighter-weight deliverable with a different name is used.

We might see an Agile CharterProject Skinny or Product Canvas. The purpose is similar—describe the endeavor and get agreement to start. When working with agile approaches, we can still use the W5+ idea to make sure we address the common viewpoints. The coverage in each section will likely be brief, but is still helpful.

Summary
Consider the context you are working in. Organizational standards and project characteristics such as size, cost, and impact of failure will dictate the level of detail and rigor that will be necessary. Then keep the sections simple and clear. Use appendices or references to external documents if sections become too long. We want people to be able to read the core body of our charter through in one sitting and then make a decision to approve it.

Make sure the sections address the W5+ views of the project one topic at a time. For instance, do not mix schedule with business justification; keep them separate. Do not paint yourself into a corner by committing to unrealistic delivery dates or optimistic costs. Present what you believe is realistic and let the steering committee assume the risks of reduction (if possible).

Recommending a template is problematic since organizational needs vary, but common sections for a small- to medium-sized project might contain:

  • Introduction – Explain the purpose of the charter
  • Problem Statement – Outline the what
  • Scope Outline – More detail on what would be delivered
  • Definition of Success – Define what “done” would look like
  • Risk Summary – Review the high-level threats and opportunities identified
  • Constraints and Assumptions – Outline the accepted operating parameters used
  • Business Case – Explain why the organization should do this
  • Schedule – Explain when the project will be completed
  • Deliverables Schedule – Outline when the key deliverables will be completed
  • Budget – Explain how much this is likely to cost
  • Team Structure – Outline who will be working on the project     
  • Organizational Structure – Explain who will be responsible for oversight and direction
  • Project Approach – Explain how the project will be run
  • Steering Committee Decision – Record the approval (or otherwise) of the charter
  • Appendices
    1. Project Background – Supporting material about why this is a good thing to do
    2. Deliverables List – A list of what should be delivered and what Done looks like for each
    3. Deliverables Schedule – A schedule for the deliverables’ leave some wiggle room
    4. Risk Assessment Detail – Details of the threats and opportunities analyzed to date
    5. Communication Plan – Details of how people will be kept informed about progress and issues

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


New PM, New Choices

Choices(Over at ProjectManagement.com January’s theme was “New PMs”. I wrote this article about the choices of approach we have and ways for new PMs to navigate them.)

These days, new project managers are exposed to conflicting guidance. On the one hand, there is a plethora of traditional “Plan the work, work the plan” literature. On the other, media is full of light-touch, self-organizing team advice. These sets of recommendations often appear to be at odds, so what is the new PM to do? Consultants will say, “Oh, it depends…” and start a lengthy (aka expensive) conversation. I say let’s examine the basics so we can make an informed decision ourselves.

The goals of planning, scheduling, and tracking are universal. We need to understand what work needs to be completed, determine a good way to do it, then make sure it happens while making adjustments as new information emerges. However, in the last 30 years, we have started tackling more projects with higher degrees of uncertainty and change. These characteristics help us determine if we should use traditional, predictive approaches or rely more on newer, adaptive techniques.

When our projects undertake defined, repeatable work using technologies and approaches our organizations have experience in, then uncertainty and change rates are typically low and manageable. Here, traditional project management approaches work great. It is safe and effective to use Gantt charts, detailed work breakdown structures (WBS), network diagrams and earned value analysis.

Yet when projects use new (to us) technology and tackle problems our organizations have not solved before, then risk, uncertainty, and rates of change will be high. Traditional approaches have plenty of tools for handling risks, uncertainty, and change; but modern, adaptive approaches were purpose-built for these types of projects and have proven to be effective in these circumstances.

Work Characteristics, Not Industries
It is important that we examine work characteristics, not just the industry domain we are operating in. It would be easy (and wrong) to classify all construction projects as candidates for traditional approaches, and all IT projects as needing an agile approach. Instead, there are plenty of experimental construction projects using new designs, materials and assembly approaches. Likewise, there are defined, repeatable IT projects that can (and have been) successfully managed using meticulous planning, detailed estimation, and formal change control procedures.

So we need to dig deeper and see if we are dealing with low-variability tasks or more consensus gathering and problem-solving. These work types often change depending on which phase of a project we are working on. Designing something is typically a consensus-gathering and problem-solving exercise. Here, formal planning and estimation are difficult because we don’t know what we will encounter.

Consider the process of designing a new car or home. We have a combination of creative goals (produce something new and appealing) and engineering goals (meet specifications, constraints). The process is likely to be iterative and adaptive. We are looking to build consensus between stakeholders, who include sponsors (concerned with value, schedule, quality), designers (aesthetics, features) and engineers (performance, practicality).

This design phase requires collaboration between subject matter experts and probably iteration on prototypes to confirm understanding and validate ideas. Approaches like lean, kanban and agile work well in these uncertain, high-change environments. Their tools for experimentation, rapid feedback, reprioritization, and improvement help generate consensus on designs and drive uncertainty out of models.

Then, once the design is agreed upon, the process of production is typically more defined and repeatable. Unless our car or home is using new technology, materials or assembly techniques, the process of actually turning designs into completed examples should be less uncertain and iterative so more predictive approaches to work management can be used.

Physical projects—which manipulate tangible materials like concrete, steel, and plastic—have significant production phases where predictive approaches can be employed effectively. Digital projects—which manipulate intangible data and algorithms—have no production phase since the process of turning code into executable software (the process of compiling code) is automated.

Physical Project Characteristics

So, software projects remain in the design phase—that early, upfront, uncertain period where subject matter experts are collaborating to create something that has likely not been done before.

Digital Project Characteristics
There will be many trade-offs between design goals and implementation practicality to be made. All the divergent stakeholders will have divergent goals. The sponsors want fast, cheap and high quality; the users want their work simplified and streamlined so they can focus on their goal. The development team wants interesting work using new technology and skills to further their craft.

Once we understand what work types suit predictive and adaptive approaches, we can make better sense of our projects. Having said software development is design phase focused, it’s important to understand most IT projects do more than just software development. Tasks like ordering equipment, installing hardware and training users can all benefit from predictive planning and management techniques.

A Case Study
A couple of years ago, I worked on a project to develop and install routing software for truck drivers. This combined custom software development, integration with commercial off-the-shelf (COTS) software, and hardware installation that required wiring into the truck’s engine management system and installing GPS transmitters, tablets, etc.

The custom software development was easy to plan (but not easy to do). It was new, uncertain and benefitted from an agile approach. Integrating with the COTS software was a hybrid process. We worked with the vendor to iteratively tackle the highest risk and highest business value portions first. However, being just one customer of many, the vendor did not have the availability to serve our needs as quickly as we would have liked.

We worked on a monthly delivery cadence maintaining a backlog of issues and features to tackle next. Due to previous disputes about charges, the working relationship with the vendor was quite adversarial—so detailed statements of work and a formal change control process was followed. This consumed quite a bit of time for both parties, time that could have been focussed on feature development—but that reflects the reality of many commercial projects. We have to make the best use of what we have, given the current circumstances.

Installing the equipment in the trucks demanded precision timing, OCD levels of planning and copious communications. Semi-trucks cost hundreds of thousands of dollars and are carefully scheduled to make the most of their time. Bringing them in from a wide distribution area and having them out of commission while installs are performed (and drivers trained) is an expensive exercise.

When there are several hundred trucks spread across the United States and Canada, scheduling install teams and trucks to come to install/training centers becomes a variation on the traveling salesman math problem. Minimizing the total cost of lost trucking time, travel costs and staff time is a classic traditional planning problem.

In summary, like most real-world projects, the environment was complex and required using a variety of approaches. The custom software development was in-house and under our control. We used an agile approach with team-led sprints, demos, retrospectives, adaptation etc. The integration with the third-party package software was more of a hybrid approach. There were monthly deliveries based on a backlog we prioritized, but also statements of work and formal change requests.

Finally, the hardware installs and driver training was handled in a traditional, predictive way. Schedules for installs, equipment, and labor were planned and communicated well in advance. We did adjust these plans based on findings from early installs, but traditional, waterfall-style plans have always been amenable to minor adjustments. Software updates were delivered to the trucks over-the-wire as the trucks communicated back to base, so the agile teams could get new versions distributed once the equipment was installed.  

Making Informed Choices
Assessing uncertainty and consensus-gathering needs are important factors in determining the most appropriate approach to use. Thinking first about uncertainty, well-understood, often repeated work (such as building a new Costco store) represents much less uncertainty than rare endeavors such as building an underwater hotel:

Project Uncertainty

If we add to this uncertainty view the dimension of approach focus, we arrive at a framework for assessing project approaches (shown below):

Approach Focus

The “Approach Focus” Y-axis describes if techniques (approaches) are technical, such as creating a work breakdown structure (WBS); or people-focused tasks, such as team decision making or conflict resolution.

Using this framework of project uncertainty and approach focus, we can see that traditional, predictive approaches cover the bottom left quadrant of the graph well. They are great for work we are able to define and provide good process guidance:

Traditional Approach

Agile approaches tackle the problem space from the opposite corner. They are best suited for projects with high degrees of uncertainty and offer good people-based guidance:

Agile Approach

There is a large overlap, too; it represents areas where we could use a traditional approach or an agile approach. Usually, it is recommended to use the approach the stakeholders will be most familiar with. So, if we are running with an agile team, a risk-adjusted backlog and risk burndown chart will likely be an easier sell than traditional risk management approaches. Likewise, if we are in a traditional, formal contracting environment, then statements of work and bills of materials will be accepted more readily than agile alternatives.

Summary
We can use the project environment to help determine which execution approach to use. Obviously, there will be organizational standards and guidelines to be aware of, too. However, even within traditional or agile guidelines, we can tailor our approaches based on uncertainty and task focus.

New project managers should understand that traditional project management has a wealth of process-oriented guidance for well-defined tasks. Likewise, agile offers much for uncertain, high-risk work that focuses on collaboration and people-based tasks.

We should also be aware that real projects are messy, complicated affairs. We often use a combination of approaches at macro and micro levels to try and be successful. It sounds complicated, but it forms the mastery of being a great project manager and is a journey worth pursuing.

[Note: I first wrote and published this article on ProjectManagement.com here]

 


Focusing on Results, Not Agile Approaches

Focus on Business Value


Quarter Century

25 Years Agile2019 marks the 25 year anniversary of Scrum and DSDM. I was involved in the creation of DSDM in 1994 and was an early adopter of Scrum and FDD shortly afterward. Now, having been at this for a quarter of a century I am reflecting on where my journey has taken me compared to others.

I am agnostic about agile. I value the mindset and goals more than approaches that preach a single path. This has had mixed blessings for me. I remain agnostic and impartial, but I have not jumped on any of the approach bandwagons.

I received more training in Scrum by Ken Schwaber in 2002 and offered a training role (before they were called CSTs)  but I have never offered Certified Scrum Master training. I would feel wrong evangelizing the singular view of Scrum as the way, or role of the Scrum Master to spread Scrum. That feels too religious to me.

Don’t get me wrong, I think Scrum is an OK starting place, but I would not recommend only using a Scrum approach - since approaches like Lean, Kanban and FDD have great things to contribute too. Some Scrum practitioners correctly explain that Scrum does not say you cannot add other approaches. In fact, it can be viewed as a deliberately incomplete framework, so organizations have to add their own process to make it successful. Yet this message is undersold as I visit organization after organization that only use Scrum practices with maybe some XP engineering practices. They are missing out on so much more and struggling because of it.

The Scrum community often has a myopic focus blaming implementation struggles on a failure to understand or apply Scrum properly - when maybe something outside of Scrum would better suit the situation.

Likewise, I think SAFe does a great job of packaging and presenting some good ideas for organizations to consider - but its adoption draws too much effort away from developing valuable product. By all means, raid SAFe for valuable content and ideas, but create your own approach with the bare minimum of process. Then continue to ditch that process as soon as it is no longer worth the effort.

 

Take Off

Agile TakeoffIn the 25 years I have been using agile approaches, I have seen companies like LeadingAgile and LitheSpeed form, grow and prosper. They offer Scrum and SAFe training even though they are also agnostic and understand the benefits of various approaches.

I have thought about just sucking it up, drinking the cool aid and offering these courses. I could also explain there is nothing to stop us blending other approaches too. However, then its not really Scrum or SAFe, or whatever I am peddling so it is not a genuine message, which is important for me.

I offer my own training courses in agnostic agile, focussing on the philosophy and tools available for a variety of circumstances. However, like trying to market a healthy, balanced diet, I am first to acknowledge the message lacks the clarity, simplicity or sex-appeal of a single, silver-bullet solution.

People want a “Paleo”, or “South Beach”, or “Atkins”, “Mediterranean”, “Keto”, “Raw”, or “<Whatever>” solution to follow. I can yell, “Stop being lazy sheep and think for yourself”, but the majority of people want recipes and ready-meals, not to learn nutrition and cooking skills.

 

 

Benefits, not Popular Fads / Staying On Track

Staying On TrackThat is OK, I would rather be genuine than popular. I truly believe we are most successful when agnostically taking the most suitable approaches for our circumstances. Then, ruthlessly reviewing, morphing and pruning these approaches as our teams evolve.

We need to focus on the output, the business value, not the process. If wearing purple hats produced better results than agile then I would be all for purple hats and ditching agile. This is one reason I named my company as LeadingAnswers and not a name with the word “Agile” in it. I am focussed on solutions and outcomes, not a single approach. I still believe Agile is our best starting point, but I am always hopeful we will create something better.

As 2019 starts, I am doubling down on my “Yes, and…” commitment. I realize the message lacks the clarity of a single, sexy, (sub-optimal) solution and so it will never be widely adopted. However, my last 25 years has taught me that there are enough people who see the benefit of a balanced, evolving approach.

So, I hope you stick with me as I explore being successful by focussing on delivering business value regardless of approach. I think there is merit in traditional processes in the right circumstances. There are also many underemployed benefits from leadership, emotional intelligence, and industry specific practices that get used in pockets that we could all learn from.

Here’s to another 25 years of delivering the most business value we can through situationally specific approaches.


DIPMF 2018

Dubai SkylineI have just returned from the 2018 Dubai International Project Management Forum (DIPMF). It was my second year presenting there and this year I hosted a session called “Agile: Not New, but Now Necessary”. It traced several techniques back through history and explained how lean, agile, and design thinking approaches share common guidance for building high performing teams.

During the conference, I mainly attended the agile and artificial intelligence (AI) sessions. Having written about AI augmented project management previously I was interested to learn more about Microsoft’s PMOtto assistant that uses Azure Machine Learning Studio. PMOtto has a chat-bot interface that uses their LUIS (Language Understanding) machine learning based natural language system to understand questions. It integrates with Office 365 tools, a cognitive services model for learning about projects, and business intelligence tools for analysis. Like having a project assistant who is always getting smarter, PMOtto will track, trend, and answer questions for project managers and PMOs.

TED speaker and child prodigy Tanmay Bakshi gave an inspiring keynote on AI. His main theme was it is more like Augmented Intelligence rather than true Artificial Intelligence. He profiled some of his work including helping those with Rett Syndrome "speak" through the detection and interpretation of EEG signals analyzed by cognitive systems.

PMI’s Murat Bicak, senior VP strategy, also gave an interesting talk on AI as Augmented Intelligence. He profiled some AI generated artwork that used machine learning to identify pleasing images. Interestingly, when control groups were asked to try and identify images as either human generated or computer generated, people rated the computer-generated images as human 75% of the time compared to human-generated art only 48% of the time.

There were also great keynotes by Yancey Strickler, co-founder of Kickstarter on building socially responsible companies and Lisa Bodell, founder of Futurethink on why simplicity wins.

The whole event was really well hosted and it was great to see a massive display wall featuring a Project Management History Timeline. It showed PM developments and local Dubai mega-projects since 1917 from the Gantt chart all the way up to the present. The early years showed the creation of the Critical Path Method, the building of the Dubai airport, formation of the PMI, and creation of the PMP certification.

Timeline 00

The middle years celebrate events like building of the world’s tallest tower, the Burj Khalifa, and breaking ground on the world’s largest solar energy facility. The chart seemingly culminates in the grand finale, the Agile Practice Guide. Having worked on the guide with many other people, it was great to see it profiled. It was a fantastic conference and I hope to be invited again next year.

Timeline 2


What’s in your backlog?

Let’s explore what you do and do not put in a backlog. How do these sound?

  • Features and non-functional requirements – Absolutely
  • Bug fixes and change requests – Yes, probably
  • Risk avoidance and risk reduction activities – Sure, maybe
  • Opportunity exploitation activities and marketing ideas – Now you’re just getting weird!
  • Team building and social events – Erm, no!

Yet, if it’s all just stuff for the team to do, then why not put it in the backlog? Maybe because the customer has not asked for it and the product owner has to own and order it, but let’s look further.

If we used a backlog metaphor for prioritizing backlog work items. It may look like this.

Backlog of Backlog Items

I am not suggesting these are the correct elements for including in a backlog, I am just showing the common ones. However, I am probably getting too abstract too quickly. Let’s start at the beginning.

A Backlog Primer

For agile teams, backlogs represent their To-Do list of work. All the things they need to complete before the product or project is done. Now, there may be interim releases. In fact, there should be interim releases delivering valuable functionality as soon as possible. However, there typically remains a list of remaining work. For long-lived products this list may never be emptied by the team, instead it is refreshed and reordered based on the latest priorities.

While the team works from the backlog, it is typically prioritized by a product owner / business representative / ambassador user that sequences the work. This product owner manages the backlog, keeping things up to date with the latest product decisions. They also flesh-out items prior to work starting on them. Product Owners also answers questions about the work from the team, etc.

Here’s a typical backlog showing a combination of features, change requests, bug fixes and a couple of risk reduction activities.

Backlog example

Types not Granularity

This post discusses the types of things in a backlog, not the names we give different levels of granularity. Big chunks of work might be grouped into releases and then divided into themes, or features, epics, user stories and tasks as they get smaller and smaller. There is not an agreed to hierarchy at the large end of the spectrum, often teams miss out one or two of the theme / feature / epic options. However, most teams use the user stories and tasks as work gets smaller.

Nevertheless, this post is about types of work, regardless of their size or what we call them.

Scrum Product Backlogs and Sprint Backlogs

Your view of a backlog may be different from mine. Most people I meet these days were introduced to backlogs through Scrum.

The Scrum Guide describes the product backlog as an ordered list of everything that is known to be needed in the product. It is also the single source of requirements for any changes to be made to the product. The guide goes on to describe the sprint backlog as the set of product backlog items selected for the sprint, plus a plan for delivering the product Increment and realizing the sprint goal.

My backlog history goes like this…

“It’s All Just Work We Have to Do”

I was first exposed to backlogs of work in the early 1990s. Working as a developer at Data Sciences Ltd in the UK I wrote a program to manage our work tasks on a government project. My project manager saw it one day and two interesting things happened.

  1. He did not chastise me for working on a side project of developing a visual work tracker rather than working on the client project.
  2. He asked why it did not contain all our bug fixes and change requests? I did not have a good answer, other than those are different buckets of work we should track separately. He dismissed this explanation and told me to add a flag if I wanted to track work types separately, and said “It’s all just work we have to do” and walked off, but his insight stuck with me. The class of work is secondary – all this stuff needs to get done.

My visual work tracker was quite limited and I abandoned it. The database connection from Easel (a language better suited to building graphical UIs for mainframe systems) did not support concurrent users well. Yet, a couple of years later when we started creating DSDM I knew the backlog was “Just work we have to do”. The backlog is the input-hopper for team work. The product owner is the input-hopper custodian, often subject matter expert, and settler of priority and compromise disputes / negotiations.

 

Risks in the Backlog

I have been keen on proactively addressing risks for many years. Just as features deliver value, risks in the form of threats to the project cost money and cause delays - if they occur. As such, these threats are potentials for anti-value. Like bank deposits and bank-fees, the act of adding value and avoiding losses go hand-in-hand to maximize value.

In the late 1990s I used RUP with some clients and was impressed by the Elaboration phase’s goal of tackling risks early in the project lifecycle. I corresponded with Philippe Kruchten, co-author of RUP, about how to illustrate the good work done on risk reduction during Elaboration that often did not have a lot to demo or show for it. I ended up creating Risk Burn Down graphs for my projects. I wrote about these ideas when I started blogging in 2006 as Risk Profile Graphs. By this time I’d been using them for 4-5 years and knew they were well received by sponsors and executives.

Later in 2006, I wrote about risk adjusted backlogs and Agile Risk Management explaining how to insert risk avoidance and risk reduction activities in the backlog. In 2012 I presented some Collaborative Games for Risk Management at the Agile 2012 Conference and PMI Global Conference. 

When members of the project management community read these posts and papers they correctly criticized my ignorance around proper risk management terminology. Risks, of course, can be positive (opportunities) or negative (threats). I was only talking about negative, potentially harmful risks (threats) when I talked about inserting risks based activities in the backlog. A real risk-adjusted backlog has both threat avoidance and reduction steps, as well as opportunity exploitation and opportunity enhancement actions.

This is how we got to risk avoidance and opportunity exploitation activities in the backlog.  One aims to avoid costs, the other aims to generate new value. Risk management techniques like Expected Monetary Value converts probabilistic events into financial values. For instance, if we have a 50% risk of incurring a $400,000 loss then this event’s expected monetary value is 50% x $400,000 = $200,000.

Likewise, we can assess opportunities too. If the average profit for new customers is $20,000 per annum, then we can determine if inviting qualified applicants on a factory tour with product demos and giveaways that costs us $500 per head is worth it at a 5% conversion rate. Here $20,000 x 0.05 = $1,000, so yes, it appears worth offering factory tours and giveaways for qualified leads.

Multiplying guessed benefits or losses by guessed probabilities is an inexact science. However, it is one that the insurance industry has spent centuries trying to master. So they err in their favor and often price based on what the market will bear. Yet it happens throughout all forms of business and is the basis for taking an economic view of production that underpins all the return on investment and prioritization schemes such as Weighted Shortest Job First. We are constantly looking to maximize value.

So, if a team building lunch is important for boosting performance or reducing the likelihood of conflict and delay, why not put it in the backlog? If it would be helpful for someone to walk the VP of sales through the latest product demo, put it in the backlog.

The Product Owner remains the custodian of the backlog, but with some discussions around threats and opportunities, they often see the advantages of adding these other work types to the backlog. Taking an economic view of work allows us to decide “Where is the next best dollar spent’. That may well be on Feature X or a site visit to help build relationships and increase motivation.

 

 


Certification Proliferation and Confusion

Cert ProliferationLike TV channels, the choice of project management credentials has exploded recently. 20 years ago things were much simpler, in North America, the PMP was the dominant credential, in the UK and ex British Empire countries it was PRINCE2. Life was straightforward, career paths defined, and credentials well understood.

In 1983 in the US, over 100M people watched the finale of the TV series M.A.S.H. Outside of the Apollo moon landing and sports events, it remains the most watched US TV broadcast of all time. Chances were most people in the office watched it and everyone had something in common to talk about. That was Peak TV, viewer counts have increased since but program choice has exploded much faster. These days there are so many cable choices, on-demand services, YouTube channels, and Periscope sub-streams it seems as if everyone watches something different.

Likewise, project management credentials have proliferated too. Today I discovered 7 different credentials for PMO staff from the same provider. Each (presumably) providing some niche specialization or incremental progression from a former step. Don’t even get me started on Agile certifications which have splintered and multiplied faster than the brooms in Fantasia’s Sorcerer’s Apprentice.

This creates problems for project management professionals and hiring managers alike. How can they compare or rank one over another? Within the PMI community, people know the CAPM® is a foundational credential and the PfMP® is more advanced. However, outside the PMI the situation is complex and rapidly evolving.

Becoming a Certified Scrum Master might sound impressive, but for many people, it merely required attending a two-day class. Yet, at the other end of the spectrum, the Association for Cost Engineers (ACostE) requires degrees or over 30,000 hours of experience (3 times Gladwell’s 10,000 hours guide). This is more like a career quest, rather than a 2018 learning aspiration. 

This diversity in experience requirements and study effort along with frequent new offerings muddies the waters of comparison. It would be negligent to simply ignore new offerings since many have been created to fill real needs.

Instead hiring managers likely use unknown credentials as a demonstration of lifelong learning and career change motivation. They may not know exactly what they entail, but for promising candidates, a few minutes on Google should shed light on the credential requirements and process. Unfortunately with the rise of automated and AI-assisted recruitment workflows these candidates might not make the initial selection due to keyword filtering.

If someone was a little sneaky I guess they could state on their resume that their New_Credential_ABC was similar to a PRINCE2 Practitioner, PMP®, or another credential so they pass the keyword scan. Yet, if you were so inclined, you might as well have a section called Future Credentials Planned and list them all along with your Nobel Prize.

It is unlikely TV channels or credentials will ever converge back into a simple collection of universally understood offerings. People want choice and specialization.

If the future of recruiting really will be AI driven maybe a service that ranks, validates and checks credentials will be created to remove the need for hiring managers to do so? It could be constantly updated and evaluated by independent experts to ensure parity. In the meantime, if you have a niche credential or are considering pursuing one, be aware its lack of recognition could be a factor.

Ideally, credentials are just an entry point, beyond which experience and character fit are evaluated. Hiring managers should look for a baseline proficiency but then focus the bulk of their decisions on soft skills evaluated through interviews, etc. We could say it is like making sure candidates have a driver’s license if a job requires driving, it is a prerequisite. Yet we know hiring managers attribute more credence than this.

It is because of this proliferation of credentials and the encouragement to renew and expand that some people are opposed to them. They believe they are money-making schemes for the owners and not reflections of ability or experience. I sympathize to some degree, as stated, at best they are entry points, like drivers licenses, that demonstrate a base level of competence. Yet they are used by hiring managers to qualify candidates. It seems if you are looking to change jobs they are, to some degree, a necessary expense.

For other people, credentials are pursued for personal reasons. Maybe to encourage ongoing development or for differentiation among peers without changing jobs. The list of motivations for pursuing credentials is likely as diverse as the credentials themselves.

More choice is great - until it isn’t. When options and complexity overwhelm our decision-making process we need new tools. Luckily we can learn from other arenas that have complexity. The internet has not unified and standardized the choice of news, entertainment, or services. It has done the opposite and created more choice, enclaves, silos, and choices than ever before.

Fortunately, the internet also comes with tools to search, sort and rank to help us navigate all the diversity.  We need the same with certifications. As television and films proliferated sites like IMDB, RottenTomatoes, Fandango, and Metacritic were created to add smarts and help us choose. Built around expert and personal ratings these sites allow people to sort, filter and view aggregate scores.

Hopefully, we will see the same with certifications. Hiring managers and people looking for the next credential to consider will have tools to help them choose. Whereas films and TV shows are filtered by genre (action, adventure, drama), actors and viewer age recommendations, certifications will have different criteria. Categories such as topics covered, experience requirements, and assessment method are some basic measures. Beyond that user-provided data on market awareness, average study effort, typical salary bands, etc. could be added.

Just as we will not be reverting to only 3 or 4 TV channels again, we cannot expect the diversity in credentials to disappear. Unpopular ones will fail, but more choice seems to be the future. Fortunately, the solutions for managing complexity and too many choices have been modeled in other domains.

Currently searching for “Best PM credentials/certificates/qualifications” yields lots of articles, but no community-sourced tools. That’s likely the future and maybe a project for one of our readers?

 

References:

  1. UK Project Management Market Snapshot, October 2018 – Arras
  2. Wikipedia: List of most-watched television broadcasts, Retrieved October 2018
  3. Project Management Certification Benchmarking Research: 2015 Update - Dr. Paul D. Giammalvo

 

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


GOAT18

Shaw-center_0I am excited to be a keynote speaker at the Gatineau-Ottawa Agile Tour (GOAT) conference on November 30th. Along with Mary Poppendieck, we will be leading a day dedicated to learning about agile culture and collaboration.

The Gatineau Ottawa Agile Tour is an annual conference in the heart of the nation’s capital, focused on sharing and learning. GOAT has run for 7 years and is part of the Agile Tour that takes place in 90 cities worldwide.

Click to see the Keynotes Overview and the Sessions Previews.

I hope to see you there.


Hybrid Knowledge: Expansion and Contraction

Knowledge Expansion and ConsolidationExpansion 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.

Learning as a Project Manager

One of the things I love about project management is the opportunity to expand our knowledge. There is so much to learn that is useful and applicable to projects. We also live in an age where there are more avenues for learning than ever before. Like a hungry kid in a candy store, the options seem endless and enticing.

But what should we learn next to make the biggest impact? We could learn techniques to make us more effective or alert us to risks earlier. While earned-value is widely used, earned-scheduling is just getting started but promises useful tools. Alternatively, we will never be done learning how to better work with people. Communication, collaboration and motivation skills are more important than ever now talent is so mobile.  Likewise, expanding our industry and business skills are critical to build credibility with sponsors and useful collaborations with teams.

The PMI Talent Triangle nicely describes these connected but infinitely extending fields of study.

Talent triangle tm

For learning purposes, the Strategic and Business Management segment includes all aspects of your industry. For example, if you work in IT, learning anything your team does or uses would be valuable.

Hybrid Learning Model

We should study topics from each of the Talent Triangle segments. However, it needs be fun to be sustainable. We learn best when we are interested and engaged, not when trying really hard to stay on topic or complete a task. Learning also needs to be balanced with other aspects of our lives. We need to look after ourselves and our relationships. We won’t perform or learn well if sick, depressed or lonely. (See the Project You post for more on this idea.)

When we get stuck, tired or burnt-out on one topic, switch to another after recording what is challenging. Our brains process things in the background. Often the simple act of recording that we are stuck on a topic yields an A-ha breakthrough days later in the shower or out on a walk. 

In addition to a stuck list, recognize all the things already studied. The following Kanban board has columns for To Learn, Studying Now, Stuck On, and Studied Already.

Learning Board

Personally, I try to limit my studying to one topic per Talent Triangle segment at a time. That’s my mental capacity, but I might mix in some short articles alongside a book on a similar topic.

Line Chefs not Eggheads

Knowledge is only useful if we can apply it when necessary. We want people who are humble and smart with a bias for action. When presented with a problem, recalling potential fixes is only half the solution. We then have to select one and try it otherwise we have analysis paralysis. The selection might be done individually or through discussions with the team, but we need to go from many options to a preferred one.

Many people find having too many options with no clear preference overwhelming. Kicking around alternatives is good to select the best solution, but be aware of the anxiety this can cause. So keep it short. Power comes from agreeing and focussing effort on the selected approach. A 40 watt light bulb is barely enough to light a room. Yet a 40-watt laser beam will cut through cardboard and aluminum. It’s the same amount of light energy, just focussed in one direction.

For me, there is an analogy or parallel between learning multiple skills and navigating. Once we know our way around we can create new pathways and connections. I live near the Canmore Nordic Centre. It has> 100km of cross-country ski trails tightly winding through a heavily treed, mountainous park. It also has > 100 km of summer mountain biking trails in the same space.

People describe the trail network and map as confusing as a plate of spaghetti (summer trails) dumped on top of another plate of spaghetti (winter trails). It took me a couple of years of frequently getting lost to become comfortable navigating there. Now knowing both sets of trails allows me to create new loops by tagging trail segments together. It also allows me to get from point A to point B quickly or get back to the Day Lodge swiftly if needed. In short, learning where all the connections are allows us to link elements together for better flow and shortcuts.

Learning as much as we can about project management, emotional intelligence and leadership builds similar skills. It allows us to see connections between ideas, link concepts together like creating a common vision for a project through storytelling.  Or, resolve conflict with empathy and appreciative inquiry.

If we can layer these skills with learning more about our industry, then in the eyes of our sponsors, we go from effective employees to trusted advisors.

When We Get it Wrong

This is all great in theory, but we will inevitably screw-up sometimes. We will assess the options and gallantly blaze our way forward into bigger problems and unintended consequences. This is when being humble and flexible pay dividends.

Just as a lack of direction in the face of uncertainty looks like fear or paralysis, then dogged adherence to a doomed plan looks like blind stupidity. By carefully framing decisions with qualifiers such as “Right now, our best course of action looks like X” or “We have decided to try Y for an iteration and evaluate the results” this way we reserve the right to be smarter tomorrow than we were yesterday.

People are more likely to forgive a mistake and try another approach when it was originally positioned as today’s favoured strategy rather than our only hope. This is not to say we should get into the habit of failing and flip-flopping, just be smart enough not to get preachy about decisions in case the occasional one turns out to be a dud.

So, strive for clarity with options to change direction if needed. We can explain: Here is what we are going to do... but, if along the way we learn of a better approach we reserve the right to revaluate and change direction. In fact, we have a duty to our sponsors to change direction if there ever looks like a better option.

Summary

If we cast the net wide and learn all that we can about project management, leadership and our industries we will never be bored or lacking topics to explore. The beauty comes when topics connect and we make links between subjects. Like always wondering where that unfamiliar road goes only to emerge from it one day and suddenly realize where you are and make the new mental connection.

As we grow in our careers we see how management is really about leadership and leadership really starts with ourselves. Then a simple shift over here makes things go better over there. Project success is a hybrid of technical, leadership and strategic domains. As we grow we see more connections and then achieve more through doing less. It is great when it works but still uncomfortable when it fails so, follow the advice of Patrick Lencioni, and stay humble, hungry and smart.

 

[Note: I wrote this article for ProjectManagament.com first and it can be found here - membership required ]

 


Agile Animations

Animation Film
Following my Agile 2018 conference workshop, I had a couple of people ask how I created the smooth PowerPoint animations. I have always liked using animations to explain ideas since they help me understand processes.

My logic has been, if they help me understand it, then they should help others understand it too. Visual learning, and especially animations, are valuable on knowledge work projects.

Animations help us overcome the three challenges of knowledge work:

  1. Invisible – designs and ideas are often abstract and hard to visualize.
  2. Intangible – bits not atoms. Since we cannot see or feel ideas there is a real danger other people might interpret them differently, leading to difficulties with collaboration and problem-solving.
  3. Transient – Our work is often novel and unique, the challenges teams face are often unique too. The solution to our last problem is unlikely to help us today.

Tom Wujec, the author of The Future of Making, has an interesting short Ted talk on how animation helps create meaning. He explains seeing an image triggers 30 portions of the brain to start working together to process information, solve problems and make decisions.

Visualizations address the knowledge worker challenges:

  1. Clarity through visualization – engage all those brain circuits, helping us comprehend faster and clarify ideas.
  2. Making concepts interactive – when we all see the same interaction of components, we build a common understanding as a group.
  3. Make permanent – Animations can be stored, shared, and replayed - capturing mental models of A-ha moments.

So, if a picture is worth a thousand words, is an animation worth a thousand pictures (a million words)? – No, but it is hard to beat visual storytelling.

Continue reading "Agile Animations" »


Creed Over Greed: Motivation and Purpose

SunriseThere have been a couple of stories in the news recently that reveal some important facts about motivation and purpose.

  • Ex-Tesla Workers Are Still Believers

Some people’s reactions over being fired from Tesla surprised many analysts. Rather than the normal angry barbs (and I am sure there were plenty of those) what made the news were the messages of thanks from, now ex-employees, explaining how they enjoyed their time there and were glad to be a part of it. Some of the Tweets included:

  • “Thanks for the opportunity, Elon! Eye on the mission. Will always be proud to say I worked for Tesla”
  • “I just wanted to let you know that I really enjoyed working for Tesla”
  • “I was laid off from Tesla yesterday and although it hurts (a lot!), it is the right thing for the company. I don’t regret giving all I had and in a way bidding adieu is my last contribution. I’ll be cheering Tesla on knowing I did my part. Thanks for the years of memories!”

A Bloomberg article Fired Tesla Workers Still Love Elon Musk recaps some of the comments.

  • Enlightened Pessimism

From a reverse perspective, a recent Science Direct article found that Employees who practice mindfulness meditation are less motivated, having realized the futility of their jobs. It seems that when people learn how to detach from sources of stress they are less likely to want to work towards goals they are not aligned with.

So, beware those corporate mindfulness workshops unless your organization has a compelling purpose!

The Importance of a Compelling Purpose

First, people want jobs that satisfy their physical and safety needs of having enough money to provide the necessary food and shelter. These are levels one and two in Maslow’s hierarchy of needs. None of the later stages of motivation ever come into play until these most critical needs are met. However, once they are met, people want to work towards something worthwhile and motivating.

Tesla has never been about making fancy electric cars, that’s just a side effect of their real purpose. The Tesla vision and mission statement used to be: “To accelerate the world's transition to sustainable transport.” However, in mid-2016, the company changed it to “To accelerate the world's transition to sustainable energy.” So, they are not building cars, they are helping save the planet for us and future generations.

That is a worthy goal. It is a purpose people can get behind, and a reason people were glad to work at Tesla, even if their role has now ended. They were never just car makers, they were game changers and that’s what people are grateful for.

Contrast it to the mission of BMW: “Strategy Number ONE aligns the BMW Group with two targets: to be profitable and to enhance long-term value – from a technological, structural and cultural perspective. The mission statement up to the year 2020 is to become the world's leading provider of premium products and premium services for individual mobility.”

While it mentions culture, there is a focus on profit, value and being the world’s leading… In other words, it is based on money and dominance, rather than a compelling purpose.

Creed Over Greed

Most organizations share mission and vision statements like BMW’s. They talk about generating shareholder value and becoming the biggest this or the leading that. This is understandable in a purely economic model, but as we saw earlier, once people have enough money they want something more - something compelling, something worthwhile.

When we can appeal to people’s desire for meaning, and when we can support them to make valuable contributions to a worthwhile purpose, they will experience motivation beyond the economics that dwindles over time. “Creed” means a belief system, it is more powerful than greed. Growing larger for the sake of profit and market share is unfulfilling, like a cancerous growth.

Having a worthwhile purpose people can unite behind is tremendously powerful. Organizations like TOMS Shoes and Warby Parker attract top talent not only because they are rewarding places to work, but also because they share a larger goal of helping others less fortunate. Studies show that contributing to good causes makes us happy so it should be no surprise that working for an organization that helps others should be the most rewarding and motivating.

Talent is More Mobile Than Ever

The internet has lowered the cost of communication. It is easier than ever to advertise jobs and share the corporate purpose. People tend to switch jobs more frequently now and the same tools that make advertising jobs easier, also make relocation easier. Smart, talented people are more mobile than ever. They want to apply their skills in worthwhile, interesting settings.

Given the choice of making more money for executives and shareholders or saving the planet, most people (thankfully) would choose to try and help save the planet. When Tesla was hiring last year, they received nearly 500,000 applicants for about 2,500 job openings. So, people only had about a 1 in 200 chance of being accepted – a  testimony to how much people want to work there.

With these odds only the very best people get accepted. This has a two-fold effect, 1) the top talent moves to the better companies, 2) lacklustre organizations get a higher concentration of sub-par people as the best move on.

Find the Purpose/Make a Purpose

If you are a CEO, aligning your organization with a higher propose will help attract top talent. If you are a leader in a traditional organization, then creating opportunities for employees to contribute to society is a powerful motivator.

We cannot all work for Tesla or Patagonia, but we can try to inject some worthwhile components into people’s work lives.  Hackathons for a good cause, Habitat for Humanity volunteering, they all help create more satisfied and motivated team members.

At various stages of people’s careers, they care about different things. Many people starting out just want the highest paying job they can obtain to get established in their adult lives. This is understandable and natural. Then, later they want to be part of something bigger, something more useful. Understanding and recognizing this desire allows organizations offering a motivating purpose the capability to appeal to the top tier talent.

 

[Note: I wrote this article for ProjectManagement.com first and it was published here]


Webinar – Solving Wicked Problems: What is Old is New Again

Problems
My PMXPO webinar has now been watched by > 11,000 people and received lots of positive feedback. It is hosted at ProjectManagement.com here.

(For people collecting Professional Development Units (PDUs), it also auto-records 1.25 credits for you.)

The webinar reviews problem-solving through the ages and shows how agile is the rediscovery of many old approaches. Wicked problems are those that cannot be solved with traditional methods or ways of thinking. They are the unique challenges never seen before in your organization, region or industry.

As companies race to innovate and compete in a global market, we are seeing wicked problems more and more often. While the solution may be new, some common steps repeat in the stories of novel problem-solving successes through history. This presentation combines a fast-paced view of wicked problems and solutions through history—with a slower reveal of the common steps for solving challenging projects.

It is ideal for anyone faced with managing projects with lots of uncertainty—or people looking to understand the links between lean, leadership, building collaborative teams and problem-solving.

Watch Now.


Agile 2018 Conference – Unraveling Team Dependencies

Agile_SD2018_600x100_Speaking_FM
I am excited to be presenting on the Enterprise Agile track at the Agile 2018 conference in San Diego, August 7. I have worked with several organizations this year that had issues with work dependencies between teams. My session called “Two-Pizza Team Heartburn Relief: Solutions to Team Dependencies” highlights the shift to global rather than local optimization.

We will investigate dependency problems through animations and simulations and then explore some candidate solutions. Each brings their own issues – if these problems were solvable they would have been already, but the suggestions do help considerably. Here is the description from the conference program:

Small teams are great - until they cause bigger problems than they solve. Small teams can communicate more effectively than large teams. They can leverage face-to-face communications more readily and share tacit knowledge without the need for so much written communication. However, for large endeavours, using many small teams present their own problems. Work dependencies between teams can cause major delays through costly hand-offs, mismatched priorities, and blocked tasks.

This workshop introduces strategies for structuring teams to reduce hand-offs and dependencies that create blocked work and delays. By investigating the (lack of) flow through multiple teams we can diagnose the cost of hand-offs and culprits of delays. We examine tools for making hand-offs and dependencies visible to highlight and bring collective attention to the problems. We then explore resolution patterns and work structures that maximize small team communications but limit negative aspects of managing multiple, inter-dependent project teams.

Learning Objectives

  • Understand the time and cost penalties of team dependencies and hand-offs
  • Gain tools for making dependencies, queues, and blocked work visible
  • Learn how and when to balance small team benefits with more dependency issues
  • Share implementation patterns and strategies to maximize team throughput
  • Examine the pros and cons of larger teams, feature teams, and product vs. project development.

That probably sounds more technical than it really is. It is a workshop to show people how teams often get stuck with work items when they rely on work from other groups. It combines anecdotes and experiences from 20+ years of agile consulting along with some insights from Troy Magennis on dependency delays, and Dominica DeGrandis, author of Making Work Visible.

Through case studies and exercises, we explore the hidden impacts of well-intentioned small teams. First, we’ll explore the “mostly harmless” two and three team dependencies, and then see the impacts when five or six dependant teams try to get work done. Please come along if you are attending the conference and have issues with dependencies between teams.


Post-Industrial Project Management

Old TractorIntroduction

We know old concepts that govern agriculture do not apply to industry. Engineers do not consult the weather or growing seasons before designing machinery. Yet many project managers who work in the knowledge worker domain still apply project management approaches developed for the industrial era. This mismatch of approaches wastes effort and misses important new risks.

This article identifies the mismatch of applying industrial project management in today’s post-industrial marketplace. We first examine how to determine if your projects are: industrial, knowledge work, or hybrid. Then classify project management tools and techniques. Fortunately, for every industrial focused approach, there are modern knowledge worker equivalents. Using this information, we can apply the right tools for the job or at least identify the risks of mismatched projects and techniques.

 

How We Got Here

Work, like people, has evolved. Humans started out as nomadic hunter-gathers following the seasons and game. Then, when they discovered farming, they settled and built permanent home sites. This change was christened the Agricultural Revolution and heralded a huge shift in how people lived and worked.

Next came the Industrial Revolution. Farmers and craftsmen (craftspeople really) moved from distributed communities to live in expanding cities where the industrial mills and factories were booming. Again, this was a massive change for humanity. Schools focused on timekeeping, rigour, and repetition to prepare children to work in factories. Conformance to schedules and plans made the scaling of a workforce possible.

Concepts like Taylor’s Scientific Management provided tools for tackling big engineering endeavours and applying specialized labour. Progressive decomposition of work and detailed scheduling of tasks allowed complex projects to be planned and managed. Techniques like work breakdown structures, network diagrams, and Gantt charts were taught to project managers to tame and track engineering work.

These techniques work well for tangible, stable and mostly predictable projects. As long as an organization has a history of building a similar product, then the gap to a new design or bigger scale can be reasonably estimated and planned for. Difficulties arise when we try to use these approaches on intangible, unfamiliar, and new environments. Differences in understanding frequently occur when we lack physical reference points such as “I want a wooden door like this one, but a foot taller”. These differences result in more change requests, more reported defects, more uncertainties and risks.

In novel, intangible environments like software development or filmmaking things rarely progress predictably enough to follow the “Plan the work, work the plan” mantra of industrial projects. New technology evolution accelerates the rates of change. Demands to deliver faster worsen the situation. Many of today’s projects fit this new breed of project that were christened "Knowledge Work" projects by Peter Drucker.

Also, many traditional industrial projects have been automated or offshored to cheaper labour markets. This leaves a higher proportion of new projects developing largely invisible, intangible, difficult to reference, products and services – knowledge work.

I am not suggesting all project work has changed. Just as we still have farmers - and hopefully always will, we still have traditional industry and industrial projects. So, while not all work has changed, the fastest growing segment has. The increasing role of software in business also means a larger proportion of projects have at least some knowledge work component. 

To help diagnose your project types, answer the following questions about the nature of projects you execute.

Table 1

If you scored more on the left-hand side of the table, you are engaged in mainly industrial type projects. This is good news for reliable execution, traditional project management tools and techniques should serve you well. If you scored more on the right-hand side, you are firmly in the knowledge worker domain. You should move from industrial project management approaches and adopt knowledge worker ones. If you scored equally from each column, you are in a hybrid environment. Here you likely need to draw on a combination of approaches to be successful.

 

New Territory, New Tools

The tools and approaches of the knowledge worker revolution address the complexity and ambiguity that accompany these projects. Let’s dig deeper to understand the characteristics and appreciate post-industrial project management techniques.

Knowledge work projects bring subject matter experts together to collaborate on new and unique products and services. This might involve scientists, teachers, doctors, lawyers, software developers, or web designers working with the business to build something new. Each of these groups has specialized knowledge, typically no single person knows everything needed to complete the project. What is being created is new or sufficiently different to the sponsoring organization that previous project’s plans and estimates are not particularly useful to predict progress.

Compared to traditional, predictable industrial engineering, complexity, uncertainty, risk and change rates seem very high. Without tangible reference work, it is necessary to use an iterative-and-incremental approach to determine fitness-for-business-purpose. Teams could attempt to analyze and predict all features and functions, but often initial use uncovers additional opportunities and requirements.

Trying to explain the nuances of iTunes or Netflix to someone who has never seen anything like it before is difficult. Incremental trial proves faster and more useful than speculative big-design-upfront that cannot anticipate every interaction with user behaviour or linked systems.

Tools rooted in big-design-upfront, predictable decomposition of tasks, linear progression of work, etc do not work well in these environments. These include detailed requirements documents, work breakdown structures, network diagrams, Gantt Charts and earned value management. That’s not to say you cannot use these approaches, just there are alternatives that better handle the high rates of change and uncertainty.

We still need to record requirements and the use of product backlogs containing user stories makes it easier to reprioritize when changes occur. We still need to break down work and help the business decide how to best divide a big project. Instead of looking at complex architectural component diagrams, the business can make better delivery decisions by using release roadmaps, and features lists.

In the face of high rates of change, averaging delivery rates to-date can give more reliable projections than estimating the durations for planned activities. Likewise, when work is creative or R&D type in nature, we often get nonlinear progression – in other words, some things go faster than anticipated while other items take longer. Approaches like earned value management that extrapolate performance to-date to predict likely completion schedules and costs assume a linear progression of work. Instead, tracking progress based on tested, accepted features only is a more reliable predictor of true progress.

Table 2 shows knowledge-work alternatives to industrial work project approaches

Table 2

Traditional project management approaches are built on the realities of predictable, industrial work. Knowledge work projects defy these traditional laws of physics since they operate outside the physical domain. Instead, they deal with ideas, people and collaboration, which is intangible. Traditional resource management suggests if we are digging a ditch with 10 people, then adding 10 more people would complete the task in half the time. Fred Brooks’ law of software development tells us that adding more people to a project that is already late will increase its duration.

Traditional project management approaches are not flawed or broken. They work great for the industrial world. In these environments, the best way to run a project is with detailed upfront planning, clearly articulated tasks and schedules, and careful granular tracking. However, if your results from assessing Table 1 indicate a hybrid or knowledge work environment then use the appropriate tools.

Trying to use the recommendations from a previous work era is akin to waiting for a full moon before starting your kitchen reno. At best you are adding wasted activities and at worst you are ignoring the realities of your environment that carry the risk of overruns and failure. 

 


The Truth About Transformations

TransformationTransformations are flavor of the month. It is no longer enough to launch “initiatives,” “programs” or “projects” to undertake work. Instead, we launch agile transformations, digital transformations and productization transformations. They sound more revolutionary, more dramatic and further reaching. Our organizations will emerge reborn, uniquely positioned to compete in a new world of opportunities and growth. Like a larva transforming into a butterfly, we can now fly!

Well, that’s the idea and the promise of the consulting companies that sell transformation services. However, what really happens? Can the average organization actually become a disruptive leader just by adopting the structures, tools and processes from the real disruptive leaders? Or, is it like buying the same shoes as our basketball heroes wear hoping they will transform us into slam-dunking superstars? The reality is somewhere between these extremes. Any company can improve, but we should not expect to become something we are not.

Let’s look at some of the popular transformation services on sale and examine the promise and truths they hold.

 

Agile Transformations Dandelion

The goal: Agile transformations move organizations from working with traditional project management approaches to using agile approaches. They also seek to change the way organizations are structured and run from a top-down, command-and-control model to a more business- and customer-led, value-driven approach.

They aim to instil lean concepts of respect for people, minimization of waste, and value delivery. They employ a more trusting Theory Y view of workers as willing contributors rather than the traditional Theory X view that workers need close supervision to work hard. They encourage workers through intrinsic motivators such as empowerment, autonomy of work, and belief in a worthy purpose rather than carrot-and-stick approaches.

The claimed benefits: Agility allows organizations to respond to change more quickly since plans and work are done in smaller batches with frequent checkpoints. This allows changes in direction to be made when feedback indicates it would be desirable. The evaluate-as-you-go and learn-as-you-go aspects of iterative and incremental development help organizations manage complexity and uncertainty.

Agile approaches allow for the delivery of value sooner since work is prioritized via business value. The empowerment and intrinsic rewards offered result in happier, more engaged employees. Allowing workers to design their own workplace and work practices results in a more loyal and productive workforce. A mantra of one agile approach is to “Change the world of work.”

The reality: Agile is much easier to implement at a team and project level than it is at an organizational level. Teams quickly see the benefits of frequent collaboration and business engagement. Tools like product backlogs, kanban boards and release roadmaps bring much-needed visibility to design work and problem solving that often manipulates invisible data and ideas. Iterative development of small batches of work, with frequent reviews, provides better insights into progress and issues than sequential, large-batch development. While some people find the “let’s try something” approach counter-intuitive to rigorous upfront planning and design, most understand the risk reduction and true requirements validation benefits.

At the organization level, it’s a tougher sell. The initial confusion and apparent chaos that comes with establishing empowered, self-organizing, self-managing teams can seem like the inmates are running the asylum. What happens to supervisors and managers? In some organizations, departments are built around functional silos. If I was head of the quality assurance group and now all my people report into individual teams, what’s left for me to do? How do I justify my yearly budget (and position) with my headcount down to zero?

Organizational structures often reflect their culture and decision-making style. This may be hierarchical, flat or distributed. Truly transforming the organization to be agile requires a change of structure, which means changing the culture. Not an easy task, and not something to be undertaken lightly. It requires sufficient buy-in from the very top through every layer to the bottom.

Agile transformations often stall at the organizational level. Instead, we see pockets of conversion and pockets of resistance. It often takes changes in roles for the transformation to occur. However, just changing the way teams operate brings many benefits. While not really an agile transformation, a “switch” to agile project operation within a traditional organization can still be very beneficial.

So, while true agile transformations are rare, agile implementations are common and still worthwhile. The organization may never grow wings and fly as promised by consultants—but if it learns to wiggle more efficiently, avoid danger, and eat faster, that might be all it needs.

 

Digital Transformations  Digital

The goal: Digital transformations aim to convert and grow business in the self-serve digital domain. They do not have to involve websites, but many do. Rather than visiting offices or calling in for service, customers self-manage through apps and websites that greatly reduce labor costs and offer almost unlimited scaling opportunities.

The claimed benefits: Cost reduction and closer engagement are the main claimed benefits. They use websites and AI-powered chatbots to handle the majority of customer questions and interactions. This reduces the need to have as many people employed at physical locations and answering phone calls. Banks and insurance companies are undertaking digital transformations to offer services in convenient formats for customers (mobile phones) as well as reduce overheads.

Encouraging customers to manage their services via mobile apps also opens up options to ping, notify and promote upsell opportunities. It is cheaper and easier to push promotions and “exclusive member benefit offers” to people who install apps than compete for attention in traditional advertising channels. Apps also let companies gather additional marketing intelligence like location, contacts, spending habits, etc.—all additional fuel for promotions and potential sales.

The reality: Building compelling websites, apps and AI services is no small undertaking. Many organizations go through the significant expenditure to discover that only a portion of their customer base embraces the new options. Organizations then try carrot-and-stick paperless discounts or paper-based account fees to incentivize the desired behavior.

These new websites and app projects will never be finished or done. Since they now represent the organization's face and communications vehicle, expect ongoing investment in their upkeep and technology refresh cycles. When looking at the potential savings, do not underestimate the likelihood of initial build costs to spiral—and integration into existing back-end systems to be orders-of-magnitude more costly and time-consuming than anticipated.

However, it seems an inevitable trend. Using established content management systems and app frameworks can help rein in costs. Being at the forefront of technological capability is only paramount if your core business is selling technology services (Amazon, Apple, Google, Microsoft). For everyone else, fast-follower (or even majority-adopter) is probably fine. Digital transformations are real, already here and unlikely to be fading anytime soon.

 

Productization Transformations Product

The goal: This is the transition from using projects to build software systems to building and viewing software as long-term products. As organizations realize software represents a market differentiator, they recognize their systems will never be “done.” If they were to finish, it means they are no longer innovating, improving or competing.

So, they move from the start-stop world of software development through projects and instead adopt continuous development and drip-feed funding models. Historically, organizations staffed and funded projects through vendors and contractors using capital expenditure models. The switch to software as a long-lived product or service changes both staffing and budgeting. The increase in cloud-based hosting also raises the question of opex (operating expenditure) versus capex (capital expenditure) funding.

Organizations often reach out for help making these changes to development, staffing and funding models. This is the new and emerging world of productization or “continuous digital delivery.” It involves restructuring and forming long-lived product teams with everyone present to develop and maintain the software products over its entire lifespan.

The claimed benefits: By eliminating the handoffs between development teams and sustainment teams, more knowledge about the system, and how to extend it, is retained. Fewer handoffs in general is one of the biggest benefits of switching to products instead of projects. Handoffs are very wasteful—they contribute to the eight lean DOWNTIME wastes…

Defects
Overproduction
Waiting
Non-utilized talent
Transportation
Inventory excess
Motion waste
Extra processing

…all of which can occur when one group hands off work to another group.

By creating stable teams that are aligned with developing and sustaining long-term products, organizations can wean themselves off unpredictable vendor models. From a budgeting perspective, estimating the burn rates and capabilities of stable teams is much more reliable than estimating how long a new vendor-based team will take to complete some work.

Stability, continuous development and better knowledge retention are all compelling reasons to trade projects for products. The difficulties come in the transition and available support.

The reality: Switching from running traditional stop-and-start software projects to continuous product development is still a new idea. Usually, organizations have a suite of currently executing projects that still need to be delivered on schedule. Existing vendor contracts may make it difficult to switch to the onsite execution approach favored by continuous digital delivery.

Finance departments are typically set up to evaluate and approve requests for expenditures based on one- or multi-year ROI projections. In the continuous development world of productization, the spending never stops.

Instead of project-based funding, small teams create minimal viable products for evaluation. If they show promise, they get additional funding in more of a venture capital-style model. New metrics like customer market share and profit-to-funding ratios are used.

The benefits are real and don’t require a major upheaval to organizational culture or structures. However, experience is thin on the ground along with books and training courses. It’s like using what we today call agile approaches in the 1990s. There are early adopters, conference sessions and blog posts, but far to go before the idea even approaches the chasm (let alone crosses it).

 

Summary

“Transformation” is probably too grand a word for the degree of change most organizations achieve. However, as so many ideas compete for our limited attention spans, it would seem crazy to merely name a change initiative a “rollout” or “improvement” these days. People have become desensitised to reasonable names and seek revolution and excitement to generate the interest they need to participate.

We should not expect traditional organizations to truly match digital-first companies like Spotify. They were founded to disrupt existing businesses and came without the baggage of a traditional client base to support. (Also, they are led and staffed by people that share different values than most North American institutions.)

Their ideas may be great for other organizations to experiment with and adopt what works, but what makes them truly powerful is that the ideas were created internally and vetted through experiments. Copy the concept (internally generate new processes to solve local problems), but not Spotify’s actual procedures.

There is nothing wrong with buying the same kind of shoes as Michael Jordan wore (heck, if the placebo effect gets you exercising more, they were likely a good purchase). However, don’t leave your day job to sign up with a basketball team until you’re sure you are world class. Today’s transformations bring many benefits—as long as you take the “transformation” claim with a grain of salt.

 

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


Mining Bitcoins with Your InstantPot: Has Agile Popularity Gone Too Far?

InstantPot_Bitcoin_MachineI am excited to be presenting at next week’s PMI-SAC Professional Development Conference on May 2 in Calgary. I am looking forward to seeing old friends and meeting new people at this new format conference.

My session “Mining Bitcoins with Your InstantPot: Has Agile Popularity Gone Too Far?” examines the hype, realities and use of agile approaches.  Here is the presentation summary from the conference site:

“The project world seems to have gone agile mad. The PMI has stuffed agile into everything in an attempt to stay current, but is it right or even helpful? Fear of missing out has vendors claiming to be agile and executives asking managers to be more agile. However, like InstantPots and cryptocurrencies, does the reality live up to the hype?  This session investigates the agile trend and looks at a new breed of agile suitability filters that help organizations apply agile approaches only when and where they make sense.

The presentation profiles organizations that effectively use agile approaches and how to build PMOs that support agile, hybrid, and traditional project teams. We look at the limitations and applicability concerns of using agile approaches. It would be naïve and arrogant to believe that agile (or any other approach) is universally the best way to execute projects. So, what types of projects do suit the approach (spoiler alert: novel, knowledge-worker projects) and what types of projects should best avoid it?

We will explore hybrid approaches where certain portions or periods of the project can exploit agile approaches. In these hybrid scenarios, we examine how to coordinate and integrate the agile work with the more traditional, plan-driven work. Also, we will examine the cultural fit of agile approaches and investigate how corporate mindsets and values effect structures and decision making. Trying to force fit a new mindset that is at odds with the corporate culture will inevitably be met with resistance. So, we need to be smart about what we try to introduce and how we plan to do it.

Our end goal should be successful projects and happy stakeholders. The approach we take should be appropriate for the tasks at hand, there are no points for style or conformance, since every project is different. So, learn how to analyze the project variables that include organizational, standards, technical and team components then act intelligently within that framework also guided by the inputs of the contributors.”

That description was for a 2-hour slot proposal and I was assigned a 1-hour slot so I will have to cut some material, but I will cover the highlights. The presentation title and outline are deliberately a little controversial to hopefully spur some reaction and interest in the session.

Having been involved in the development of the recent PMI standards, I personally do not believe “PMI has stuffed agile into everything in an attempt to stay current”, however, I can see how this may appear so to external parties.

As agile rides the hype cycle it is important to retain a grasp on where it can add value and where it’s use should be limited. This session aims to strip away some of the hyperbole and ground people with some practical application tools. Please come say hello if you see me at the conference!

PMI-SAC PDC Banner


Where Did All the Project Managers Go?

PuzzleSoftware is eating the world” claimed venture capitalist, Marc Andreessen in his 2011, New York Times article. Seven years on, the trend continues, and project managers are also on the menu. The next generation of project managers face new challenges but also new opportunities as organizations undergo a major transformation.

Software is becoming omnipresent, it is embedded and integral to all industries. Not just technology companies (like Google, Apple) but every sector is being disrupted by software including retail (Amazon), banking (PayPal, cryptocurrencies), transportation (Tesla, Uber), and travel (Airbnb).

As a project manager you may say “Great, just think of all those IT projects that will need project managers!” Well, that’s where things get interesting. First, today’s software teams don’t respond well to being “managed”, that’s old-school command-and-control thinking along with Gantt charts and calling people “resources”. Instead, they are led, empowered and supported by servant leaders. Next, the idea of a “project” with a defined endpoint is dissolving too.

As organizations realize their software systems provide the competitive advantage then stopping development equates to an end to innovation or competing. When organizations become more software-driven their systems are never “done”. As a result, organizations are switching from projects (that have a fixed end) to products - that continue to evolve. This movement popularized by the #NoProjects and Continuous Digital titles is growing exponentially.

 

 The Project Manager in a No Projects, No Managers Future

This double whammy of no more projects and no more managers likely creates heartburn for people with the job title “Project Manager”.  While this trend is clearly the future of work I believe there will always be a role for smart, cooperative people that can help with collaboration and development. 

 A quote that comes to mind is “The more things change, the more they stay the same.” by Jean-Baptiste Alphonse Karr. The next generation of project managers will have new titles like “Product Leads”, “Development Team Coordinators” and “Digital Transformation Leaders”. They will help organizations build development capabilities around long-term products.

 This new generation will still communicate with stakeholders about status and risks. They will still facilitate consensus gathering amongst experts. They will still try to diffuse conflict and find common ground during arguments. The goals (satisfied stakeholders and value delivery) will remain the same but the tools, titles and processes employed will be vastly different.

 

New Tools and Approaches

Heavy upfront planning efforts and the use of tools like critical path network diagrams and PERT charts are not so useful when the input data is very uncertain. Tools like work breakdown structures offer great insights into sub-system assemblies but they are slower and more difficult to reprioritize than modern backlogs and release roadmaps.

As rates of change increase so too does early lifecycle uncertainty and the competitive need to start work quickly. The days of carefully analyzing work products upfront are dwindling. Instead, organizations build prototypes based on what they know right now and then iterate towards the final product. In the intangible world of software, the cost of experimentation is less than that of detailed analysis.

Also, using a software product provides better feedback on its suitability and possible expansion than reviewing a document or diagram about it. IWKIWISI (I Will Know It When I See It) becomes the new mantra, replacing the “Plan the work, and work the plan” ideas of old.

As organizations adopt a continuous delivery model that is focussed on products not projects then funding models change also. Instead of yearly budget cycles to fund entire projects, smaller tranches of funds are released to create a Minimum Viable Product (MVP). Then, providing the product continues to return value, more funding is made available. A venture capital funding model lets product leaders focus on delivering a stream of high-value features that support continued investment.

Projects classically track metrics like on time/budget and Return On Investment (ROI). Products track customer satisfaction, market share, profit to funding ratios. They are similar concepts but a new vocabulary to learn.

 

Role Changes

Agile software development teams organize their own work, solve most of their own problems, and are empowered to experiment with new work strategies and approaches. They do not need (or want) to have work assigned to them, nor asked to report status. Instead, they make their work visible via kanban boards and new features.

They do however need people to remove impediments and chase up external dependencies. They also need investment in training, shielding from interruptions, plus regular encouragement and words of thanks to stay motivated. In short, all the servant leadership practices that good project managers did anyway still apply.

Project managers cannot be the center of work planning or task distribution. There is too much complexity to be anything but a bottleneck. Instead, we must trust development team members and product owners from the business as subject matter experts in their own domains.

Where these teams often need help is keeping the larger perspective on where it is we are trying to get to. When you are heads-down on solving a technical issue, it is easy to lose sight of the end goal. Having someone communicate the product vision reveals a beckoning summit towards which others can chart their own course.

In this way servant leadership and visionary leadership that predate modern project management are still valuable and needed. Yet the scientific project management that grew out of the industrialization of process is largely left behind.

 

The Future

In many industries, the classic role of projects and project managers will continue. I don’t see construction moving away from big upfront design and the reliance on project managers any time. In the software world though I think we are heading for substantial changes. Sure, some companies will continue as they always have with software project and project managers. However, most organizations will transition to long-term products with leaders and coordinators.

It is an exciting time for life-long learners willing to acquire new tools and approaches. There is no shortage of work for people who can collaborate with others and solve problems. The critical role of software will increase as organizations undertake digital transformation and adopt continuous digital strategies based on products vs projects. So, while the role “project manager” might be heading into the same category as “switchboard operators”, “human alarm clocks”, and “bowling alley pinsetters” the work and opportunities in this exciting field continue to grow.

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


PMI-ACP Exam Prep Course with Mike Griffiths, Calgary, Alberta

Pmi-acp_exam_prep_cover_2nd_ed_updatedI 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 9th 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.


Talent Management of The Future

Talent Management 2.JPGWe have shifted to Knowledge Work, but how do we find, develop and retain knowledgeable workers? This post examines Talent Management from two perspectives. First, what works well for agile teams. Second, how does the function change as organizations evolve, showing us how talent management may be done in future.

Let’s start by understanding what talent management covers. Talent Management is the strategy, planning and execution of everything needed to hire, develop, reward performance, and retain people. So, all the traditional Human Resources (HR) work, that we don’t call “HR” anymore because people are not resources.

The term talent management comes from research done by McKinsey in the late 1990’s and popularized in the book “The War for Talent” in 2001. At the time the authors were talking mainly about recruiting for leadership roles and the importance of finding people who possess: "a sharp strategic mind, leadership ability, communications skills, the ability to attract and inspire people, entrepreneurial instincts, functional skills, and the ability to deliver results." However, the term became so popular it is now used for the hiring and development at all levels, not just senior roles.

Why it became a big deal and the model organizations aspire to follow is because the McKinsey research found a definitive connection between top performers and superior corporate achievement. Not surprisingly, when you have the best people, you get industry-leading results. Not only that, but based on studying 13,000 executives in 27 companies, they identified how to do it and defined the following steps:

  1. Embrace a Talent Mindset
  2. Craft a Winning Employee Value Proposition
  3. Rebuild Your Recruiting Strategy
  4. Weave Development into Your Organization
  5. Differentiate and Affirm Your People
  6. Construct a practical framework for making this happen in your organization

When we read through this list anyone familiar with the agile mindset will likely see connections to agile and lean values. The recognition that people bring value and the need to respect, attract and engage people is central to the process. However, like agile adoption, just because organizations have known what they should be doing since the early 2000’s it does not mean they always behave that way.

Just as the agile mindset is sometimes paid lip service and poorly implemented, many organizations say they have policies for talent management but implement them poorly also. So, after recognizing why the process is a good one, even though it is often implemented less well (much like agile) let’s see how talent management operates for agile teams.

Agile Teams

Agile approaches recognize it is people who add value. They favor a Theory Y (people want to contribute and learn) approach to leadership over Theory X (people are lazy and need close supervision). Agile teams are built around intrinsic motivators such as autonomy of work, mastery of skills, and alignment with a vision and purpose.

Agile approaches encourage engaging the team in the recruiting process. So, while a hiring manager may pre-screen candidates for basic skills or security clearances, the actual evaluation of candidates and selection of the successful person is performed by members of the team itself. While this may sound inefficient, diverting attention from project goals, the negative impact of a poorly matched new hire is much greater.

When external people hire new team members without significant team consultation problems often ensue. This is then made worse because there is usually a delay in resolving the issue. People understandably want to give new hires “time to find their feet” and the “benefit of the doubt” before removing them from a team which aggravates the issue.

By contrast, when the team selects new members themselves they have already mentally prepared themselves for them joining. By asking candidates to perform tasks like coding exercises or a design-review, they test skills, get a feel of how candidates think, and how interactions may be.  There are fewer mismatches of talent or temperament and high performing teams are more likely to stay in the Tuckman Performing stage rather than churning back through the Storming and Norming stages again.

Getting the teams involved in hiring is part of the talent management process Step 6 “Construct a practical framework for making this happen in your organization”.  Agile approaches adopt many of the other steps also, they support Step 4 “Weave Development into Your Organization” and Step 5 “Differentiate and Affirm Your People” through empowered teams and adaptation.

Agile teams are empowered to make local decisions and encouraged to self-organize about accomplishing work. Shifting ownership and decision making down to the doers of work is more respectful of their talents and a more rewarding way for people to work.

Encouraging inspection and adaptation through product demonstrations, retrospectives, and experiments develop employees. It demonstrates trust in their opinions and allows them to better advance in their careers through experimenting with new roles.

Finally, the emerging practice of keeping high-performing agile teams together and bringing new work to established teams, values employee contributions. Rather than disbanding high-performing teams when the project completes, keeping that integrated unit together and giving them a new challenge to work on.

Organizational Evolution

Some progressive organizations have dropped hierarchical, command-and-control structures in favor of flatter, empowered teams. Coming from a background of agile development it is natural to think this is the broadening of agile thinking into the larger organizational landscape and the growth of truly agile organizations. However, while this observation matches our worldview, it is a flawed perspective of a bigger picture.

When we start examining organizational evolution from primitive gangs to the most sophisticated egalitarian organizations we discover that the agile mindset and principles are stepping stones on a journey that goes further. Agile approaches, that started out in organizing knowledge-work teams, are not the best tools for examining organizational structures and strategy.

Social researcher Frederic Laloux, a former associate partner with McKinsey, literally wrote the book on organizational evolution entitled “Reinventing Organizations” in 2014. In it he charts the development of organizational types in a progression from the most basic to the most advanced. Each stage of this progression has an accompanying color associated with it as a shorthand for the more descriptive titles. A summary of these stages with their color names is listed in the table below:

Teal Organizations

Laloux is careful to point out that organizations may straddle categories. Some departments in the same organization may be more mature than others. Also, one level is not necessarily better than another, they are just different and hold different values as their guides.

40 years ago, most companies were Amber with inflexible hierarchies and they struggled to compete with the emerging Orange organizations that valued and rewarded talent more. These days most organizations are Orange and are struggling to respond to the challenges of competing with the growing number of Green values-oriented organizations.

What is surprising to some agile enthusiasts is that agile is not the latest stage of development. Agile values and principles align most closely with Green organizations that emphasise empowerment and a value-driven culture – like maximizing for business value.  However, there is a stage beyond Green called Teal. It breaks apart the family mentality that uses centralized operational functions and empowered teams and instead encourages small communities of practice in more of an organism/ community-based model.

Laloux’s Red to Teal model is very useful for agile teams. The characteristics of Amber and Orange organizations nicely summarize most corporate companies today. The challenges of implementing agile approaches successfully involve the struggles of moving a traditional Amber or Orange organization to Green. Not an easy task.

However, Teal organizations are more advanced than agile Green and their approaches to talent management may reveal the future of recruiting and retention. In Teal organizations small, self-managing groups are given autonomy to do what is necessary to be successful. Each group contains all the decision-making power it typically needs, supported by a very light-weight group that provides templates and services. People are encouraged to find where they can add value and roles change frequently.

Attributes of Teal Organizations

An example of a Teal organization is Buurtzorg, a Dutch nursing organization whose name means “neighborhood care” in Dutch. Grown from the idea of its founder and nurse, Jos de Blok in 2007, who had become frustrated at the bureaucracy and “machinification” of nursing care. Buurtzorg is now the largest nursing organization in Holland. It has over 10,000 nurses and assistants working in 850 self-managed teams of 10-12 people and routinely wins awards for Best Employer of the Year.

Buurtzorg has organized around autonomy, not hierarchy. Teams make nearly all their own decisions and are supported by a bare-bones staff of 45 in the back office and 16 coaches. While they conduct over 280 Million Euros of business each year, they have only 6 people working in finance and no CFO. Without this hierarchy, their overhead costs are 8% compared to industry average of 25% which provides more funds for care and innovation. People enjoy working there too. Their staff sickness rate is 4% compared to industry averages of 7% and staff retention is the highest in the industry.

Talent Management in Teal Organizations

For a start, they don’t call it “Talent Management”. Just as “HR” is a throwback to Amber thinking of organizations as machines and people as interchangeable parts in that machine, “Talent” is also a throwback to similar thinking about skill trumping values and integrity. An unlucky/insightful choice of companies to profile in the book “The War for Talent” that give rise to the term “Talent Management” focussed on how Enron selected people based heavily on their intelligence.

Subsequently, the book and movie “The Smartest Guys in the Room” recounts how prioritizing intelligence over integrity can lead to poor choices, scandals and downfalls. Instead, Teal organizations just call the hiring and care of its staff process “growth and looking after its members”. They do not have a centralized HR department; each local group practice self-organizes and recruits as the business expands.

Work structures change quickly in Teal organizations. People may see an opportunity for improvement and partner with other team-mates to tackle it. Roles and functions come and go frequently. People are not bound by job titles and may be working on many different initiatives. In such a dynamic environment, it makes little sense recruiting for a single role, since that role may not exist for long. Instead, people are recruited for fit by their peers. Their skills are still checked, but it is much more important that the values of the new hires align with the organizational values.

After hiring the onboarding process in Teal organizations differs from Traditional/Orange and Agile/Green organizations. Since values and working co-operatively are so integral to Teal organizations, significant training in relationship skills are common after joining. It is normal for Buurtzorg staff to undertake extensive training on how decisions are made, how to resolve conflict, and how to collaborate effectively.

Training and performance reviews happen differently as well. People in Teal organizations have personal freedom and responsibility for their training. Employee’s at FAVI, a metal manufacturer in France also using Teal approaches, decide what products and techniques would best benefit their group to learn. Once mastered these skills are then used to enhance services or open new product offerings.

Instead of traditional performance reviews that try to take an objective view of past performance, more holistic reviews of one’s learning journey and calling are undertaken. They focus on wellbeing in addition to skills acquisition and growth. This may sound “Foo-Fooey” to employees in traditional organizations used to leaving their emotions at home. However, the mid-life crisis is the classic result of a life in traditional organizations without emotion.

All too often in traditional organizations people play the game of success and run the rat race. After 20 years when they realize they will not make it to the top, or the top is just as bad, but now with fewer friends, they question Why? After chasing targets and numbers, surviving yet another change program for so long people cannot help but wonder about the meaning of it all and yearn for something more.

So, What Does This All Mean?

Organizations are evolving. HR practices became Talent Management and will likely evolve into something else. We currently exist in a landscape where most organizations are run as machines prioritized for growth. However, we are seeing changes in more employee engagement and autonomy. As these changes continue work should become more meaningful, personal and rewarding. We need to embrace these changes, after all, "When you're finished changing, you're finished." -Ben Franklin

 

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


Project “You” and Project “Two“


We work hard in our organizations on projects to build new products and services, or affect some kind of change. We are also constantly on the lookout for ways to make the work go faster, by removing impediments and improving efficiencies. Techniques like Value Stream Mapping analyze the value-adding activities and the non-value adding activities to identify queues and waste in our processes that can then be eliminated. Looking at our contributions and opportunities for efficiencies is like considering our work as a machine and trying to lubricate it so it will go faster and run more smoothly.

Cog 1

However, this view misses who is driving your work - you. In effect we watch the work, but not the worker. It is you that drives the contributions you make on the project.

Cog 2

Attempts to improve and optimize the project may not be as productive as improving our own performance. So, instead of oiling the process, increasing our capability is a great way to improve output.

Cog 3

Now with a bigger and better you, your project performance will improve.

“Project You”

This is “Project You”, the improvement and investment in yourself. “Project You” should come first, but often it is relegated to second or third choice, or forgotten completely, as work and home pressures take over. However, I invite you to consider “Project You” as your first priority and your regular project work as “Project Two”.

This may seem selfish, but it is not when you consider what is powering your project contributions – your capabilities. Investing in yourself will help your employer and project, it will increase your competencies and capacity to do more work.

More than Just Skills

Skills are just one aspect of you. Your Health, Happiness, and Relationships with others are also critical parts of your makeup that will hurt performance if they are not attended to and in good condition.

Cog 4


All too often people focus on work performance or skills to the detriment of another aspect such as health or supportive relationships. When this occurs your work and project performance will eventually suffer also.

 

Cog 5

Like having a faulty or unevenly developed cog wheel, mismatches in these quadrants will in due course limit your effectiveness at work. People cannot go on if they are unhappy, unsupported, or sick. Just like learning new skills, we need to invest in our well being and the well being of those close to us to remain productive.

A New Year, a Better You

As we start the New Year, now is a great time to assess our overall work engine. To perform a review of “Project You”, recognize and celebrate what we have working in our favour and make a commitment to improve the elements that are our weakest.

Focussing on “Project You” now will bring dividends to your “Project Two” and “Project Three” in 2018. Look beyond the usual sphere of just work and ask: “Am I happy?”, “Am I healthy”, ”Am I in and creating strong relationships?” Then, just as we would for planning the acquisition of new skills or certifications, create a plan of action for addressing the areas that need the most work.

It Nests Infinitely

Of course, the idea of “Project You” applies to all the team members on our project also. It is common to view teams as the interaction and sum contributions of the team member efforts. Then, as good servant leaders we attempt to remove roadblocks and communicate a clear vision of where we are trying to get to.

Cog 6

However, a better view of projects is to see the people components driving these contributions. When we consider our team members as more than just their skills and effort, but also take an interest in their health, happiness and relationships we discover more places we can help.

Cog 7

I remember working on a software project where a developer came up to me and explained he had just received a call from his wife who was sick, and he wanted to go home to see her. I could have just said: “Sure, no problem, go home and see her”. However, because I knew he walked to his nearest train station and took the light rail network to get into the office, I asked if I could drive him home, since I drove to the office and had my car there. He was very appreciative, he saved 30 minutes on his journey home and I was back in the office in under an hour.

It was no big deal to me; my team was very self-sufficient and diligent, and I was glad to help. However, that simple gesture to help with his relationship and the health and happiness of his wife was not forgotten, it helped strengthen our work relationship and was repaid many times over.

Put on Your Own Oxygen Mask Before Helping Others

It would be hypocritical of us to try and assist with the health, happiness or relationship success of our colleagues if our own lives were steaming piles of self-loathing and depravity. We don’t need to be saints, but we should try to get our own lives in order before helping others.

We will also be viewed as a more credible source of council if we have a healthy, balanced home and work life. So, start where you have the most influence, in your own life. See how we can address any imbalances and then look more holistically at your team members. Maybe share the “Project You” and “Project Two” concept with them and see if there is any way you can support them as they grow also.

Summary

Projects, by definition, are temporary endeavors, people, however, should take a longer-term view of their success. Our achievement on our current project and the projects to come will in large part be driven by our full-spectrum wellbeing.  The same goes for the colleagues we work with. So why not use this year as the opportunity to examine “Project You” and invest in your future?

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


Government Lessons in People Over Process

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


PMI-ACP Training Partner Program

RMC TPP ImageWhen 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.

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

  1. 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 mmccarthy@rmcls.com


Got Your CSM, Now What?

Credential QuestionPerhaps, like 500,000+ other people, you have some form of Certified Scrum Master (CSM) credential and are looking to distinguish yourself and continue your learning journey. Of course, learning is not tied to credentials, many people are anti-certification and that is an understandable choice. I encourage lifelong learning separate from credentials. However, for credential seekers, this article explores some common credential pathways beyond the CSM.

I want to disclose upfront that I have been involved with the development of ICAgile, PMI-ACP, and DSDM Leadership credentials so I likely have some bias and preferences. However, my goal here is not to recommend specific credentials but instead to explain options and environmental factors to consider, helping people make their own choice based on their own situation.

Also, because there are so many credentials available I will undoubtedly miss out many credentials in this discussion, maybe including your favorite or your company’s. This is not meant to be an exhaustive catalogue of agile credentials rather a thinking or discussion tool for getting the research process started. 

How Did You Get Here?

When people ask me what credentials to get next, I ask how they got where they are now. Did they move from software development into a Scrum Master role? Were they previously a PMP certified project manager who took a CSM class to learn a little about Scrum? The answers to questions like these and the next one: “Where Do You Want to Go?” help ground and orient the decision-making process. If we don’t know where we are to begin with, then a map is unlikely to be helpful.

Where Do You Want to Go?

Credentials may be obtained to help secure a new job or promotion. People also seek them to demonstrate understanding of certain topics, and just for personal achievement. All of these motives are valid and help drive the choice of where to go next. If you are pursuing job opportunities then you should research what hiring managers are looking for. Are they asking for PMP, CSP or PMI-ACP credentials? If so then we are narrowing our choices down.

Alternatively, if you are pursuing a credential more for personal learning, then the curriculum is likely more important than recognition by hiring managers. Maybe there is an online program that very few people have ever heard of but it’s a great fit for your learning objectives. If so, be more influenced by content and quality rather than recognition and opportunity.

This sounds basic, but I’m surprised by how many people pursue credentials just because their colleagues did and they don’t want to be left behind, or it was the next course suggested in their company’s training roadmap. Credentials should be for you. Asking questions like: Do you want to strengthen your current role? Do you want to change roles? Do you want to stay at your current organization? All these issues factor into the next steps to take.

Directions from Here

There are a few obvious directions from CSM that include Down Deeper, Upwards and Outwards. By Down Deeper I mean going deeper into Scrum with an Advanced Certified Scrum Master (A-CSM), Certified Scrum Practitioner (CSP), or Professional Scrum Master (PSM) credential. These are good options if you want to demonstrate a further commitment and understanding focussed just on Scrum.

Upwards refers to scaling Scrum for large projects, programs, and enterprise transformations. There are several popular Scaling frameworks available including SAFe, Nexus and LeSS. All offer training paths and credentials if that is the direction you want to pursue.

The Outwards direction means broader than just Scrum. Due to the popularity of Scrum people sometimes forget there is a rich wealth of complementary approaches outside of it. Lean, Kanban, Leadership, and Emotional Intelligence are all topics that agile teams can benefit from. Certifications like the PMI-ACP and the ICAgile suite of credentials provide coverage and demonstrate knowledge of these topics. Also, I class Disciplined Agile Delivery (DAD) here rather than a scaling framework since it is more pragmatic and deals with more than just agile and scaling.

How to Decide: Personal and Environmental Factors?

So, knowing how we got here and a little more about where to go next and why, we can start to create some pathways.  Shown below is a sample flowchart for someone interested in pursuing agile approaches further and wondering what to consider next.

Flow Chart

However, maybe you are not interested in agile and want to pursue risk management further. That is fine, use these personal and environmental factors to create your own framework. Maybe a PMI-RMP (Risk Management Professional) credential fits the bill? My point is that with a wide variety of experiences, goals, motivations and credentials to choose from there will be a huge array of possible decision trees like this.

The purpose of this article is not to recommend a single path for the half a million CSM’s in the workforce, rather explain a framework for evaluating your options. Don’t be pressured by peers or corporate training roadmaps, instead honestly evaluate why you may want to obtain a new credential and then which would best fit your development goals.

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


DIPMF Review

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

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

DIPMF and APG

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

Burj Khalifa

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

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

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

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

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


Conference Updates

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

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


PMBOK Guide 6th Edition and Agile Practice Guide - Impacts on Credentials

PMBOK and APGOn September 6, 2017, the PMI published the new PMBOK® Guide 6th 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

PMI Exam Question 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 6th 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.

PMBOK Guide Scope

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 6th 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 6th Edition.

Summary

If you are studying for a PMP or PMI-ACP credential, the recent publication of the PMBOK® Guide 6th 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 6th 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]

 


The Importance of Focus

Edison BulbI 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)


PMI Global Conference Chicago

PMI-Global-Conferenc-2017-Circle-Join-Me-OctI 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.


We Should All Be Learners

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

Satir

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]


PMBOK Guide – 6th Edition gets an Agile Appendix + All new Agile Practice Guide

PMBOK v6 CoverNext week the PMI launches the 6th 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 – 6th 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.

APG Cover

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


Agile 2017

17-2480-Agile_Orlando2017_Speaking_300x250_FM (1)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 6th. 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.

Agile Practice Guide Inputs

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:

Agile Conference Slides

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.


Agile Consulting

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

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

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

What you dont know gets bigger

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


They are “Lessons to be Learned”, not “Lessons Learned”

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

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

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

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

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

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


New PMI-ACP Workbook

PMI-ACP WorkbookI 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:

PMI-ACP Workbook 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:

PMI-ACP Book Contents

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.

 

 


PMI EMEA – Rome – PMI’s Agile Future

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

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

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

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

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

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

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

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


Boosting PMO's with Lean Thinking

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

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

It’s about people first.

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

  • Involve everyone – Always make sure everyone involved, impacted and perceived to be impacted is consulted and engaged in the process. This does not mean every font change of a Project Charter template needs CFO approval, but it does mean that all plans, initiatives and work are open and available for contribution or comment to anyone who is interested. Basically, be open and transparent, you never know who might have a great insight or spot a flaw before it impacts performance.
  • The Customer Defines Value – Rather than automatically acting to minimize costs or reduce time to market, lean specifically adds the step of asking the customer to define what value means to them. Some groups may focus more on quality at the expense of time or costs, others may value time-to-market and happily sacrifice some scope or cost over runs to get there. It sounds like common-sense, but all too often people get disappointed with a group because of mismatched values. Adding the “customer defines value” step helps avoid those mismatches before the can occur. 

Lean Thinking Principles and the PMO

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

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

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

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

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

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

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

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

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

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

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

 

Eliminating DOWNTIME - The Common Forms of Waste

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

  

Take Aways

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

 


Agile DNA Webinar

Agile DNA 2This 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.

Agile DNA 1

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.

Continue reading "Agile DNA Webinar" »


“When Will This Software Project Ever Be Done?”

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

 

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

The “When will you be done?” issue

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

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

This is not a problem, this is the future

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

Continue reading "“When Will This Software Project Ever Be Done?” " »


The Business Analyst and the Product Owner


BA and PO rolesIn my last article we talked about the role of the BA on agile projects, reviewing what stays the same and what changes from traditional approaches. In this article, we will review the contentious topic of how the role of the BA varies and overlaps with the Product Owner (PO). We cover the similarities and differences including danger signs such as “BA as PO Go-Between” and positive patterns such as “BA as PO Supporter”.

 

The Product Owner (PO)

First, let’s make sure we understand the role of the Product Owner (PO). It originated in Scrum but is often also used beyond Scrum in other agile approaches and hybrid approaches. The Scrum definition of the role is the person responsible for maximizing the value of the product and the work of the development team. This includes being responsible for managing the Product Backlog. Extreme Programming (XP) has a similar “Customer” role, DSDM has one or more “Business Ambassadors” depending on the scale of the project. They all play a similar role in stewardship of the backlog, including:

 

  • Ensuring that the product backlog is visible, transparent, and clear to all, showing what the team will work on next
  • Ensuring the team understands items in the product backlog to the level needed
  • Clearly expressing the product backlog items
  • Ordering the items in the product backlog to best achieve goals and outcomes
  • Optimizing the value of the work the team performs

 

Benefits Beyond Backlog Management

In addition to this backlog focused work, the Product Owner is often the primary interface to other business stakeholders. They help teams gain access to business subject matter experts for insights on topics where the Product Owner may not have all the answers. They also often act as a gateway to funding, making the business case for additional funding requests, or as a powerful ally when asking for roadblocks to be removed. Playing the “Business is asking for X” card is typically stronger than the “Team is asking for X” card when asking for an exemption from process, or to expedite an issue.

 

Continue reading "The Business Analyst and the Product Owner" »


BA's on Agile Projects?

Team EffectivenessThe role of the business Analyst (BA) on agile projects in some ways parallels the role of the project manager (PM). In that, some people believe these roles are not needed at all! The Scrum Guide, for instance, that outlines the Scrum approach describes only three roles: Scrum Master, Product Owner, and Development Team. Even when you look deeper into the Scrum Guide’s description for The Development Team role, it does not mention analysts or analysis work. However, most organizations agree, good BAs are great assets for any team, be it plan-driven, agile or hybrid.

This article examines what BAs really do, looking at what stays the same on an agile project and what changes. The quick version is that the What and the Why fundamentals stay the same, but all the How, When, Where and With Whom details change dramatically.

Let’s start with What business analysts are supposed to do. (I say supposed to do rather than actually do because yours might watch cat videos most of their time and that is not what they are supposed to do!) Anyway, Business Analysts elicit, analyze, communicate, manage and validate requirements. They also help understand the business and make sure the solutions fit the business. In addition, they help translate technical issues to the business and facilitate stakeholder communications.

Why they do these things should be fairly obvious. To help ensure the project builds the right product, and requirements are not missed or misunderstood. They are also valuable to help facilitate and bridge communications between client, customer and technical groups.

The good news is that all these functions, roles, needs or whatever you want to call them still exist on agile projects. Also, to some extent, because agile timelines are often compressed, these functions become more critical for teams to remain productive and so good BAs are extra valuable.

Now for what changes; let’s start with the How? Agile teams typically do not create large, detailed requirements documents that get reviewed and signed-off before development begins in earnest. Instead, requirements may be captured as user-stories, or on index cards that act as reminders to go and have a conversation with the relevant subject matter expert prior to development. They are typically smaller in terms of how much scope they cover and depth of description. More like micro-requirements for attention deficit readers who only want small, bite-sized components.

 

Continue reading "BA's on Agile Projects?" »


New Role with RMC Learning Solutions

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