Can We Still be Agile?

Can we still be agileHow does work from home impact our use of agile approaches? If co-location is no longer possible, can we still be agile?

Yes, of course we can, and in many ways, now we need to be more agile than ever as we try new approaches, learn and adapt how we work. However, let's address the co-location question and look at agile practices in remote work situations.

The Agile Manifesto and Agile Principles do not mention co-location. They do not say teams have to work together to be agile or effective. Instead, they say, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" and "Business people and developers must work together daily throughout the project."

Face-to-face (F2F) and daily business collaboration are certainly easier to arrange if people are co-located. However, most agile teams already had some remote workers before work-from-home instructions. The Digital.AI (formerly VersionOne) 2020 14th Annual State of Agile Survey reports 81% of respondents use agile approaches with remote team members (typically not the whole team, but a subset is remote).

Why F2F and Remote Alternatives
So, how do we do F2F remotely? The answer is with video. Instead of debating if video is F2F, let's look at where the F2F agile recommendation came from in the first place. Alistair Cockburn, an Agile Manifesto signatory, developed a popular graph to show various forms and levels of communication effectiveness. Later, Scott Ambler expanded the graph to show types of modeling and added video conversations.

The goal of the chart was to show how interactive, F2F discussions are more efficient in terms of data transfer per minute than traditional paper documentation and allow for questions and answers to clarify understanding. They also convey emotion through tone of voice and body language, so are richer forms of communication.  Here are the two graphs merged with F2F and video marked as points 1) and 2)…

Agile Communications

We can see both F2F 1) and Video conversation 2) are in the top right quadrant of the graph indicating high effectiveness and high richness (emotional temperature). Video is slightly lower on the curve than F2F conversation, but still significantly higher than working via email or documents. The highest form is working together at a whiteboard, where we also bring the benefits of visual collaboration.

I suspect there was not a lot of data behind the exact positioning of these communication forms. Instead, it is a visual to help discuss a continuum of information transfer formats. One conclusion is that if F2F is not possible, then video conferencing is our next best option, and it still allows us to get a feel for people's temperament and emotion about a topic. 

Other Agile Approaches
Rounding out our review of agile recommendations, the Scrum Guide does not mandate or even recommend co-location. It talks about teams working together to build a product. However, groups can work together on a product remotely. For instance, Jim could build the website while Rosa develops content. They are both working together on the product, just not physically together.

Extreme Programming (XP) includes the practice “Sit together” as one of its primary practices and notes “The more face time you have, the more humane and productive the project.” Remote teams fail to meet this practice recommendation and video face time is not the same as in-person face time. However, XP co-creator Kent Beck explains “sit together” is a goal and is not mandatory.

We should also remember when the agile principles were developed in 2001, video conferencing was not as straightforward or familiar as it is today. It was not until 2003 that Skype and other applications provided widely used and low-cost options for getting some face time.

Team Types
The image below shows different team composition types. First, Type-1 teams are fully collocated. According to agile surveys, these are the minority. The majority of agile teams are Type-2, which have a core of co-located team members, but also some remote team members. Finally, Type-3 teams are all remote, with everyone contributing from their own workplace.

Remote Team Types

During the COVID-19 response, many organizations have gone from Type-1 or Type-2 quickly to Type-3 due to work-from-home mandates. This change has brought about technology and work challenges, but also highlighted opportunities for the future.

A common problem with Type-2 teams is that there can be a division or communications gap between core co-located and remote team members. Some information may, unconsciously, not get shared with remote team members. Going all remote, Type-3, is a great leveler. Now everyone is in the same boat, and the need to communicate broadly is highlighted and universal.

Lessons from Experienced All-Remote Organizations
Many organizations have been successfully using Type-3, all-remote structures, for years. They deliberately chose this format and believe it offers many advantages.

Organizations like Automattic who build products including WordPress and Tumblr, employ over 1,100 people in 75 countries using an all-remote strategy. GitLab, makers of the code repository and development tools, has 1,295 team members spread across 67 countries using their all-remote work practices.

