At that time, I was the manager of a front-end development team working in an Agile environment. It is years later only, while explaining my adventure into fitness to some of my peers, that I understood there were similarities between Agile and my weight loss. I was able to conclude there are at least 6 parallels between Agile and the way I was able to accomplish this personal achievement.

1. The mindset is paramount

In Agile as in weight loss, everything depends on having the right mindset. Of course, you’ll find some processes, but in both cases they are useless if one doesn’t find the right mindset.

The mindset in weight loss

At the start of the program, we were 18 members. At the end, we were 8. It means that 10 people were not really ready to change their lifestyle to be in better health and shape. Only those who had the right growth mindset (as opposed to a fixed mindset) completed the 9 month program.

Those who left the program, after putting in so many efforts, paid a lot of money to go back to their old habits without getting any of the benefits that were within their reach. If the required physical efforts are difficult, sometimes the required mental efforts are much more of a pain.

The mindset in Agile

Very often, organizations “do” Agile without going through the pain of changing their old cultural habits which are well entrenched and hard to break. Those are traditionally the organizations that will state that “Agile doesn’t work”, and quickly go back to a lifestyle in which they were comfortable. Agile doesn’t work, really? Or weren’t you ready to change in order to succeed? Because Agile, by definition, is the capacity to adapt according to needs that are in perpetual change.

It is now a consensus that applying Agile processes without making radical changes in the organization’s culture brings none of the benefits of Agile, but will create a level of cynicism as developers will observe that “even when it changes, nothing really changes”.

2. Motivation is essential, but discipline will make the difference

Everywhere I go, I put a maximum of efforts to understand the intrinsic motivations of my peers. Intrinsic motivation, which is a combination of mastery, autonomy and purpose, is essential for me if I want to to be fulfilled in my work. It was the same when it came to weight loss.

Motivation can spectacularly kick-start any professional or individual ambition. It is motivation that’s responsible for me being so active on LinkedIn when it comes to the Agile mindset and organizational culture. However, it only became possible because I set a proper routine for myself.

Motivation and discipline in weight loss

A friend of mine told me this a few times : “Olivier, I see what you’re doing and it’s a big motivator! I will also lose weight, just like you!”

After hearing it for the third time in a few days, I told him “Dude, stop being motivated and do it already!”. To this day, he has lost 100 lbs (45 kg).

Motivation is essential, just like the foot that pushes the accelerator pedal. It gives the initial push. However, just like driving, routine and discipline will keep you going forward, just like you need to apply the right pressure on the pedal, for a long time. I soon figured that if I didn’t have recurring and precise time slots to workout, I would end up with excuses not to do so. My solution was to simply create 4 immutable time slots entirely dedicated to working out. No need to ask myself anything, or wonder if I should go or not: i’m going on Mondays, Wednesdays, Fridays and Sundays. End of the line. As soon as I’d meddle with the routine, I had to work again on my motivation, so I tried not to.

Motivation and discipline in Agile

In some Agile frameworks such a Scrum, discipline in ceremonies are help making it a success. That’s why we call them “rituals” sometimes, by the way. The stand-up happens daily, same place, same time, whether everyone is there or not. This routine greatly helps removing ambiguities, as we don’t have to ask “At what time is it today? Where is it today? Who’s coming?”.

It is even better if planning session, reviews and retrospectives can be set upfront, at recurring days and times. The less the team has to wonder about time and location, the more it will be engaged in ceremonies, which will become a reflex.

3. People over processes

The first value of the Agile manifesto, and also the one I prefer. As softwares are developed by people, we have to (and some find this quite unfortunate) consider people first, and processes second. It goes the same way for weight loss.

People and processes in weight loss

I was invited to give lectures twice after my weight loss. My audience was composed of new participants who just subscribed to the same fitness program, since those conferences are part of the package deal.

I had to tell them the unfortunate news: there is no miracle approach to losing weight. You got to eat more healthy, and be physically active. You can’t go around that. However, there is no magic formula that applies to everyone (even Canada’s Food Guide isn’t a “one size fits all” solution). People are different, and have different needs. You got to work with experts, try things, keep what works and improve on what doesn’t for an efficient and long term weight loss.

People and processes in Agile

It is exactly the same. Some companies try to sell efficient processes. It must be hard, as there’s going to be people using these processes. What works for a team might not work for the team next door.

So, since I’m a little lazy, I could almost copy the paragraph I used in the previous section :

There is no magic formula that applies to everyone. People are different, and have different needs. You got to work with experts, try things, keep what works and improve on what doesn’t for an efficient and long term product development.

4. Taking action items in order to improve

It’s a generally well known fact that one can’t expect different results by always doing the same thing. There are plenty of interesting quotes to this effect :

“The definition of insanity is doing the same thing over and over and expecting different results.” – Albert Einstein

“You can’t dig a different hole by digging the same one deeper.” – Edward De Bono

Taking action items in weight loss

In my life, I tend to use what works for best for me. If I like a certain sports routine which makes a difference, I’ll stick to it. Sometimes, I might slightly depart from it for a change, but I’ll go back to it. However, if it’s obvious that my routine has no effect or impact, I’ll change it.

A time comes in weight loss when you reach a plateau. Your body tells you “Oh no, I’m losing so much weight, I must be in danger. I’m going to stop burning those calories and keep them, just in case”. A good way to break this plateau is by trolling your body, by eating differently and trying different physical activities. To this end, one must inspect oneself regularly to find ways to break straight lines and stability.

In short : quick, regular changes, and a way to measure the impact of those changes. If it works, continue. If it doesn’t, just stop.

Taking action items in Agile

If you ask me, retrospectives are the Agile ceremony that bring the most value. A time period reserved to inspect each other as a team, and contemplate what works for us and what doesn’t, so we can take concrete action items in order to improve. Continuous improvement. Isn’t that great?

There are plenty of metrics we can look at to know if the team stagnates or experiences problems, and identify potential sources of improvement. Failure to leveraging retrospective is the biggest mistake an Agile team could make. Otherwise, why bother trying to be agile?

5. First and foremost, measure impact

Numbers. Who doesn’t like the numbers that allow us to measure progress and see the results for which we’ve put so many efforts?

Measuring impact in weight loss

When I started my transformation, I was measuring everything: activity length, calories burned, weight, BMI (Body Mass Index), etc. All these metrics had a lot of value to me. However, none of them were really tangible. Even the weight that I lost wasn’t tangible. It’s a number. I couldn’t correlate it with the impact on my body.

I understood the impact on my body the first time I was able to wear my belt by using a different hole than before. And when I started wearing t-shirts that were one, two and three sizes smaller.

All other metrics were useful to measure… whatever measurable think that didn’t mean much. There wasn’t necessarily a causal link. At best, I could see some pattern emerge and try something new. But the impact on my body was the only measure that had real value to me. This is how all the efforts invested were taking anchor in reality.

Measuring impact in Agile

If there’s one thing one learns to do when becoming a Scrum Master is to gather metrics. Velocity, happiness index, burndown chart, team maturity, you name it.

Teams, Scrum Master, management, everyone seem to love measuring all that can be measured, because it gives us the impression that we’re in control. A lot of metrics are used to identify emerging patterns and generate discussions and opportunities for improvement.

However, in reality, many metrics bring little value to most people. Velocity, for instance, can be used by teams to measure stability in delivery, and make projections. It doesn’t say anything about the impact on the client, or about the real value that needs to be measured to have a satisfied client.

Taking only weight in account when in a fitness program is a mistake. Comparing your weight to someone else’s makes no sense. A person who weighs 220 lbs (100 kg) might be in much better shape than someone weighing 180 lbs (80 kg). It goes the same way with velocity. If it’s the only thing measured, it makes no sense by itself, and comparing teams by their respective velocities hints to an important lack of vision, and that the organization is focusing on the wrong objective.

6. Sustainable pace

Wanting to do too many things at once, biting more than one can chew, working hard at all costs. The negative and adverse effects of this approach are well known, and they apply in both context of fitness and Agile.

Sustainable pace in weight loss

It’s a well known fact that a fast and drastic weight loss (unless it comes from surgery) can cause create a situation where the weight will be regained just as quickly, if one doesn’t keep the lifestyle that encouraged the loss. Extreme diets along with intense physical efforts will definitely help you lose weight, but if ever you stop, the body will get out of its emergency state and will go “I’ll accumulate all the calories in case it happens again”.

In the long run, the human body needs its calories as much as it needs rest. Trying too hard is not only unhealthy, it’s also dangerous. The important is to keep a sustainable pace, and doing sports at a constant frequency that can adapt to our changing lifestyle. Healthy eating without necessarily doing without every food we love. A loss of 2 lbs (a little less than 1 kg) per week is ideal, a big maximum.

Sustainable pace in Agile

For the exact same reasons than above, wanting to do too much hurts in the long term. A team that commits to too much work in a Scrum iteration, for exemple, probably won’t be able to deliver everything without doing overtime. If this happens, not only does it create a precedent, but it makes metrics lie, and will increase expectations towards the team’s productivity. If it keeps going for too long, the team will end up exhausted.

A good team must keep the necessary focus on maintaining a sustainable pace so to stay out of a permanent state of emergency.

Olivier Fortier

Owner of Primos Populi, partner and coach at Moabi. As a former manager, I prefer to use a “people first, the rest will follow” kind of approach. My favorite topics are organizational culture, safe work environments, and lowering the center of gravity of the decision making process. I cultivate people’s awesomeness.

www.primospopuli.com

You’ve read a whole lot of books on the subject. You devoured a bunch of blog post too.

You know it is now time for an organizational change in your organization. You’re ready and willing. You’re pumped!

So… how do you proceed?

Change is a difficult subject to tackle, especially since people are a bit (okay, a LOT) weary about change. With good reasons too.

