5 Years in Business - IJYI's 5th Birthday

IJYI is 5 years old! In today's episode we speak to the directors of IJYI about why we came into existence, how the journey has been, what our service offerings are, what they would have done differently and what the future holds!

Transcript

spk_0:   0:03
great. Hello and welcome to the first ever recording off the easy way podcast We're broadcasting here Live from E gs groovy offices in Ipswich. If you're seeing this on a video clip on the one of our social media feet, if everyone could just turn away with camera Hey. Hi. How you doing? Hello. Obviously, if you listen to it on the podcast, that'll mean nothing to you. So instead, we're going to introduce Justine Granger, our CFO. Good morning on Dhe Crisp. Aunt who? C E o. Good morning on Alan Jackson. See? Hello, everyone. My name is Andrew Walker. I'm helping out today. I'm an old friend of e g. Basically, come here. That's just this is your fifth anniversary year here in Egypt. It's spelt I j y it's know, an easy name to pronounce. I want to know what's the story behind the name. It's usually the

spk_3:   1:06
first question people ask when they come through the door on dso. So our name it was actually Purchase brand. But we liked the word because what we're trying to do was be an example of how software delivery should work would come from a consultancy, background and so with seen in many cases, things done the wrong way on dso e g really was Ah, sort of twist on the abbreviation e g g, which is Latin, for example. We wanted to be an example of how software delivery should work.

spk_0:   1:40
Did you expect to be here five years down the line? What did you think was gonna happen? Has has has the future panned out as expected,

spk_3:   1:49
A spin him much, much more different right than we expected. I think we're already always anticipated to be here in five years time in 10 years time in 20 years time. But you know how that was gonna go? We didn't really have many expectations, Really. We sort of jumped in feet first and hope for the best. In many cases,

spk_0:   2:11
E g is all about agile methodologies on. I'm gonna ask Alan. You're the chief operating off some Nazi. You this question? Okay, because everyone's all about agile. I hear agile all the time. I got an agile coffee this morning in Starbucks. Just just just around the corner. Um what? What is agile all about? What does it mean here? Egypt.

spk_4:   2:36
I mean, at Charles, a method of doing something. It isn't something in itself. So agile enables us to deliver a software effectively, but we use hopefully use. That agile methodology is particularly scram or out there. Ovation of scrum for what it was intended for is no intended to manage the whole project life cycle. It's not intended to do everything up and down the whole process of building software. It's a method for the team on dhe, the customer to use to work in a way which maximizes the amount value that you can possibly deliver for your scope for your budget on for your your time constraints. So, you know, focuses on flexing the scope and keeping the budget on the time exactly where it should be, which is where you expect it to be. So we we use you know, the elements of Squam. I believe for the right reasons. We don't try and morph him into something more than they are, and then we wrap it up in more traditional project management methods because clients big and small, like the assurance of a risk log, they like the visibility that somebody is in control and agile has a unwarranted reputation for sort of having a slight lack of control around It s o we, you know, we wrap it up on things that make people feel comfortable about what we're doing on dhe speak Thio more senior roles in our client's organizations that board levels and things like that. And we leave the depths and the product owning the people on the ground to take advantage of the agile method to get what they want.

spk_0:   4:12
Two years running, I'm looking at my notes here. Institute of Project Management in the U. S. Has reported that even with organizations have really embraced agile development, most agile projects deliver. This is an amazing statistic between 50 and 60% on average. Over a couple of years, most agile projects come in either late or over budget. Now, the reason I raise this AIDS because you for the last two years I'm going to say it. I know I shouldn't drink, but for the last two years, E g has prided itself on delivering everything on time on dhe within budget. So I'm gonna ask. Okay, how is it that you do it when most the industry According to this, these these surveys

