How Agile can boost performance of Remote, Distributed Teams

Picture by bongkarn thanyakij

The imprisonment to which most of us are subjected in this period due to Covid-19, actually can bring unexpected benefits if you are able to look in the right direction, spotting new opportunities. What if you discover that teams working from remote are able to maintain same, if not better, levels of effectiveness?

Isn’t that counter-intuitive? Doesn’t success of Agile lie on face to face communication, proximity and side-by-side collaboration?

No alt text provided for this image

Yes, performance and productivity not necessarily drop down inexorably, for (agile) teams, when working remotely. A simple research we conducted internally in our Agile practice, regarded dozen of teams we are working with, shown that effectiveness remained the same if not increased in some cases.

But. We know since decades that one key pillars of agile is letting people interact directly, personally and in strict proximity, avoiding waiting times, misunderstandings, and enabling better interactions and collaboration approaches.

This is why it’s always worth insisting to build co-located teams: we want to create a real change putting people together, getting rid of silos, hand-offs and old mentality.

Covid-19 is challenging us dramatically, teaching meaningful lessons and pushing to us to be creative and to explore new possibilities. One is: how to remain effective when working miles away from our companies, offices and colleagues?

Agile remote and distributed teams are, since years, an established reality. This has been reflected also in the 2019 State of Agile Survey:

While working together, face-to-face, can be desirable for agile practices, survey respondents indicated that organizations are supporting distributed teams and team members. There is no evidence of a trend toward increased co-location, as organizations continue to support and encourage team collaboration across geographic boundaries and time zones.

The survey goes on reporting some statistics:

of respondents say their organization practices agile with team members distributed (not co-located)

Now, this seems to be, for many companies and people around the world, the only way to continue to work and produce value, already. Now it’s even more important than ever before.

Importance of Culture in Distributed Remote Teams

No alt text provided for this image

During one past agile conference, I had a great chat with some Agile fellows on how, some years ago, they have been able to build from scratch a company whose employees are spread across Italy and Europe, working from home: no company buildings to reach, no dedicated offices to walk in, no desks to tidy up, no stolen personal chairs to be found around, no common cafeterias where to heat lunches or coffee machines to be punched to get your money back.

…Sigh…how much we miss these things….but anyway, it’s not time to be nostalgic, here some key lessons I collected.

Once you start to work and connect from remote, some differences such as gender, age, disability, race, become less “visible”, or better, they become less important and divisive; while soft skills such as openness, ability to listen, empathy and engagement, take the scene becoming even more important compared to when working closely, co-located in the same team room.

Another interesting aspect is that the attention to culture and related behaviors is paramount, but the curious thing is that its reinforcement is somehow left to a sort of self-organization.

Companies like that one relies on strong values and principles, while strict policies and agreements are not necessarily written neither formalized. Actions and related behaviors are somehow self-regulated due to frequent interactions that distance necessitates and that technology allows, resulting in valuable continuous and repetitive stimulus for everyone, to reflect, inspect and adapt.

It seems that acceptance and belonging in remote teams is even more important

As social animals, we know that when someone is creating value in how he or she interacts with others, this will enforce its belonging to the group while, on the opposite, any dysfunctional approaches will put that person incrementally at risk to be excluded, marginalized. It seems that in remote teams, this rule is even more exasperated due to the necessity to remain effective and pragmatic in creating value, avoiding misunderstandings and waste.

Another key point regards recruitment, where the attention here is of huge importance (and sometimes maniacal). Hiring the wrong person could severely disrupt the capacity of teams to collaborate effectively “polluting” current culture, while the opposite is true as well: hiring the right person can elevate the whole organization to the next cultural maturity level.

Being very flat in their organizational structure, candidates usually pass through several interviews directly done by (senior) team members who lived the company since many years, who firstly explore closeness of person’s values to company ones, soft and behavioral attitudes and, only then, technical and hard skills.

Working from remote in those companies, thus, presents some great benefits:

  • Formalities and etiquette become less important, while real talents become more visible, exposed and “utilized”.
  • Time wastes due to commuting are avoided, while parents can better take care of children, beloved ones and their houses (…pollution of air decrease and sustainability increases, too).
  • Politics lose power, opening up to real meritocracy.