It’s hard for a company to reinvent its architecture. It’s even harder to implement a new one. The endeavor will face the full brunt of the organization’s immune system, competing personal agendas, danger from unexpected context changes, and the mighty power of truly apathetic people. Fun times.

Here are three strategies for change management. Each has their specific uses and knowing which one will save you lots of pain.

Big Top-Down Change

This strategy is a popular one. Not because it’s the best, not because it’s the safest and not because it’s the least traumatizing one. No, it’s the most popular because:

• It can be managed just like a project, with big planning committees, lots of predictive planning, and good excuses to scrap the whole thing when it goes awry.
• Many consulting firms prefer to work this way: big endeavor means you’ll need more help, and thus more revenues for the firm.
• It’s a great way to focus attention. It can be on yourself. It can be away from something else. If your company is large enough, it can even be newsworthy! Perfect to hide something.
• It keeps you in control.

This doesn’t mean that it can’t be the most appropriate form of change in many situations. It’s just that the bigger you go, the riskier it gets. If you want to go that route, then make sure you do it for the right reasons.

Use this strategy when:

When an organization needs to implement something across the board and do so in a specific manner, a Big Top-down change might be the way to go. Ex: A new governmental constraint for example or a new company initiative.

When the organization needs to do a major pivot quickly, this strategy may be appropriate. Pivots will cover changes in vision, or organization and maybe even the very nature of the work being done. In theses cases, there might now be a better way to implement the change. Mind the risks, however.

Avoid this strategy when:

Avoid this strategy if you can use another. Big top-down change seems safer because a lot of Very Intelligent People talked and planned and produced solid documents. They still often fail because the employees (and even people in upper management) don’t buy-in on the change and will resist it actively or passively.

Know the risks:

It is easy to plan such strategy and still fail miserably to communicate to the organization why it is important and why it has to be done this way. Communication is key here because any Big Top-down change is assured to elicit the most aggressive organizational immune response.

This risk can be mitigated by exchanging with the affected people well in advance, not just to inform them of what’s to come, but to allow them to express themselves and maybe even contribute in making the change less traumatizing for them. Getting any measure of buy-in from them will go a long way toward the success of the change endeavor.

Never underestimate the power of a large group of people dragging their feet.

Bottom-up

When you want real change, but are very conscious of limiting the possible damage if something goes wrong, the bottom-up strategy allows you to drive small change increments and observing results before committing at a larger scale.

Use this strategy when:

If your organization already follow a kanban approach, then this will be the way to go, as kanban prefer small but constant improvement over large wide-scale efforts. That’s one way of looking at bottom-up changes; there are two others.

The second one is the small, controlled experiment approach. That’s the one favored by Modern Agile. Find a group willing to participate, ask them to adopt a small change for a set amount of time, then debrief with them and choose to permanently adopt it, drop it or tweak it and retry the experiment. This participatory way of conducting change doesn’t require a huge plan and will give you a lot of data moving forward. When you are done with one change, move on to the next.

The last type of bottom-up change is the grassroots effort. That’s when the people affected by the change request it and drives it. You can’t get better ownership than that, and you get it right from the start. Grassroots efforts can be fragile, however, especially when they cannot get the buy-in from higher-ups.

Avoid this strategy when:

When the buy-in from higher-ups is necessary and won’t be possible, don’t waste your time with the bottom-up approach.

Know the risks:

A lack of buy-in from decision-makers within the organization will doom any bottom-up change efforts. Same goes for lack of buy-in from those asked to participate.

“Weak” buy-in from decision-makers, that is a verbal support that isn’t backed by actions will only drive the organization’s immune system to target the change effort and squash it. Over the years, I saw many department directors asking for change but unwilling to ask HR, finances, PMOs and other such groups to allow for the exemptions to the standard rules needed for the change to be successful. I saw people courageously agreeing to step into a new demanding role just to be told later than that all duties from their old role were still expected of them.

Organic cohorts

Writers such as Frederick Laloux and Dave Gray and others argue in favor of a much more organic approach to change in an organization, even if the two have significantly different takes on it.

In his book The Connected Company, Dave Gray describe a model where self-organized groups (called “pods”) plug into a platform that defines the boundaries of what they can do independently and what is expected of them in return, creating a networked company. Called Podularity, the model essentially calls for the creation of franchise-like entities within your company.

This strategy calls for testing the change strategy in a receptive target group (your first pod), see how it goes, broadcast the benefits to reassure the organization. You then readjust your strategy based on what you have learned, and start with a second receptive target group.

You will notice that the platform will constantly grow and change based on the result of practice, observation and back and forth between the pods and management. If your organization is a bit larger, maybe you will end up with more than a single platform. That is totally fine.

This approach will create a living dynamic between upper management and the pods. The platform will stabilize after a while but will always keep this ability to grow and change to better adapt to your current reality in a far more natural way than initiation big changes.

Use this strategy when:

When you want to evolve your company toward a more self-organized, decentralized and adaptative model, this strategy truly shines. It turns upper management into stewards of a sort, rather than taskmasters. It creates more autonomous and engaged employees, who will be better at responding to any situation that is local to them.

Avoid this strategy when:

Organic cohorts change people. Avoid this strategy when you require only a temporary change and plan to go back to normal after a while. It would create a traumatic effect even more important as a Big Top-down change as your employees will feel betrayed to have been granted autonomy only to see it recanted without cause.

Know the risks:

Going toward self-organization and autonomy changes people and the dynamics of the social contract between employer and employees. While this isn’t a problem in itself, it can be a risk to an organization who doesn’t realize the depth of the change in expectation about the dynamics within the organization. Understand what these kinds of changes mean and start on this path only if you feel that you can live with them.

It’s important that your pods get their constraints from the platform and not from the usual sources from the rest of the organization. The reason for that if you ask a group to change but still forces them to conform to all the same rules and requirements as before, you are not only sending a mixed message but in many cases you are preventing the change from succeeding.

We see this situation with Agile transformation all the time: the company request that a group becomes Agile but instead of gathering to their specific needs they still force the group to conform to traditional financing models, conventional project management models, and so on. The Agile transition fails to deliver on its promises simply there was never a real change, just a chaotic mess of contradicting rules.

Getting Help

Change management isn’t easy, and it’s certainly not second nature to most people. Getting professional help is advisable. To that end, many organization hires external consultants (like me).

Getting the right help can be tricky. Many consultants are familiar with only a specific approach to change management and might not be equipped to advise you properly. Look for a versatile one with experience, rather than one branded to a specific approach.

Don’t hire a consultant to drive the change for you. Your organization should take ownership of the change, and the actual work should be done by internal people. This is the only way that the consultant’s expertise will pass on to your organization and allows you to reinforce and maintain the change over time without depending on the consultant.

Don’t keep the consultant for too long. The value of an external consultant over an internal change manager is as much the different perspective brought in than the expertise. Perspective needs to be constantly nourished by different experiences and will weaken when deprived of that diversity. I wrote a blog post on that very subject.

Getting rid of change management

Change management will always be traumatic to an organization, even when that trauma is lessened by using the right strategy. The only way to getting rid of it to move away from change management.

Continuous improvement is a different type of strategy to approach change. Kanban and agile teams are already using this concept, but nothing limits it to them.

In continuous improvement, every group, no matter its size, strives to improve itself, its members and the benefits it brings to the company. It’s an entirely decentralized approach to change and adaptation that allows an organization to adapt and evolve as needed to better respond to its context while still following a vision.

I’ll discuss more organizational continuous improvement soon, so stay tuned!

Maurice Lefebvre

I am a futurist, system thinker and organizational transformation expert, dedicated to easing our transition into Society 5.0. I am available as a speaker through the think tank Hivernité (www.hivernite.ca) as well as a trainer and organizational coach through Moabi Formations (www.moabiformation.com).

www.hivernite.ca

However, being a Scrum Master also means, as I like to explain, being “a specialist of human beings in a technological environment”. The SM training teaches very little about the diverse ways we can achieve self-organization within a team, the ways to empower our coworkers, and making sure they take ownership of their work.

Here’s a rough estimate: 90% of the time, people that are now Scrum Master or Agile Coaches were previously either developers, project managers or team managers. Some of them chose this path, others were assigned to this role following a change in the business. It is not rare, for instance, for a developer to become Scrum Master because he knows the Scrum processes better than his colleagues. It is also common, for a project manager to become Scrum Master “by default”, after the adoption of Agility in the company.

Sometimes, though, one’s past will dictate how one tackles the present and future, and I think this is especially the case for Agile practitioners. Our past experiences have a high potential of influencing our approach as Scrum Masters, and most of us will encounter certain challenges and will be tempted to use old reflexes while coaching our teams. Since 50% of the problem is solved by acknowledging it, I thought it would be a good idea to write about this subject.

I came up with a list of what I think are the “good qualities of a Scrum Master”. I am not claiming I am right about everything, but the idea is to see what challenges a SM will face based on his/her professional background. To cover most cases, I will focus on those that have backgrounds in software development, team management as well as project management, using a simple list of pros and cons.

Being a Scrum Master with a software developer background

It’s a very common case, and sometimes a developer will even be a part-time Scrum Master. I will refrain from discussing this practice too much, as I haven’t tried it myself, but in my experience, a dedicated Scrum Master can have more than enough work to focus on his/her role. Everything depends on the expectations held by the company and the team.

A former developer will be good at:

• Understanding the technological dimensions of the product, as it will be useful every day;
• Finding the balance between quality and efficiency;
• Applying concepts such as a simple design, refactoring which he/she should already know;
• Facilitating any processes related to Quality Assurance;
• Applying and defending practices such as pair programming and peer code reviews;

A former developer might have difficulty to:

