If you really want to know what customers think, why not go to where the customers are — and ask them? That was the thinking of Bank of New Zealand’s Nigel Manning and Eric Mattlin when they embarked on what they described as “the experiment”.
The bank’s Internet and mobile software development teams have been employing Agile for around half a decade now, Manning told the Agile Australia conference yesterday. Manning and Mattlin are both product owners at BNZ.
There are a range of tools that Agile teams developing products for external customers can use to get feedback, Manning told the conference. However a few years back he was working on a project and a management team warned him that customers’ time was precious.
“These customers we’re building for — we can’t interrupt them,” he said.
“We shouldn’t go and talk to them – we know what they want, so build this and give it to the customers and they’ll be happy” was the attitude, Manning said.
“This really didn’t sit well with me”
“It got me thinking: If their time is precious and we can’t bring the customer to us – perhaps we should move the team. Move the whole development team to the customer,” he told the conference.
He spoke to management, but there were a lot of questions about the cost and security of such an approach.
“It seemed like a bridge too far to move the team,” he said.
And, on the other side of the equation, the development team was apprehensive about the idea. It would have taken them out of their comfort zone, Manning said.
The idea didn’t get off the ground.
An earthquake in Wellington, where his team was located, “re-sparked” the idea after the BNZ offices were badly damaged.
There was another round of conversations, but again the logistics of implementing the idea and apprehension about it meant that it didn’t happen.
Read more: Coding education key to Australia's competitiveness, says Shorten
Manning remained keen on the idea.
“I couldn’t move the whole team for a whole project out – what else can we do?” he said.
An ‘innovation day’ at the bank opened up a new opportunity. The innovation days allow teams a chance to work on something of their choice.
“So down tools on your project, whatever you’re working on, and you get time to innovate – work on things and problems that you might not necessarily get prioritised normally,” Manning said.
“I started thinking: If I can’t move the development team for a project, the whole project, maybe I can move a team for a day, for one of these innovation days.”
“That’s where this whole experiment was born.”
Manning and Mattlin put a team together for the innovation day.
When it came to the innovation day team “everyone opted in – everyone wanted to be there, everyone was on the same page, everyone was on board with what we were doing,” Mattlin said.
They chose a bank branch (the Willis Street branch in Wellington).
Initially there was a mixed reaction from branch staff at the news the team was going to be working out of their premises for the day. The manager was keen but other staff less certain: “There was just this massive sense of apprehension,” Mattlin said.
“Their first reaction is: ‘What are you doing here and what is this going to mean for me? You’re obviously going to probably mean more work.’”
“So we’re there. There’s this apprehension. We’ve got a little back office room. Where do we begin? We start writing down ideas of things we would like to work on – ideas and problems customers have.”
Read more: Red Hat to launch DevOps training services
“And we settled on one problem to solve for the day. That problem revolved around shoe shopping,” Manning said.
The scenario the team devised was a bank customer who had been saving for a pair of shoes using a separate account to the account linked to their bank card.
“You’re in a shoe shop and you see some shoes you want to buy… but the problem is ... how do I actually pay for these shoes?” Manning said.
“I’ve got my savings, I’ve got my card – but my card is pointing to my groceries account, or my petrol account, those types of things. It doesn’t actually have access to my savings account.”
“We built a backlog around this problem,” Manning said. That backlog was set up in the store and visible to all the customers coming and out during the day. The developers started building a mobile-based solution to the problem.
The team took along a significant collection of chocolate to use as “bribes” to get customers to participate in the feedback process. (In the end the chocolate wasn’t needed at all; its precise fate remains unknown, according to the Manning and Mattlin.)
“So we start iterating,” Manning said.
“We create a bit of a solution around this problem. We go out, we talk about the problem with the customers, we get some feedback, we come back – and we just keep looping through that.”
Early on in the process, the interaction with customers had a significant influence on development: The team ditched a home screen widget for switching the account linked to a bank card in favour of integrating a similar feature within the BNZ mobile app.
Customers felt quite uncomfortable doing their banking outside the app, Mattlin said.
“What was really interesting and also really good here, is we’d spent probably two months arguing about how much unauthenticated banking we can do outside of the app – at what level will customers cease to feel comfortable with doing that?” he said.
“We’d never really come to a conclusion. Within two hours in a store, we had a pretty firm conclusion on this one feature. So we’d burnt months talking about this and we got some really quick feedback.”
The team also found the initial UI (based around a stacked cards metaphor) was confusing. However, the feature itself was good, he said.
“People really wanted to be able to do this and they were really excited about it – they just didn’t like the way we had done it. So we scrapped it – everything.”
Even when a team understands the value of failing fast, it can be hard to discard work, he said.
“In this circumstance no-one flinched – we just got rid of it.”
The team carried out a redesign – and each member of the team went into the process having had direct customer feedback within the last half hour.
The freshness and immediacy of feedback meant that the team was forced to be mindful of the customer: “We couldn’t help but think what the customer told us – they had just told us before we did this. It was that quick.”
So the team iterated, and sought further customer feedback.
“We started the day with one question. We went through some iterations. We went through a lot of customer feedback sessions, we had this backlog of work that we slowly moved across the board as we were working through it,” Mattlin said.
“We did 24 software builds in that day. We did 22 customer sessions.”
Around seven months later, the idea which had been for the most part thrashed out during a single day entered production. (The delay entering production was not due to development work on the feature, but due to the team, outside the innovation day, having other, more pressing priorities, Mattlin and Manning told the conference.)