On Risks and Agile Approaches

November the 9th I had the honor and pleasure to talk at Italian Agile Days in Modena.

Here below the slides of my speech. Enjoy ūüôā

iad19 on risks and agile approaches


About Agile and that intersection between sustainable growth and people engagement

Surfing Agile

After almost twenty years of life of the Agile Manifesto, we can confidently say that such a document marked a radical change in many areas of the world of work. Thanks to its founding values and principles, a cultural re/evolution started and it is now at its highest peaks on the implementation perspective. However, can we say that all the promises of the Agile Manifesto have been achieved?

No alt text provided for this image

We think that the big change Agile introduced, has been possible because the values and principles gathered in that document, vividly describe in their truest essence, the meaning of work for human beings.

That could sound a bit romantic, but actually Agile helps the ones who create a product or service to deliver value by leveraging their own passion and talents; Agile also favors strong connection with their users and customers, aiming to create the most possible satisfying and pleasant experience.

As we know, Agile is first a change of mindset, a change in culture; then, based on that and relying on its practices and methodologies, it allows the organizations, who truly embrace it, to deliver great results.

Of course, it is not surprising that the increasing trends in customers’ satisfaction, value delivery and quality, are the ones the companies are running after, when embarking the agile journey.

The founding fathers of the Agile Manifesto actually provided a specific principle (the first) to create a context able to produce those benefits:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

However, more and more organizations are today increasingly pursuing more employees’ engagement and involvement, as the primary driver to achieve the benefits aforementioned.

In support to this thesis, a 2017 research by the Gallup institute, concerning the state of the workforce in the United States, reports that only 33% of Americans say that they are satisfied at work. According to another survey carried out by YouGov who asked 1,000 respondents between the ages of 17 and 23, it seems that Millennials are looking for better ways to find better work-life balance.

Well, we’re lucky because the¬†13th Annual State of Agile Report, highlighted that ‚ÄúImprove Team Morale‚ÄĚ continues to be among the first¬†top reasons¬†Agile is implemented on the shop floor and the¬†fourth benefit¬†after being adopted. Wow!!

No alt text provided for this image

Additionally, respect to the previous year, that survey shows that both the Team Morale aspects (reason for adopting and benefits achieved) became significantly more relevant for respondents, which can make us say that:

Agile is, for organizations, at a great intersection between continuous business growth and increasing people engagement

So, from one side companies are looking for better results, from the other people necessitate to be more involved in pursuing a (hopefully noble) company purpose, aiming to find more sustainable and healthier jobs. Any organizations, who want to win the battle of talents, need to find ways to retain their best, experienced people and attract new, young ones.

…and Agile seems to be one of these promising ways…

The Agile Challenge

We cannot forget that Agile brings some key challenges when implementing it. Here below a short, not comprehensive list:

  • Close cooperation. It aims to create small teams bringing together diverse, cross-functional people, which need to work¬†collaboratively¬†and¬†communicate constantly. Very often, these people did not even work together before.
  • Accepting failures. Agile was born to find solutions for complex problems. Complexity needs people to get out of their¬†comfort zone¬†to apply ” “try, fail, learn, and repeat” approach, in order to finally being successful
  • Strict cadence. It is strongly rooted on the¬†empirical¬†approach, following sequential, uninterrupted, incremental¬†iterations, through which incessantly distill knowledge to deliver better value over time

Coping with all of this is actually not trivial for the people involved.

It seems that the founding fathers expected this as well and wanted to help. First of all they suggested to create the right environment where people can work and accept those challenges, through the fifth principle:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Then they gave indications on how to deliver value constantly, in a sustainable way. If we have a look at the eight principle of the Manifesto, we discover the following:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

Being able to do what the eight principles states, means that both the 1) way of working and the 2) rhythms the teams will sustain, are such that they could keep going and maintain that pace, indefinitely.

Uhm…not that easy…isn’t it?!

My personal and joking interpretation is that, when the seventeen gurus were writing the Agile Manifesto, unconsciously had some¬†doubts¬†about this topic. Actually, if we read that principle again, very carefully, we note that this is the only principle that presents a verb conjugated to conditional “[..]¬†sponsors, developers, and users¬†should¬†be able to¬†[..]”.

No alt text provided for this image

