Specially in Social Media, where there are many “specialists” from all areas. And there’s actually a big part of all that I have been hearing that makes me think people have actually misunderstood what Agile really is about.

There’s not just a misunderstanding of what Agile is truly about, but there’s also the false idea that Agile is this “silver bullet” that will solve all problems of an organization; and/or that Agile is this destination where companies that embark on the journey, believe they will get to…

This discomfort brought me to this article and a talk that I do on the same topic: What is Agile and Why Should We Care?

Agile is a set of Values, Principles and Practices; that together drive behaviour (yes, human behaviour); and when you have the majority of people behaving in a similar way, then you have a Culture.

And a Culture is what Agile really is. A mindset; a way of thinking and behaving; a culture.

The Agile Values are the Foundation.

And these values are really some very basic, day to day values, that most of us live by on our everyday lives.

Respect. Means having due regard for someone’s feelings, wishes, rights, thoughts, opinions, history.

Openness. In two ways. Being open to different points of view, perceptions, thoughts, understanding… diversity. And being able to work in the open; display your work, show people what you have been working on and feeling proud that others visualize it.

Courage. The ability and strength to be brave. To question the status quo. To challenge ‘as is’ and ‘has always been like this’ scenarios, processes, answers…. Change (in mindset and behaviour) will only happen if you have the courage to break through, to crack shells…

Trust. Belief in the reliability, ability, commitment of someone or something. This regards your management, your peers, your employees; your process, the ecosystem and all that this involves.

Empathy. Ability to understand and share the feelings of another… of your managers, your peers, your employees, your customers… If a person is frustrated and angry, really try to understand where they are coming from and why are they feeling that way. No judgement. Just understanding.

The Agile Principles. Let them guide you.

As my very own translation of the Agile Manifesto:

• Begin with Clarity about the Outcome, and let it guide every step of the way. Once the organization; management; you and the team understand where you’re headed to, this should become the “True North” where the group looks up to and connects steps and next steps to.
• Listen, Iterate, Learn and Course Correct… rather than wait until it’s perfect. This is what Agile is about. Experimenting, trying out, testing hypothesis instead of trying to come up with the perfect solution or process and then learning it doesn’t work and being left with this big chunk of waste and frustration (specially from the team! That will have to acknowledge they are throwing their time, effort, passion… in the garbage). Be iterative and learn fast.
• Encourage self-direction for teams to unleash innovation; instead of concentrating Leadership in the hands of a select few. Creativity, Passion, Purpose, Expertise in everybody’s hands and a company should make the most out of their individual beings. There is just SO much they can contribute with. Give people space to think, create, innovate, problem solve…
• Focus on the Customer and the Business Value. This should be more important than most other things… If you keep your mind on this (and the above), you will probably make the right decisions for your product, service or whatever you are putting out there in the market.
• Be flexible, adaptive and continuously improve within a collaborative team. The world changes. Everything changes. Accept, embrace and deal with it.

The Agile Practices

Ahhhh, this is a true buffet in terms of variety! Each Agile framework has their own set of practices (some of them are the same, with different names…); and these practices can be focused on Leadership, Collaboration; Delivery and more…

Don’t get caught into this. The practices are the least important part of the Agile behaviour enablement if you have the Values and the Practices understood and being lived. The practices are almost like a ‘detail’ and teams should be able to pick and choose what better suits them in terms of what problems and pains they are trying to minimize and solve.

In the Agile Culture, we should always be asking the question: “How can we get Better?”

This thought will drive inspection and opportunity to experiment with new things to bring you, your team and your company to even better places! – Yes, amazing!

Now, why should we care about this?

Well, if you have not made your own conclusions yet; I’ll help you with why I care about this shift…

• Change is inevitable. Agile has just shown to be a better way of embracing it and going about it with less waste, frustration and its consequences, like disengagement.
• It enables people and companies to identify incorrect approaches faster, which gives them the opportunity to act faster and have things back on track and with minimal impact.
• Enables achieving consensus and making decisions without suffering from big pains and going through so much churn and losing timing and momentum.
• Accelerates your time to market and proves the concept faster and better. AND, enables you to make more money, earlier.
• It’s about Value first; fewer defects; more quality… which will make your customers happier and believe me, they will come back to you due to the amazing experience your product or service provides/allows.
• Human behaviour is changing through different generations… Agile is just way more appealing to them, which happen to be your customers AND your workforce.

What are your thoughts about all this? Share with us!

SlideShare: https://www.slideshare.net/CristianeOliveiraCun/what-is-agile-and-why-should-we-care

Cristiane Pitzer

Agile Coaching and Enterprise Culture change are my areas of expertise in a world that is going Digital and changing fast. I work with Individuals, Teams and Leadership to design and build a workplace that is adaptable to the ongoing changes and shifts in the world and that unleashes innovation within each individual being.

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

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

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