Automattic uses agile approaches to build its products. It created its own distributed team project management product called P2, that it uses to organize, communicate and build community. It also embodies some key aspirational goals in the Automattic Creed. These include:

  • Never stop learning
  • Do not just work on things assigned
  • There is no such thing as the status quo
  • Never pass up an opportunity to help a colleague
  • Communicate as much as possible, because it’s the oxygen of a distributed company

The reference to oxygen in the communication concept is deliberate because too much oxygen can be fatal as well. As a group scales, it’s important to invest time from an editorial mindset making sure that the right information isn’t just published, but it’s heard and understood by those who need to.

GitLab also builds agile tools and uses agile approaches. It has a vast resource library about working remotely that any organization could learn a great deal from. Similar to the Agile Manifesto, Gitlab has its own published values and manifesto.

GitLab's six values are:

Collaboration
Results
Efficiency
Diversity
Inclusion & Belonging, Iteration
Transparency

…that together spell the “CREDIT” given each other by assuming good intent. Their remote manifesto reads:

  1. Hiring and working from all over the world instead of from a central location
  2. Flexible working hours over set working hours
  3. Writing down and recording knowledge over verbal explanations
  4. Written down processes over on-the-job training
  5. Public sharing of information over need-to-know access
  6. Opening up every document for editing by anyone over top-down control of documents
  7. Asynchronous communication over synchronous communication
  8. The results of work over the hours put in
  9. Formal communication channels over informal communication channels

Items 3, 4 and 9 favor written communications over verbal. In a remote setting, this is preferable so people can consume it wherever and whenever they please. Yet it is at odds with the Agile Manifesto that favors F2F communications with its immediate feedback and richer bandwidth. However, these remote organizations have an ace up the sleeve that likely more than makes up for any communication penalties.

People over Process
Accessing the best talent is the saving grace for remote teams. There have been many studies and speculation about the productivity differences between average and best-in-class workers. Some reports claim 2X, 3X and even 5X differences in software developers, but I suspect the data is shaky at best. Yet some classes of problems can either be solved or not. Working longer for someone unable to solve a problem is not going to help.

The argument for remote agile teams is that the efficiency penalty from sliding down the Communications Effectiveness graph from F2F to videoconference or documentation is more than made up for by having the best possible people. Also, because “work from wherever and whenever you like” offers great flexibility, the best talent is attracted and retained.

Remote Work and Agile Values
There are many parallels between all-remote work structures and agile principles.

  • Autonomy - For remote teams to function best, organizations adopt a results-oriented view of work. They trust their staff to work independently, collaborating and communicating as required to create the outcomes desired. They do not try to micro-manage or schedule tasks. Instead, they allow people to organize their work and operate with autonomy. This mindset closely mirrors “empowered teams” from agile approaches.
  • Transparency – People are encouraged and expected to communicate widely and frequently. Automattic’s “Communicate as much as possible” and GitHub’s “Formal communication channels over informal communication channels” emphasize communication. These ideas map to the agile and Kanban concepts about making work visible and Scrum’s Transparency pillar.
  • Challenge the Status Quo – People are expected to be curious and always looking for new markets and improvements. These concepts align well with the inspect and adapt ideas of retrospectives and continuous improvement in the agile mindset.
  • Iterate – Working iteratively is one of Gitlab’s core values and a central theme of agile approaches.
  • Valuing individuals – Recruiting globally and providing flexible work options, even if that means more written documentation, is an excellent example of living the agile value “Individuals and interactions over processes and tools.”

Summary
Remote teams can be agile. They do experience some disadvantages by not working together. All-remote, Type-3 organizations admit that onboarding can be a challenge, and communications take longer. However, access to the best talent, providing flexibility and autonomy offset these drawbacks.

When people value agile principles, they usually find a way to make it work no matter the circumstances. However, being agile is not the point; building an engaged, energetic workforce who support each other and create worthwhile outcomes is the real goal and measure of success. 

Useful Remote Work Resources

  1. GitLab “GitLab’s Guide to All-Remote”
  2. Automattic “On Working Remotely” 
  3. Stefan Walpers’ “Remote Agile Guide

 

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

 