To summarize: less waste, less pollution, more value, more money.

Working in those settings, however, can be alienating if pushed too much. Why? Lack of human contacts.

You know what my Agile friends told me on this? Apart from organizing company dinners from time to time and reserving some budget for face-to-face collective training, in some key moments of their projects (or when they feel they need to meet in person), they take their cars and meet for some hours in halfway motorway service stations.

Well, my friends, since a vaccine for Covid-19 won’t be found, in addition to your computers, you will need to bring protective face masks and gloves with you.

Want your Remote Team to be effective?

In these times of uncertainties, many people who were used to work closely, are today struggling in remaining productive, looking for ways to effectively work together. Well, why not give Agile a try?

Agile naturally creates for them a context where value creation, creativity, adaptation and reciprocal trust are the main ingredients they can use to prepare their “dishes”, while the intrinsic empirical approach helps them to experiment, learn fast and quickly adapt.

No alt text provided for this image

Additionally, Scrum can be thought as a great playbook that, containing the barely minimum structure (e.g. rules, roles and events), will for sure help those people to coordinate as teams and deliver value, even when work remotely.

Certainly and undeniably, it’s a big change but it’s worth trying it because results won’t be long in coming.

The post “Do not give up. Being Agile is the answer” gives some guidance on how to invest on team’s values, charters and facilitation techniques, to let you agile team become stronger.

Key aspects for Agile Distributed Teams

Teams that embraced Agile normally did that mainly because are exposed to complexity, variability, uncertainty and volatility. What any other and additional challenges distributed agile teams will find in their journeys?

Distributed agile teams are spread geographically, located in different locations, countries if not continents. Those teams face culturalcommunication and time-zone issues.

In these settings, assuring that key roles such as Scrum Masters and Product Owners are covered by energetic and inspired people, helps assuring that teams are carefully built and treated.

Additionally, the right digital technology must be used for backlogs, team agreements, boards and information radiators; they must be available to everyone, always, frequently updated to reflect reality. Two of the most important information radiators distributed teams needs to write and made explicit, are the definition of ready and definition of done.

Events need to be arranged keeping in the right account the different time-zones and, if necessary, adapting cadence to allow everyone to participate avoiding late or early hours, possibly arranging sessions in diverging converging activities, to let people breakout in sub-teams and rejoin to consolidate.

Celebrating main events and results is even more important to remote teams to let them build strong bonds and trust in each other.

Brainstorming activities are normally great moments for teams to be creative and look for solutions to complex problems. Agile teams usually do this in their rooms, sketching on whiteboards and flip-charts liberating creativity, building on each other ideas, strongly collaborating; a noble by-product of these sessions are improved trust and stronger relationships among team members. Distributed teams need to replicate these moments, choosing the right digital tools and investing some time to transform these experiments in teams’ habits.

No alt text provided for this image

Furthermore, there is not anything worst than participating to an event that is poorly prepared in terms of environments, technology, timings and facilitation. Scrum Masters and Agile Coaches will need to spend the right amount of time to prepare and host these events to let teams to be effective in delivering value.

Finally, Product and Business Owners need to allocate budget to allow team members to meet in person during the team and release inceptions and other events like releasing major product increments, to continuously build the team.

And, once Covid-19 will loosen its grip on our lives, let’s use part of that budget to finally meet in person for dinner, sipping a bear. See you there…

Customers, Employees and Communities, first; then, Shareholders

WikImages

To date, most companies gave higher priority to return on shareholders investment. This has created major problems for the fragile balance of the planet, as well as dramatic and always increasing disparities among rich and poor people.

The Covid-19 crisis we’re living is teaching us, one more time, that everything in this world is inter-connected. Can human beings and corporations change their priorities and remedy to these disparities? Where can we start?

I think Agile could help, but it’s obviously a titanic endeavor if left alone. But if we rewind the tape to just a few months ago, we we may find a first sign of this change. This story starts on August, 2019, the 19th…

No alt text provided for this image

There are dates. There are dates that we knew in advance they would become historical; events that the entire humanity knew about, which ti expected to become reality at a specific point in time.

