Software Delivery the IJYI way

In this episode of The IJYI Way podcast series we look at software delivery and digital transformation. 

Andrew Walker joins us again as our host with the most (coffee) to bring us a fascinating look at digital transformation. 

It was a really exciting session for us as we had one of our clients join us for the podcast; Jim Overy, Head of IT and Change at Ipswich Building Society. Jim spoke to us about driving digital transformation within Ipswich Building Society and how this is enabling them to improve customer experience. 

Our IJYI lineup is a little different this week, we're delighted to have Robyne Birkby, Senior Business Analyst and Martin Dumbill, Business Development Manager join us alongside our COO Alan Jackson.

www.ijyi.com 

Transcript

Andrew:   0:05
Hello and welcome back to The IJYI Way Podcast coming to you live and direct from sunny Ipswich and IJYI's headquarters here. We've got a really interesting show today because we're talking about software delivery and digital transformation. We have joining us from Ipswich Building Society Jim Ovary, who's the head of IT and Change. Also joining us we have from the IJYI team,  Alan Jackson, Chief Operating Officer, Senior Business Analyst Robin Birkby and we also have on Martin Dumbill who is the business development manager. I'm Andrew Walker. I'm a freelance journalist. I'm sort of like IJYI's Deadbeat Uncle. I stayed over one night after a party and now I live in the loft! Let's kick off today's discussion because it's very interesting. First of all, I'd like to welcome Jim because you are a client which is very exciting. It's just I don't meet clients. They won't let me meet people very often. That's exciting for me and your head of IT and Change at Ipswich Building Society. So presumably your job is driving digital transformation.

Jim:   1:39
It is, yes as well as a number of things I cover in the society IT and digital change is also a big part of my role.

Andrew:   1:46
Okay, And here's a question. We hear a lot about digital transformation. It's kind of like a buzz word. Why are you transforming things digitally?

Jim:   0:00
I think from from our perspective, we have quite a traditional model in terms of the way that we do business with our clients. Things are obviously significantly changed in the way that a lot of businesses now engage with their customers. So I think from our perspective, it's about making sure that we remain relevant and that we are also offering those similar services, but we try to put a different spin on it from our perspective, in terms of the way we engage with customers. So we don't want to lose focus on our customers. 

:   1:57


Andrew:   0:00
Because I mean it must be difficult in financial service is sector. It's a heavily regulated space, so there must be a challenge there. And how do you innovate when you've got so many rules and regulations you have to follow?

:   2:38


Jim:   2:39
Yeah, I mean, it is incredibly difficult. Luckily, I think that most of the regulations are now taking digital transformation seriously. There's probably much more of a focus in terms of that digital piece now, so it makes it a little bit easier. But you're right. We do have to, you know, we have to stay making sure that we our customers are protected, their funds are protected, so we obviously have to follow very strict regulation and guidance. But I think, you know, as long as we are adhering to those policies, I think digital transformation is more than possible.

Andrew:   3:07
So, Martin, I'm gonna put this one over to you here because you're business development on you're working with Jim in heavily regulated environment. How does it affect your role as someone who is putting software solutions in place?  

Martin:   3:22
It's a tricky one because I think no two clients of the same. I'd say that it's around tying it into an outcome on what a client is looking to achieve, because if you can then tie into that specific deliverable, it makes it easier for everyone to understand and  it gives you a common goal to work towards and then you can understand plan for all of the elements that might make that piece up.

Andrew:   3:47
Robin. I mean, you're a business analyst, so you must be faced with constantly different changing sets of business circumstances that you've got to deal with and then turn that into a solution. I mean, what's your take on digital transformation?

Robyne:   4:04
Let's I ever case is completely different. So we take a lot of guidance from the clients themselves, and the clients generally have a good idea of what they want. So we can advise and we can give ideas. But at the end of the day, they are experts in their field, So we were only there to help them achieve their goals. 