Jokes apart, the applicability of that principle is actually challenged every day due to the difficulty to navigate the VUCA sea in which each of us is immersed.

It incessantly creates significant changes of context and needs in the market. Effects of this uncertainty is usually reflected as:

  • challenging¬†dates¬†to be hit,
  • product/project¬†scope¬†that can change significantly within days,
  • budgets¬†that are shrunk unexpectedly,
  • increase in¬†costs¬†due to constant rework.

So, how can we deliver results and value on a constant pace, in a world of uncertainties, while making all this sustainable, for the people involved?

Agile and Sustainability

If we read the Scrum guide, we discover many places where, directly or indirectly, it addresses sustainability:

  • Teams are¬†self-organizing¬†in how they choose to accomplish their work: no one is forcing, pushing or directing the way they are doing things
  • The¬†Sprint Goal¬†must be¬†preserved¬†and shielded; no one, development team aside, can modify it putting at risk the whole sprint
  • Only the development team is in charge to eventually¬†review the scope¬†once it become more knowledgeable because of the learning acquired during the execution of the sprint
  • Only the development team is in charge to estimate, and subsequently decide,¬†how much work¬†it is able to finish, by pulling it from the product backlog
  • In case the work necessary is different than what was expected, the development team collaborates with the Product Owner to¬†re-negotiate the scope¬†of the current sprint

According to what cited above, the scope of the current sprint is ‚Äúquite‚ÄĚ frozen. No Product Owners, managers or stakeholders, can actually change it. Only in case of drastic, dramatic market changes, which make current sprint goal useless (actually waste), the Product owner is in charge to¬†terminate¬†it.

If we look at all this with dogmatic lens, it is quite normal for every person or team, to become very rigid, and to fight the Product Owner, holding the Scrum guide as a sword, confronting every new requests or changes he tries to propose to the team. This behavior leads to tensions, disengagement and poor results.

On the other way round, if we decide too much¬†flexible, allowing the Product Owner to add or change the scope of running sprints, we could never being able to accomplish the sprint goal and finish the user stories that have being ‚Äúloaded‚ÄĚ into those iterations.

Well, this situation also leads towards bad places, made of frustration and disengagement.

What should we do?!

Plan Driven vs Value Driven

First of all, we need to train intensively the stakeholders involved, on Agile culture and how it copes with forecasts.

It’s important they do understand that we definitely throw away the Project Management Iron Triangle where everything (cost, time, scope) is fixed, because it always happens that, when we are behind schedule or exceeding costs, we negotiate on (or forget about) quality (which in Agile is a taboo).

Traditional theoretical plan driven approaches based on Gantt charts, Activity Network diagrams and detailed Statement of Work, projected on mid-long term periods, are useless when facing complexity.

Agile fosters, indeed, a value driven approach, where customer and team work together, through the Product owner, constantly prioritizing what is most important, inspecting results every two weeks and gathering feedback from users, for better decision making.

So we pass from this:

No alt text provided for this image

with fixed scope, estimated cost and time (which are 60% of the time wrong) to this one:

No alt text provided for this image

where time and cost are fixed and the scope is continuously reviewed according to its value and the feedback coming from the market.

Never Push too Much on the Accelerator

Of course, that’s not enough. The companies who are on the Agile journey need to know about how forecasts, funding and road-mapping are done in this new context (will write soon about it in a future post).

It happens often, however, that companies do commit to very challenging deadlines, forgetting about the inverted triangle above, and so the teams are somehow obliged to commit to huge amounts of scope in order to try to finish their sprints and hit those dates, by working on nights and week-ends. This is of course is an old, awful practice.

As we know, this leads to many problems that are incredibly worse than re-negotiating the scope or the dates with the customer. Typical problems are:

  1. Technical debt and in defects in general, increase drastically.
  2. Amount of work finished, decreases significantly
  3. Team morale drops down
  4. The team stops to apply best practices (both development and methodological)
  5. Employee churn rate increase which leads to teams instability due to people living the company

A d√©b√Ęcle.

Human beings are not machines.

No alt text provided for this image

Human beings want to be more in control of their lives, are looking for more decision making.

They are finding working places where their mastery is appreciated and autonomy is given them to reach challenging objectives.

