5 Years in Business - Part 2

IJYI is 5 years old! In today's episode we speak to the directors of IJYI about why we have based ourselves in Ipswich, how we run our discovery workshops and 5 day sprints and the agile manifesto. 

Transcript

Andrew:   0:03
Welcome back to the IJYI Way Podcast, here broadcasting live and direct from Ipswich, the Princess Street studios which are a large glass walled building if you're looking on the Internet, you may have seen us here before. We'll wave to the camera and say hi. Follow us on twitter @IJYILtd Come and find us.

Andrew:   0:31
Joining us today. Justin Granger, CFO

Justin:   0:33
Good morning

Andrew:   0:34
Chief Technical Officer John Nicholson

John:   0:00
Hi  

Andrew:   0:38
There we're clapping again! *laughing*

Andrew:   0:40
Alan Jackson, Chief operating officer is here.  I should point out that waving on a podcast work, you see, he's he's all about he's so Chief Operations Officer, he's all about the video. There you go, it's visual communications. Sorry, UX, we should have included that. And finally, but certainly last but not least we should say Chris Pont, our CEO and Co-Founder. Okay, let's get started..... taking up where we left off we were talking about.....

Andrew:   1:28
You've got all the hallmarks of a funky tech start-up. But you don't immediately think of Ipswich when you think of funky tech start-ups, you kind of think a little bit -  London, Shoreditch, Silicon Roundabout, as they call it. So what made you choose Ipswich as your base?

Chris:   1:45
Well I think London's really saturated in similar agencies that do things similar to what we do. Ipswich really, as well as being close to where me and John lived. It was also sort of being able to make use of the local talent. There's a lot of people who are often getting on the train just near our office and commuting into London every day, spending a couple of hours if they're lucky, along with the rat race getting into into the city. We wanted to give people an alternative really, once they got some experience, once they'd got fed up of that commute and wanted to settle down we could provide them with a decent job and a great culture to work in.

Andrew:   2:40
There's a challenge isn't there in the business of software that people often solutioneer. I've heard this word solutioneering quite a lot where the thing that worked last time, people think that's got to work this time. Where as your philosophy is much more about loving the problem, it's actually running a discovery, sprint or rapid prototyping Sprint, where you get everyone around the table, including the clients, and actually get them to explain more about their circumstances so you can really pick problems apart.

Alan:   3:14
Yeah, I mean, we have a technique which we offer to our clients, which is a five day workshop, which is, it was developed by Google in the Google, sort of in their investment sort of incubator to help start up companies overcome specific problems that might be stopping them really achieving what they want to achieve. So it's a five day process, which is design focused, and is there to solve a specific issue that somebody might have. So if a customer, for example, is unsure why a certain user group in their environment is not using their product as they want it to. Why aren't doctors taking up our medical insurance platform? Why aren't they doing that? You can use a sprint to get into how to redesign your product, to engage that user group and the great thing about Sprinted because it's five days, it za minimal investment. You get a working prototype out of it and that prototype is tested against the user's that you care about, and that all happens in five days. So you you commit some expertise from you, start your side. A vendor like E G will facilitate and commit some expertise from outside to help build the prototype. And then we get some users together, and you find out whether the idea that you have in the way you want to go forward is is a good one or not. And you obviously find out in five days rather than the typical life cycle of a decision like that, which might be several months. Eso the investment is an ex of one in terms of r a y for for someone trying to make that decision.

John:   4:51
And the great thing is, our clients loved being part of these. You know, it's it's exciting, is very, very structured, Um, and very far on. But at the end of the week, they've got some working software. They've got some feedback, something ready to take to an investment committee or an investor. Andi. It's a great process to be part off. You definitely need the public the end of the week. Once the process is complete, but it's quite a a heavy week, but it's great to be part of.

Chris:   5:22
Yeah, I mean, we didn't come up with this, you know, this is a tried and tested process that Google developed over many years. You know, we we get to benefit, and our customers get to benefit from their failures, their trials and tribulations On as Chris said, it's extremely structured down to the hour. You know what you're gonna do every hour of every day and everything drives in a very tried, tested wait water outcome of use attested idea, which is huge

Justin:   5:51
thing goes back to manifest

Andrew:   5:55
first principles. Working software over documents Taste.

Chris:   6:01
Yeah, And that's not to say there's no documentation, right? It's just you're prioritizing

John:   6:05
software. Yeah, I think that's very much part off what people make a mistake of. When they think of the agile manifesto is, they said, Well, you've got documentation. You shouldn't have documentation because you're running, scramble, your running and your processes and what it What it says is it is not saying we don't have documentation. It's not saying we don't have contracts. It's saying we prefer working software over those other things So if it's one over the other way, choose the one that offers the most benefit in the most value to the customer.