Then, there are other dates. Dates that most of people do not know in advance, related to events that were not promoted or communicated.

Dates which the people started to call Event, with a capital letter “E”, only in retrospect by recognizing them as historical and, from that moment on, celebrating its anniversary by signing them on calendars.

Agile Manifesto white board original picture

How many of you, on February 2001 from 11th to 13th were nervous, in front of the television (or pc), biting their nails and waiting the seventeen Agile gurus to finally sign the Manifesto, one after the other, with the same apprehension with which our fathers and mothers, anxiously, were looking at Neil Armstrong, taking the first step on the lunar soil on July 21st, 1969?

Well, even if thinking this way to the birth of the Agile Manifesto is quite romantic, that story is highly unlikely. Actually, we understood the importance, magnitude and the extent of that event, only after months, if not years. In retrospect, in fact.

But actually, for many of us, it completely, definitely and wildly changed the course of their lives.

And August 2019, the 19th, in my opinion, could be one of those dates.

Business Roundtable

According to Wikipedia, the Business Roundtable is a non-profit association based in Washington, D.C. whose members are (181) chief executive officers of major U.S. companies. Its mission is to promote public policy favorable to business or social interests, while opposing others (e.g. the Trump administration’s family separation policy).

That day, they met to draft and sign a document which content was quite unexpected according to what the public opinion usually expects from a committee of that typology, where personal and financial interests, games of power and false promises generally predominate and then having the courage to present the results as revolutionary, through big and bold announcements.

No alt text provided for this image

But this time that was different.

Yet, in my opinion, in a near future and only in retrospect, we will be able to appreciate the extent, magnitude and importance of that event, as huge. I cannot say 100% like what it has been the Agile Manifesto, but I honestly hope so.

What was that document about? It radically redefined the purpose of American corporations. And what does this has to do with Agile? Well, be patient and follow me.

Purpose of a Corporation

You can find the entire declaration here, but let’s see what are the most important passages of that document, reported below by following the original, strict sequence (priority).

[…] While each of our individual companies serves its own corporate purpose, we share a fundamental commitment to all of our stakeholders. We commit to:

  1. Delivering value to our customers […]
  2. Investing in our employees […]
  3. Dealing fairly and ethically with our suppliers […]
  4.  Supporting the communities in which we work […]
  5. Generating long-term value for shareholders […]

What?! Am I dreaming?

Shareholders are in the last position and, additionally, corporations should not pursue short but, however, long term value?

And what about the higher priority stakeholders? Customers, employees, suppliers, communities? Music for our ears…and did you see the accompanying verbs? Delivering, Investing, Dealing fairly, Supporting.

All this sums up into two very dear concepts to us: Sustainability and Agility. Bingo!

No alt text provided for this image

More sustainability for a suffering world

Before Covid-19 outbreak, one the biggest concerns for many of us were the climate change and the devastating effects it’s having on our planet, in a world where the gap between richest and poorest people dramatically increases every day.

Concepts like circular economy and a green new deal, seem to be the only way out to literally save our planet and ourselves.

But, the speed with which we are walking that path it’s quite slow, unsure. This is why I consider that declaration a big step towards the right direction.

Can you imagine?! 181 CEOs of major American corporations (knowing that U.S. is one of the most polluting countries in the world) are promising to be more attentive and dedicated to employees and communities, no more looking to them and the resources of our planet like oranges to be squeezed for the immediate and prevalent thirst of the shareholders.

The companies these CEOs are leading, will review their operating and cultural models according to those principles; thousands if not millions of their employees will be benefited and hopefully, at their turn, will apply those behaviors in their families and communities, starting a virtuous circle, which we all hope will (this time positively) “infect” the whole planet.

The crisis we are living due to the Corona virus infection, is demonstrating how an isolated phenomena happened in a very local situation (Chinese Wuhan wet market) if not understood and underestimated, could propagate and cause unimaginable consequences in the whole world.

No alt text provided for this image

This stresses even more the concept of inter-dependency of every living being, community or corporation, despite weather they are in Italy, U.S. or China. For the ones who want to deepen this topic, this is a good place where to start: Butterfly Effect of Edward Lorenz.