Well, the Agile Manifesto paved the way, now is our turn to make it thoroughly happen, finding the right intersection between people engagement and satisfaction versus business growth

Stable, long-lived, Teams: between myths and reality


Competing as a protagonist in the digital, global market, means delivering actual value to customer, always striving to improve speed, quality and adaptation. The performance of the work teams that produce those results, is obviously one of the key factor in achieving these standards. Agile suggests, to reach that objective, to design teams which are self-managing, cross-functional, co-located, and long-lived. In this post we want to reason about stable teams, their advantages and, if any, difficulties or myths.

No alt text provided for this image

We strongly believe that creating stable and long-lasting agile teams, is a key-competitive element for companies, who want to deliver continuous stream of value to their customers.

Stable teams develop, over time, stronger behavioral and working dynamics, higher levels of transparency that favor trust and collaboration among its members; when facing complexity, trust within the team actually drives increased levels of performance, creativity and intrinsic quality of the product the team is dealing with.

To reach this state, a team needs to pass through a series of developing steps. A model that is largely used to describe this evolution, is the Tuckman Stages model.

This post, then, will also go through some weakness areas of that model, and how to assure performance for agile teams in contexts where stability is not assured, by exploring the 60-30-10 heuristic.

Tuckman Stages Model

In 1965, Bruce Tuckman, developed and published a research about the interactions between the people belonging to a group, and its following development as a team; this study eventually led to the creation of a model that took his name.

That model involves the following phases:

No alt text provided for this image
  • Forming: it represents the initial phase where, among the team members, the development of a first sense of belonging takes place; they share common values, align to the corporate mission, live first joint experiences and prepare themselves to trust each other, as the foundation to be successful
  • Storming: phase in which conflicts can occur due to the attempt of individual team members to find their place and “impose” their individuality and leadership
  • Norming: having successfully passed the previous step (which shouldn’t be taken for granted), the team defines proper norms, working methods, and refines roles and responsibilities. The sense of unity initially only perceived, is now established and individuals feel themselves actually part of a whole: the team
  • Performing: finally the team has achieved sufficient stability to deliver continuous business value and achieve results. The team is now able to manage itself in improving its process and working practices

The model presents a logical sequence of phases and clearly shows the impact of each one on productivity.

In practice, though, it has some¬†weakness areas. First of all we could think that the phases are¬†discrete and linear¬†in their development. However, that’s not the reality.

“Scientific community emphasized that this model should be considered more a conceptual declaration”

According to the context, the people involved and the work that must be done, the team can pass from one phase to the other more or less quickly, and have regressions. Performance trends are not always that “smooth” in their descending and ascending, but could have continuous up and down peaks.

It is worth noting that in the following years, the scientific community emphasized that this model should be considered more a “conceptual declaration” than a fact; it was conceptualized and brought to life by the data collected by the author’s studies, which actually¬†lacked, and seems still lacks, an¬†empirical validation¬†on the ground.

Getting rid of Tuckman’s Model

A study conducted by the US Defense Ministry in collaboration with the Defense Acquisition University, shows that in teams formed by a few members, with strong competence and motivation, the phases described by the Tuckman model, actually strongly overlap.

No alt text provided for this image

The¬†Storming¬†stage would be very limited in its wideness but extended in time, so as to be called “Brainstorming“: moments in which the team reflects productively on how to become more effective and evolve its ways of working. Additionally, it seems that the¬†Norming¬†phase continues to happen until the end of the measured endeavor.

Agile Teams: acrobats on uncertainty

Agile teams are¬†small ones¬†(no more than ten), technically and business competent and, by design, they are given the¬†autonomy¬†to decide their ways of working. Furthermore, they are¬†cross-functional, which increases the overall internal competence and, finally, they are physically or “digitally”¬†co-located, which definitely favors communication and adaptation among members.

They systematically hold retrospectives which helps to adapt and adjust their process in order to become more effective over time (see Brainstorming phase observed in the previous example).

Additionally, these teams are open and transparent enough to review and amend their norms and rules, as soon as they are no more effective, actually confirming that the Norming phase lasts until the very end of the project.

It seems, indeed, that Agile teams naturally fit very well in that situation. But, what about stability and not changing their composition?

“Due to the high volatility and fluidity of the markets, team stability is strongly challenged”

