How to Influence and Win Team Members Who Hate Agile

The Agile and Scrum revolution in IT has been phenomenal. Followers of the Agile development religion swarmed in thousands overnight, eagerly converting to the new way of working. A lot of it had to do with the simplicity of what Agile proposed to takers.

The lure of faster delivery, better quality, lower costs – naturally, Agile was (still is) to IT what honey is to bees. More and more IT organisations are converting to Agile every day. They see far more benefits with using Agile methodology for delivery, than not.

Is the awareness about Agile methodology and its benefits widespread?

A resounding YES!

Are the pluses of switching to Agile methodologies far greater compared to any (perceived) minuses?

No doubt!

Are IT managers successfully able to inculcate Agile thinking into their team completely?

Not so much!

Well, you’re not surprised to read that.

Now, I know you hear more than enough criticism of Agile methodology from some of your team. They hate any mention of Agile and Scrum. And they have their own whys and wherefores for why Agile development doesn’t work.

You’re looking for a solution to help your team/stakeholders stop hating Agile, and start embracing its benefits.

That is why you’re here.

I understand the confusion and frustration that Agile Transformation can bring to a team. I have experience in helping individuals, teams and organisations tide over what can, for some, be a difficult transition.

That is why I am here.

In this blog post, we’ll look at why Agile doesn’t work according to some people, and how to influence and win them over.

Why do some people hate Agile?

Let’s try to see things from the point of view of the haters. Because there are two poles, two sides to a coin… you get the drift.

Agile methodology, while it has brought many benefits, obviously hasn’t converted everyone to a believer. Just as a court of law hears two sides to an argument, let’s look at why some people believe Agile development doesn’t work. And we’ll look at solutions to some of their concerns.

“How do you create a detailed business case with timelines, plan, resource, cost etc. for Agile projects?”

Lack of a concrete plan and date

If you work for a traditional IT organisation that goes through an annual budgeting exercise, you know how budget approvals work. Business cases for Projects for the next calendar year probably need to be drawn up by November this year. As it turns out, such exercises need a lot of detail – of plan, timelines, resource, cost, technical enablers, impacted areas/products etc.

How do you create a detailed business case with timelines, plan, resource, cost etc. for Agile projects

Simple – you don’t! Working Agile means you don’t spend as much time on up front planning as with Waterfall-type projects. No wonder then that you don’t have as much detail to share about plan and dates. At best, you have a target release date, target architecture and some high-level costs. This lack of certainty doesn’t sit well with senior stakeholders. This is why managers hate Agile.

It doesn’t matter that Waterfall projects may not actually meet original plan and dates. Some people just get used to seeing a date, cost, schedule and like tracking to these.

It gets worse: Agile doesn’t report Waterfall

This issue flows from the lack of a concrete plan and dates with Agile projects. When you’re not quite sure when your project will go live, you can’t report the project in the traditional Red/Amber/Green scale.

Why does RAG matter? It doesn’t – not for Agile projects. What matter, are burndown charts, sprint velocity, story pointing, percentage of story points completed. These are (relatively) new Agile metrics [link to PDF file] that some stakeholders aren’t used to yet.

So what do they do? They hate Agile reporting in favour of the familiar face of RAG, and its age-old reporting cohorts (read PowerPoint slides, spreadsheets, word documents).

“Demonstrate how Agile reports are updated-to-the-minute, and present the truth, the whole truth and nothing but the truth.”

What to do about it:

• • Educate. Get experienced Agile coaches to explain to plan-addicted stakeholders, how Agile projects plan, schedule and report.
  • Train them on how to read Agile reports.
  • Demonstrate how Agile reports are updated-to-the-minute, and present the truth, the whole truth and nothing but the truth.
  • Explain managers that hate Agile how they don’t need to wait till a weekly/fortnightly Project Working Group meeting to know whether a project is doing fine.

Agile kills off some project roles

Change brings – you guessed it right – change. With the advent of Agile, how IT projects were managed changed. So did some of the roles.