Returning to the (Electronic) Cottage

Electronic CottageThis is not a post about rich people now able to visit their second homes after the lockdown, instead, a revisit of the concepts of decentralized work being the new way of undertaking projects.

In 1980, Alvin Toffler’s book The Third Wave introduced the idea of “The Electronic Cottage” as the modern workplace where information technology allows more people to work from home or wherever they want. Toffler was a futurist and businessman who did not get the attention he deserved. Even though Accenture identified him as one of the most influential voices in business leaders (along with Bill Gates and Peter Drucker), we do not hear much about him.

When I was at university in the 1980s, we were required to read The Third Wave. At the time, I was more interested in learning about compiler design and database structures, but I read the book and the ideas stuck. Thinking back, The Third Wave, along with Zen and Art of Motorcycle Maintenace, are the only books from my entire degree that I still remember.

The First and Second Waves
The first wave was the agricultural revolution when hunter-gathers started farming and settled in villages.

The second wave was the industrial revolution, when cheap, non-renewable fossil fuel energy was used to leapfrog previous levels of productivity. This industrialization required mobility from the workforce, and people moved from villages into cities to work in mills and factories. This movement resulted in the end of the large multigenerational families rooted to the soil.

The “nuclear family” (of father, mother and a few children, with no burdening relatives) became the standard, socially approved model for industrial societies. Schools started emphasizing punctuality and rule-following to condition children for working in factories.

The Third Wave
The “third wave” is the information revolution. It is what Peter Drucker called the knowledge worker age. What set Toffler apart was his ability to see how the second industrial age must end and why the information age was inevitable in 1980, more than 10 years before the internet was invented (let alone became popular).

Toffler described factors that make the continuation of the second wave impossible, including: “The biosphere will no longer tolerate the industrial assault” and “Non-renewable energy sources are drying up (one of the hidden subsidies of the Second Wave).”

He went on to describe factors that made the third wave possible and inevitable. These included:

  • Cheaper electronics and computers: “If the auto industry had done what the computer industry has done in the last 30 years, a Rolls-Royce would cost $2.50 and get 2,000,000 miles to the gallon.” Computing is cheaper and more powerful than ever.
  • De-massification of the media: As the quantity of information available to people expands, they become less and less able to cope with it all. People fall back to paying attention to only what is important to them. We see a rise in the number of specialty channels appealing to narrow segments of the population.
  • An intelligent environment: Home computers networked together and notifying us of weather alerts, home security alarms, etc. What we now call the connected home and IoT.
  • A new social memory: Originally, human groups stored their shared memories in the minds of individuals (tribal elders, wise men, etc.). The second wave moved beyond memory by spreading mass literacy. Libraries and museums were built. By increasing the store of cumulative knowledge, it accelerated all the processes of innovation and social change. Now information is stored electronically and can be readily searched by all.

The fact these predictions came true show the credibility of Toffler’s forecasts for the electronic cottage. Our recent work-from-home mandate has accelerated the transition to the electronic cottage, and maybe some of Toffler’s other predictions about changes to work and society will come true also?

Here are a few things he said about this shift in working practices. The opening points are ideas from the book; the thoughts that follow are observations from today…

  1. IT makes it possible to work from home.Computers and electronic communications make it possible for many types of work to be done from home.

Observation from today: Recent work-from-home mandates have pushed even laggards of this technology to try it and work through the kinks. While everyone wishes for freedom to return, maybe we can capitalize on the positive aspects of working from home, or from a favorite café, or a pleasant, local co-working space?

  1. Commuting diminishes.Consider the cost incentives to companies. Commuting, which they indirectly subsidize, runs an average of 29 times as much as the installation of telecommunication equipment in a person’s home. Also, considerable savings in real estate costs, capital building investments, and building maintenance can be had. Staying at home will also reduce pollution and the cost of cleaning it up.