• Manage interpersonal relationships and conflicts if he/she isn’t used to it;
• Ensure self-organization within the team if, for instance, he/she used to be a team lead with the responsibility of deciding “who does what”;
• Keep in mind that principles are more important than practices;
• Be an agent of change, or dare disrupt established order;
• Know when to let the team fail when necessary;
• Use his/her power of influence;
• Follow up the state of the sprint and make projections;
• Create burn-up charts as well as roadmaps;
• Facilitate relationship with the client;

Being a Scrum Master with a project manager background

A typical case, following change management in a company, that went from “waterfall” to agility. For some, a project manager can fulfill both Scrum Master or Product Owner roles, as if it was a simple Tetris block that fits perfectly in the equation. I have seen numerous cases where this worked perfectly well, and some others that were more problematic.

A former project manager will be good at:

• Following up the state of the sprint and make projections;
• Creating burn-up charts and roadmaps;
• Facilitating relationship with the client;
• Coaching the team to focus on a common objective;

A former project manager might have difficulty to:

• Manage interpersonal relationships and conflicts if he/she’s not used to it;
• Ensure self-organization within the team, and refrain from deciding who does what;
• Keep in mind that principles are more important than practices;
• Be an agent of change, or dare disrupt established order;
• Know when to let the team fail when necessary;
• Balance quality and efficiency;
• Be at the service of the team, and not the opposite;
• Master concepts such as simple design, refactoring, quality assurance, pair programming, peer code reviews;
• Let the team estimate the work;

Being a Scrum Master with a team manager background

This is a little less common, and everything depends on which kind of manager we are speaking of. Let’s take for granted that it’s proper people-oriented management. Someone with this kind of experience will probably have no trouble understanding the concept of being a servant leader.

A former team manager will be good at:

• Managing interpersonal relationships and conflicts;
• Ensuring self-organization within the team;
• Keeping in mind that principles are more important than practices;
• Being an agent of change, and daring to disrupt established order;
• Letting the team fail when necessary;
• Using his power of influence;
• Coaching the team to focus on a common objective;

A former team manager might have difficulty to:

• Understand the technological dimension of the product;
• Find the balance between quality and efficiency
• Apply concepts such as simple-design and refactoring
• Facilitate processes necessary for quality assurance
• Apply and defend practices such as pair-programming and peer code review

In the end, no matter the direction a Scrum Master’s career takes, he or she will have to master elements that are outside of their expertise or experience. What we need to keep in mind is that without Agility, there is no Scrum, and no software. The Scrum Master must keep his/her focus on the fact that teams are composed of human beings, it’s the team that must be developed in priority.

I will conclude with a quote that I saw in my LinkedIn feed while I was writing this article and that magnificently summarizes the biggest challenge of every agile practitioner:

Thanks to my colleague Éric Laramée for the quote!

Olivier Fortier

Owner of Primos Populi, partner and coach at Moabi. As a former manager, I prefer to use a “people first, the rest will follow” kind of approach. My favorite topics are organizational culture, safe work environments, and lowering the center of gravity of the decision making process. I cultivate people’s awesomeness.

www.primospopuli.com

In fact, a large number of them seem to be copy and pasted from a project manager job posting with the additional requirement of a scrum master certification and possibly some agile experience. If that is your case, your agile endeavor is in a heap of trouble.

The goal of this article is to shed some light on what to look for in an agile professional. There are a lot of emerging titles, certification acronyms and different frameworks out there. It is also easy for the non-initiated to see scrum masters and product owners as nothing more than traditional project managers with a fancier name.

The situation is not helped by the fact that many companies who ask for agile personnel have a limited understanding of what agility is, believing it to be simply a new delivery method involving only superficial changes.

I hope the following will shed a bit of light on how best to approach hiring agile professionals.

What is Agile again?

Agile is not a delivery framework (although there are agile delivery frameworks).

It is not a management method (although several management philosophies such as Management 3.0, Tribal Leadership, Teal organizations and the like are arguably agile).

Agile is a mindset that involves:

• Being adaptable in the face of changing contexts.
• Putting a focus on the need of the clients and users.
• Delivering tangible value continuously or in short bursts.
• Being able to experiment, learn and improve in very short cycles.
• Trusting self-organizing professionals, and being worthy of that trust.

There is more to it, but these are the main characteristics.

Finding a good agile professional is first and foremost about finding someone with the right mindset. Certifications and even years of experience should be secondary considerations.

What you should stop doing now

There are two habits that seem to be standard in recruitment that does not work when you are looking for agile personnel. Using these practices will simply cut you off from the best candidates. Those are:

• Copy-and-pasting typical project managers requirements to agile job posting
• Pre-filtering by credentials and years of experience

Agile approaches are product-oriented, not project-oriented. That difference alone is a huge deal. If a recruiter is asking for an agile project manager with an MBA, PMI-PMP, and a decade of experience in being accountable for delivered requirements, there are two possible explanations: either your organization is doing A.I.N.O. (Agile In Name Only) where it’s business as usual with agile nomenclature slapped on top, or the recruiter has no idea what he is looking for.

Many companies get lured in the agile movements by promises like “twice the work in half the time”, without any understanding of the changes required for that to be remotely possible. You end up with accountability without responsibility or authority, a traditional project-based approach based on predictive planning, inappropriate funding scheme, matrix-based environment, etc. It’s business as usual, but far from what agile is about.

For agile personnel, environments like these are a nightmare: typical project management jobs with a layer of unrealistic expectations and opposition to change added for good measure. Candidates who have experienced working in true agile settings will flee these types of openings.

What should I ask for?

Asking for the correct agile role for the situation shows that both the recruiter and the hiring company know what they are looking for. Please keep in mind that these roles are full-fledged jobs, and not meant to be tacked on a more traditional role (like business architect/product owner, or the ever popular project manager/scrum master), especially since the duties of these roles are often conflicting.

Product Owners are the people in charge of a product. They are different from traditional Product Managers, as product owners work directly with the team while traditional product managers are higher up the hierarchy. Products Owners do not manage projects, they make decisions on the product (like prioritizing work) and represent the interests of the stakeholders.

Scrum Masters are support people in some frameworks. The term originated with the Scrum framework, but nowadays it covers the support role embedded in an agile team. Alternative names for this role includes facilitator, team coach or, team support. They have no authority over the team, except to enforce the framework. Their role is to keep team members working at peak efficiency by removing impediments, building the team culture, smoothing relations with other teams and doing some administrative work. The skill set of a good scrum master tends to be quite different than for a good project manager, as the role is completely different.

Agile coaches are, like the name says, coaches. Their role is to help with agile transitions, training, and coaching agile personnel. They set up new teams, they are advocates for agility and they bridge discussions between agile groups and other groups within the organization. While many of them started as scrum masters, those are two different roles with the coaching role requiring more solid experience.

Agile business architects, agile enterprise architects, and agile software architects are like the non-agile version of these roles but who are agile-trained and who can produce work especially designed for agile teams. In a nutshell, that means work designed as small independent chunks, with little dependencies, aiming at producing a minimum viable product quickly and then building on that.

Agile managers refer to any type of senior managers with the training and experience required to work in an agile organization.

You can note the glaring absence of an agile project manager role. Such roles occur when a non-traditional organization wants to label a project “agile” without the necessary associated change to the environment.

What should I look for in candidates?

Unless a candidate has some experience working for organizations that are well-known for being agile, his resume will sadly give you little information about his agile expertise. You are looking for someone with the right mindset, and who can display a solid knowledge of agile.

Agile expertise

The best way to measure agile expertise is to talk to candidates, or even better to research what they have written. Presentation letters, blog post, white papers, slide decks or video presentations are all good sources, as long as they are not simply reports of someone else’s work. If no such documentation exists, then it might be interesting to ask the candidates to explain in writing either their approach handling a certain situation or a specific concept.

Agile experience

You might find it surprising but a large number of agile professionals have never had the chance to work in a fully agile environment. Most have been working in hybrid environments, often with little more than agile labels on a traditional framework. Having more experience in a purely agile environment is a big plus.

In the same vein, a lot of traditional experience (especially in project management) is not necessarily a good thing. The dynamics in traditional and agile work are very different, and leftover habits from a traditional dynamic can hamper greatly your agile efforts. Still, if your organization is starting a transition and is not yet ready for it, having someone able to work in a hybrid way might be a boon.

Keep in mind also that an agile expert will gain experience rather quickly. In just six months, an agile team will have delivered usable value a dozen times, or even more if they use continuous delivery. In a traditional setting, a team will have delivered maybe once in the same amount of time. While delivery isn’t everything, these events always bring a fresh crop of unexpected issues that need to be addressed ASAP. Have your candidate talk about those events. It will be revealing.

What about certifications?

Let’s not be coy about this one: certifications are products, or part of products, offered by training organization in order to make money. Very nearly all of them cover a framework or another. My advice is: do not let those (often virtual) pieces of paper define your selection for a good candidate. Many good agile candidates will have learned through non-affiliated consultants and won’t have a costly certification to show.

That being said, there are a lot of different certifications out there and it can quickly become confusing. Many Agile professionals show their credential by stringing as many certification acronyms at the end of their name as possible.

The Scrum framework has by far the largest number of certifications. Those shown below are only the most frequently encountered. Other frameworks, like Disciplined Agile, also offer certifications, and some Lean frameworks, like Kanban, should also be considered if you are looking for an agile professional rather than specifically a Scrum professional.

As you can imagine, your candidates’ budget will be a limiting factor for certifications. Many agile experts will have both the knowledge and the experience to cover several of those certifications but are unwilling to pay for the seminars, the exams and, in many cases, the costs for the continuous training and the periodical renewal fee.

Buckle up, we’re going to see quite a bunch of letters.

Scrum Master certifications

CSM: Certified scrum master from Scrum Alliance. Like all Scrum Alliance certifications, this one requires attendance at a costly 2-days seminar. This is by far the most common certification out there.

PSM: Professional Scrum Master from Scrum.org. Granted after a somewhat difficult online exam. Comes int three tiers (PSM I, PSM II and PSM III) of increasing difficulty.