Andrew:   4:25
I think the interesting thing for me about working with Jim and IBS and probably the challenge for Martin is one of the early bits of guidance we were given this they wanted us out of there as soon as possible, I think that's fair...? ! So they didn't want to get tied into some kind of long term reliance on a software provider they wanted someone to come in to help them deliver the reports initially, but to leave them with a trained team and a legacy of software, which they could run themselves and they could build on themselves. So you know, for Martin in the sales role, that's very counterintuitive, but we knew that we weren't gonna be out to work with them at all if we didn't listen. So we built our proposal around that. We built our proposal with a training outcome at the heart of it and I think that's what helped us win the work. 

Martin:   5:16
And I think to add to that, I think it's it's less of a...it's more about a joint relationship in terms of driving this transformation. It's not an "us and them"  relationship. You have to consider yourselves as a supplier, part of the client's team and vice versa. I think the client needs to see you as an extension of their team. That mindset really helps on those sorts of engagement so that you can really work together and get the best outcome.  

Andrew:   5:50
Now, this brings us to this interesting idea of delivery. I've sometimes heard you talk about your your work and say that you know you focus sometimes being a software delivery company and obviously, when I hear that I think of UPS right. You know, I think of someone actually delivering software. But software delivery is a lot more than that. Presumably, when you talk about training outcomes and working with clients as part of the team, it's It's a more nuanced concept than just turning up with a box with a CD in it.

Alan:   6:22
Yeah, I think the idea is that some companies say they do software development. We put the delivery word in the title rather than the development word in the title, because we're not here built tech for the sake of it. It's not a hobby. It's not something to keep people entertained. It is there to enable businesses like an IBS to achieve their goals. It's a tool software in the end, so software delivery means, for us,  means that we are focused continually on getting the right outcome as quickly as possible for the best price that we can do for our customers, we're focused on delivering for them, rather than just simply developing the software that we think's cool or we think is  useful.

Robyne:   7:02
In addition, I'd say that any code and any software that we provide it fits in a wider space so that what we're building for them is owned by the clients In the long run. so. It's things that were handing over to them, and they anything that we create is not ours. It's theirs. So we are delivering a software solution, but that solution fits into  their business and into a much wider ecosystem than just the little bit that we're working on.

Andrew:   7:34
There's an interesting point that sort of emerges from that, which is, and I'm going to put this one to Jim first, which is everything runs on software and processes. And in the digitally transformed business, increasingly, there are elements of automation, data management, that kind of stuff. So is there really a dividing line between software and business consulting in the way that, you know, there used to be a very clear delineation between what consultants did and then what the Devs produced. But it seems like those things are getting closer together?

Jim:   8:08
Yeah, I think they are. I don't I don't think there is any sort of differentiation between the two now. I think in order to be able to provide a good solution, you have to be really ingrained in what the processes are and understand what they are in order to deliver something that is going to be useful to the client. You really have to almost live and feel the business a little bit. It's not a case of just being able to sort of walk away with a spec sheet and say "There you go knock up." It just doesn't work that way anymore. And I think it goes back to the point earlier about having that sort of longer term relationship. Um, you know, from our perspective, we wanted them to come in and deliver a piece of work that allowed us to be able to offer more digital services longer term and as they said it was about delivering that piece of work and effectively being able to walk away from that and allowing us to carry on the journey internally, but understanding the way that IJYI work and the way that they helped us with the process in a way that helped development allows us to have a much stronger relationship with them because they start to understand our business and about what the challenges are for our business.

Andrew:   9:12
Presumably then Robin. That's why IJYI have a team of business analysts here as opposed to just a room full of coders.

:   9:18


Robyne:   9:19
Yes, yeah, it's our job to go in and understand the customers that we're building it for the people who are gonna be using it. Because if you don't understand the people who are gonna be using it, you may design something that's completely unusable to the people who it's meant for. You get people who aren't very tech savvy, in which case they need very simple screens. You get others who want to know how every intricate detail works, in which case, something that's really simple and just a quick button click might be a bit too novice for them. So you have to really bear in mind exactly who you're building this for in every decision that's made along the lines has to be for the particular scenarios.