Observation from today: Most organizations do not need to pay for any additional equipment since many people have high-speed internet and their own computers. People may currently have less-than-ideal working conditions with children being home from school, but once they return, do you want to go back to commuting with the associated cost and time drains?

  1. Shorter work week:On the home side, as shorter workweeks become common, the higher ratio of commuting time to working time becomes more irrational, frustrating and absurd. Millions of jobs could shift out of the factories and office into which the second wave swept them and right back where they came from originally: the home. If this were to happen, every institution we know—from the family to the school and the corporation—would be transformed.

Observation from today: Our current glimpse of homework and closer family relationships is artificial and lacking many of the benefits of being able to escape to the company of friends when we want to. The FIRE movement (Financial Independence, Retire Early) has already seen people reduce the number of hours they work, consume less and spend less on nonessential items like expensive commuting options. Few people have been talking about impacts on family, but the nuclear family might become a relic of the past.

  1. Customization of products and in-home production:Most highly developed countries will concentrate on the creation of one-off and short-run manufactured goods depending on highly skilled labor and automated production systems. Customization will lead to the manufacture of one-of-a-kind products with items custom-made for individual users. This home-centered society will bring many changes:
  • Greater community stability due to less forced mobility, less stress on the individual, fewer transient human relationships, and a greater participation in community life.
  • Energy requirements will be reduced due to energy decentralization. Energy demand would be spread out, making it easier to use solar, wind and other alternative energy technologies.
  • The auto industry, oil companies and commercial real estate developers would be hurt.
  • The electronics industry, computer companies and the communications industries would flourish.
  • Increasingly, workers would own the means of production.

Observation from today: We are seeing these shifts already. As I sit typing this from home, a 3D printer next to me is producing something (incredibly slowly) that my wife designed. Increasingly, we can create and customize products from home or locally within the community.

  1. Radically changed corporations:The big corporation was the characteristic business organization of the industrial era. Just like families, the mass media and schools, corporations are facing drastic changes:
  • An accelerated economy: There is a drastic speed-up in the pace of business. An accelerating wave of change, pushed by the coming third wave, is causing disorientation, frustration and increased mistakes on the part of managers.
  • The de-massified society: Today, as the third wave strikes, the corporate manager finds all their old assumptions challenged... the marketplace and the labor market are beginning to break into smaller, more varied pieces. Second wave corporations are uncertain how to cope with this rising tide of diversity among their employees and customers.
  • Public anger at corporations: People are demanding a new definition of what corporations are and what they do. They want to see more responsibility and more accountability—not merely for its economic performance, but for its side effects on everything from air pollution to executive stress. The result will be corporations who attend to multiple bottom lines. Some examples are already happening as organizations are focusing attention on social impacts as well as economic results.

Observation from today: Incredibly, those words were written 40 years ago—they read like a modern description of emerging organizations. Just recently, PMI started talking about the triple bottom line (people, profit, planet). Organizations now revolve around the customer, and customer experience analysis is driving more diversification of products along with accelerating rates of change.

What this Means for Project Managers
The way we engage with teams is likely to be different in the future. For projects in the knowledge worker space (legal, marketing, sales, education, IT, research and development), having whole teams onsite will likely become a rarity. These roles can be done from the electronic cottage, whether that is someone’s home, a café or a community co-working center.

Work times for project work will likely relax, and family activities take a more influential focus. Industrial factories needed everyone in one location—at the same time—to function. Knowledge work does not; as project managers, we need to get used to that and accommodate for it. Maybe we need everyone to be available for core meetings, but outside of that, we let people work when they want to. As long as they meet their commitments, why does it matter when the work gets done?

The Future
Not all of Toffler’s predictions became true. He also suggested we would be growing a significant proportion of our food needs in the oceans. That might be possible, but we have not seen it happening yet.

The second wave of industrialization brought tremendous economic growth and technological development. Yet those brief 300 years were non-sustainable to the planet—and also ripped people from homes and family structures that had existed for 10,000 years previously. Nobody is suggesting we return to being farmers. Instead, do more creative work without the time and space constraints industrialized work demanded.