SMAC: Scrum Master Accredited from International Scrum Institute. Granted after an online exam. This is the lowest cost solution for certification, making it very popular in some regions of the world as well as with people who have been mentored or trained by experts not affiliated with Scrum Alliance or Scrum.org.

Scrum Product Owner certifications

CSPO: Certified Product Owner from Scrum Alliance. Like all Scrum Alliance certifications, this one requires attendance at a costly 2-days seminar.

PSPO: Professional Scrum Product Owner from Scrum.org. Granted after a somewhat difficult online exam. Comes int two tiers (PSPO I and PSPO II) of increasing difficulty.

SPOAC: Scrum Product Owner Accredited from International Scrum Institute. Like the SMAC, this is the low-cost alternative.

Scaled Scrum certifications

SPS: Scaled Professional Scrum from Scrum.org. This certification covers the Nexus framework, which is basically a scaled version of Scrum.

SSEAC: Scaled Scrum Expert Accredited from International Scrum Institute. Covering the “Scrum of Scrums” classic approach to scaling (rather than the newer Nexus, LeSS or SAFe).

Other Scrum certifications

CSP: Certified Scrum Professional from Scrum Alliance. This is a second-tier certification that requires either the CSM or CSPO in addition to 36 months of experience and PDU-like learning credits.

CST: Certified Scrum Trainer from Scrum Alliance. This certification is required to give official Scrum Alliance trainings leading to certification.

STAC: Scrum Trainer Accredited from International Scrum Institute.

LeSS Practitioner by the LeSS company: LeSS is a framework for scaling agile software development over several teams. It is based off Scrum.

Disciplined Agile certifications

Disciplined Agile is an agile framework, but of a much larger scope than Scrum. It is described as a decision-making framework and cover aspects of the entire business, not just software engineers. Disciplined Agile is also one of the scaling frameworks (along Nexus, SAFe and LeSS). As a framework, I believe it to be the most complete one available, but a very difficult one to get into for the uninitiated.

CDA: Certified Disciplined Agilist from the Disciplined Agile Consortium. This is the basic certification, earned after a solid online exam covering a large number of agile techniques usable across the company. A CDA is also able to act as Scrum Product Owner or Scrum Master.

CDAP: Certified Disciplined Agile Professional from the Disciplined Agile Consortium. The advanced Disciplined Agile certification, requiring verified extensive experience with the framework and a difficult exam.

SAFe Certifications

SAFe is a lean-agile scaling framework based on Scrum, but it covers the whole chain from the portfolio level all the way down to team level. It is popular with many large companies who can see their existing structure in SAFe. It is very controversial with many agile pundits for the very same reason.

SA: SAFe Agilist by Scaled Agile Inc. Aimed at executive, managers and change agents.

SPC4: SAFe Program Consultant by Scaled Agile Inc. Aimed at external consultants who are brought in to help with a transition toward SAFe.

SP: SAFe Practitioner by Scaled Agile Inc. For project and product managers, software developers and other people involved in a SAFe organization.

PMPO: SAFe Product Manager/Product Owner by Scaled Agile Inc. Aimed at product owners, product managers, Product line leads, program managers and business analysts.

PMI Agile Certifications

PMI-ACP: From the prestigious Project Management Institute, the Agile Certified Practitioner certification covers many frameworks such as Scrum, Kanban, Lean, extreme programming (XP) and test-driven development (TDD). It offers three advantages: its certifying entity is well recognized, it must be maintained through continued training and it’s far more versatile than specialized ones.

Agile Coaching certifications

CEC: Certified Enterprise Coach. Aimed at coaches, it requires them to have sufficient experience in addition to holding the CSP certification for at least a year.

CTC: Certified Team Coach. Similar to the CEC, but aimed at people specialized in working with agile teams rather than the whole enterprise. Requirements are a bit easier than the CEC.

SCAC: Scrum Coach Accredited form International Scrum Institute. Attainable with only an online exam and no other requirements. This certification is a bit lacking by itself and says little about the experience of the coach.

CDAC: Certified Disciplined Agile Coach from the Disciplined Agile Consortium. This is the highest level of Disciplined Agile certifications, requiring lots of involvement and a review panel.

There are others. So many others.

If I missed your favorite certification product, feel free to mention it in the comments.

The TL;DR version

When looking for Agile personnel:

1. Stop asking for agile project managers with non agile credentials
2. Demonstrated expertise should trump certification
3. Agile experience, even a shorter one, should trump long non-agile experience
4. If you are confused by all the certifications, just don’t ask for any and leave it to the candidates to justify theirs. That’ll teach them!

Maurice Lefebvre

I am a futurist, system thinker and organizational transformation expert, dedicated to easing our transition into Society 5.0. I am available as a speaker through the think tank Hivernité (www.hivernite.ca) as well as a trainer and organizational coach through Moabi Formations (www.moabiformation.com).

www.hivernite.ca

The idea that we live in a VUCA (Volatile Uncertain Complex Ambiguous) world has been making its way into the business world for a few years now. It has been used to measure how stable (or not) and known (or not) any given context actually is.

It is human nature to seek stable and known environments, often to the point of blinding ourselves to variability in order to maintain an illusion of stability. By ignoring the variability that is there, we are not doing ourselves any favour. It simply means that we will be woefully unprepared when our artificial bubble of safety bursts under the pressure.

Since it is natural for us to seek stability, living in a VUCA world requires some training. In this post I will show you how we can train for high VUCA environment in business using an old human training tool: games.

Translating games to the workplace

Games, by nature, have very limited stakes. Real-life situations have much higher stakes and shouldn’t be approached lightly.

To use a radio metaphor, the problem with high VUCA situations is that the noise to signal ratio is very high. There’s so much information that need to be tracked and understood that we lose the significant information (the signal) drowned in all the insignificant information (the noise).

High VUCA situations can be unnerving and confusing because of the sheer amount of noise. The more noise, the less we understand a situation. The less we understand, the higher the stress. High VUCA environments are like high VUCA situations, just longer-lasting. We can say that working in those environments simply requires nerves of steel, but that’s just unfair. Those nerves of steel would requires to be sustained almost indefinitely, something human beings are not build for. We can be good with short burst of stress, but extended bouts grinds us down.

While gaining control of high VUCA environments might never be possible, a clear head and a sense of confidence build through experience in the face of chaos will give you the right tools to react appropriately. Even in very high VUCA situation there are some dynamics that can be observed and understood, if you know what to look for.

That’s where games are useful. They teach you to learn to look for signal amongst the noise, in chaotic but ultimately safe conditions. By teaching you to recognize signal, they help cut through stress-generating noise.

Let’s start with something simple.

Low VUCA training with chess

The time-tested game of chess is the ultimate low VUCA simulator. In this 1400 years old game, two players measure up against each other using their wits and their predictive ability to win. With no randomness and a high enough complexity as to be unsolvable, chess is seen as a great equalizer (with only Go being better at it).

Chess is a low uncertainty game. The objective of the game never changes: checkmate the opponent’s king by placing it under an inescapable threat of capture. Players will always take turns consequentially. Pieces always behave the same way from game to game.

Chess is a low ambiguity game. The rules for the game have been very stable for the past 1200 years and are well-known to players. Chess is a perfect information game, meaning that no part of the game is hidden in any way. Both players have access to the exact same information at any given time.

Chess is a low volatility game. The first two sets of characteristics make chess a predictive game, meaning that players will actively try to predict an influence their opponent’s future moves. While the game dynamics will change during play, good players will see these changes coming and will make decisions that will influence those changes.

Chess is a medium-low complexity game. There are 1043 legal positions in chess, making the game practically impossible to solve (to know the perfect series of moves to win every game). The interactions between pieces, however, are well known, never changes and are devoid of randomness or surprises. For all of its legal positions, this makes the game just complex enough to keep things interesting, but no more.

Players takes turn trying to create irresistible choices for their opponents, choices that cascade into one another to weaken the opposing player, trapping him a little bit more each time by removing his options, by capturing his pieces and maneuvering him using the board’s edges and your own pieces. The skill of the players at out-predicting and out-maneuvering each other is all that matters.

In business terms, this would equate to always making the same product following the same process, with no variance for seasons, no variance for raw material price or availability, no variance for customers habits or loyalty. Predictive planning is easy in those environments, and seeking efficiency at all costs will not expose you to much risks. But honestly, do you know many industries like that? Even something as stable as garbage collection suffers for seasonality (well, at least here in Canada) and human factors.

Chess is a great game and a valuable tool to learn simple causality and predictive planning. But the world is not neat like a chessboard. The rules are not always clear, situations change often and to a varying degree, and other players lie and cheat. This is why predictive planning — the main planning strategy of most businesses — fails so often.

To get a better understanding of today’s business world, we need to understand semi-random dynamic causality. We need to learn to analyze constantly. We need to learn to rely on what we see rather than what we think we know.

We need Cosmic Encounter.

High VUCA training with Cosmic Encounter

Cosmic Encounter is a science-fiction strategy game that has been very influential in the field and remained popular ever since its first publication in 1977. With asymmetrical gameplay, near infinite combination of gameplay elements, randomness and the ever-present human factor, no two games of Cosmic Encounter can ever be the same.

This game is a great high VUCA simulator as the number of varying game elements and the rhythm of those variations create some short-lived stable opportunities amidst bursts of volatility. Each player will be affected differently by those, meaning that every player must remain aware of his current situation and infer the situation and possible strategies of other players based on incomplete information. Predictive planning is bound to fail, and trusting in chaos is suicidal. Cosmic Encounter is about the opportunistic capitalization of emergent short-term strategies.

The game has a simple set of rules and a simple goal: players compete to build 5 space colonies on planets outside their solar systems. Any pretence of simplicity stops right there however, as pretty much everything other aspect of the game introduce some variance and unknowns.