Complexity, interdependence, people centricity, effective value creation, adaptiveness, respect, teaming, engagement, transparency, sustainability, courage: aren’t these the topics that we Agilists study, understand, believe in and embody every day?

Agility for a better world

If we take a look the twelve principles of the Agile Manifesto, we discover how much this discipline has its feet deeply rooted in lean and humanism currents of thoughts: a noble and effective platform that can help every corporations to stick to the above reported declaration.

Agile was created to satisfy and captivate customers, solve complex problems and avoid unnecessary waste, by creating the right product the market needs: nothing more, nothing less. Again, repeat with me: nothing more and nothing less.

How? Iterative, empirical approach, feedback and early and continuous delivery of value, are the main components,which can help delighting the customers while not misspend or misuse any resources (and polluting less).

Additionally, effectiveness of teams is another key topic with the intent to spend their minimal amount of energy, in order to create the maximum amount of value. This is incredibly well described by the tenth principles:

Simplicity–the art of maximizing the amount of work not done–is essential

Furthermore, the fact that Agile advices to “melt down” silos by creating cross-functional teams and getting business people sitting beside product developers, is another element that gives companies more opportunities to be adaptable, essential, effectual, reducing hand-offs, misunderstandings, delays.

Once more, reducing waste.

When we analyze the situation from the point of view of employees’ well-being, we found that, undoubtedly, Agile is many steps ahead from any other approaches.

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

It explicitly states principles like sustainability of pace, motivation, safe environments, trust and empowerment.

Agile processes promote sustainable development. […]

But first, step back, avoid Agile involution and jump ahead

It seems that, as human beings, we have a big ancestral flaw: to over-complicate, over-engineer, what is simple. We are great at creating superstructures that often create inefficiencies, entropy, complicatedness. Waste, in facts.

It seems that our Agile community is also sick of that disease. Alistair Cockburn, an Agile Manifesto co-author, describes this phenomena this way:

Agile has become overly decorated. Let’s scrape away those decorations for a minute, and get back to the heart of agile.

He thinks actually that the proliferation of frameworks, approaches and certifications obfuscated the original meaning.

No alt text provided for this image

Alistair is also one the founder of the Hearth of Agile, a movement which suggests to be simpler and wants to somehow “reboot the machine”, by starting from these four principles:

  • Collaborate closely with others to generate and develop better starting ideas. Communicate often to smooth transitions.
  • Deliver small probes initially to learn how the world really works. Expand deliveries as you learn to predict and influence outcomes.
  • Reflect periodically, along the way. Think about what you’ve learned in your collaboration and from your deliveries.
  • Improve the direction of your ideas, their technical implementation, and your internal processes.

My wish is that the day we were put into quarantine due to the Corona virus, can become one of those dates we could remember as memorable.

A date where a real change happened, in the way we behave, live and work, with more respect for people, their interactions and the planet they live…and, of course, with more agility, where values and principles come first, frameworks and certifications then.

 

Do not give up. Being Agile is the answer

0

The dramatic crisis we are living due to Covid-19 and the consequent fears and uncertainties, could put at risk some of the advancements we have experienced in the past twenty years, also thanks to the Agile movement. Some of the underlying principles of that revolution are today dramatically challenged by this infinitesimal virus who, mercilessly, undermines the foundations of that approach: interactions and close collaboration among individuals. How can we react?

No alt text provided for this image

Some people, scared by what is happening, could yield to the temptation of switching back, again, on putting too much attention and focus on processes and tools, instead of continuing relying on individuals and interactions, which the Agile Manifesto preaches since February 2001. This, in the hope of a better control of the situation.

Others could revert to centralize majority of decisions given the impossibility to directly get in touch with a workforce that today finds itself obliged to work remotely, probably suffering from poor performance if compared to yesterday’s one. This, in the illusion of greater alignment.

On the shop floor, a few ones could give up in trying to find new working approaches compatible with the new situation we are living, discouraged by difficulties and operational impediments. This, because of the wrong thinking that this situation is very short, only temporary and everything will soon be back to “normality”.

Yes, the impact it’s huge, also for our Agile community, which has made of trust, collaboration, proximity and face to face communication its workhorses.