It seems the world of work is changing to meet Toffler’s predictions. Perhaps the social forecasts about a revival of putting down roots, staying in one place and returning to live with extended families will happen also. Recent events seem to be accelerating these trends, and I am optimistic about our future.

References

  1. The Third Wave Book
  2. The Third Wave Book Summary
  3. Alvin Toffler Wikipedia Bio

 

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

 


Regaining Trust: The Winners and Losers of a More Cautious Tomorrow

Future ProjectsPeople are smart, resourceful and inventive. We are also dumb and irrational. This combination makes forecasting nearly impossible.

People build cities, express themselves through art, and push forward our understanding of the world through science and logic. At the same time, they exhibit cognitive bias and often behave in ways that defy this same science and reasoning.

The simultaneous application of logic and defiance of logic is part of what makes humanity rich and complex. It is also why predicting how the world will change after the COVID-19 pandemic contains much uncertainty. Some effects will be the sensible results of events and reactions. Others will be nonsensical reactions (like hoarding toilet paper) due to cognitive bias. These factors will intermingle and interact with new yet unknown events to create a tomorrow that is impossible to calculate.

So, while nobody knows how our future will be different, we do have some ideas to help make an educated guess.

(Y)Our Thinking is Flawed
Before following the conclusions to their impacts on project management, such as more remote work and an aversion to collocated workplaces, let’s review why this logic will be proved wrong. People do not behave rationally. Instead, we exhibit many illogical behaviors called cognitive biases. There are several informative lists and pretty maps of cognitive biases, but some that apply in predicting life after COVID-19 include:

1. Loss aversion – The feeling that it is better to avoid a loss than acquire an equivalent gain. In experiments that ask people how much they would need to win to risk losing $100 on the flip of a coin, the answer is always over $200, which has financial parity. We genuinely do not like losing things.

Evolution has taught us to be cautious. When prehistoric man hunted for survival, seeing something in the grass that could be a deer or a lion, it was best to consider it a lion and live to hunt another day. The gain (food) is much less than the potential loss (death). All the people with a more optimistic viewpoint were soon eaten and did not get to further contribute toward our evolution.

2. Availability bias – The tendency to overestimate the likelihood of events with greater “availability” in our memory, which is influenced by how recent the memories are or how emotionally charged they may be. People are not going to forget COVID-19 for a long time, and will likely behave disproportionally to the risk of a similar event.

In 2013, my home town of Canmore, Canada experienced a freak weather event when three storm systems became stuck in place for days, creating unprecedented rain and flooding. Scientists estimated that the likelihood of it ever happening again is tiny. However, because it happened once—and it was recent and unpleasant—all kinds of flood mitigation and debris-capture dams were justified and built.

Logical and Flawed Forecasts for Project Managers
The logical and illogical ramifications of the pandemic will change how we work in large and small ways. At a macroeconomic level, the business case for many projects will change. Entire industries will flounder while others flourish. Project managers should expect to see a shift in project types as investments change.

Industry Changes
The cruise ship business may take a generation to recover as the vivid reporting of confinement and concern will be hard to shake off. Air travel industries and support services could be severely reduced for a couple of reasons:

  1. First, more people have now tried remote collaboration and worked through the kinks and learning process. People will question if all meetings in the future have to be face to face. A switch to just, say, alternating remote with F2F would be a 50% reduction.
  2. Second, the pandemic accelerated through air travel and people were stranded in foreign countries away from their family. People will think of travel differently in the future and be more reluctant to go.

On the upside, remote work tools, health care, personal protection equipment and a host of other industries will see increased investment and growth. Online products and services and business-to-consumer retail sales will likely stay in high demand as people get used to cutting out the middle man and saving money. Project managers would be well served to learn about cloud-based platforms and remote collaboration tools as their adoption has been rapidly accelerated.

Project and Personal Changes
At the project level, what might change? We often want what we cannot have; as people are told to work from home and stay indoors, they naturally want to go out. Yet, once the restrictions are lifted, I think more people will want to work from home when they realize the savings in commuting costs and time.