Cosmic Encounter is highly uncertain: The game can be played by 3 to 5 players (up to 10 in some versions). Each player controls one (well, usually) alien race with its own unique (again, usually) power that breaks the rules in some way. Each player has a (variable) hand of cards, each influencing the game in some way. Plays in the game are either random, semi-random or non-random (depending on type) and their randomness can follow a variable rhythm.

Cosmic Encounter is highly complex: Alien powers, Encounter cards, Artifact Cards, Flare cards, alliances and cosmic events (such as cosmic quakes and hazards) can all affect each other and several of those can stack or cancel one another. Players bring their own personalities and relationship in the mix.

Cosmic Encounter is highly ambiguous: The basic rules, the situation on the board and the cards in play are shared information available to all. But each player has a variable number of cards in hand, which are not revealed to other players until they come into play. Nothing a player says is binding, so misinformation abounds. Even pleas for help can turn out to be traps.

Cosmic Encounter is highly volatile: Technically, the game can be won within a single turn although I have never heard of anyone pulling that off. The current dynamic of the game can (and will) change dramatically with the play of a single card, or more frequently by several cards played by several players at once in an insane combination that no one could ever see coming.

Cosmic Encounter has the right balance between method and madness. It teaches you to analyze situations quickly and accepts unknowns. It teaches us not to rely on anything for long, but to capitalize on fleeting opportunities whether you created them or saw them emerge.

A good Cosmic Encounter player is used to cutting through noise and looking for what pass as signal at this very moment. It can’t turn a VUCA situation into a walk in the park, but it will help revealing where you can exert influence on the situation, and gives you the confidence to do so.

Enlightened decisiveness in the face of chaos, and the readiness to adjust when needed. It might not be full control, but it’s certainly the next best thing you can have.

Games from low to high VUCA

Chess and Cosmic Encounter are situated at the extremes of the scale. Between them are a variety of fun games that can introduce you to higher and higher VUCA contexts. Here’s a few examples:

Texas Hold’em poker is a good low-medium VUCA game and a nice introduction to some uncertainty and volatility (and now you have a good excuse to play).

Pandemic is a medium VUCA game where teams of players must cooperate to save the world from highly contagious plagues. Low ambiguity and very high volatility means that poorly managed situations can become catastrophic in a flash.

Fluxx is higher VUCA than the first two, but it simplicity and sheer randomness limit its educative side. In Fluxx (or any of its dozen or so variants) the game starts with ridiculously simple rules (Draw one card. Play one card) and no victory conditions. The game’s rules will evolve and change constantly during the course of play.

Games are safe microcosms

Changing one’s mindset from a stable and predictable environment for a volatile ambiguous one is quite the step. Games can be great tools because the stakes are either limited to the game or have limited real world impact (like gambling with a set budget that you expect to lose).

Instead of risking your career and your company’s assets on an instinct and experience that might not be appropriated to your new context, games help you make that transition and learn the new dynamic at little cost.

Don’t be fooled into thinking that games are only meant for children. The right game can be an amazing tool for learning, in addition to being both fun and social.

Game on!

Maurice Lefebvre

I am a futurist, system thinker and organizational transformation expert, dedicated to easing our transition into Society 5.0. I am available as a speaker through the think tank Hivernité (www.hivernite.ca) as well as a trainer and organizational coach through Moabi Formations (www.moabiformation.com).

www.hivernite.ca

But it does not have to be that way. Very large companies such as Google, Apple, GE, Lockheed-Martin and so many others make good use of intrapreneurs to innovate in a manner similar to startups, without as many risks.

Intrapreneurs share the thirst for exploration and strange waters that their entrepreneur cousins have, while also enjoying breaking the rules of the calcified organizations they work for. Back in the early ’80s, Apple’s Macintosh team took up the pirate imagery and followed the maxim “Better to be a pirate than join the Navy”. That same renegade spirit inhabit intrapreneur teams everywhere to this day.

What are intrapreneurs and why should you care?

Intrapreneurs are people inside an organization who act with the creative freedom and low red tape environment of startups. Intrapreneurs are most often used as R&D teams, but the mindset can be powerful even elsewhere in a company.

Any kind of companies can use intrapreneur groups. The idea is to create a semi-autonomous cell unaffected by the processes, politics and scrutiny of the rest of the organization. In essence, intrapreneurs give any company the best aspects of a startup. It is no wonder Lockheed-Martin maintains its Skunkworks experimental group since the ’60s despite following a very traditional manufacturing model for the rest of the company or for GE to swear by their FastWork teams to drive innovation while the rest of the company still follow rigid Six Sigma principles.

Find the right people

Not everyone can make a good intrapreneur. Most people who function well within a large company will have trouble operating as an intrapreneur, even if they believe otherwise.

The characteristics of a good intrapreneur are similar to those of a good pirate:

They crave freedom and brotherhood. Some people need to make their own way. Independence is a defining trait of an intrapreneur, but lone wolves will be a problem. You need to identify creative troublemakers with a knack for gathering like-minded people. They are your pirates.

They enjoy chaos. Good intrapreneurs focus on results, experiments and thrive on changes of plans. Routine bores them.

They’re not afraid to fight. Intrapreneurs will constantly have to justify their existence, fight for budget and even debate approaches within their group. Sparks will fly. That’s good. They need that energy.

They sail into storms laughing. Intrapreneurs will constantly face challenges, sometimes insurmountable ones. It is not enough for them to be unafraid of these challenge. They need to actually enjoy rough waters.

They deliver. For all their freedom and chaos, a pirate who does not follow the rules or does not deliver will end up marooned somewhere. Same goes for their captain: a captain who does not deliver on riches will face an abrupt change in management.

For many a manager, putting together a team of intrapreneurs will feel like gathering all the nightmare employees. Whoever will be their point of contact with the rest of the company needs to share at least some of the characteristics of intrapreneurs.

In all cases, avoid imposing the entrepreneur lifestyle to someone who doesn’t want it. Many workers today are creature of habit, order and comfort.

Give them what they need

Above all, pirates need freedom and the open sea. Your intrapreneurs are no different. You cannot force your intrapreneurs to deal with the typical processes and hierarchy of your company. They need freedom and space to operate.

Funding the team is an issue. As long as the team can deliver for the budget they are granted, they should be left alone. However funding the team in the traditional way will draw the attention of finance people. Finance requires order, has a low tolerance for the necessary chaos of the innovation process. If the intrapreneur team is in itself an experiment, then I recommend funding it off discretionary budgets.

It can be a good idea to set up the team in a different building so they are cut-off from unwanted attention and to make it very clear that the team exists in a pocket universe of sorts. It helps them focus and detach themselves from corporate habits that kill innovation. It also removes them from the scrutiny of envious co-workers, scheming executives and overzealous auditors. You do not want to attract the corporate immune response. The natural enemies of intrapreneurs are jealous people and bean-counters.

Finally they need to understand the best approaches for this kind of work. Agile thinking is highly recommended as it gives the right mindset to thrive in such an environment. Lean Startup is a lightweight exploratory process framework that fits perfectly intrapreneur teams as it mixes the chaos of exploration with just enough structure and discipline to produce valuable data and tangible results. Training in either, or better in both, does not take much time or budget. However, while these theoretical frameworks can be learned quickly, the real learning will be done in practice. Coaches are a good way to help new teams adjust to these radically different ways of working and can be a good investment to help a team pick up steam quickly.

Make them suffer a little

While it is important to give the team what they need, there can be a big difference between want and need. Intrapreneur teams do not need a nice office, brand new equipment or infinite budgets. Do not be soft on milestones either: People work better when some constraints are in play. They need to be creative to deal with these constraints and still produce what you ask of them. For having lived it a few time, I believe that the ambiance provided by squeaky chairs, second-hand tools and leaky pipes help feed the roguish adventurer vibe you will find in many startups. Think of it that way: If your people want to play pirates, they need to learn to live like pirates, scurvy and all.

It should not come as a surprise: the theory of constraints tells us that a reduced number of small limiting factors help us focus and achieve more. The key is to be able to identify constraints who will act as propulsors for the team and those who will be useless inhibitors.

Don’t pamper your intrapreneurs, but don’t torture them for no reason either. After all, you want them to succeed. Setting ridiculous deadlines and goals designed to be beyond the team’s reach, constantly shuffling the team’s composition, micromanaging the team or forcing them to multitask are not helping them in any way. These constraints only help an insecure incompetent boss feeling self-important.

Making them suffer a bit has the additional effect of deflecting attention from your intrapreneurs. Their position, even if they benefit from special treatment, will not seem enviable. Of course, your pirates won’t have it any other way.

Manage the system, not their work

It is extremely important that you do not try to manage either your intrapreneurs or their work. Let them self-organize. If needed, a training on agile thinking will teach them how.

What you need to do is create boundaries. Set some rules. Grant them a fixed budget and some milestones. Schedule regular presentations so they can show their progress. Beyond that, cut the red tape and get out of their way. Remain available in case you are needed.

These boundaries and rules create a platform to support their work. Change the platform if needed, but don’t bend those rules. Projects are expected to go over budget or to require more time. Innovation teams are usually under far more scrutiny than others and have to defend their very existence. While other groups can afford to be late or go over budget, your intrapreneur team cannot.

Again, the analogy with pirates can be useful here. Privateers for examples were pirates sanctioned by governments through letter of marque, legitimizing their activities as long as they restricted themselves to attack only enemy ships. The Republic of Pirates that thrived in Nassau in the 18th century is another example of how simple boundaries can allow highly individualistic teams to work for a common goal.

It is possible that at first your team will miss a milestone simply because they are not used to self-organizing efficiently and respect constraints. The team needs to understand that those light constraints are the price to pay for their level of freedom.

Give them clear milestones

