CAL II Grads—Agile Transformation is Convincing People
Most of my fellow Agile professionals have been through at least one Transformation. Rarely are any of us hired directly into an enterprise that is ten years into their transformation, and has it all figured out.
I’ve been through two Transformations. One on the tail end, where a lot of stuff was indeed figured out, and one from the very beginning. I was hired as the very first Product Owner/Agile Champion at a company that had never even employed a Developer, let alone multiple Teams of them in an Agile environment. I literally wrote User Story #1, ya’ll. We were green, to say the least.
Two years past that day, we’re still green. Not quite as green, but we still have a long way to go. Folks, this is hard. It’s really, really hard. Championing an Agile Transformation is nothing more than convincing people. It’s convincing all manners of people: those who want to be convinced, who don’t want to be convinced, those who think they are already convinced, but definitely are not, etc. I’ve never intended to be a politician, but goodness – convincing people of the merits and worthiness of an Agile methodology feels like trying to convince people that Americans would save money via Universal Health Care. They ask for all the things you’re trying to give them, but refuse to accept the steps you want to lead them through to get there. Sound familiar? Just call me Bernie.
a few things I learned during my first Agile transformation that I wish someone had told me
A clean slate is not a clean slate
I took this job knowing that there had never been software dev at this company. I was excited for the clean slate. We won’t have to make changes! We’ll just start off being Agile, we won’t have to “transform!” There won’t be bad habits to break!
Wrong. Dead Wrong.
If you end up in a position where you are starting dev teams from the ground up, and you happen to hire team members who were born yesterday, then congratulations, you might not need to “transform.” For the rest of you mortals, starting dev teams from the ground up WILL entail a transformation.
Everyone brings their own baggage, including their views on the “right” way to do things. You’ll find people who had the luxury of being in a true Agile shop previously—they’re your saviors and you rely on them heavily to endorse you.
You’ll find people who have never heard of Agile. Hopefully they’re open minded to your suggestions toward the process, and take cues from their fellow Agile experienced teammates.
You’ll find people who did stand ups, had demos, and were told they were Agile by doing those things. These folks are hard nuts to crack. They think they’ve been Agile, when in fact they’ve only done Agile. They don’t want your suggestions, because they’ve seen Agile, and it’s not what you’re saying. It’s especially tough when these folks are leading the department or the company.
Which leads me to my next point:
Don’t assume verbal buy-in from the top actually translates to day to day buy-in.
I was hired as the enterprise’s first PO/Agile Champion. I had buy-in from the CTO: “We want an Agile shop, you’re here to make sure that happens.”
“Awesome! Step #1 is to trust the teams so that means you, the CTO, can stay out of the dev teams’ business.”
“But I need to know what’s going on, they’re not good enough to do this without me.”
Sigh.
As an Agile transformation champion, you might hear what sounds an awful lot like true, honest to goodness buy-in from the top. Be wary that this might not actually translate to buy-in from management on the day to day order of business. An Agile transformation will need to happen at all levels, even if you think you already have management in the bag.
Some folks just really don’t want to broaden their horizons.
My favorite dev team members are transplants who spent some of their career in other industries or fields. Perhaps they dropped a career in teaching to attend a coding bootcamp, and are starting from the very bottom. I find that these folks tend to be open minded, and fit the Agile cornerstone philosophy that a dev team member should be willing to do whatever it takes to get the sprint completed. They’re happy to try anything and everything.
Contrast that with a developer who has spent 15 or 20 years in a non-Agile shop, where he or she was labeled “Front End” and did nothing else. I have found that that type of person is very lost when his or her team is presented with a back-end heavy sprint. If this person is unwilling to try work that is outside his or her comfort zone, he might feel underutilized.
There are several levels of convincing that might need to happen here: perhaps you are going to have to convince that developer that it’s worthwhile to learn the work that they have never tried before, even though, yes, we know you’ll be slow, and yes, you’ll likely slow down the expert that has to teach you. Perhaps you’ll have to convince the expert on the team that it’s worthwhile to let a newbie touch her code, so we can be more well rounded as a team in six or 12 months. Perhaps you’ll have to convince the manager that it IS possible for a dev team member to be an expert in one area, sure, but also dabble in other areas at the same time.
Some folks are very hesitant to broaden their horizons, especially if they’ve been around awhile, and ESPECIALLY if that person is a “rock star” (read: has an ego) in their area of expertise. It’ll take some lobbying to get his type of person to understand that the team commitment is the team commitment, which might mean he has to do some work that is new to him.
Final Thoughts
At the end of the day, an Agile Transformation is a journey, even if you are starting with an entire Team of brand new hires. Everyone brings baggage. Management might sound like they’re in your corner, but display some behaviors that contradict their words. You might end up with Dev team members who REALLY ONLY WANT TO DO WHAT THEY KNOW. These are all challenges that must be overcome to succeed at an Agile transformation. I wish someone had told me.
]]>