All this could lead to rollback to old, anachronistic micro-managing approaches, while, instead, what is needed is to reassure people and help them to unleash creativity to adapt faster and find new ways to be productive.

Yes, but how big is all this? It’s huge. We know it’s huge, For us, for the whole economy.

And the impact is huge also for our Agile community, which has made of trust, collaboration, proximity and face to face communication its workhorses. How can we proceed further with those fundamental principles severely limited by this dramatic pandemic?

Can we simply “go remote“?

  • Is it enough to increase the bandwidth of our signals, wifi and internet channels, to increase the quality of our remote communications?
  • Is it enough to buy a shining, brand new collaborating tool, to assure right execution of Agile events and boosting collaboration?
  • Is it enough to stick a photography of each of our team mates in front of the table in the kitchen of our houses, to remain empathetic like we were in person?

No, if those actions are taken separately and without a solid leadership foundation.

Agile was made to face uncertainty, complexity. This is exactly what we are in right now. Agile is first, and foremost, a mindset; so, let’s see how we can preserve, persevere and push this to the next level.

Values and Principles

Today is even more important to thoroughly live the four Agile Values and twelve Principles. We need to read them again and again, transpose them to what we are living, think on how to apply them accordingly to what we are experiencing.

The empirical approach shall guide every of our actions, Inspect & Adapt must become the new mantra

Do they work as they are? Is it necessary to re-interpret them (always keeping intact their essence)? How can we preserve the value of each principle, while achieving it in a different way?

This situation requires great attitudes of adaptability from everyone. Values like trust and transparency must be assured and reminded in every occasions; this is even more important in meeting not attended in person but remotely.

The empirical approach shall guide every of our actions, Inspect & Adapt must become the new mantra, and must be applied every time we are experiencing new approaches with our team, to do things we did in the past in different ways.

Additionally, the five Scrum Values seem to be originally thought to be our guide exactly in moments like these ones: FocusOpennessRespectCommitmentCourage.

ScrumValues-1000

Is there anything less current than those ones?

Team Charters

Team charters are artifacts which prepare the ground for teams to be successful.

They state the mission and objectives the teams need to achieve. They clarify roles, responsibilities, strengths and weaknesses of a team and explicitly report what values, principles and working agreements the teams shall rely on to achieve their goals and remain accountable to each other.

No alt text provided for this image

When working with teams whose members are not co-located, but dispersed geographically, it is strongly suggested to draft or renewal their charters, almost obsessively reminding each other what is there written, being the foundation for good collaboration.

Remote Facilitation

Facilitating remote meetings implies additional skills respect to what we usually do in person.

First of all we need to take some time before any meeting to understand how we can create an environment where empathy, trust and transparency can be enforced despite the greatest difficulties.

The facilitator has a key responsibility to guide the participants through the event, being the first in demonstrating engagement, giving a clear vision, always encouraging others to be present and participatory.

She needs to show how much she believes the team can perform and be productive in spite of any possible distraction or roadblock and always reminding everyone the rules of the new “remote game”, being passionate and disciplined; in a few words, leading by example.

And yes, some tips and tricks about facilitating remote workshops can definitely help:

  • Open by acknowledging different context each participant is living
  • Form groups in advance
  • When it’s time to speak call out participant one after the other
  • Even if some people are co-located, ask them to participate by dialing-in, to “normalize” and balance participation
  • Timebox everything; better if your tool has an embedded timer 
  • Frequently ask for feedback through dot voting, stickies, polls, etc.
  • Keep webcams always switched-on
  • Use a video collaborating tool that always shows people faces in one shot
  • Use the pomodoro technique to better orchestrate focus and refresh times
  • Use digital whiteboard to show sketches or draw them on paper, snap a pic of it and share
  • Every important meeting should have a facilitator and a tracker who takes notes

We all know it won’t be easy. But we are lucky, we are Agilists.

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

stabe

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

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 accountabilitymotivation 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

bd1

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 VisionAlign with Enterprise DirectionExplore ScopeIdentify Architecture StrategyForm TeamPlan the ReleaseDevelop Test StrategySecure 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 transparencytrust 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 (PlanningReviewRetrospectiveBacklog 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 systematicorganizational 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)

WordPress Themes