Do we really have to drive for 45 minutes to sit at a desk and do knowledge work we could do from home? Yes, F2F meetings are superior for communication, but perhaps just two or three days a week in the office is enough, the rest from home. Many organizations had work-from-home and entire remote work structures before the pandemic. What may change is the broader adoption of these ideas. Hot desking can save organizations billions of dollars in office space reductions alone.

What about open-plan offices, high-fives and shaking hands? Open-plan offices favored by agile teams were criticized as “germ factories” long before COVID-19. We often see people wearing headphones to counteract noise pollution (and undermine some of the reasons for having an open space)…might we see face masks, too? When people start pushing back with legitimate health and safety concerns, HR departments might be nervous to support project manager requests for team colocation.

Will people still want to attend project management conferences and in-person training courses packed into hotel ballrooms with communal buffets? Or will lower-cost and more time-efficient virtual conferences become the norm?

Project Managers Have an Advantage
Projects are all about change. We are always building some new product or service, or enhancing something and then working with people to facilitate its introduction. As such, project managers instigate and deal with change in our everyday lives. We have access to organizational change models that explain when people resist change and when we welcome change. We know about stages of loss, building support for change, and confidence assessment models.

This knowledge makes us uniquely equipped to deal with a new tomorrow. Once we realize it will be a weird combination of logical and irrational behavior, we can use our skills to embrace it and move with the changes. It’s the slower-moving industries I feel sorry for, like auditors, tax accountants and lawyers…they may all be in for a wake-up!

 

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


Playing in the Gray of Hybrid

Playing in the Gray of HybridGray areas occupy the transition from one world to the next. Neither black nor white, predictive nor agile, project managers are increasingly finding themselves in the gray area of hybrid project management. This can make us feel uncomfortable since we are neither faithfully following either approach—instead living a compromise between seemingly different value systems.

We could get uncomfortable, guarded and hesitant to embrace the reality we face. Or, we could welcome it, use it to our advantage and share the benefits/trade-offs with anyone willing to listen. This second option of embracing, using and sharing is “playing in the gray area,” a term I learned at a recent workshop I was giving. It nicely summarizes the idea of accepting and making the most of our reality rather than uncomfortably accommodating it and mainly keeping it to ourselves.

Hybrid Environments
Let’s talk about what hybrid environments are and why we might find ourselves operating in one. A hybrid is a combination of two (or more) different systems. Hybrid cars can use internal combustion engines (ICE) and electric batteries, or ICE and hydrogen fuel cells. Both combinations are considered hybrids.

In project environments, the use of both predictive approaches and agile approaches results in a hybrid approach. There are several reasons why both approaches might be used. Some common causes include:

  1. Agile is not entirely suitable – Agile approaches are applicable for high-change, uncertain, technically risky project work. They offer many great tools for engaging and empowering team members. They allow teams to go fast by streamlining communications and documentation. I am a strong advocate for using them where they work well. At the same time, I am a realist and understand they are not a panacea or silver bullet.

Highly regulated industries require lots of documentation. Well-understood technology can be applied without the need for experiments and proof of concepts. Stable designs can be planned and executed with few change requests. Often, projects combine work that is well suited for predictive approaches and work that can benefit from agile approaches. Here it makes sense to use a hybrid approach overall.

We can execute the predictive work using predictive approaches and the adaptive work using agile approaches. For example, a project I worked on to develop and roll out a custom GPS routing solution for truck drivers used an agile approach for the software development—and a largely predictive approach for scheduling the equipment install in the trucks and training the drivers. We use the appropriate tools for the job at hand; it is neither rocket science or anything to be ashamed of.

  1. Operating in a predictive organization – Some organizations operate with upfront requirements analysis, scope sign-off and funding. We can try to educate stakeholders on why a more adaptive approach toward these operations might be beneficial, but maybe this is beyond our circle of influence—or maybe we inherited a project with a scope and budget already in place.