Suddenly, a Development Manager doesn’t play as much of a role on individual IT projects. Planning, estimation, etc. have been absorbed by more empowered scrum masters, lead engineers, architects, business analysts, product owners. So you don’t need as many spreadsheet managers as with Waterfall.

A number of planning-related roles (some quite senior too) have ceased to exist with Agile, bringing a bit of an existential crisis to some. I don’t know about you, but I’d feel a wee bit worried if I was told the role I used to fulfil for so long isn’t required anymore.

And creates new ones

This was inevitable – new methodology brings with it different ways of working. And consequently, new project roles. The Project Manager gives way to a Scrum Master (I know, some of you don’t agree they are the same; one for a future blog). The business analyst sometimes doubles up as scrum master or product owner. Somebody now runs a scrum of scrums. There are Agile coaches, Scrum Lords – take your pick.

Set aside the positives for a minute (we’re documenting the whinges about Agile after all!). Naturally, a question arises – what in heaven do each of these new roles do in a project? While the new roles may be familiar for those that have embraced Agile, this shift from waterfall ways of working can be quite unsettling for managers and team members that hate Agile methodology.

What to do about it:

No matter what anybody will have you believe, redundancy of some roles is normal during transformative periods of time. Uh, hello, Industrial Revolution, anybody? Yes, it is a difficult period for some. It isn’t necessarily their fault that their role has been sucked into a vortex. They do, however, need to make peace with it. And move on. It would be their fault if they didn’t adapt to changing times.

Provide them support, and internal career options where available.

I’ve seen so many examples of people reinventing themselves during transformation – sometimes into a completely different yet more successful and immensely satisfying career. It is their personal journey. They need to experience it.

Do a whiteboard session to explain what are the various project roles in an Agile world, and what they each do. Explain to your stakeholders why they’re suddenly talking to a Scrum Master (not a Project Manager), and attending a Scrum of Scrum (not a Progress Working Group).

Reporting mechanism is by far the most challenging change to communicate, in my experience. I’ve had people – especially managers – go red faced and say – ‘So you want me to attend a 15 minute daily Scrum of Scrums to discuss impediments with the various scrums? There’s not going to be a Steering meeting or Project Working Group?’. They’ll understand. Soon enough.

‘So you want me to attend a 15 minute daily Scrum of Scrums to discuss impediments with the various scrums? There’s not going to be a Steering meeting or Project Working Group?”

They’ll understand. Soon enough.

Meanwhile, don’t forget. We’re also talking about new and exciting opportunities there for the picking. To those that are concerned about where their career is headed during an Agile Transformation, provide support and help with capability assessments and help them choose an Agile role they might be interested in. A match made in heaven!

Everyone is expected to be hands on

They can’t hide behind spreadsheets anymore. Agile is more do and less manage. And it means, you’ve got to be effectively engaged in a project to have an impact, to have a say. You have to be involved with a lot of the detail. You have to be hands on.

But being hands on isn’t for everyone. Some might genuinely like to stay at the big-picture level, others might think they deserve to NOT be hands on. Whatever the reason, it’s scary to suddenly be informed I can’t walk into a meeting, sit there and listen, not make a meaningful contribution, and yet be considered an important stakeholder.

What to do about it:

A bit of a pickle, this. I’ll try not to sound judgemental when I say this – flatter management structure is increasingly becoming the reality. Those that hid behind meeting invites and weekly, fortnightly reports, are getting left out. This is why managers hate Agile. Agile has showed them they need to do more to contribute. It’s now up to them to change the way they work, or get left behind.

Commitment required – time, resource, fewer projects

Agile equals commitment. Hard, straight commitment. To the task at hand. To the project. To your team.

It means you can’t be spread over too many projects (i.e., you need to be a team member, not a meeting member). You’ve got to dedicate your time to fewer projects – preferably, one. You’ve got to put hard effort day in and day out to help your team succeed.