We know that adding or moving team members breaks stability and forces the team to review its dynamics and create new ones: this produces inefficiencies, reducing motivation.

We know, however, that due to the high volatility and fluidity of the markets, team stability could be strongly challenged for the following reasons:

  • new¬†skills¬†can be necessary to teams,
  • ans/or necessity to increase¬†capacity¬†of the team,
  • and/or people¬†change job¬†more frequently
  • and/or¬†re-organizations¬†could take place with a smaller cadence than in the past;

to such an extent, Agile teams need to be adaptive and fast also in rearranging themselves.

No alt text provided for this image

Said and acknowledged that, are there any prerequisites to check or good practices to put in place, to help teams remaining effective even when stability is at risk?

Getting off, on the right foot

It seems, actually, that there is another important element which influence the stability of teams: how teams are designed. A bad design could lead to significant problems in efficiency, quality of work and conflicts between members.

Richard Hackman¬†and¬†Ruth Wageman¬†coined a heuristic which helps to think on how to start with the right foot from the very beginning; this is the “60-30-10 Rule for Coaching Teams“.

The heuristic explains the percentages of time/energies that should be dedicated to the following activities:

  • 60%¬†on how a team is¬†designed,
  • 30%¬†on how it is¬†launched,
  • 10%¬†on how the team is¬†coached.

Team Design, Launching and Coaching

When it’s time to design a team, it is necessary to focus on some pre-work.

“Bad performance of a team could lead to eventually re-shuffle it, which brings us to hit the same problem we are trying to solve: instability of teams”

It is firstly necessary to understand if there’s enough of¬†homogeneous work¬†in the portfolio, to create a stable team. The suggestion is to create teams which are dedicated to one or more products that belong to the same¬†stream of value¬†for the selected category of client.

Then, it is necessary to create a first draft mission for that team (which will be reviewed and refined by the actual team when formed), delineate what business objectives it needs to achieve, appoint a Product Owner, understand what skills are necessary and roughly estimate (range) how many of people should be involved.

Usually happens that teams are designed by managers, who move people around according to their actual capacity, competence and also speculating on personal relationship among them. The risk here, is that managers do not actually have all the relevant information to make the right decision and, also, they could have any biases which has the potential to badly influence their conclusions.

We know that bad performance of a team could lead to eventually re-shuffle it, which brings us to hit the same problem we are trying to solve: instability of teams.

One good practice is self-selecting teams. The idea is to let the people select the teams to which they want to belong, through attending to dedicated workshops.

“Even when the team stability is at risk, they self-arrange and look for the best solutions to find another status of balance and remain effective”

During these workshops, flip-charts are hung to the walls containing all the relevant information about the mission/objectives and the constraints (a few) that must be respected for each team (e.g. max number of people, any diversity factors, end-to-end delivery capability, etc.). Product Owners stand beside them, ready to reply to any questions.

People walk around, talk to the Product Owners, discuss to each other in order to look for the best team where, each one, can deliver value and then they stick their image/avatar on the respective team flip-chart. Product Owners and mangers, then, facilitate the discussion in order to arrive to the final refinement and adjustments of teams composition.

This approach considerably increments the accountability, motivation and resilience of the team members. One positive result is that, even when the team stability is at risk, they self-arrange and look for the best solutions to find another status of balance and remain effective.

Once the team is designed, the next stream of energy must be devoted to team launching.

In that moment it is paramount to clarify any doubts the team has according to the mission and vision, with the relevant stakeholders. During these workshops product/project dimensions like scope, technicalities, stakeholders community, estimations, risks, are discussed high level.

This phase is not successful finished, until the team has clearly and transparently defined its working agreements and ways of working and consolidated everything in a charter which is hung in the team room.

When teams are well designed and launched, we finally posed the basis for their stability and long-term value creation.

During the team journey, however, managers shall not forget to stay close to the team, supporting and coaching it to help passing through the process of transforming a group of people in a great team.

Being Agile Disciplined in managing Risks


Every time a new initiative is starting, it’s intrinsically risky. This is even more true when the solution you need to develop, is a big one. An approach that is able, if well executed, to drastically reduce risks from the very beginning is the Agile Inception. Want to know more?!

No alt text provided for this image

Agile manages risk by design. In two of my previous posts, I wrote about how risks are managed, both at team and program levels, in an agile way:

