Seven ways to get non-software teams to adopt agility
Why don't departments which work directly with customers (i.e. Marketing, Sales, and Operations) typically talk about agility?
The question is, what do these departments actually care about?
The problem is when businesses think of these things, they don’t think of agility as the solution.
Typically the 'business' will set up an improvement program to address a whole raft of internal and external pain points. The challenge for them is to determine which pain points to focus on.
Focus on the customer experience (where is the customer feeling the most pain and where is the opportunity). It's no surprise that a happy customer does repeat business and promote your brand/products for free. Also when employees think about the customer (as opposed to efficiency and volume output), they collaborate more and create better outcomes for the customer.
So how does Customer Experience and Agility work together?
For further details see How CX can drive Agile development
7 tips on how to get non-software teams to adopt agility 1. Top-down - Get a senior sponsor to advocate.
So the first step before anything else is to get buy-in from senior leadership.
How? Senior leaders in the business are not usually excited by Agile tools and methodology, but they are excited by the customer experience.
Organisations are now linking customer metrics measures such as NPS to bonus and incentive structures. Use 'customer experience' as your way into the business.
2. Focus on the customer experience
“I’m too busy to think of the customer?”
I’ve been on projects where the measure of success is only to increased productivity (a.k.a. reduction in people), reduce costs, and increase sales.
While these are important, when budget and/or timeframes are squeezed, the first thing to suffers is quality and the customer experience.
For example, Your digitisation project has reduced the number of people required in the customer service teams. However, now the quality of service to the customer is terrible (i.e. under-resourced and disengaged staff).
This often occurs the business works in silos, and each silo only cares about their own outputs & KPIs.
My tip is to slowly get the project team to care more about the customer experience. Talk about the customer's perspective more. Ask questions about what the customer experience. Following this, start measuring the customer experience. Once this happens we can start using customer metrics as a measure of success, then linking it to reward, recognition and KPIs.
3. Don’t say Agile
For a lot of people in the business agile is something their team tried once a while back, and they concluded it only works for technology and software teams.
For example, I once knew a team which had decided to “do agile” and implemented morning stand-ups and a Kanban wall for a team of 30 people. As you might have guessed, stand-ups went for sixty minutes and the Kanban was rarely updated.
This kind of mistake often happens when organisations focused only on doing agile, rather than being agile in the way you work. Agile isn't a tool or methodology, it isn't Scrum or Kanban. It is simply living by the 4 values and 12 principles outlined in the manifesto of agile.
If your team is frequently talking to the customer(s), working in a collaborative way and constantly adjusting the solution based on changes & feedback, then you are being agile.
Top tip: Get creative on how you sneak in the 4 values and 12 principles into everyday work.
4. Small incremental steps and patience
So you just joined the new team... don’t try to solve their problems. Your first step is to build trust.
You do this by observing, listening and seeking to understand. Every team has good things about them, we don't want to lose that.
After observing for a while, try running a retrospective and validate your findings with the team. Make the team advocates for change, don't try to force it on to people.
This usually takes about 3-6 months, depending on your level of senior leadership support. The key point here is patience, and being ok with being uncomfortable and having setbacks.
5. Outcomes over Solutions
Back when I first started working I would author these 100-page design documents filled with complex diagrams and hundreds of requirements. It would account for every conceivable scenario (based on the information point in time information) and take 3 months to write and receive sign off. It would be like my baby, my creation, and I would defend it from criticism and other people's ideas, because I was the expert, I had to be right.
Eventually, after much pain, I learnt that it’s not about my solution or my idea, it is about getting the best outcome for the customer.
“Love the problem, not the solution”. This means, finding the best solution(s) to solve the problem, the best outcome for the customer. For further information see I hate the word "Idea".
6. Increase collaboration
This one is kind of obvious, but I wanted to share a story. At one of our engagements, the floor we work on had hot desking. This meant people had the freedom to sit on any desk they wanted.
However, this also meant clear desks and no blue tack or post-it notes on the walls. The only posters on the wall were reminders of no loud talking or mobile phone use.
One of the first things we did was booked out a meeting room to co-locate the team. In this immersion room, we could stick our work up on the walls, talk freely, and bring in customers and SMEs to co-design.
If co-location is not an option you can use technology to bring people together. The key is to collaborate often and frequently. Don't assume people will check their emails every second of the day.
7. Make it visual.
Rather than lecturing people about agile values, principles and tools, a more non-threatening approach is to simply make the work visible and accessible for others to see. People will notice and they will come to you to learn more.
For example, during a recent engagement we didn't just post our work on the inside of immersion room, we also displayed a five by one-metre poster for the customer journey map outside our room.
Why is it so important to make it visual?
For further information see Do Visuals Really Trump Text?
Most people do some kind of Kanban wall, maybe Journey mapping. I would ask people to try taking more photos and videos.
For example, instead of sending an email status report to your stakeholder, try taking a quick video on your phone and just do a standup explaining your wall or Kanban. Not only will it be much more entertaining, but it will save you time.
What do you think?
Have you gone through a similar challenge?
What things did you experience? Any recommendation?