spk_4:   5:00
is doing it wrong. Well, firstly, everyone loves to be corrected, right? So the status for I t projects generally, so I believe it includes waterfall style, traditional projects as well as agile, specific deliveries. I don't know what the stats are on agile deliveries, but I think the key for us every last two years and the thing that I've seen us do differently compared to other supplies say you're working on the same program for a bigger customer is just the level off transparency and honesty that we bring to the process. So if we if we see a problem with the software during during the prices of delivering it, specifying it right in the contract, whatever, we will say something and I watch other suppliers that we've been engaged right next to doing the same, that will not do the same thing, and they won't have the difficult conversation when it needs to be had. They will wait until it becomes an actual problem rather than just a ah thought or ah warning. You know, it's the difference between dealing with risks and dealing with issues. We prefer to have lots of small conversations about potential risk potential paying points. How we've seen this cause trouble in the future, you know, in the past on deal with them at that point, then wait for it toe blow up on, then have the conversation. So we try and head things off the thing. Earliest possible opportunity without worrying about whether we look bad or whether it's out fault or whether it's the customer's fault. It's not relevant. The project is. What's important in the deliveries was important.

spk_0:   6:38
Now this is interesting because this goes back. Read the first principles off the agile manifesto, isn't it? The 1st 1 in fact, is valuing individuals and relationships over contracts. Is that right?

spk_3:   6:54
Yeah, I think that's That's often where you know our clients get a little bit overwhelmed when they first start working with us because we need that collaboration. We need that communication to happen on. I think we even right into our contracts that we need to have a product owner assign somebody who can head up the product to be the single point of contact on DDE can have those discussions with this. You know, it's it's it's bespoke software development, so you know there's there's gonna be a lot of unknowns there, and I'm really, you know, we need to be in partnership to deal with those issues. Deal with those risks. Andi helped design a great working piece of software.

spk_4:   7:34
The other thing, The other element that's on that manifesto, his courage. And I think that's something that we we work on. We like our developers to front up personally to the customer, talk about problems, talk about issues and take ownership of resolving them. Andi also you know the project management side of things. There is no fear in saying something's gone wrong here, and there's no fear and saying it's our fault and then asking for help. And, you know, the sooner you do that in any walk of life with any

spk_3:   8:03
problem, the quicker the problem gets resolved and

spk_4:   8:06
projects run late and go over budget because the problems are not solved quickly, they are left to grow and fester.

spk_3:   8:14
Yeah, I I thinkit's about generating that culture. It's making sure there were no, we don't breed a culture of fear here. We're not blaming people all the time for any mistakes that are made more, that means is that developers are our staff, You know, they're able to be more honest with us about project progress. They're able to experiment. If they think something is likely to have a good effect on the delivery, then, yeah, they're able to to make adjustments and try that out. We're not gonna blame them for experimenting as long as you know that they're honest with us about the outcome.

spk_0:   8:48
Google did a study, didn't they? Was it two years ago about psychological safety in workplaces? On Dhe? There's no psychological safety, and you're obviously, you know, frightened of being robbed at your desk. Justin, Uh, we will borrow his marker pens. No, it's psychological safety, and so far as being able to put your hand up, it's actually this has gone wrong. That not be a problem.

spk_3:   9:17
Yeah, yeah. So you know, being able to do that means that you are developers are able to to experiment. They're able to try things out. They're able to try new things, and yet we run regular retrospectives. It's part off the scrum process. At the end of every sprint, we run a retro and we say, How did that go? Is there anything we could do? better. Anything that's worked particularly well that we think. Can you continue to work throughout? The delivery on that has some great benefits. That how we work it

spk_0:   9:51
out say it actually comes right back to the recruitment process, and our recruitment process is quite novel in that we we actually have the staff apart. Recruitment process. That stuff have to approve a new member of staff themselves. In the interview, they'll get asked him very strange questions like, What were you gonna bring to this organization? It's a no from the very start that we want

spk_2:   10:13
them to be brave. We want them to be different.

spk_4:   10:18
I think it's important to say at this point, you know, we're obviously at risk of sounding like some kind of hippie development commune here. You know, as as CEO, there is a reality to what we do. So all of this is there as a cultural influence. But the the big driver is delivery, so everybody out there knows that they have to be self critical on they have to work together, and they have to improve every point. Every project we do in the spokes software is slightly different, so there's always a need and, you know, to question the so that's what we always do. Well, that's what we did last time. Paradigm and the guys are self critical, but they've done. It is done with a a single focus and single goal, which is delivering the best software we can for you. You know, the time and budget with we've been given. It's it's not a it's not a loving