Either way, sometimes we do not get to do everything by the book and we have to work with what we are given. This is not to say we should give up and not try to make improvements. Instead, accept that not everything will be ideal and that we need to choose our battles wisely. We might be asked/told to be the bridge between agile teams and not-so-agile organizational groups.

  1. Transitioning to agile incrementally – Large organizations rarely transition to agile approaches overnight. Some executives and training companies try a “sheep-dip” approach, immersing everyone in agile training and mandating a whole scale switch. However, these initiatives often fail. How big does the sheep-dip have to be? Does it include finance, HR and sales? How about procurement and suppliers? Usually, there are groups the team or supporting project managers still have to work with that have not transitioned to agile.

Whenever an agile team works with a predictive entity, there is some mapping, interfacing and translating that needs to occur. This work often falls on the team lead or project manager (if one is in place). As depicted in Figure 1, these interfaces could be between our project and other projects (1), between an agile department and other non-agile departments (2) or from our department to the broader organization (3):

Hybrid interfaces and buffering

Figure 1: Interactions that require hybrid interfaces and buffering

These scenarios are of course simplifications. Typically, organizational adoption of any idea, not just agile approaches, is fragmented and not uniform. Team leads and project managers often find themselves translating terminology, progress reports and plans to different stakeholders within the same meeting.

Embrace and Own It
The flipside of uncertainty is being able to explain topics and help people learn. Anyone who can bridge between two worlds, two sets of concepts and two slightly different vocabularies is extremely valuable. Whether as a project manager, BA, product owner or executive, organizations benefit more from people willing and able to talk about the similarities, differences and problem areas than pure converted zealots. These interpreters and linkers can help other people make the transition.

So, if asked “When will your agile project be done?”, rather than giving an eye roll for being asked such an uninformed question for an agile project—or mumbling, hand-waving or resorting to exotic terms about points, velocity and burn charts—instead, own it. This is an opportunity to talk about the gray area of hybrid metrics. So, a better response might be something along the lines of:

“Great question!, I ask this myself daily. Over the last four months, we have developed and gained business acceptance on about half of the features in the backlog (our total list of work), so that suggests we need another four months to finish. We have spent 45% of our budget, so we look on track for a Q4 completion within budget.”

Likewise, actively combine predictive and agile components. Work with your team and product owner on getting your risk register responses correctly prioritized in the backlog. What are the opportunities we should exploit, and which threat avoidance and mitigation actions should we do first? With the shared goal of successful projects and happy stakeholders, there are many synergies to be found.

The term “playing in the gray” has a couple of meanings. The first interpretation of “playing” addresses where we operate, our playing field (which these days is increasingly hybrid). The second meaning of playing is to enjoy things. Anyone bridging two environments has an opportunity to be useful, help people learn and add lots of value. It is a rewarding place to work, so own it and enjoy it.

 

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

Copyright © 2020 Mike Griffiths, Leading Answers Inc.


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.


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]

 


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.

 

 


AI Assistants for Project Managers

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

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

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

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

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

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

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

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

  • Knowledge Based Expert System (KBES) – these work from decision trees of IF - THEN statements to provide expertise. Gmail’s attachment reminder works with similar IF body_text includes “attach” AND Attachment = False THEN issue a warning.
  • Artificial Neural Network (ANN) – these systems model our real brains and consist of networks of weighted connections. They can be programmed to learn, recall, generalize and apply fuzzy logic. So, if we teach it someone 4ft high is Short and someone 6ft high is Tall it can generalize that someone 4ft 6 is “Not very tall”. Being able to make these types of generalizations are important for realistic interactions with people, such as Google Assistant making a hair appointment.
  • Machine Learning – this builds on Knowledge Based Expert Systems and Artificial Neural Networks to create predictive analytics that can provide validation and advice. In the project management space, this is the technology that can help with checking for missed risks, rebaselining plans, recalculating the Cost of Delay for waiting initiatives, etc.
  • Chatbots - AI powered programs designed to simulate a conversation with humans. Chatbots use artificial neural networks and machine learning to combine domain intelligence with natural language processing. This gives the impression of interacting with a (currently somewhat) knowledgeable person.

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

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

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

Over-Reliance?

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

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

Higher Value Work

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

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

This sequence is shown below:

AI Focus

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

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

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

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

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

References:

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

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

 


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.


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