Alan:   10:00
Yeah, I learned quite a long time against quite early in my project management career that there's there's a real need for a really strong business analyst in the SCRUM team. If you're going to run, the scrum process effectively with delivery in mind, then you need a business analyst because the product owner role in that environment is so all encompassing and intense, it really is the sort of key success factor in and Agile project is having the right product owner and it is not realistic in most cases to expect them to do that full roll as the textbooks might tell you. So somebody like Robyne with a real eye for detail and the ability to focus because they're dedicated to the project, really bridges the gap between what a difficult job is a product owner and the development team so the developers can focus on code. The product owner can focus on the business and the BA acts as that bridge between the two people. So the business analyst roll at IJYI really is pivotal to everything that we do.

Andrew:   0:00
So going back to those first agile principles when they talked about relationships over software well, they're really talking about is the business analyst bridging that gap between people and the technology?

Robyne:   11:11
Yeah, well, the product owners are generally coming from a different background. So  I've worked with all the developers before. I've worked in a development background before, and so I tend to know what the developers are looking for. Where as the product owners are generally business users, so they are experts in what they need and what they want, but they haven't necessarily had any experience in building the software or building a project. So I'm I'm that person who sits between them, and I am able to translate what they need into well defined user stories that the developers can then develop off. Because at the end of the day, there is a gap that internally, when we're picking up a project, we don't necessarily understand the business to the best of that that we could if we had worked for that company, and similarly, the clients don't necessarily understand how we work. So by having that bridge in between, I'm able to talk to both sides and get us all on the same page. 

Martin:   12:09
It's that process of eliminating interpretation. So the role that Robin's describing that between the B A and the product owner  minimises the interpretation which limits basically the you know, any scope, creep or misinterpretation. Something doesn't do quite as you would quite like it to. And again goes back to the relationship piece, as you develop that relationship. It means that the deliverable that you then come out with at the end is that much better, much higher quality. And I think that goes back to the challenge that the I T industry had historically of, there wasn't that relationship. It was very "us and them" in terms of business, and IT  function and that's why you would get headline news of of I T project failures. Now it's taken a change in approach and philosophy to really address that, and I think it's moving in the right direction. But that needs to continue. It can't be underplayed.

Andrew:   13:11
This raises an interesting question I think for Jim, it must be difficult in the finance sector, heavily regulated environment, people who are not all naturally engaged with IT. It must be quite difficult selling digital transformation into stakeholders and getting them to really understand the value of it.

Jim:   13:29
Oh, yeah, absolutely. I think it can be quite difficult, especially in that environment to sort of stick your head above the parapet and say "We're going to do something slightly different" because there's always a reticence to do that because you know that people are very mindful of the regulation that's entailed the constraints they have in terms of the way they deliver their business. So but I think it is about having a right engagement with someone that can help to shape what that transformation looks like and offer that sort of visibility about what actually could be achieved by migrating that and obviously the important part for digital transformation of digital transformation sorry is to make sure that you know it is still a value to the business. There's no point in just taking something and changing it for the purpose of just changing it. There has to be an intrinsic value in doing that. I think that that's a really important point that you know, that that's what's drawn out that engagement with the BAs.

Robyne:   14:19
And I think that's the useful thing about using agile in all of our projects is that we're able to then show the users, its shortening that feedback loop so that the users get hold of it sooner rather than later. They can tell us if it's working or it's not working, or if there's things that we've missed or if there's things that they get really excited about and actually they want added to it, which often is what we find. Someone will see something in front of them and go "yes that's epic!" That's what we wanted. But actually this would be really good as well. And that's where we can change out our approach. Or we can add other things and prioritise things differently.

Andrew:   14:58
Now this is an interesting point because it goes back to something one of our earlier podcast talking about the sooner you get something in front of a user the sooner you find out if it's any good.  And the reason why this is interesting having you here from a building society I was recently reading about customer call center spikes and apparently every UK bank suffered a massive spike in support calls when they introduced hardware secure keys because no one likes them, people found them hard to use. There was something like a five times increase in customer service overheads, and this is an interesting problem, isn't it? Because does it doesn't look like you solved the IT department side by putting in a new system, but that can actually cascade over into causing problems elsewhere in the business like customer services and like customer retention, those those kinds of areas. So how do you.... do you use testing to try to make sure everything is an incremental shift rather than a big change that puts people off and has them hitting the phones.

