Viewing Posts by Mike Griffiths
Risks are inherent with projects. They are an attribute of doing something new or novel that distinguishes projects from regular operational work. How well we navigate risk often decides the success of not just a project but also an organization.
In a recent blog post, we looked at how Disciplined Agile (DA) teams can effectively navigate risk, both threats and opportunities, at the project level. This post examines DA’s Enterprise view of risks at the program and portfolio level.
Often team members and project managers focussing on the success of their project may not see how their efforts at project optimization can be misaligned at an enterprise level. In Lean terms, this is known as local vs. global optimization.
Program Risks Can Compound
We know that breaking large endeavors into smaller ones helps reduce risk. Reducing complexity, the number of stakeholders involved, and the project’s duration (horizon of risk) all help increase the likelihood of success.
However, risks compound when the overall benefit is contingent on the success of multiple dependant projects. If a business outcome depends upon “Project” A completing, followed by “Project B,” “C,” and “D” each at 75% of success, the overall program only has a .75 X .75 X.75 X.75= 32% chance of a successful outcome. Working on our endeavor, it is sometimes difficult to appreciate the dependency implications of connected chains.
Project teams are often incented to take a limited view of success based on how they are measured. Did we complete it on time? Was all the scope signed off? Did we finish within budget? Again, putting on our Lean hat and taking a global vs. local optimization view, how did we really do?
The DA Governance process blade looks beyond the project for possible downstream risks. Project teams may ignore risks associated with increased operational load or sustainability. Sure, we shipped on time, but if we created increased maintenance costs, the organization might be worse off rather than better off as a result.
Knowledge sharing is critical. Individually, a risk exposure may seem acceptable, but if it is common to 50 inflight projects, the aggregate risk may exceed the organization’s risk appetite. Likewise, if many different risks could be triggered by a single event, then that aggregate risk may not be fully appreciated at a project or product level.
Sharing risk information allows for better steering at an organizational level. However, it takes a culture of support for bad-news communications as well as good-new communications for this to work. Creating psychological safety where leaders demonstrate the desired behavior is a good starting point. Then encourage information sharing throughout the organization and help rather than punish the messenger.
The upside is that opportunities aggregate also. The time or cost savings for buying a tool or improving a process may not make economic sense for a single team, but it may be viable if applied to all teams.
Ongoing Risk Governance
We should make sure teams are actively managing the risks on their projects. Check that the appropriate risk tolerances and response strategies are being applied. For instance, one team lead’s view of an acceptable risk might be very different from another’s.
Check that teams understand and are applying the basics of risk management. Have they established risk thresholds for recording risks and escalating them? Are they identifying and acting on risks and opportunities? Are they engaging the right stakeholders and with review and response actions? In short, are they following the advice captured in the Address Risk process goal?
Reviews can seem like micromanagement and lead to a lack of trust and resentment. To avoid this, explain why risk management is essential and look for evidence of understanding and intent-based actions over compliance to rigid standards unless those standards are required for your industry.
At the enterprise level, check risk tolerances are normalized, and teams are sharing their threats and opportunities across the organization appropriately. When teams are focused on delivering features or meeting a deadline, they may lose sight of risk management work.
Risks as a Positive Sign of Progress and Growth
It is important to recognize risks are a sign of healthy activity. By their very nature, projects are risky because they try new things. They create or change products and services which carry a risk of problems and failure. However, there is an ever-present opposing-risk of enterprise-inertia.
Organizations that do not innovate, improve or even just keep pace with the speed of their industry’s evolution are moving backward compared to their competitors. The risk of reduced competitiveness, loss of market share, or market presence in new communication channels have real consequences. Innovation and evolution through projects counter-act this risk.
“A ship in harbor is safe, but that is not what ships are built for.” This quote parallels the need for projects and some risk-taking. Organizations need project development, product development and other initiatives to stimulate change and to keep moving forward. They carry risk, but so too does standing still. DA provides Lean inspired guidance for applying global as well as local suggestions to help exploit opportunities and avoid or reduce the inevitable threats associated with innovation.
Remote agile teams typically use more video conferencing and extra written communication than collocated teams to stay synchronized. While perhaps not as effective as direct face-to-face communication, these approaches make up some of what is lost from sitting together and provide the advantage of being easily recorded for later access.
This asynchronous access to information is especially valuable for globally remote teams that may not share the same work hours. By accessing content on-demand, people can contribute when works best for them and sync up with the rest of the team at preset events.
Remote Onboarding Challenges
Onboarding new team members can be a challenge for remote teams. Introducing team members, explaining agreed to norms around process and tools are traditionally done in-person. Writing all of this information down along with the justifications and discussions around the decision process is a significant undertaking.
GitLab, one of the most successful all-remote agile development organizations, has onboarding materials that would occupy over 8,000 pages if printed. As organizations transition to more remote-friendly structures, documenting how teams work is becoming more critical.
Disciplined Agile for Onboarding
Fortunately, Disciplined Agile (DA) can help. It contains a vast tool kit of approaches accompanied by industry vetted analysis of when they add value when they do not, along with the pros and cons of implementing them. Teams can use the DA tool kit as the starting point for describing their way of working.
Using the upcoming DA Profiler tool, teams can debate, discuss and decide on their ways of working. The tool captures the goals, decision points and trade-off tables of each selected process or technique. Then, when new team members join, they can be pointed to the saved profile representing the team’s way of working. This saves creating lengthy onboarding materials and descriptions of processes.
Of course, processes should not remain static but instead, continue to evolve as teams and businesses learn and develop. So, at regular intervals, teams are encouraged to review and update their way of working and create a new definition. DA provides a robust strategy to support this and the goal “Evolve Way of Working.”
Keeping it Real
A strength of DA is its realism and pragmatism towards how organizations work. Not all organizations are fully agile yet, nor perhaps want to be. So, if some traditional, serial practices are still in use, that is OK; DA supports it. If Team A uses Scrum with two-week Sprints, Team B uses Kanban with continuous flow, and Team C uses SAFe, that works too.
DA is approach agnostic and capable of supporting a variety of popular techniques along with custom hybrid solutions. It also embraces a set of principles that make building guidance for remote agile teams more successful. These include: “Be pragmatic,” “Context counts,” “Choice is good” and “Enterprise awareness.” These principles provide practical advice teams can apply to define their remote ways of working.
Mind Your Toes
Returning to the GitLab onboarding process, they promote a fun principle called “Short toes,” which comes from when people join the company and frequently say, “I don’t want to step on anyone’s toes.”
At GitLab, they aim to be accepting of people taking the initiative in trying to improve things. They recognize that as organizations grow, their decision-making speed often slows since more people are involved. However, this can be counteracted by having short toes and feeling comfortable letting others contribute to their domain.
Short toes is a great concept that is required if organizations are to scale and evolve successfully. It aligns well with another of DA’s principles, “Be awesome,” which is all about striving to be the best that we can and to always get better.
Adapting to the challenges of more remote team members and new all-remote teams creates the need for better onboarding resources.
DA provides great scaffolding to build onboarding handbooks that document how teams have selected to work without making manuals with thousands of pages. It supports group-based discussion and selection of techniques, ongoing refinement and offline access. Perfect for onboarding today’s increasingly remote workforce.