Dealing with those resistant to Agile

I’m about to jump headfirst into a bunch of teams on a hugely complex multi-product & multi-WoW environment & my job is to ‘manage it’. I know right! What I’ve gathered to some degree after talking to some of the folk involved is there’ll be many of those resistant to Agile. So, I wanted to talk in this post why people & teams are often resistant, how they are resistant & why I’m not the Agile guy they may fear I am. And also, why Agile isn’t the answer anyway.

So I’m the least Agile ‘Agile guy’ you’ll meet. I call out Agile’s BS, the BS consultancy firms often peddle around Agile being a silver bullet & also why its mostly done wrong. From my discussion on why backlogs can often suck to why Agile is thrown around still like some magic bullet. I’m always up for picking its faults. Besides, most people still today in my opinion that I meet, fail to fully understand Agile’s sentiment, rather than to try & apply something from a book.

Done right though, you can take discreet pieces of WoW & the Agile mindset & slowly over time just nudge teams into process improvement. But its more about being human than understanding Agile. I do a podcast about delivery & I think there’s not much more to talk about in terms of Agile. I mean, how long can you talk about story points or estimation techniques for? I talked about being a servant-leader on my last podcast, & I maintain that. I’m here to take the heavy lifting from the teams. Not force them into meeting after Agile event meeting. Often the pressure in teams comes from lack of time to work thoroughly, (& therefore increasing operational & technical debt) but also the ongoing ‘is it done yet’ question from Stakeholders. I see it as my job to help with that, & it just so happens I know enough about Agile to able to pick the bits & bobs which help me, in turn help the team.

Let’s first talk about the types of resistance I’m predicting I’ll face;

I’m guessing I’m going to meet a few that fit into each bucket. And that’s ok. What I’m not going to do is try & force it into the existing processes or WoW. What I need to do is listen to each team, observe & understand how they work currently, what would help them & then be the ambassador for them for getting that thing. It could be time, it could be more folk in the team, or it could be something more trivial like cleaning up an information repo or helping documenting stuff. It will most certainly be developing a plan that’s coherent & tell’s the same story to everyone, but I also imagine it’s going to be to create some breathing room between the team & stakeholders.

I was asked how I’d do some of the above recently, & I’ve been giving it a lot of thought;

1. Frame the benefits to all parties;

I want to ensure I understand & can demonstrate who the winners & losers are of any process change or any existing issue. The case for change comes from being able to articulate this to all in a way which makes sense.

2. Using key influencers;

There will be invariably some positive & negative influencers within the team(s) & I want to use them to spread the message, whatever the most helpful message I need to spread it. I also want to ensure they are bought in to helping me help them. I mean, the masses are going to listen to them more than little ol’ me.

3. Leverage social pressure;

Us human beings, we’re not complicated. We’re wired to respond to social pressure. Especially when it comes to comparative performance being on display. So you can bet I’m going to leverage huge visual dashboards & reward things such as largest velocity or least number of bugs etc. The recognition & reward will act as very subtle pressure pushing people to rally one another.

4. Help the naysayers;

I’ve had so many experiences of those who just can’t’ be or don’t’ want to be helped and torpedo teams. I’d like to think I’m pretty good at dealing with this, listening properly & actually giving a damn about people. I’ll be exercising lots of listening & compassion as I go.

5. Explaining & justifying change;

There’ll most likely need to be some change. Maybe from the key stakeholders, maybe from the teams. In all cases the best way to make change is to SHOW why it needs to happen. Whether its response times, code quality, or anything else, I like to verbalise, visualise & demonstrate the impact & cost of not changing.

6. Be a lighthouse;

I want to demonstrate how the practises & techniques I use & can teach others can & WILL help the teams. You cant get change any better than by demonstrating how it works. I’ll need to understand how to build my credibility & also sphere of influence BUT its not about pushing a new WoW down peoples throats & if you’re a DM you should consider how you leverage what is often complex soft skills to get real buy in & change, rather than just some new training & mandating of a WoW.

So with that out of the way, let’s figure out the various ways in which teams like this in these environments typically work

Probably Less;

 Now I’m a huge (no pun intended) fan of Nexus (listen here) so it’ll be fun to see what improvements if any I can make. I think managing & monitoring up/down stream dependencies and articulating them in a coherent way is going to be useful, and I’ll probably use something like Nexus dependency management.

After doing this for 15 years, I’ve started getting good at it. I practice my craft every day, so let’s see if any of this works! I’ll let you know. But for now, we’re done with Agile. Completed it mate!