Thanks to iterative and incremental development, rapid feedback cycles and closeness with the customer, Agile lowers risks since from the first iterations. The graph below clearly shows how risks decrease rapidly, compared to what waterfall does instead.

No alt text provided for this image

The primary reason which explains that effect is because the Agile team and the whole stakeholder community involved in that development endeavor, learn faster about the product and the context, testing earlier their assumptions, which in general decreases the overall uncertainty.

No alt text provided for this image

A terrific tool that helps to visualize the uncertainty (thus indirect exposure to risks/opportunities) which characterizes the envisioning and further (waterfall) development of a product or solution, is the cone of uncertainty. That diagram well describes the variation of the degree of uncertainty over time, when developing a new product; this is reflected by the error factor that teams do usually make, when estimating the effort necessary.

No alt text provided for this image

We notice from the picture above that most part of the uncertainty stays with the initial period, when the vision of the product, features necessary and how they could be built, are not that clear. This is even huge and risky, when the solution to develop is a big one, in a big enterprise, which involves several teams.

In such cases a good choice which helps to face that uncertainty, and inherently to lower risks, is represented by the DAD Inception. The main objective of this approach is to spend a few time, in the initial phase, to iteratively explore the main dimensions of the initiative (e.g vision, scope, architecture, quality, team, cost, time), in order to create a common high level picture among all the key stakeholders.

DAD summarizes the goals of this phase as follows: Develop Common Vision, Align with Enterprise Direction, Explore Scope, Identify Architecture Strategy, Form Team, Plan the Release, Develop Test Strategy, Secure Funding.

It is important to clarify that this is not and must not be confused with Big Design Up Front.

Indeed, it is worth noting that, in order to avoid any misunderstandings, the authors stress on purpose, words like “align“, “explore“, “identify” and “strategy” when describing the inception goals, which are intended to be high level activities and outcomes, detailed further on during the development, through the usual Agile iterative approach.¬†In this article, the authors make that point crystal clear.

Additionally if you go through the tools and techniques suggested, they are all about lightweight ones based on collaborative working, sketching, agile modeling, etc.

Usually, those goals are achieved by running a series of workshops. A good practice is to use the first sprint (Sprint 0) to execute them.

An interesting picture (adapted from DAD disciplined agile consortium Рrisk-value lifecycle) that explains the impact of the Inception on risks and business value is the following.

disciplined agile consortium - risk-value lifecycle)

There are some interesting things to notice.

Due to the fact that the inception brings all the relevant stakeholders together, exploring the main product dimensions, misunderstandings or misalignment are managed immediately, allowing risks to decrease as well (P1).

Additionally, as soon as the¬†vision¬†is consolidated among the stakeholders, there’s another sudden drop (P2). Finally, thanks to the agile iterative approach, risk are manged proactively and thus it should not happen to have a growing trend, however this decreases till the end of the initiative.

It is interesting noting that business value starts to be created only when the inception is finished. Actually, nothing is delivered to the customer during that phase. Even if this could be seen as a sort of violation of the Agile principles, when facing a big project it could be acceptable to trade some time (money) initially, to drastically improve the probability of final success.

How can we wrap-up and represent the previous concepts all together?!

No alt text provided for this image

What are you saying?^ Your project is not that big and you have only one team involved?!

Well, the Agile Inception Deck from the Agile Samurai is what you need. Enjoy! :o)

Article “The Spotify approach: more reactive and agile organizations” [italian]

Digital revolution and technological innovation have spread to every sector of the world of work.
Only companies able to listen to their customers thoroughly and respond quickly to their requests, redesigning business models and constantly innovating their products and services, are destined to play a leading role in their target markets.
How can companies be made more responsive and close to the customer and, at the same time, increase engagement and satisfaction of their employees?

Let’s see how Spotify is organized and what can be applied to every organization who wants to be successful nowadays. Here the link to my article (italian).

Agile Risk Management @ Scale

If managing risks with Agile could seem trivial in case of just one team, what are the good practices when multiple teams are working together building the same solution?

No alt text provided for this image

In the first part of this post, I explored how great is Agile at its core and, more specifically, how Scrum implicitly and by design, takes risks into high account.

