Self-Selection Out of Agile
Self-Selection Out of Agile: Fitting a Square Peg In a Square Hole
First, a quick term check: Self-Selection, is the process in which teams form themselves by picking and choosing what groups, products, and opportunities seem to best fit their interests and skill sets. It can be a very powerful and exciting tool in your toolkit when forming teams and when trying to engage a culture that may be lagging behind in terms of innovation.
BUT, what if a team or organization chooses to “self-select” out of Agility or Agile transformations? What if you are brought in to coach or manage one of those “hard-sell” teams, where buy-in seems impossible or not wanted? What do you do with the “Island of Misfit Toys”, that can form in an organization, and are not willing to let people go who do not wish to make the changes necessary to transform?
Why does this happen?:
I was once brought in to coach a group of teams that did not make the cut for the initial Agile transformation using SAFe. My goal, as stated to me, was to help them align with the SAFe-Agile principles, and start them on the “right” practices so that they could be brought in at a later date with the rest of the ART.
When I asked why they were not included in the initial launch the answer was a mixture of: “Well, none of them know anything about Agile...” and, “Well, they cannot plan their work ahead of time because of their role...” (whatever that means) and, “Because they are not software engineers so the SAFe model does not work for them out of the box…”
Sounds like I got a lot of work ahead of me…
Self-Selecting out of an Agile Transformation can happen for a whole list of reasons:
The manager of an organization has had bad experiences with Agile and therefore does not believe it will help his teams.
A team does not fit the traditional Lean-Start-Up Model.
A team or organization is non-IT in nature: “That Agile stuff is for SW developers only!”
The framework being used is ill-understood or ill-implemented.
The team does not want to change what they feel isn’t broken.
Team leads fear that Agile will disrupt their perceived career paths.
To me, a lot of that comes down to a:
Lack of Trust
Lack of Vision
Lack of Knowledge
Strong resistance to Change, or the risk that can follow Change.
Anyone who has experienced the struggle of the mighty goal, “Obtain buy-in”, can attest to the corresponding issues associated with all of these concerns.
It is important for a coach when walking into this situation to understand the true nature of Intersectionality when it comes to people and their “whys”: their personalities, their fears, their needs, their work, and their understanding of psychological safety, to start. Intersectionality, in the feminist and inclusive movement, refers to any individuals being not just one or two aspects of what you see of them but a complex network of cross-roads that make up them and their experiences. This complex network means every individual comes with their own baggage, opinions, bias, strengths, and weaknesses.
For instance, you are not some Agilist that is way too deep in this very pink blog post just looking for some nice reading. You have goals here, that I am trying to guess as I am writing. I am attempting to understand what complex cross-roads led you here, and how I can enable and coach better understanding. This is the same task I ask those to undertake as they start to breakdown the walls of the Self Selecting Organization, the Island of Misfit Toys, the Square Peg.
How do I know what I’m dealing with?:
One of the most important aspects of being a coach is observing and listening:
If a lack of Trust is what you are dealing with, you will see/hear…
An unwillingness to adjust for fear of retribution, change of status, or change of career.
Resentment towards management or leaders forcing the change.
General begrudging around new visions or changes in priority.
An unwillingness to talk openly about problems or issues in the organization or it’s leaders.
Consistent use of back channeling to get work done or changed last minute.
If a lack of Vision is what you are dealing with, you will see/hear…
General begrudging of new visions, ideas or changes in priority.
A sort of “wait it out” mentality around new initiatives.
A lack of transparency across the teams around what the vision actually is.
Glossing over issues or problems in the organization.
A lack of buy-in on the general vision due to a variety of reasons, “Oh yeah that is what management says, but this is what we are doing”.
If a lack of Knowledge is what you are dealing with, you will see/hear…
A lack of transparency across the teams around what the vision actually is.
Glossing over issues or problems in the organization, primarily due to not having a clear understanding of how to fix the issue.
Belief that Agile can work for some people, but not for this team/organization.
A lack of training across the organization in Agile.
A lack of Agility diversity, for instance: only Scrum is taught across the entire organization and the Agile umbrella is unfamiliar to them or leadership.
If a Strong Resistance to Change or the risk that can follow Change is what you are dealing with, you will see/hear…
General begrudging around new visions or changes in priority.
Consistent discussions around controlling scope or getting a full list of requirements upfront.
Consistent discussions around managing risk and creating new risk processes (with little reason as to why).
Consistent discussions on time needed to complete work.
Team leads being pinged or brought into emergency meetings for status updates of current work.
Observation time, I start by listening and asking questions of my new team, I get the lay of the land. I try to find what mixture of the four reasons above are the keys for self-selection.
After asking questions and listening to their answers, I find that the team and the team leads trust in the Agile processes and have been trained in Agile values. They believe that their management has a good understanding of their psychological safety and engages in tough conversations around change. The teams also know where the organization is trying to go and they are doing so incrementally with SMART goals to take them there. It’s not all sunshine and roses in the vision arena, but it is enough to keep the teams moving towards a common mission. Great!
However, I start to hear phrases like this from team leads, “I just do not understand how Scrum and estimates are supposed to help us? We have tried and tried, and none of this makes sense…” Bingo. A lack of Knowledge.
So now you may have a better idea of what you may be dealing with, but how do I go about helping this organization or team?
What can be done about it?
I will start with the items my story will not address:
A lack of Trust - Means a lack of psychological safety and an unwillingness from management to truly face problems in their organization. I tend to start by, after my observation period, creating a safe space by my words and actions. When the team leads are upset at these changes or do not believe that the change is necessary for them, I empathize by stating:
“I completely understand what you are saying and I agree that this change is going to cause some disruption to your team. Agile is not a magic bullet and it will make you and your team see more dysfunction in their current processes than solve them when you are initially getting started. Change and progress can not happen without you and you have the opportunity to lead your teams in the right direction, so what is the most important thing for you?”
This statement follows the following formula:
Level Set with a Trust Building statement - Show that you heard them and empathize.
Be Transparent and Honest - trust is a two way street, and transparency can help to convey that you honestly care about their values and struggles
Inspire a Change - Empower them - Embolden them -Use what you have learned to find the key messages they most resonate with.
Coach Change - Ask important coaching questions to help guide them to their right answers and trust their own judgement instead of being overly-reliant on the suggestions of others. The best buy-in you can ask for is one built within. (Like Inception only business-y and with less cool effects)
This interaction may need to happen several more times for them to feel emboldened, or start to trust themselves and leaders around them. At first, you might only be able to do the first two steps, as you start to build understanding and transparency with your organization or team. This formula and process is also essential for coaching the leaders of your organization.
A lack of Vision - Means that an organization or team is feeling the pressure of a top-down Agility approach without being given a proper “Why” or Goal in which to rally them forward. This might even be a signal that more nefarious games are a foot, aka. The senior leader thinks an Agile Transformation will give them a nice year-end bonus.
When I see teams struggling with a lack of vision I tend to be very pragmatic, and ask these three questions:
What/Where is the Vision? - If I can’t see it and if I don’t understand it, then I don’t know it.
What problem is this Agility transformation supposed to solve? - “To Be More Agile” doesn’t count. Think about true success markers of an Agile transformation: Time to Market increases, More Built-In Quality, More Transparency across Value Streams. If all of the above, What do you want to do first?
How will you know it’s successful? - Make it an achievable, yet specific goal with ways to measure progress either already in place, or to be developed as a part of your Agile transformation.
Sometimes this is very difficult to get right off the bat, and you might even need to train leaders on how to create a Vision and go into Lean Portfolio Management to dip their toes into Strategic Themes and OKRs. At the very least, keep asking those three questions and reiterating the importance of, “If you don’t know where you are going, how do you know when you are there?”
A lack of Knowledge - Can mean a lot of things... A lack of Agile training, or maybe they have had training but need refreshers on certain concepts. A lack of understanding of Agility diversity and how Agile does not equal Scrum or Kanban. Maybe there is a lack of understanding of the structure of the organization that is causing more problems than it is trying to solve. This can happen by trying to put teams and people into certain Agile boxes they do not belong nor want to be, like traditional Project Managers that do not have the skills nor desire to be a Scrum Master or Senior developers that do not understand what it means to be an architect in SAFe.
There could be knowledge gaps in TONS of places. My best step by step is this:
Take it to the Teams - (Thank you Lyssa Atkins!) Ask team members where they see gaps? Are there differences in approach causing confusion? Are their roles they have questions about?
Find out what is not working - Ask it back to them or management, “I am curious, why do you have X team on the release train as a fully fledged team when their work is not tied to this value stream? Am I missing something or do they live at a different level?” Always try for self-discovery before suggesting or giving advice. Remember: Inception.
Teach/Mentor/Train - Once you have listened and found what wasn’t working, getting some buy-in along the way as you understand their gaps, now it’s time to help close them.
Experiment and Empower the Teams to Grow - Your way, oh mighty coach, is not the only way to “do Agile”. You have the experience and the training, but the teams have to live, learn, and adapt to what they are doing day to day. Give them the power to make their own decisions around their values, working agreements, and processes as long as they align with the overall value of Business Agility and increase the flow of value to their customers.
One final piece of advice is also that….maybe…just maybe, this is one of the teams that Agile processes may not be ideal for. The values are always important for nearly every team, but the practices and processes may not be fit for purpose. This can be a whole article on itself so I will leave it at that.
A strong resistance to Change or the risk that can follow Change - Means you are dealing with an organization that usually turns very, very slowly. Change will not come in a day and heck, it barely can happen in a couple years, hence why they want an Agility transformation. They may be so tied to their safety nets, hierarchies, processes, that change can seem impossible, and need tons of certainty to move forward.
Take it to the Teams - Same as a lack of knowledge, there are usually gaps in certainty that are leading to risk aversion. For example, “I do not want to write in user story format because our risk assessors will not understand how to use user stories to assess our risks, and I have to do double work.” Ah, so maybe your Definition of Ready is that each user story is linked to a risk assessment or has a risk assessor statement in it?
Empathize with the Why of Risk Aversion - Individuals are usually not trying to be difficult. They are trying to protect the integrity of their team, their product, or their job. Find that why, be sensitive to that, and make your understanding of the why clear in your coaching.
Emphasize Small Changes - Massive organizations do not typically implement Full SAFe or the Lean Start Up model overnight, it takes time. Coach and emphasize when you make small changes, lead by the team, and show success towards your organization or team goals.
Celebrate Little Victories - And when you do, celebrate them!
Experiment and Empower the Teams to Change - Those who are averse to change sometimes need to see the change and celebrate it, before they see themselves in it. Empower your teams and your organizations once they start to see successes, and that the true change and growth comes from them. Enable them to experiment and empower them to lead the change themselves so you create a guiding coalition of change that can tackle any traditional hierarchy!
In discussing with the team leads I found that the teams were getting told Scrum was the only way to do Agile, and that was the way they needed to align to the overall Program. But, when we pulled back the curtain, all of their work as injection from either customers or other teams. This made it nearly impossible to plan for even a two week period. We analyzed their flow and found only 10% of their work was planned work like maintenance. Once we found that gap, I asked, “Have you all ever tried Kanban?”
”Oh, no, what is that?"
It ended up being perfect for that team. I trained them on how to measure the flow of value and focused on “Value In vs. Value Out” metrics, and empowering the team members to manage their own priorities, only going to the lead if they were truly stuck. Finally, I encourage them in their retrospectives, held when necessary, to adapt their flow, working agreements, and classes of service to fit new challenges they may face along the way.
The team finally saw themselves in the Agile vision and did not have as many fears about joining the overall program. My last hurdle was working with management to help them understand how having 5 Scrum teams and one Kanban team would not totally topple their Agile transformation, but would lead to a more diverse and well functioning organization.
Closing thoughts:
I rarely experience a self-selecting team or organization with only one of aforementioned issues, and it might take many iterations and many hard conversations to really get to the root cause of self-selection. Remember though, it can be incredibly rewarding when you see those first “Aha!” moments and start to unravel the protective coils around these teams. We all, even the most stubborn self-selectors, want to belong to the larger change and achieve greater purpose in what we do, but sometimes us coaches need to switch up our tactics and fit a square peg in a square hole for once.
You are the key to real organization change, do not give up, and you got this.