What to do about it:

This is the new reality. Accountability is paramount in Agile projects. Do not condone inefficiency, sloppiness, sluggishness. Expect 100% commitment from each member of your team. Identify and individually coach the weak links. Support them, encourage them. Just don’t allow them to pull your team down.

Some projects don’t support Agile working (e.g. regulatory)

Agile may not be relevant for every project situation. Your choice of methodology should be informed by the working environment – internal and external. Imagine working to a strict deadline from your regulator to deliver a critical reporting project. Can you afford to tell your regulator that you work Agile, therefore cannot commit to a date or scope?

What to do about it: Evaluate the needs of a project before deciding methodology. It’s still possible to work agile when facing restrictive waterfall-type conditions. You just need to find the right balance between both.

For instance, one of my clients had to deliver a project that improved the transparency of investment advisory fees charged to customers. The regulator gave them a specific deadline, and ‘incentivised’ compliance by dangling heavy fines. We spent more than the normal amount of time scoping and planning. Because we had to understand whether we could meet the date. I suggested we get the regulator to provide regular consultancy. So we got them on board as one of the product owners.

We worked Agile. With two-week sprints, we were able to frequently demo the progress we were making to the regulator. We challenged some of their mandates in the course of the project, and got concessions. And, surprise, surprise, we delivered three months before the actual deadline.

Want to know the best part? The regulator actually asked my client to provide consultancy to competitors who were still struggling to get back on track. Our team became an advocate for working Agile in a waterfall world.

The rest of the organisation isn’t Agile

This is a classic example of failed Agile transformation. If your team/department are the only Agile adopters in your organisation, how do you expect to be Agile? Time and again, projects in poorly adopted Agile environments stall. They stall because key stakeholders that enable completion of the project (like an Analytics team that help with MI) are still working Waterfall.

“I’ve been on projects where we completed building an app in six weeks, and had to wait three months for a critical back-end team to allocate resource to complete end-to-end integration.”

I’ve been on projects where we completed building an app in six weeks, and had to wait three months for a critical back-end team to allocate resource to complete end-to-end integration. They were tied up on other projects due to their own Waterfall planning practices. This is one of the reasons why Agile development doesn’t work – the reason isn’t the methodology but how you choose to implement it.

What to do about it:

Your entire supply chain needs to be Agile. Work with teams external to your sphere of influence. Make them see your vision. Help them become more Agile. Support them through their journey. Be patient. Go for Agile Transformation for your entire organisation. Read more about Agile Transformation here.

Your Organisation is actually Waterfall in an Agile garb

Now, this is a fundamental issue. I come across this wolf in sheep’s clothing problem now and again.

A lot of people think they can go Agile by using Agile terms, but skip actually changing processes. For instance, one of the project teams I consulted for had all the Agile ceremonies in place. There were sprints, scrums, burndown charts.

Sprints were four weeks long – that was okay (i.e., tolerable – not necessarily right).

Scrum calls ran for an hour – NOT okay.

There were still RAG reports – unacceptable.

Every new requirement had to go through Change Control – laughable.

There were dedicated requirements sprints, dev sprints, test sprints – making for twelve-week intervals to see working product demos. So the so-called ‘sprints’ were actually twelve weeks long – not the four weeks it said on the tin.

I can understand how somebody would be disillusioned when they are forced to follow what is essentially lip service to Agile.

What to do about it:

Implement Agile and Scrum right. Period. There’s not much more to say about this. If you want your team to be invested in your efforts to go Agile, then go about it the right way.

---

Bringing it All Together

In summary, try to understand why your team/stakeholders hate Agile methodology. And address their concerns. Try to understand and respect their point of view. And show them how they can make Agile work for them. With the right effort, you will turn skeptics to lifelong champions of Agile.

Do you have your own experiences to share about influencing and winning over Agile haters? Share them in the comments section below, and let’s have a healthy discussion.

And don’t forget to share this blog with friends who might benefit as well.