We know that risk management is mainly about culture. Whatever is the approach, technique, methodology used to handle risks, people shall be predisposed, educated and sensitive to it.

Risk culture is a term describing the values, beliefs, knowledge, attitudes and understanding about risks, shared by a group of people with a common purpose. This applies to all organizations. An effective risk culture, is one that enables and rewards individuals and groups for managing and taking care of the risks in an informed manner.

So, the first thing to do when in need of improving the way risks are managed within your organization, is to teach and train people on risks and how to manage them, then evolve the mindset by increasing transparency, trust and fostering a disciplined approach to risk management, again, whatever is the methodology applied.

Back to Agile, we know that Scrum teams manage actively impediments and are able to better foresee risks and implications. But how does this scale through a program of several teams working together on the same product? How risks are managed and escalated to the upper level?

It all starts with firstly enforcing the way risks are managed at team level.

Agile Risk Management Tools at Team Level

Scrum teams manage risks daily through the Daily Scrum. Additionally all the other events and practices (Planning, Review, Retrospective, Backlog Refinement) help them to identify, asses, evaluate and manage risks proactively and consistently, thanks to cadence and clarity of events, transparency of roles and responsibilities, team collaborative behaviors, etc.

Additionally, Scrum teams handle risks through lightweight approaches by using visual management and radiators, which maintain the information always visible and present to the whole team, asking for action.

No alt text provided for this image

The board above reported, helps teams to manage in their resolution and physically in one place both impediments and risks; for the latter, keeping also into consideration the different levels of attention.

However, in case of very risky and critical programs, a more robust approach in managing risks shall be applied; in those cases, the most disciplined agile teams used to measure, for each risk, two additional dimensions: Likelihood and Size of Loss.

Likelihood regards the likelihood that a risk can actually happen. Size of Loss measures the number of estimated days needed to recover and to get back on track if that risk eventually materialize.

The result of multiplying these two numbers, gives back the exposure for each risk, which can be added and accumulated for each sprint and, thus, reported over time. This assessment is done every iteration, according to Scrum events (Retrospective is a good one), in order to identify what actions can be put in place to mitigate if not definitely solve the risk.

The results of such actions, should lower, over time, the risk exposure. Risk Exposure trend can be then visualized through the Risk Burndown chart,

No alt text provided for this image

As we know, Agile teams are self-managing and self-organizing.

This means that they should always try to solve impediments and face risks, autonomously. When working in a program, it happens though, that some of these risks are more systematic, organizational and cannot be directly solved by themselves.

This is the time when teams shall escalate risks (in an agile way) to the upper program level. Let’s see how ūüôā

Agile Risk Management at Program Level

Whatever is the Agile Scaling Framework chosen, Risk Management at program level follows similar rules described for Agile teams (fractal mode). Usually, when having teams working together to produce the same product/solution, we should have at least the following events (whatever the chosen framework):

  • Inception¬†and¬†Release Planning
  • Sync Events¬†between team representative and Program roles during execution (e.g. Scrum of Scrums, Tribe/Train Sync, Nexus Daily Scrum, etc.)
  • Program Demo¬†and¬†Retrospective

Risks are actively managed through this events.

One of the tool used which can be used is the same board above described for teams. Risks coming from that level and which relate to program, are pulled and here managed.

No alt text provided for this image

Risks are usually identified and assessed also during one of the events above reported. The¬†Threat¬†Matrix¬†is also used at this level; this helps in assessing the likelihood and Impact of the risk…but always done in a collaboratively way by the teams and program roles:

No alt text provided for this image

Then every risk, according to its threat level, is discussed and managed by deciding which action must be taken. A good tool which can be used is the ROAM Board which groups risks into four categories:

  • Resolved: no more a threat
  • Owned: risks which need further investigation. An owner is assigned
  • Accepted: risks whose level of threatness is very low, thus even if happening won’t impact seriously the program
  • Mitigate: risks who are serious and thus are mitigated through punctual actions
No alt text provided for this image

…again visual management, involvement and cooperation between teams and program roles are key for the success of the activity and in general for risk management practice when you are playing the game in an Agile way.

No alt text provided for this image

Once a “traditional” guy told me: “when it’s time to manage projects and product development, Agilists like you are just cowboys which hug trees and hung post-its on walls”.