Andrew:   6:35
Yeah, and also, I suppose it's the fail early failed fast approach. Yes, sprints. A really interesting because often a barrier Thio signing up with, you know collaboration with E G. Might be from the finance director, so you know it's bespoke. Software is a big investment, often on it means sometimes, if there's a sprint evolved Aiken, talk finance director, to finance director and say, Look, there's a limited budget you need to spend here, and you will have something at the end of the day here that you can justify the spend. We can really show that you will make a return on investment. If you make the bigger investment off the back of this, it really does help overcome that nervousness.

Chris:   7:19
It's it's an interesting prices, anyway. I mean, it's the funny thing that came across when I first got involved in that is absolutely not a democracy. So this isn't a bunch of people sitting around in a room having a big sort of blue sky thinking session and a ll deciding that they agree on things like this. There's one person in the room will be the person who has the most to gain or lose from that from that decision, and they will get to decide what happens so everyone will put their ideas forward. Everyone votes, everyone goes through this happy sort of, you know, a collaborative approach. And then you turn to that decision maker and you say, What do you want to do? And they can do whatever they like so they can just disregard everything that's been voted for, do what they want, and that might sound sort of horrendous. But it actually makes a huge amount sense, because the chances are if they don't agree on the Wednesday of that week, you're gonna go through. You're gonna build the thing everybody thinks you should have. You're gonna use a test it, and then the Wednesday the following week, that person she's gonna go now I'm going to do what I wanted to do anyway. And that will happen. S o what you've lost. That that point is the ability to test the idea that was going to get implemented regardless on so you may as well front up to that fact. During the process, you let that person who ultimately is responsible, accountable for the decision making the decision. And you get that user testing done because the when that decisions made a week after that's going through that three month cycle of finding out that's going to life. So that's a big waste of money.

Andrew:   8:50
And nobody wants to spend tens of thousands, hundreds of thousands of budget to find out something doesn't work.

Chris:   8:58
Absolutely. Yeah, so this way, he goes, Depending you get within five days a pretty good independent assessment of your idea. And you also, as Justin said, gets a working prototype, which is not a couple of sheets of paper with the school on it. This will be a sort of envision or a clickable prototype on a mobile phone website could be mock ups of a magazine. You know, a marketing campaign. Whatever we decide is you decide is the right thing that you want to test.

Justin:   9:39
There isn't another statistic. That's what comes out

Andrew:   9:42
every year. There's another survey says that something like 2/3 off all the features in software packages never get touched. They never get used by the user. And this is this has been around since I started working in Software myself, which waas in the 1970 something. I'll just gloss over that. It was a long time ago. So is the whole point here the rapid prototyping to try and develop software that gets used more fully? Or is it just a question of weeding out those features that people don't want?

Chris:   10:22
Yeah, I mean, most agile methodologies, actually, rather than the Sprint is such a thing. The agile methodologies, like Scrum, are based on prioritizing the list of requirements. But by fixing the amount of time of budget, you're forced to make choices about which of those requirements actually really need to be built. You tend to be end up in a situation where most clients will prioritize, say, 70% of their list of requires absolutely must have on. Even at that half of it's not gonna get used, but at least you're better than 100% being must have. So you go 70% and then you commit to building those and your time and your budgets based around those, um, and of course, the other paradigm. That sort of address is that at the beginning they write that list of 70% of the requirements of the prioritizing, but actually it's impossible for anybody to know exactly what they want this thing to do. So the agile process, the scum process again gives regular opportunities to revisit your prioritization so you can keep shuffling things around that list. Keep batting things in, but you keep the time on the budget exactly where it is and a T end of it. You will have you because you would have been forced to choose. You will have the features that you need on dhe. There's just no room to have any more than that.

John:   11:41
Yeah, and this is our office. Often, where our clients find find most value is that when they come up with that new must have feature halfway through development on, Day said, I have to absolutely have that new feature. Um, we can say to them we can have that conversation and say, Okay, how about three items that you thought were nice tohave at the beginning? How about we swap them out for this new must have feature? Obviously, that's dependent on how big each of those those things is. But you know, often that means that we don't really have to have that time and cost conversation with them. We could weaken, simply swap out features, and they they get more benefit from what we're building for them

Andrew:   12:19
on. That's staying true to the agile manifest. So it seems like a natural thing that actually scopes can change. But your goal on the budget most difficult things that are hard to move. They don't have to change.

John:   12:32
Yeah, I mean, once once software goes into a development cycle and once people start to see something appearing in front of their eyes and we're running demos for customers every two weeks, once they see that software developing, they often come up with new ideas or new ways of achieving the same goal. New features on DSO You know it's natural that they're gonna want different things is that progresses and that's where the benefit of Scrum is with a waterfall process. You know everything's to designed upfront, you know, is locked down and you know, very rarely able to make those adjustments were scrum. It's a lot more collaborative. There's a lot more benefit customer Andi again. It's doing delivering that value, Thio.

Andrew:   13:23
So let's look for words. So it's five years now for E G. Five years from now we're your predictions about where software is gonna be with agile Go to me Is everyone going to be Dev Ops? Are we all gonna be mobile? Is it going to be augmented reality or bust eyes the only channel world coming through because, you know, I'll be honest with you. I live out in the countryside not that far from here, but I still can't get decent Internet connection in my house. So where are we going to be five years from now? For me? I want 12 Mex. That's what I want. 12 makes a broadband.