An intrapreneurially team is not an out-of-view playground where people and money disappear to, hopefully, come out with something useful. Make sure intrapreneur are accountable for their work. “Success” in a team who’s devoted to experimentation is not necessary a functional product. Sometimes the only result will be learning quickly that an idea should be discarded.

Intrapreneur are accountable to answer three simple questions, who act as milestones. Those answers are “yes/no”, backed with explanation. A “no” to any of those questions means that this particular endeavour needs to stop right away.

It is important for the intrapreneurs to focus on one of these questions at a time, and in the right order.

Is it feasible? is the very first question to answer. The timeframe to get that answer must be kept relatively small, from two to eight weeks. “Yes” requires the team to have some sort of working proof-of-concept prototype. If after two months there is no prototype, it’s time to look elsewhere. That constrain can be adjusted but I advise to keep it tight.

Is it viable? Making a product commercially viable is the goal of a business. A process that creates diamonds from seawater in “only” 5000 years, a 3000$ disposable camera, an environmentally-friendly cleaning product using a manufacturing process with the carbon-footprint of a small country or super-silent break pads made of material that can only be mined on a asteroid can be valuable from an academic point of view, but are not viable from a business standpoint. This second questions should arrive quickly after the first.

Is it scalable? or can we turn a profit with it? Unit viability does not mean that it can be produced in enough quantity to be profitable at the business level. Scalable means different things for different businesses: an artisan bread-maker and a disposable plastic cup manufacturer will have wildly different interpretations of the word. But in both cases the question remains valid. If the business is not able to produce enough at a reasonable cost to turn a profit, then even the best of ideas is nothing but dead weight. Again, keep the time between the second and the third milestone question short.

It might sound counter-productive, but as a business you want your intrapreneurs to answer “no” to these questions. Each “no” is potentially millions of dollars saved on a product that will not be profitable. Every time they cannot answer “no” to any of those questions, then you have good potential product.

Once you get a “Yes” to each of these milestone questions, then it is time for them to build a complete prototype, so the kinks can be identified and smoothed, and potential risks clearly identified and remedied before actual production starts. The time required for this milestone will vary greatly depending of what you are building.

The time to sail is now

Intrapreneur teams are cheap and easy to set up, as they should. This means that there are very few risks in experimenting with them. Intrapreneur teams do not start perfect, and aside from Agile thinking and the Lean Startup process, there is little formal training that can teach them to run efficiently. Most of their processes will be learned by doing, so the sooner they start the better. There is no better time than the present.

Maurice Lefebvre

I am a futurist, system thinker and organizational transformation expert, dedicated to easing our transition into Society 5.0. I am available as a speaker through the think tank Hivernité (www.hivernite.ca) as well as a trainer and organizational coach through Moabi Formations (www.moabiformation.com).

www.hivernite.ca

Still, we see many of our corporate clients dismiss the idea of creating a safe culture, lest their employees would have free reign and would avoid accountability for their actions. Employers would lose control! Chaos and pandemonium would ensue!

The problem is that safety is often confused with immunity or absolution. In an unsafe environment, where failure leads to witch hunts and retributions, it can be easy to make that jump.

In this post I will go into what safety is and how it differs from immunity and absolution. The idea of safety is not … ahem… “a hippy concept not fit for a real business”. It is, in fact, a powerful tool that can be leveraged to spur innovation, excellence, engagement and ownership.

To create a good work culture, safety is not an option. That’s why Joshua Kerievsky lists make safety as a prerequisite as one of Modern Agile’s guiding principles. That’s also why Jurgen Appelo makes it a central argument in his books Management 3.0 and Managing for Happiness, and why writers such as Daniel Pink, Dave Grey, Frederic Laloux, Lisa Laskow Lahey and Robert Kegan spend a large portion of their arguments on it. And yet, not one of them argue for a culture of immunity to consequences or absolution.

A culture of safety

Let’s start by defining what is a culture of safety.

In a nutshell, a culture of safety is a culture where members of the team do not have to hide for fear of retribution because of who they are, what they think or what they do.

In a safe culture you will see people readily admitting to failures or mistakes. As a result, remedy to problems happens much faster and are much more efficient since no ones tries to save himself. Education about those issues can be shared across the company, raising awareness and reducing the risk that the same mistake will happen again.

In a safe culture, people will speak their mind and ideas will be debated, leading to better solutions. “Sparks must fly”, says James M. Whitehurst, CEO of Red Hat, in his book The Open Organization. A bit of friction while debating ideas is a good sign that people care about the subject and want the best outcome. But stay vigilant that those debates do not degenerate in spiralling arguments. Still, an occasional spiralling argument is much better than no argument at all.

In a safe organization, people feel safe to be transparent about their strengths and weaknesses, making it easier to get help working on weaknesses and raising one’s overall usefulness to the organization.

As desirable as safety might be, no organization will reach that state naturally. It requires the right conditions, time and a concerted effort. The very first step is actually the hardest one to take: get rid of the blame.

Stop the blame

When something goes wrong, it is important to react to it. React. Note that I haven’t said either how to react nor who should react. What is important is that there is a reaction to something going badly.

In a blaming culture, the first reaction is either finding out who is to blame or making sure someone else will be blamed. Neither reaction addresses the problem, nor do they lower the chances of the failure happening again. The goal in this scenario is for individuals to protect themselves.

In a blameless culture, there is little need to react with self-preservation. The reactions tend to be swifter, as no one is trying to cover their tracks. The reaction is first focused on fixing the issue, then making sure it does not happen again.

Etsy has such blameless culture, where it is common for employees to receive a communication along the lines of “I messed up. Here’s what happened. Here’s how we reacted. Here’s what to watch out for”. They even have a good-natured annual three-armed sweater award given to the most surprising failure of the year, awarded in a ceremony and accompanied with the testimonies of the people involved on how they handled it and what has been learned. The goal here is not to humiliate them, but to spread lessons learned and raise awareness.

The only purpose of blame is to bring fear of consequences, from share to loss of employment.. It is no wonder then that in a blame-based environment, many employees opt to never try anything, to do the strict minimum, and often waiting until they get direct orders from a manager so their tracks are covered and they can divert the blame toward the manager when the results end up being unsatisfactory.

React appropriately

There are three types of failures: Smart failures, accidental failures and negligence failures. Each comes with their own type of reactions. These reactions are consequences of sorts, but with the aim of making things better.

Smart failures are, as far as failures go, the type you should aim for. If you are careful with your actions, including your experiments, you should plan to limit the impact of a possible failure, discuss it beforehand with people who might be impacted, act carefully and react swiftly when the worse happens. If you approach experiments in this way, then failure can be turned into a valuable learning experience for the whole organization. Someone who is able to experiment, fail and handle the recovery properly is an asset that should be celebrated. Blaming people for a smart failure would be absolutely counter-productive.

Someone who fails accidentally, through an oversight, a lack or knowledge or sheer bad luck should own it, and act swiftly to help with the recovery. Accidental failures happen all the time and should be seen as part of doing business. When an accidental failure happens, review what happened, derive some action points to help reduce the chances it will happen again, and move on. Again, blaming would not improve anything.

In either case, if you are responsible for the failure, own your mess and be part of the effort to clean it up. If your are not, avoid assigning blame as it does not bring any value except perpetuating an unwillingness to try for fear of failure and blame.

Failures caused by sheer negligence, pig-headedness or straight malevolence should be dealt with seriously. There should be consequences for these kinds of failure, but again they are not about blame. Often, having a talk with the person in a safe space will reveal some issues that can be addressed so this does not happen again. At other times, especially for a repeated offense, the best course of action might be getting rid of the bad apple.

Or not: Some deliberately developmental organizations such as Next Jump have a no fire policy and will salvage you no matter what. Still, we are not arguing for either immunity or absolution: follow-up actions, or consequences, are part of the deal.

Working with self-organized groups makes this system easier to use. Teams share success and failure and even more, they share effort. When an organization wonders how it should react to a situation, the best course of action is to ask the team involved. Disaster recovery, lessons learned and recommendations as well as how to react to the person at the core of the problem can all be dictated by the team.

Safety isn’t just about you

When Joshua Kerievsky developed Anzeneering in 2014 — his approach to a culture of safety — he described this work culture as something your are responsible for upholding rather than something that should be owed to you.

It should be every individual’s responsibility to ensure that coworkers are safe from a bad environment, that your organization is safe from your actions, that users are safe to use the work you produce, and so on. Nothing about that mindset is about making yousafe, it’s all about making others safe. You become protected too when the mindset spreads across the organization.

That is an amazing approach: look at safety as a gift you freely give to others.

Towards a culture of responsibility and ownership

A culture of safety is not meant to exist by itself. It goes hand in hand with a culture of responsibility and ownership.

Modern Agile puts make safety as a prerequisite to remove the fear of failure and blame we so often see in organizations. As we’ve seen, fear leads to an understandable lack of desire for ownership and responsibilities. Without this fear, we are better able to reach our potential.

The other three principles of Modern Agile are the key to unlocking that potential.

Deliver value continuously forces us to revise how we approach work. To be able to deliver any kind of work in a continuous fashion, we need to divide it in smaller, independent chunks. That approach is very important. Smaller chunks means that if we fail or miss the mark with a chunk, the damage remains small and the issue can be resolved quickly. By making these chunks independent, we make sure a failure will not spread or contaminate other chunks (ours or somebody else’s), thus limiting the impact of the failure. Small, self-contained chunks drastically reduce overall risks by making each failure insignificant. Without fear, and with insignificant risks, experiment and learn rapidly becomes a very powerful tool. It allows us to figure out solutions empirically, work out kinks to provide better quality and stimulate innovation. New discoveries are far more often the result of failed experimentation than of planned design.

With safety from reprisal and blame, with work habits that reduce the risk and the impact of failure and with constant learning from practical experimentation, we make people awesome by giving the environment they need to be stimulated by what they do, to take ownership of their work and to become the assets everyone, deep inside, wish to be. In turn, they can see it as their responsibility to spread that culture and help newcomers feel safe enough to participate and grow.