Jim:   16:00
I think certainly from a traditional. If you look at financial service is traditionally they've been based on very lots of legacy technologies where that that testing site was very drawn out. You're not really seeing anything towards the end, and by that time, a lot of cases actually, it's too late to change anything. By that point, I think whether the drive for Agile and the changes, the more iterative approach to changes allows you to almost prepare the business for what changes you're likely to need in order to address your user community or the way that they're going to engage with that product or the way your customers are gonna engage with that product, it helps you to start building those journeys early on so that there's no real surprises when it comes down to the final point. It gives you longer to engage your customers, to prepare them and let them know what's going on and what's coming around the corner. Also, in terms of your own business, to prepare your own staff to make sure that they understand what's likely to impact them when in that journey for digital piece.

Alan:   16:54
I think those card readers particularly, are a classic example of a sort of a stopgap, bridge type solution to a problem because the solution that's there for banks now is smart phones and SoftKey's that generate encryption, thumbprints stuff like this. But we obviously when they sat down and decided they had a problem about two factor authentication in these kind of things. That was the only option they had. You know, the sort of smartphones weren't in everybody's pockets quite so much and so they probably thought, and this could have been two years ago bearing in mind how long it might have taken to get this stuff done on. That was probably the right answer to a problem, but you'll see them fade out now, because there's a better way now. You know it's in direct response to the customers. So you kind of you do your best at the time, but it's more proof that sort of long cycles off, you know, product design, followed by build and sign off and issuance out to customers and things like that are not effective. So, you know, we offer things like the five day Google sprint, and I imagine if HSBC had sat down and gone "Right we've got a security problem. I want to do this card reader. Let's spend five days kicking the idea around and then test it with some users." They would have got to the Friday and realise very quickly that, you know, people did probably what I did when I received mine from Barclaycard a few months ago, which has looked at it once and shoved it in a drawer.  

Andrew:   18:16
But that raises an interesting question. I want to go out to the whole room because you all come at this from slightly different angles, which is..... Digital Transformation doesn't stop, presumably because the digital world keeps changing, which means the business processes keep changing, which means the demands in terms of what you're delivering, what the user's expect is changing from a business point of view that must put you in a challenging situation because you're constantly trying to hit a moving target with your clients.

Martin:   18:45
I think moving target is right. I think it's a mindset shift in that you know, the way that technology developed so quickly becomes that much more accessible faster. I think you know, the businesses that do well are those that take the smaller, more frequent steps maybe even to medium term steps, but definitely no longer term because things change so quickly. Consumer demand changes, technology changes, cost changes. So, you know, I think it does go to that mindset. But as you say, I think it means different things to different people. And that's why you have to work going back to that relationship element with your clients to understand what the appetite is, what it is they're trying to achieve and then target it that way.

Andrew:   19:36
I'm gonna tie it up there for now on software delivery on digital transformation. But hold that thought because in a couple of weeks we're gonna do another one of these and get out another session with the team here about how you do agile in an effective way that meets the needs of the business and meets the needs of your customers. So moving on this goodbye  from sunny Ipswich, it's goodbye from Head of I T and Change at Ipswich Building Society.,Jim Ovary. It's a good bye from Robyne Birkby, who's the senior business analyst here. Goodbye to Alan Jackson. OK and goodbye to Martin. Sorry, Alan's the chief operating officer. Sorry...

Alan:   20:16
It's not important *laughing*

Andrew:   20:16
*laughing* What could be more important than that?! I'll tell you what Business development manager Martin Dumbill. Okay. And we're all gonna wave bye bye to the camera this time, which is hilarious on the podcast because you can't see us do it. And if you want to see that clip, join us on our Twitter feed. That's @IJYILtd. That's I J Y I  . It's pronounced ee-gg because everything we do is a great example and find us online at www.ijyi.com Thanks, that was The IJYI Way.