Chris:   14:07
Why talk about what I know. So in terms of where we'll be in five years, I could talk about the principles that would go behind software delivery. And as dull as it sounds, I don't think the core principles that we implant will have changed too much. I think you know the honesty, the collaboration, time, boxing, controlling, you know, focusing on controlling the time of the budget on delivering business value is just It's just obvious when you sort of virtually look at it. So I can't see that changing. I think the things that will make my job easier and the developers job easy will be the tooling that's available. I think some of the processes that are manual and a bit of a pain in the neck will become easier. I think technologies like container ization on DDE and that kind of thing will become more commonplace, more familiar and just make life easier in terms of the boring stuff, you know, deploying code, releasing, maintaining environments, the dull stuff that gets in the way. So I think the tolling will get better. And I think that's what would make things easy. And I think developers will have more exposure to it by then two. Then it will become just part of our standard tool box of what developed it does. But the basic principles they can't they won't change that. They haven't changed. Really? Okay,

Andrew:   15:19
Chris, five years from now, where are you?

John:   15:22
Yeah, well, coming back to the technology, I think you know, it's an incredibly exciting time. The technology is very much commoditized. And so, you know, everything is moving into the clouds. Everything's software as a service platform is a service. Infrastructure is the service, and so that gives some massive agility to organizations who you need to innovate. Eso I think you know the demand for our service is any any any gonna go up over the next five years? I think organizations need to innovate. They need to keep the customers happy. They need to keep ahead of the competition on bacon, gain a massive amount of benefit from having, you know, self service applications that allow their customers. Two gallons is when they need Thio. You No. One in the morning sitting downstairs in the boxer shorts, you know, rather than have to sit in a queue on a help line and wait for somebody to speak to them. So, yeah, I think it's an exciting time to be in Tech. I think there's loads out there this huge amounts of scope for what could be done with the current set of technology, and that's only gonna get better over the next five years.

Andrew:   16:28
Presumably, that means that people aren't going to be investing in whole floors of data centres like they used to having that covered at work for a small business which is full of computers. That's very hot normals to go in there because it's it's full of wires and lights and you're terrified. You won't blood something and you can't fix it.

John:   16:46
Yeah, I mean, unfortunately, Justin's Justin's now left the room. Otherwise he'd be out to talk to you about cap Ex overall effects, etcetera, and, you know, having to invest in technology that goes out of date over a 23 year period. But yeah, it means that the expertise for maintaining their systems is with Amazon. It's with Microsoft in on those sort of companies who are very, very good at what they do there. They invested incredible amount of technology into that. Andi. Therefore, you know, I t teams can concentrate on on what their best out, which is to innovate and deliver software.

Andrew:   17:20
Okay, John, five years from now,

Alan:   17:22
well, I can answer your question about better than 12 Meg. It will be that with the rollout of five G that's happening this year, there's there's a transformation coming in that space, but that's really important. What the future of technology and software is a hole we've already seen the ubiquitous nature of APS expanding and moving further. So a large portion of Internet access now is purely off a tablet or a mobile phone. Five years ago, that wasn't the case. Most of it was off their stops. We were seeing a transformation in how people are interacting. Using information on that is gonna be affecting companies. Um, some for the better. Some of the worst. Um, the way that I can see this moving forward, though, is there's gonna be a greater demand, an emphasis put on quality and test. Whatever happens, the reason for that is the way we've moved now is to lots and lots of interconnected into dependent systems. Before we would have a large application, we talked about a large big bang, e r P implementation. That large application would do everything, and it had its faults. But it was one thing that an organization could understand and test what we've moved to on dhe there's large numbers of energy companies are retail, is a great example. They have a well known CR M in place. They have their own pieces of software hanging off that they have, but their own operational systems hanging off that they're interconnected on dhe, wholly interdependent, and that's created A and creating a new, interesting problem that needs to be sold. I

John:   19:09
think time that'll back into where we think e g will be in the next five years. I think you know, our team's expanding. Its always been expanding for the last five years, but I think is that team grows. It gives us greater flexibility, toe manage resource across projects, but also thehe bility To have experts and given fields with a small team, you have to have a lot of generalists. Or is it? The team gets bigger. You can afford to have people who specialize in data Rapps people who specialize in things like a i people who specialize in container ization. So you know that gives us the ability Thio have those experts available and to share them across different projects as and when they're needed, deploy that resource effectively and that

Justin:   19:52
gives our customers a huge mouth. Obviously

Andrew:   19:57
it is alive working day here, but we're gonna be back from or off of the e g way. Keep watching the website for new podcast coming out. Keep watching the social media feeds on Twitter Act I j why I l t d I mean, you know what? The LTV iwas Just the e e g. Remember? Because everything we do is a great example on.

Justin:   20:20
We'll see you next time.