The Modern Agile logo is a wheel. I believe that to be very deliberate: each aspect builds into the next one and keeps the whole wheel turning.

Too rosy a picture?

In this blog, we saw what is intended with a culture of safety. Put in place properly, it can propel any organization and its members to new heights.

However, it is possible for the ideals of such a culture to be corrupted. Toxic safety is a very real danger, and one we should watch for. We will explore its forms in my next blog post: When safety turns toxic.

See you then!

Maurice Lefebvre

I am a futurist, system thinker and organizational transformation expert, dedicated to easing our transition into Society 5.0. I am available as a speaker through the think tank Hivernité (www.hivernite.ca) as well as a trainer and organizational coach through Moabi Formations (www.moabiformation.com).

www.hivernite.ca

We often had conversations and debates, trying to learn from one another and finding ways to overcome roadblocks. During one of those conversation one of the coaches, who was at that client for several months at that time, was arguing strategy until a more senior coach, who was visiting us, said:

“You’re pickling. I’m not hearing you, I’m hearing your client. Their excuses have become your excuses. You are an agent of change, but you are adopting their mindset. You have been marinating in their juices for too long.”

At the moment it made me smile, but it also made me think. Was I pickling? Of course I wasn’t (I was) and I was certainly aware enough to realize if I’d ever start to pickle (I wasn’t). I felt full of certainties that were not based on any experimentation. To me, that is a clear indicator that something was amiss. So, true to my values, I had no choice but to conduct some experiments.

I start paying attention to the words used by coaches around me and by myself. Two words stood out: “context” and “reality”. “Reality” is a red flag: when someone does not want to change, variations of that word get tossed around a lot — “let’s get real”, “in real life”, “in our reality”, etc.. While “context” usually describes something external (like the market), “reality” ends up describing internal organizational impediments or culture. I noticed that coaches who were just beginning working with the client used that term far less often than those who were there the longest.

This let me to observe the differences between newer coaches and those who had been with the company for a long time. I started bringing some specific conversation topics to elicit “pickled” responses. I was comparing what I thought was the right course of action and what other agile thinkers were saying. Over the next few months, I observed the slow pickling of every coaches. I had trouble evaluating my own pickling, but that was to be expected. It just meant that my experiments were not over yet.

After I ended my contract a few months later, I tried to throw myself in a context that was the complete opposite of what I had experienced during the previous nine months. I would love to pretend that I deliberately took more numerous but smaller commitments or devoured as many books as I could to expose myself to new ideas, but the facts are that I was thrown in the maelstrom of life in a startup company and I was spinning in all those smaller commitments and new ideas in a very chaotic fashion.

The ridiculous amount of new experiences in a short time de-pickled me very rapidly and made me aware of just how much I had pickled. It also made me realize exactly what being pickled meant and what I could do about it.

Why We Hire Consultants

External consultant of any type, including agile coaches, bring two things with them: EXPERTISE and PERSPECTIVE.

We are usually hired based on our expertise. We have knowledge and experience and our role is to either transfer that expertise to our client, use it to his benefit, or both. Expertise grows over time, as we learn new things and put them to practice.

We also bring perspective with us, and sometimes are hired especially for that. Perspective is the state of our understanding based on the number and diversity of our experiences. Perspective is dynamic and volatile: perspective absorbs new experiences easily and reframes itself constantly.

A good consultant needs a balance of both expertise and perspective. Expertise without enough perspective sets us on an unchanging path because WE KNOW. Perspective without enough expertise forces us into a very chaotic trial and error pattern. A balance helps us learn through controlled experiments.

We pickle when we are exposed to a limited number of contexts, limiting the diversity of our experiences. Our perspective adapts to this new reality and starts losing its flexibility. This is akin to tunnel vision, when we are so focused on one thing that we lose sight of everything else.

The Effects of Pickling

Pickling can be desirable. You want new employees to adopt your company’s culture, processes and dynamics, and that is done by pickling. The new employee needs to soak in your company for a while before he becomes truly “one of us”.

For an external consultant, that is dangerous. Since perspective is half of what we can offer, losing it to pickling greatly reduce our value. The worst is that we pickle without realizing it.

Many clients argue with me that they want a consultant that really understands their context and their realities, so he can assist them better. I do not agree with that. Without enough perspective, we end up really bringing only a small subset of our total expertise that fits with the clients current reality.

An external consultant should not be a yes man. It is our duty to challenge what the client is doing, not necessarily to change it but to make sure he understand why he is doing things this way. That understanding will expose him to new perspectives now, and allow him to sense when a situation is evolving in the future. If we lack perspective, we are not able to do that.

What Can We Do About It?

The prevalent business model in agile coaching is to send one or more coaches to a client, as full-time as possible, for extended periods of time. It provides steady income for the coach and makes the client feel safer by having an expert on-site. This is also the perfect scenario for rapid pickling.

When we realized those dangers, we, at Quantum Monkeys, started to re-evaluate our approach. At what speed is someone pickling? What’s the progressive loss of value for a client? How much effort does it take to un-pickle a coach after an assignment? How can we prevent pickling in the first place.

We found part of the solution by observing executives and life coaches: their business model revolves around a much smaller involvement and rely less on their own expertise than in developing their client by exposing him to new expertise and perspectives. It inspired us to remodel our coaching approach to a much lighter one, devoted to making our client ready to handle change and transition by himself. It also allows the coach to continue to be exposed to a large variety of contexts at once, reinforcing his perspective and providing a better value.

This approach to our services is not enough in all clients, so we developed other services as well. In our overall approach, the more time-intensive the service, the shorter its total duration will be. That way we make sure we do not stay long enough to pickle or, if we maintain long-term relationship, each coach will maintain several such relationships with several clients, keeping his perspective fresh.

Even internally we opted to make exposition to new ideas, debates, sharing experiences and placing people out of their comfort zone part of our culture.

What About Internal Coaches?

There is a trend lately of either hiring permanent agile coaches or bringing scrum masters to coach positions. This has some benefits, but also raises the dangers of pickling. Internal coaches will pickle quickly and lose perspective. They lose perspective, but still retain all their expertise. Since they are paid far less than external consultants and they stay with you to spread their expertise over time, they can be a very good trade-off.

Internal coaches can be moved around within the company with the hope of avoiding pickling, but since they still marinate in the company’s culture this strategy has limited success. I suggest that internal coaches could benefit greatly from having a coaching relationship with an external coach. A relationship that follows a model closer to executive coaching rather than the typical agile coaching. The cost is very limited, and the external coach will be able to challenge the assumptions of the internal coach and expose him to different points of views, thus limiting the impact of pickling.

The TL;DR Version

External consultants bring both expertise and perspective. Limiting their amount of new experiences by leaving them at a client for too long “pickles” them into the client’s culture and process, making them lose perspective. This can be fixed by shorter and more diverse assignments.

Maurice Lefebvre

I am a futurist, system thinker and organizational transformation expert, dedicated to easing our transition into Society 5.0. I am available as a speaker through the think tank Hivernité (www.hivernite.ca) as well as a trainer and organizational coach through Moabi Formations (www.moabiformation.com).

www.hivernite.ca

Please keep in mind that I’m not advocating the use of these tools above the ones you might currently be using. I am not disparaging any other tools either. Context is everything, and the right tool to use will depend on that context.

Modern Agile

Agility has been around for a bit over 15 years now. Modern Agile, presented by Industrial Logic’s CEO Joshua Kerievsky, acknowledges what has been done in the field in that time and the lessons that were learned. It moves away from frameworks, roles and artifacts to bring back agility to four principles to act as True North; the direction we should strive to keep.

Make People Awesome: “People” includes customers (yes, YOU have to make THEM awesome), employees, managers, clients. When you aim to make people awesome they will want to work with you or for you, and stay.

Make Safety a Prerequisite: Safety is the foundation on which everything else can be build. We protect people’s time, information, reputation, money, health and relationships. Without Safety people don’t dare to experiment, take any kind of risk or speak up against problems.

Learn & Experiment Rapidly: This is a combination of Classic Agile’s Continuous Improvement and of Lean Startup’s short experimentation loop. Making it safe to fail is a prerequisite here. Small, controlled experiments will help you learn fast at the cost of very little risk.

Deliver Value Continuously: To make people safe or awesome, value needs to be available for consumption. It is not about scaling up anymore, it is about rethinking how we architecture work so we can scale OUT, and deliver value continuously from everywhere without having to deal with dependences. The faster you deliver and the smaller your deliveries, the smaller the risks taken.

Because they are very high-level, those four principles can be applied to different domains from different industry. The goal of this approach is to foster a better culture and guide agility across the whole organization.

For more about Modern Agile see www.modernagile.org.

VUCA

The world is not only accelerating: it becomes more complex and far less predictable than ever before. That is why Context & Situational Awareness are essential survival skills to have. You need to know where you stand and understand what is happening around you.The changes are constant, so your efforts to understand your context should be constant as well.

VUCA (for Volatility, Uncertainty, Complexity and Ambiguity) is a technique developed by the US military to quickly make sense of any given situation. It helps soldiers figure out how much of a situation they might not understand as well as how fast and drastically that situation can change. It is a handy technique to master when everything around you can quite literally blow up in your face.

The VUCA approach has since been adopted in diplomacy and business. A high VUCA world is now seen as the “new normal” and that new reality is well represented in Quantum Monkey’s trainings.

Antifragility

In his book Antifragile: Things that gain from disorder, Nassim Nicholas Taleb suggests that the opposite of fragility is not resilience but antifragility.

In a nutshell, a system that is damaged by stress is fragile. A system that is not bothered too much by stress is resilient. A system that thrives and grows from stress is antifragile. The quest for efficiency and predictability has led us to fragile systems and a lot of self-delusion. We suggest that rather than trying to predict variability, let us make sure we can survive and benefit from the unexpected.