spk_3:   11:07
on get. Everything we focus on really is about delivering value to the customer. If we're doing something that isn't delivering value, if it's getting in the way, then we should really be questioning whether or not we should be doing it.

spk_0:   11:22
This is a perfect time to bring in. John Nicholson, chief technical officer here e. G and co founder from back in the day, which does imply you're, ah, a lot of older than you look. Thank you. Say that look well. So, Justin, this is a working day here at E G. Just in the chief. Financial officers had to go, and John has come in. Also, we've only got four mikes rigged up, so that's just that's the way it is. Everyone's seen that already on the camera wave to the camera job. If you're listening on the podcast, we will just waved to the camera again, which is very exciting. John. You've had a big role in shaping e g sort of outlook towards tech and agility in the way it works. And we just Bean discussed discussing this idea that actually, by doing sprints by reviewing every couple of weeks in a sprint cycle, the software develops much more organic. And of course, you're also bringing into that situation sort of move towards consulting with clients and helping glance move over to Devil pes. So, although obviously we're not all snowboarding hippies, if only if only I could still get on a snowboard there is a lot of cultural shift sort of work that goes on here with your plants.

spk_2:   12:44
Yeah, there's a large cultural shift that we try and enable. Generally speaking, the larger organizations we work with have quite a dysfunctional relationship between the business and I t. Often that's been brought about over the years by broken promises or, uh, a perception that that they can't keep the lights on, and we tend to work quite closely, both with the operations teams, the development teams, but with the business to bring them together on get them talking the same language but also focusing on what's important to the business. We have this strange dichotomy around what happens within i t. One department is tasked with literally keeping the lights on. It must never turn off the other portion off it is tasked with. You must give us the latest and greatest and newest change, um, and that there's an awful lot of friction that's caused in there. No, not dissimilar to an innovation director in a finance director in terms of one constantly wants to spend the other has to keep control on. We try and facilitate that communication and enable them to see that change is good for stability from one side of it. But also that uncontrolled change is really bad for getting innovation. So we try and bring some control in some process around that, and some of that is technology. Some of its automation, but a lot of the time, actually it's around the people on dhe, facilitating conversations a regular basis. We work in scrum for that key reason. It facilitates conversations. It's not the be all and end all its a regular point of communication that gives time boxes that gives ways of communicating, facilitating planning.

spk_0:   14:34
Now, this is one of the interesting things about gonna use afraid. Buzz jargon comes out now in digital transformation. We hear it a lot. Digital transformation on dhe, it often sounds like a huge change, like, you know, that you go from being a caterpillar into this crystal is, and then you come out with a mobile app on, you know, funky new Web, and you're the sort of digitally transformed butterfly. But in fact, what's happening in the software industry is it's not like that at all. We're actually transformation really talks about the iterated release of new code to sort of control that flow of change so it doesn't destabilize the core business. But it also doesn't mean that every three years you're gonna spend half a $1,000,000 on a whole new system from big supply, like people used to 10 years ago, right?

spk_2:   15:31
Absolutely. I would like to say that we're in a world where I t is cutting the way in. Software development is doing amazing new things around continual improvement. The reality is as a portion of the industry, we've been quite late to the show, so agile is as amazing as it is in this. It's transformed business. If we look ATT, the quality programs that came in in manufacturing in the seventies and eighties and nineties, it's just a extension of those same things. Continual improvement is something that's being a key tenant off business and successful business for decades. Now all we're doing when we're talking about it from a digital transformation or from a delivery perspective is applying it to that specific problem. We know we can't change a business overnight. The same applies the 80 systems. You can't change the entire system overnight. When you do things go wrong. We can see that in many, many public failures right now, what we try and do is instill that concept of small, incremental, manageable, low risk change because this mortuary jizz you introduce and the more confident you come in the process of change, the less risk is involved.

spk_3:   16:54
Yeah, I think it's very much evolution over revolution. So small, continual change, get good at rolling those changes out practice, putting those changes out on, then it doesn't come as much of a shock when when it actually