Well, we Agilists create the space where individuals and their great interactions meet lightweight processes and tools; this is when actually magic happens.

Wasn’t this the reason why Agile has been created?! :o)

On Risks and Agile approaches

What if some sarcastic guys would challenge us by asserting that Agile/Scrum primarily are mainly great approaches to manage risks?! Should we feel offended by that? Well, let’s see how Agile addresses and manages risks, then we can decide :o)

No alt text provided for this image

Once I read, don’t remember where, that Scrum is not, at all, the best approach to develop products when facing complexity; rather, it’s the best known¬†Risk Management¬†approach in the world.

Well, I could not agree 100% (actually, you do develop great products when strongly challenged by uncertainty) but, putting aside the sarcasm of the author, which made me smile, I found myself in sympathy with it.

If we take a look to the Agile Manifesto and the Scrum framework, there are may practices and principles which, by design, help teams to actually manage proactively risks:

  • Fast feedback cycle: let you to discover in advance any bad variance between progress/value created, respect to client/user expectations. Furthermore, in case of bad surprises, you can recover pretty well and fast.
  • Continuous (re)planning: Agile is based on¬†empirical process control. This means that every iteration ends with the inspection of the product (sprint review) and the underlying process (sprint retrospective). These are key events where agile teams discover, assess any risks and adapt their behaviors according to it.
  • Daily Scrum: every day the development team meet for 15 minutes in front of the board, discussing progress, plans for the new working day and impediments (risks that actually became facts) and any possible risks.
  • Small batch size: Agile suggests to work in iteration. During these ones the team shall design, build, test and deploy a potentially shippable product. Iteration must be small ones (2 to 4 weeks maximum) preferring the shorter timescale when uncertainty is high. Well, this implicitly means that the amount of work is limited, more manageable, dependencies are easier to visualize, uncertainty is limited and, thus, risks are inherently less “risky” in terms of probability of occurrence and impact on project objectives.
  • Team diversity and cross-functionality: teams like these ones are better equipped to explore solutions for complex problems and foreseen any possible risk in advance respect to other team typologies.
  • Backlog Prioritization: backlog is prioritized by the Product Owner. There are many techniques and approaches to do that (MoSCoW,¬†Cost of delay,¬†WSJF, Kano,¬†Relative Weighting); of course business value and effort (cost) are the primary factors to be considered, but also the risk is a key item that must be taken into large account when prioritizing backlog items. Why? What if we continue to deliver the most valuable backlog items (in the eye of the customer), while neglecting some very risky items that remains in the lower part of the backlog (mening low biz value) and which can derail the whole project because of tech problems or something? By the way the WSJF method from SAFe, is crystal clear on how to prioritize features and epics keeping in account risks (and opportunities as well).
No alt text provided for this image

If you are still reading this post, I am sure now you agree with the sarcastic guys mentioned in the introduction :o)

If we bring this one step further, by looking back on how traditional project management categorize risks, we find the following:

  • Known Knowns: things that we know that we know; it regards our general knowledge. Risks we know, which we can assess in terms of impact and probability and we can decide how to manage them (owning, transferring, mitigating o accepting).
  • Known Unknowns: things we know that we don‚Äôt know, or we don‚Äôt know their potential risks. They have not been accurately measured, but we are aware that in that area we could have problems or surprises and we need to monitor them accurately.
  • Unknown Unknowns: these are the most dangerous kind of risks; they are strongly linked with uncertainty and complexity. We actually don‚Äôt even know, that we don‚Äôt know that they exist. Any of this kind of risks, can hit seriously and unexpectedly our project.

Agile teams intrinsically are able to address any o these categories of risks.

Daily Scrums are the primary technique they have to manage the Known Knowns.

In addition to that event, backlog refinement, sprint planning, review and retrospective, are the tools agile teams have to address Known Unknowns.

And, what about the¬†Unknown Unknowns? Well guys, aren’t Agile and the empirical approach be made exactly for¬†exploring uncertainty¬†and¬†complexity, by incessantly lowering risks through iteration execution?

Article State of Flow: how to increase innovation, productivity and agility in organizations

Here one of my article (Italian) published by Leadership & Management magazine.

stateofflow aticle


Leadership, agility and innovation in the digital era article (italian)


Here one article of mine published by Tecna Editrice.


WordPress Themes