Again, the reflex of so many companies is to scale up, which creates more and more fragility by adding steps and work dependancies. It is trying to solve a tower’s instability by adding more, wider floors on top of the existing ones.

The key steps to resilience are relearning how to organize effort to scale out, removing system dependencies, partitioning work in much smaller independent doses and making sure one group’s problems do not contaminate others. Antifragility goes one step further by adding short learning loops and a strategy for constant, relentless improvements across the board.

Networked Organisms

In The connected company, Dave Gray brings the notion that complex systems should not be seen and designed as machines (efficient but prone to obsolescence and too complex to truly be controlled), but rather as networked organisms or ecosystems, to be grown and guided rather than controlled.

He presents Podularity, an organizational model that uses the notion of platforms to grant more leeway to connected groups and to enable a true form of distributed leadership without compromising the company’s safety

Platforms bring tools, services, expectations and boundaries in one system. Smaller systems (such as teams), called pods, can adopt the platform and are free to self-organize independently within the boundaries set by the platform. This grants a lot of freedom to these pods while controlling the risks. The learning done by any of these pods can improve the platform to the benefit of all. Even the catastrophic failure of a pod will positively improve the platform rather than contaminate other pods.

Not only does this approach help bring antifragility to a large organism (like a whole division or an entire company), but it can also be implemented at a small scale first and spread progressively across the organization.

Triadic Relationships and Networked Leadership

The Triadic Relationships of Tribal Leadership is a great approach to create those networked connections and balance relationships and the spread of information by making relations and conversations three-way rather than two-way affairs. It makes systems more resilient by improving transparency. It also fosters safety and fast learning, two key elements in making people awesome. Awesome people form into awesome groups, or tribes, that have a better attitude and can accomplish a lot more. The role of a leader is to create other leaders, and networks of leaders across the organization. By doing that, they create a widely distributed system of decision-making that is faster and better by virtue of being closer to the problem, and still be accomplished by trusted people.

The saying “too many chiefs and not enough indians” does not apply here. A leader is not a boss: the former empowers others while the latter concentrates power. A bellhop can be a leader even if he has no one to lead but himself: all that is required is initiative and reliability, an inquisitive and open mind, trust and trustworthiness as well as the desire to make others reach their potential.

Where to Go From Here

Networked relationships & systems, situational awareness, experimenting & growing from challenges, distributed leadership, safety: these ideas are not new, but they matter now more than ever.

If you want to experiment with these ideas, do not hesitate. Most of these concepts are high level and you can explore them within your context with little effort and little risk, as long as you follow the Learn & Experiment Rapidly principle: small scale, well-defined experiments with clear goals within a limited time frame.

For larger experiment or organizational transformations, make sure to talk to a professional first. A bit of planning can go a long way to ensure success and reduce risk, stress and trauma on a system.

Maurice Lefebvre

I am a futurist, system thinker and organizational transformation expert, dedicated to easing our transition into Society 5.0. I am available as a speaker through the think tank Hivernité (www.hivernite.ca) as well as a trainer and organizational coach through Moabi Formations (www.moabiformation.com).

www.hivernite.ca

During a coaching session a few weeks ago I was asked by a client about the advantages of keeping teams together in an Agile setting. After all, they used to build teams to order for each projects and it was working fine. Building teams for specific small projects and disbanding them afterward seemed like the most efficient way to go, as it meant that all specialists were exactly where they needed to be at exactly the right time.

This question is tricky to answer. Of course the client is right: in a very narrow view, he uses is ressources far more efficiently that way. But he’s also completely wrong, as the short-term gain of efficiency comes at the expense of long-term gains and of the overall strength of his entire system.

The answer is also not necessarily to keep teams completely stable over time, but to understand the “why” and “how” to change team members.

The Issue with Efficient, Predictable Teams

Business and production in the 20th century was marked by a continual quest for two elements: efficiency and predictability. From Taylor’s “Scientific management” to Lean Manufacturing, most of the proposed approaches have likened companies to machines that can be precise and predictable.

Predictability is desired in order to to plan from months to years in advance with little variance. Estimation experts either skim or use complex algorithms to calculate risk in their estimations, with results that are now increasingly off target. Predictability requires a very stable market, a very stable environment, and only “expected” unexpected events. As we try to predict over many years, we leave the realm of predictability for sheer divination.

Efficiency is desired to increase the output while reducing the waste. To be efficient, one needs to create a well-oiled machine, with all steps carefully planned and tweaked. It is much more achievable than a reliable form of long term predictability, but throw a wrench in that well-oiled machine and the the whole system will be blocked, if not damaged. Efficiency also requires a great deal of stability in the work flow, the market, the technologies involved and the corporate environment. Volatility and uncertainty are the worst enemies of an efficient system, as efficient systems are not meant to deal with significant variance. In effect, as a system moves towards efficiency, it also becomes increasingly fragile.

Entropy is the direct result of adding complexity to a system, such as new features or quickly patching defects. Increased entropy mean increased fragility. The more complexity you add to a system, the closer you bring it to the breaking point.

Non-Agile teams are created to deliver something specific in an efficient manner, often to be disbanded afterwards. Team members’ time is precisely managed using Gantt charts. Even estimated variation is accounted for and planned. Matrix planning allows for each person to be part of multiple teams with specific time allocation for each. It looks good on reports, but emerging problems causes variations, and there’s rarely a shortage of problems. Teams, and the systems they are working on, rarely seems to improve with time but rather accumulate entropy in the form of a backlog of work, defects, etc..

From Fragile Teams to Resilient Teams

New teams are always fragile, wether they are Agile of not. Agile teams however benefit from several advantages that makes them a bit more robust from the get-go.

Agile teams have a stable core of dedicated cross-functional individuals. They are not only systems, but networked systems. Their strength comes from the criss-crossing of diverse types of relationships within the teams — personal relationships, skill redundancy, information sharing and team self-organization. The balance between these relationships is whats make them complex organic systems.

However, even Agile teams start fragile. Growing them toward resilience require following the four Modern Agile principles:

Safety as a Prerequisite is achieved by creating a blameless team environment through shared accountability of work, group problem-solving, frequent synching and the all important right to fail. As Seth Godin argues, people are not afraid of failure, they are afraid of blame.

Learning Rapidly is achieved by spreading knowledge in the team through paired work and mentoring as well as small, controlled experiments. An Agile team uses a short learning loop to absorb new information and update their knowledge constantly.

Delivering value continuously, or in small batches, reduces the team’s overall risk by insuring that no matter what happens (budget cuts, human error or disaster), completed work is already out there bringing value to the company, client or customer.

Make people awesome is achieved in large part by the results of Safety as a Prerequisite and Learning Rapidly. Safety, experience-based knowledge and confidence empower people to go out of the beaten path without fear of reprisal. They will be able to absorb stress into their system, and be more willing to adopt new ideas. They will grow faster, improve faster and just be plain more awesome at their job.

Funny thing is, these teams will reach some form of predictability and efficiency, but from a completely different route than teams that are assembled to be an efficient system. It’s the combination of several traits that are not seen as efficient that brings them there: redundancy of skills, the collaborative approach, absence of fear, experimentation. By using non efficient practices, they end up more efficient.

When that point is reached, the team is already resilient. It will be able to withstand a lot of challenges, adapt to change and face both uncertainty and volatility. The team is not invincible though: very high levels of stress (such as changing several team members simultaneously) will make it crack.

From Resilient Teams to Antifragile Teams

Resilient teams are able to accept stress without being bothered by it too much. It’s good, but it can be better. Agile teams have all the building blocks necessary to progress from resilience to antifragility, so let’s put them to work.

Antifragility is the ability to take up a lot of stress, and become stronger as a result, like building muscles. Taleb uses the hydra as an analogy: a multi-headed monster that grows two more heads every time one is cut off.

The short learning loop of Agile teams is the key. The use of practices such as retrospective meetings allow teams to capitalize on that short learning loop: problems and challenges can be seen as new opportunities to grow. These challenges and stress are beginning to make the team stronger — or Antifragile. In order to convert stress into growth, a team needs to become comfortable with these short learning loops.

An antifragile team needs stress to continue to perform. Anyone who trains at a gym or does physical work for a while and then suddenly stops for an extended period of time will notice that the body will quickly lose its newfound strength if it is not used regularly. When not exercised through stress, the antifragile team stops growing.

This is where the Experiment & Learn Rapidly principle of Modern Agile truly comes into play. By conducting small, controlled experiments that are not too risky, teams can try and explore new ideas, keep themselves stimulated and create more challenges.

Introducing a rotation of team members is another way of adding some healthy stress. Changing one team member at a time, and then letting the team recuperate by spreading team expertise to the new member and absorbing the new perspective brought by the newcomer will make the team stronger. The departing team member will help another team by spreading his expertise and getting pollinated by his new environment.

The trick to this evolution through stress is pacing. If you do it too rarely, the teams will stagnate or regress. If you do it too often, however, the trauma might become too much and prevent them from reacting to unexpected large amount of stress.

Just The Beginning

Agile Teams are relatively easy systems to bring toward antifragility, because of their very makeup. It takes time and conscious efforts to grow them that way, but it is well worth the effort.

Other kinds of systems can benefit from antifragility. After all, what is the benefit of having antifragile teams in a company that cannot survive in a volatile and uncertain environment? Of course making a whole company antifragile brings a whole new set of challenges. In further posts we will explore how to bring those larger, and more complex systems along the same path.

Maurice Lefebvre

I am a futurist, system thinker and organizational transformation expert, dedicated to easing our transition into Society 5.0. I am available as a speaker through the think tank Hivernité (www.hivernite.ca) as well as a trainer and organizational coach through Moabi Formations (www.moabiformation.com).

www.hivernite.ca