spk_0:   17:09
happens, if you could go back on this is really for for Chris on Dhe John as sort of the co founders. If you go back to yourselves five years ago this very month, what would be the advice you would give to yourselves about running this company about where tech was going? I

spk_3:   17:35
think from my perspective. And it's not just writing to tech already. It's Don't be so hard on yourself. You know it's a bumpy ride. Is a start up. You have to go through through these peaks and troughs. Andi. It's very, very easy. Thio do a bit too much self analysis and and yet blame yourself for some of those mistakes. But they're all they're all learning opportunities. So you know it's it's important to go through that journey if would have just gone from from the bottom to the top overnight. I don't think would have taken those learnings, and we wouldn't be as good as what we do now in the process.

spk_0:   18:12
Were you agile in the way you approach the business? That's a tricky one, Can you tell?

spk_3:   18:18
Yeah, I think So we've We've never seen ourselves as experts in any of this. S o. I think we've always been open t that inspecting adapt. It has been taking those agile concepts, and we're always looking at new ways of doing things. New ways of approaching things, new ways of mentoring star, for example, so way run a lot of coaching sessions with our staff Now with we've adapted how we run pay review structures. So taking the performance review Onda pay review separating those so that you know they're not intrinsically linked. We've taken different approaches to how we work as a management team. So it's It's a ll very much bean, you know, inspecting, adapt, work out what's not working and change it.

spk_0:   19:07
John. What? Would you go back five years? What advice would you give to Young John back then?

spk_3:   19:15
Would you still be young, John?

spk_2:   19:19
I'm definitely younger than you. I Yeah, we've definitely gone through this journey of inspecting adapt. So in that sense, I wouldn't change what we've done there. We've developed not just there's an organization but individually is managers and leaders. We've changed our approach over that time, and it's made us for better or worse, the organization that we are now and I don't think we're in a bad place. Um, I think there are bits around our journey early journey in business development, where the key thing I would go back to both of us and say You stick to your call. We we took a journey as a start of every every small business does. This will be take on everything you can, and then you start to come back to what you started out to do. Um, we there were points where we clearly went beyond what we should have, and it's in hindsight. It's very easy to identify those, but it's something that we we've learned over time to do.

spk_3:   20:30
Yeah, I think it is cos we have to wear many different different hats, and I think you know potentially. Earlier on in the journey, we could have identified where we were overstepping our marks on DDE, where we needed to hire specific roles to do those those tasks. People who were potentially were a lot better that that particular role with him we were

spk_0:   20:54
Now it's interesting. That's probably the point where I should bring Alan Lane Because your chief operating officer five years ago, what advice would you have given yourself? And did you see yourself? Were you in a big corporate? Did you see yourself working in a groovy Santa? Yes. Of

spk_4:   21:10
five years ago. I was working for a footsie 100 company will just call them name names. It was my third in a row, actually, fourth so straight out of university, that was my background. That's all done. And five years ago, I was still learning howto deliver software. Quite frankly, I got to a point. Um, for three and 1/2 years ago, what was completely disillusioned? Probably for the same reasons John and Chris were with how that was done and the process had done. And the customers were working for a night. I was crying out for something different on dhe e g. A. G gave me that opportunity. It was going from working, managing a budget of four and 1/2 1,000,000 quid in a team of 45 people on the next week. Oh, is managing a budget of 35 grand and two people and thinking, Well, this is gonna be easy, but actually, no thing there's these challenges in delivering software, whether it's big or small. But I just enjoyed the challenges in the attitude to those challenges a lot more e g then I ever had in my previous cos It's a an element of Been out to decide determine your own destiny. You know how to make decisions that affect your day to day working and also effect. You know what your future looks like? A swell as opposed to being in a big company where you you can really only change where you put the stapler on

spk_0:   22:36
your desk. So time that up that is being three e g way coming to you. Live and direct from deep switch on for beedies shiny glass walled office building here, if you don't believe us and you think it's a shoe cupboard? No, look at the social media feeds and see us on Twitter Act E g Limited. I realized saying that Now that's no easy to spell. So that's I J. Why I l t d I mean you know what the lt people Sorry. Okay, just the e g remember is everything we do is a great example on