Guest Rob Healy | Agile/Lean Startups
Rob Healy and I discussing agile and lean in startups.
A bit about Rob
Rob is a principal consultant with Ammeon where he provides agile and lean training, coaching and consulting services to startups, SMEs and enterprise clients. A qualified mechanical engineer and MBA, he has worked to develop and improve products and services for the nuclear industry, formula one teams, telcos and antivirus companies.In his spare time, he organises the Agile-Lean Ireland Meetup group that hosts technology meetups for Scrum Masters and Agile and Lean Coaches once a month.
Ammeon is an Irish owned Training, Consulting and IT Professional Services company. From Understanding the Fundamentals of Agile-Lean, to Operating IT Software in Production, our training services are designed to improve and fast-track your organisation's journey. We can custom-designed our courses to meet our client's specific needs and provide coaching assistance to help them integrate new processes and technologies into their working environment. Ammeon is listed on Enterprise Ireland's Lean Service Providers list and also on their Lean Education Directory.
Dave Albert: Hello, and welcome to the podcast. I’m your host, Dave Albert. In this show, I talk about technology, building a company as a CTO and co-founder, and have guest to discuss their roles in technology and entrepreneurship.
Hello, everyone. I just had the great pleasure of sitting down with Rob Healy who currently works at Ammeon. He is one of the founding members of the Agile Lean Ireland conference, also known as Ali which is also a Meetup group. He is basically an expert in agile and lean methodologies. It’s always great to sit down with him and discuss how to get better as a technologist and as a startup founder. Well, not just as a startup founder, but as an employee. So, without further ado, here is the episode. I hope you enjoy.
Rob Healy: Would you like me to introduce myself?
Rob: The good stuff. So, I’m Rob Healy. I’m a mechanical engineer. I’m from a long, long time ago, I started out my career working for a software companies making fluid mechanics solutions for oil and gas, nuclear, and Formula One teams, and from there, I kind of accidentally fell into doing work for localization, then doing work for telcos, and more and more, I worked in other industries in software, I just started to get addicted to the process side of things. I started to see passions, again, because I’m an engineer. I see the world in systems, right? And, I started to see that the systems that were common, and then Agile came along in my life, and followed by Lean, and fairly quick succession, to be fair. I started to see how the two could be used to start driving efficiencies. So, for the last year, and basically going on for two years now, I’ve been working with a company called Ammeon here in Dublin city center to drive efficiencies and help other companies improve their processes to make things work better. We say better, faster, and smarter.
Rob: That’s a little bit of speech
Dave: Thanks very much.
Rob: No problem.
Dave: So, Rob and I worked together at Symantec for a while, and I’m very happy to have you here.
Rob: Oh, thanks, man.
Dave: So, I really appreciate you coming here. Yeah, so what about the Agile and Lean that kind of hooked you so early on?
Rob: So, back in 2008, the first project I worked on basically coming out of university was a big old waterfalls projects. I was working for a nuclear industry and I was working as a tester, and they hired mechanical engineers because the software was written by physicists and PhD’s, and engineers, and we had to make sure that led could not turn into gold according to software, things make physical sense, that tea would not heat up by itself. Those are genuine real tests that we used to run. So, the first piece of software that we worked on, it was a two-year release, and at the time, that was how waterfall worked, right? That you had four years’ worth of requirements and a 2-year release and everyone walked around the building with huge, big folders, and we spent a year or something like that right thing test requirements, and then the developers at the same time were writing all their software, and then we released – we had an alpha release and a beta release, and all the rest of it, and the software was released to nuclear industry standards, released to the customers. The customers said, “Yeah, it’s cool, but we’re thinking of moving to your competitors,” and we went, “What do you mean?” and they said, “Well, with you, it was just perfect. It was perfect.” They said, “Well, think about it, right? Your competitors are delivering now every few months. We can’t wait for two years.” One of the customers were a Formula One team; that’s two full seasons. You have to go faster. So, I was lucky enough that I was enthusiastic enough. Now, I’ve changed. But, back in the day, I was enthusiastic enough to jump on board and to be in the pilot team to bring in agile across a visit big Fortune 500 company and drive it through a brand-new project, and it wasn’t without its problems. There was plenty of cynics and naysayers, but you could see from moving two years, to delivering every two weeks. Now, we were still using hard inexperience in some weird stuff like that, so we were only actually getting customer out to the customers every three months or so, but still, it was a sea change, and the software quality though, the software we were delivering went on to be what Red Bull used in their Formula One things. The laser swimsuit, the one on their records in the Beijing Olympics was built using the software and designed to be super efficient by Speedo. So, you got an immediate feedback of how powerful this thing could be, and so you just, at the time, like Agile was seven years old and I left of that company and moved to a competitor because they were based in a better place for me in London, and they were equally trying to do Agile, but when you start to see how other organizations are doing it and missing out on the tricks of that you know, that is where you get hooked, and that is where you can say simple changes can change not just like profitability and keeping companies going which is important, but equally given balance, work life balance, like in the first release that we worked on because testing have been squeezed as it always is in waterfall processes, and we were working through the nice training territory and all the rest of it. Whereas now, you are working in a sprint cycle, if you are working in scrum, and because it’s a regular cadence, there’s no need to burn out people like that. So, you’re actually looking after individuals, as well as looking after companies, it is kind of a win-win, usually.
Dave: Yeah, no, and even some of those examples you gave there were a bit more about larger enterprises and even as part of a startup, I’ve seen it hard to actually embrace some of that lean mindset, so we took a long time to get our first version out, but we were actually basing decisions on user behaviors as opposed to user interviews. Now, we did a good job with their user interviews, but making sure that our questions were very open ended and describe your problem, not do you like our solution? Because if you ask somebody, do you like our solution? Everybody likes to please other people, other than a few our souls out there, so you have to ask about the problem, and then near the end, you began to describe how your solution fits in, and if that seems like it would fit in our lives.
Rob: It’s really hard for engineers to not jump to solutions. It’s not in our makeup and it is much nicer to come into a quiet room and start coding. It’s much more difficult to go out and listen to somebody and listen to their problems and understand them. Yeah, it’s something that we see again and again, and again, even when I’m looking at Agile teams, a lot of it, I do experiments, right? And, to be setting themselves up, so it might be within an enterprise or it might be in a startup, but I do a thing, or I get them to make any kind of competition, I will have usually two teams playing off each other, and you give them virtually no rules. It might be moving ping-pong balls or throwing paper airplanes, or making paper snowflakes, any of those things. You give them virtually no rules, but a goal, and the first thing that groups of people do is set themselves incredible red tape, right? Don’t go ask so I’m I` would be open and say, I’m the customer in this world. I’m here, I’m sitting here, and looking at you, I’m ready to talk, and they will go in completely sit with little groups and try to solve a problem without ever asking fairness, and it’s something inhumanity. I don’t know if it’s all people or just engineers, but yeah, it’s definitely worth watching out for.
Dave: I totally relate. That’s one of those things as you get older, if you pay attention to your selves, you’ve learned a lot of ways not to do things.
Rob: In a sense you know, I haven’t failed. I just learned 10,000 ways it doesn’t work. I’m only at about 900, so I have a long way to go, things that don’t work.
Dave: Understood. So, with your new work with Ammeon, what would be one of the first things that the people that you go into work with, you wish that they had understood when they began before they needed your service, if that question makes sense?
Rob: No, it does. So, every time I go in, I put one word up on a board or if it is a presentation and the word is ‘fly,’ right? And, I just put it up there and I say, you need to know why you are here. What is it you are trying to achieve, where is it that you are trying to get to, but if you don’t understand that, I can’t help you. It’s back to what you were just saying a minute ago: we need to get down to the root of the problem or what we perceive to be, and then we can move at that and build off it, and so some of my clients just don’t know, particularly if they are very high-level execs that are far removed from the work that they just – then, it turns into a different question. You are asking, how does work work here? Do you know what I mean? And so, what we have to do is often, in Lean, they talk about the gamble work. It is taking these people who are often very decent, diligent people, but they have become through time and through no fault of their own removed from how work is working on the ground and go down and walk them through how work flows through the organization, and you get to see something just completely different. We had one client last year that they called us in, and of the management wanted to us to do values stream mapping and do that kind of process analysis, but they didn’t want to, in their own words, disturbed the guys were doing work on the ground. So, after about three weeks, we just went up – I’ve been locked in the room doing nothing with no data which is no, this is not going to work. You are never going to get to– what we have is a lovely theoretical model, but unless you go see for yourself, so it’s really important, and that is back to what you were saying again. You got to get out of this bedroom, you got to go talk to people and see what they are really saying and doing, and what’s the behaviors.
Dave: I’ve had a number of people at meet ups and just through my profile and things asked me, how do I go and build process, and my very first thing now – not in the past, but now is stop right there.
Dave: It’s like they come asking technologists, how do I build this technology, and it’s so odd for me to say don’t yet, wait, talk to people, make sure that you are really solving the problem as the person with the problem sees it, not as you see it as an outsider. Now, unless you have that specific problem yourself and you are building something to solve your own problem and you believe that there are more people, still, go talk to more people. It seems to really be shocking to everyone, including me.
Rob: You could be lucky, and then also, a lot of the cases that you see are people who are lucky, who paid attention to their own problems, solved that, and happened to find others, but for each one of those, there’s million that we’ve never heard about because they sold a tiny, tiny problem and everyone went, yeah, I don’t care.
Dave: Well, the other thing is that they may not all be completely wrong. They may be so close, but they spent so much time and money building in isolation what they thought was the solution that they have run out of energy, cash, time, and have the just go get a job to keep going or just torn apart because they have invested so much and Ed, and they were so close that just a minor change by listening to users.
Rob: I mean, that’s definitely – and it’s great that in the start of community and paying attention to this, one of the things that I work with is internally within Ammeon, so we have like, 150 engineers, and again, these are smart guys paying attention to problems and have an ability to solve it, but it’s the exact same problem that they have a great idea of what you do. Do you know what I mean? It’s like, what did Kodak invent? A digital camera but didn’t know how to do with this. Xerox invented the most, but didn’t know how to deal with this, and there’s an awful lot of – the startup philosophy and those startups get out of the building and go ask questions is even more nothing but two engineers working in companies because they just, what you are saying with putting a rule on themselves, they just go, I can’t leave. You know I feel; I can’t possibly do that and go explore. So, there’s a bit of work with that, trying to help a bit of innovation to and helping existing companies to keep on growing.
Dave: How do you think engineers and middle managers who do see the value in going out and talking to the customers, or users, or whatever it is, how do you see that they can bring more evidence or or have the courage to push?
Rob: In the United States, what they have to do in companies, because they feel like there is knowledge rights and all the rest of it, but the group that have helped and are helping to smash down that barrier are the UX group. UX groups who cross, and so it depends on company to company how well they are doing, but the UX philosophy and the Lean UX site is actually bringing that Lean startup mentality and bringing it into the enterprise. So, those guys are extremely good at finding customers just like – and getting out there, and asking the right types of questions, and translation between the internal people and the external people. So, like, Jeff Cusack work was really good with that, and Jake Knapp’s work with Sprint which is from an agilist perspective, the worst name he could’ve given a book in the world, but it’s still an excellent book and it gives a nice little tool set for how to get out there, and there’s some companies in Dublin and that are doing that right now and using those techniques to get out, go talk to actual customers, get real feedback and try and bring it back to the engineers.
Dave: Yeah, so that Sprint book, would that be described as a designed Sprint?
Rob: Yes, that’s exactly right, and in reality, everyone talks about design Sprint, but they put the word Sprint in it and it causes no end of confusion with people who are looking for how to do a scrum, and then they will do a design Sprint.
Dave: What exactly do you mean by that? For those who don’t know, design Sprint is basically, you take a weekend bring all the people around your team that can deliver something and try to deliver a prototype within the week. So, you start with ideation and figuring out what you’re going to solve, then you do a bit of design work – not necessarily high fidelity finished perfect design, but it is something you can put that someone’s hands.
Dave: And, they hand it to them and see what they do with it.
Rob: Precisely, yeah. On the back of it, from my perspective if I’m trying to talk to people like that, it forgets about the next step. The only weakness to that book and it is a tremendous book, just in case Jake is listening, it’s an absolutely brilliant book but it doesn’t say how to take that idea and build it into epics, build it into stories, build it into tickets, however you want to work, there has to be a way to translate that knowledge you’ve got from the customer back into the people who will actually build the full high fidelity kind of product. That’s an interesting step that has to be taught about.
Dave: That’s a really interesting point there about how to split it up, and that makes me think of something I had just written a minute ago. So, you know startups are limited in funds and people, and possibly knowledge and what’s required in agile. Myself as a CTO, I’ve almost taken part of a scrum master PO role, and it’s really hard. How can startups do the best work without those people? If you can hire them, you should because trying to do development and guide the project forward, it is a special skill set and I don’t have it. I can’t be tactical and strategic at the same time, and you need to be basically 100% both. I think I do a better job of facilitating the team, so that’s more of the scrum master role, but way less of the PO, our UX expert has a good bit of focus on individual elements of what the user demands, so from that perspective, he’s a bit of a product owner, but not of the overall picture. Do you see any ways that people in our position?
Rob: Yeah, definitely. So, there’s a couple of things to definitely try there. Scrum masters are really good starting point for this, right? So, in Dublin now, there’s three basic types of scrum masters. There is the scrum master that is an Agile coach which is the problem, kind of the classically defined scrum master. Coaches the business, coaches the product owner, coaches the team, and so on. There’s a scrum master who acts as a de facto project manager. These are people that are still command-and-control ask, you do see them in big organizations trying to get stuff done. They do an awful lot of reporting and stuff, and then the last one, is a scrum master who is also a team member, part-time scrum master. So, in startups, you have no alternative; you have to use that kind of role, right? Then, the next thing, the product owner, so one of my heroes is Mary Poppendieck, the author of software development, and she was in Dublin last year and she was talking that she’s actually not a fan of the product owner role at all, that she says it’s complete and total proxy, right? Then, when you think about it, she’s absolutely right. If you can get out to the customer and if the developers can get out to the customer, what the hell are you doing translating what they have just said. You know what I mean? You are just rewriting down at the same words again, and so she says, for smaller and nicer, if you get the people that can do the work to talk to the final customers were enough of them, then you don’t need a product owner to act as a proxy for the team. So, with those two little tricks, that is how I’d be suggesting to startups.
Dave: So, I’ve got to grab mine UX guide by the hand and drag into a customer, and the two of us sit there and listen.
Rob: Listen and do that. So, the purpose of the scrum product owner, so a scrum master and team was, is it’s a delegation technique without being command and control, right question you are empowering the team and the scrum master product owner tries to solve their problems, but in start of world, you can fully empower the team by breaking down that barrier, and using an internal coach to keep the conversations going and keep the flow of work going, right? And, at the end of the day, four, yeah, start at level, it’s dealing with chaos, it’s dealing with more chaos and Agile is really in particularly scrum is happy with. It is a survival level of chaos.
Dave: I do know what you mean.
Rob: And, this is where Ries, with his logical jump of taking Agile and jumping into the startup says you have to solve those small problems as fast as you can because you are staying alive. You have to be able to pivot rapidly, right? You are not in the lub-dub of the cadence of scrum or even at the cycle time measurement of canvass, right? Those are more stable type flows. You are in a purely chaotic flow and you are trying to get to them, that is what you are trying to do – grow and be able to sport and have the confidence that you can delegate out to individual teams.
Dave: Right, so that’s Eric Ries from Lean Startup.
Rob: From Lean Startup, yeah, yeah, yeah, and so if in the early stages, just keep it tight. Give as few people as possible right because that is your overhead which is burning down your runway. Get out in front of the customer as far as you can, right? And then, take that learning and try and get back to that customer and get cash flowing which is all important, and that’s keeping people going and stuff.
Dave: And, be ruthless with yourself in making sure that you are absolutely delivering the least amount that your users will accept, even if that group of users is small. They are probably better off with 10 users who are contacting your everyday about something than 1000 users who couldn’t care less.
Rob: And so, it’s really interesting David, so my clients, some of them are really small startups that are very infantile level, and with them, I’d be just talking about Lead canvas, the model, the cheap, and sometimes, just go, don’t do this. One of my clients, all his work is built out of networking and he was about to spend a fortune building a website, and I said, for whom? Who’s ever going to use this? And he said, “Well, I need it to compete with some of these big boys.” What I said, but you are targeting a different market, right? Oh, yeah, so there you go. People save themselves the cost of all that web design and all the rest of it, hosting, maintenance, all the time that will take them to focus on the thing to do, and in some of my other clients, one of them has grown from a six-person complete with third-person company, and the difficulty for that groups was they were still in what you are describing the tiny MVP stage and they are still in some of their engineers were doing such and such in the morning, and marching the afternoon and development, and testing, and all the rest of it, it’s only causing absolute chaos and frustration amongst the teams who are going, well, my role was to be a tester, right? And, my role is to be developer and whatnot. Your role is to be one of the architects of the whole team, so stop disturbing us all, and that getting them out that mindset than focusing on the bigger thing.
The last thing, I’d caution is it’s great for startups to focus on the minimum viable product. We have a curse in this country that we get to local maxima and the local maxima of Irish startups tend to be the UK market, right? We grow to – we move out of Ireland, which normally people to the UK which is 60 million and stop and think, yay, we won! Everything is hunky-dory, and then possibly sell at that stage, and that what goes on classically, that you listen and watch American startups and they don’t think like that. They think, we’ve got 400 million people here ish, and after that, it’s the world. It’s only a small jump to get to 8 billion.
Dave: Well, seriously, I mean, the way Asia is growing, it’s still developing in a lot of areas, but there is still growth there. The older technologies, let’s say older android phones are becoming super relevant there, so don’t ignore them just because it doesn’t seem flashy and new, and fancy. I mean, there is so much value you can get, but considering customers from any country.
Rob: A lot of my work is supported by the Enterprise Ireland and DID, and so both those groups are doing an awful lot more to try and bring the mindset away from Britain. With what’s going on today in Britain, we don’t know what Brexit would bring, and whether that market will be closed or to what degree there’ll be tyres in ports across the board. So, they are moving far more to East Asia and to China. It’s a huge markets, and I think that that’s a really good idea. Yeah, it’s interesting.
Dave: Nice. You brought up Mary Pappiendieck. Tell me what she was here for last year for the listeners. I already know.
Rob: Yeah. Mary is a hero of mine and I think she’s absolutely brilliant. She’s a lovely, lovely lady, and there was a bit of an incident when we brought her over for a meet up with Agile in Ireland and she gave a spectacular presentation on PO as a proxy, and then she went down to the pub to work with all of us, like she’s amazing. I met her at the airport and the taxi right between Dublin Airport and the hotel, she has asked me how I was getting on and was solving my clients problems for me, just genius, and so she went to the pub and she was solving a load of people’s problems, and she’s – I don’t know, I don’t know what her age is but I think she’s in her 70s, I guess? I might get into awful trouble here, but herself and her husband, I mean, she said, we would like to go back to the hotel please. Can you book us a cab? So, myself and our friend Anto, we won’t give his surname. So, we said, we would catch a train, so we jumped into the Two, and we sat into the car, and I said “Mary, would you like to sit in the front seat?” She said, “No, I’ll sit in with Tom.” So, I jumped into the front seat and little did I know, the back door was a slight detour, so Mary put her hand on the tiller of the door just as I was slamming the front door.
Dave: Oh, oh my goodness.
Rob: And so, she said – they say, don’t ever meet your heroes, and then likewise, don’t ever meet your friends.
Dave: Actually, I didn’t know that part.
Rob: Did you not know that story? Cause i know you’re getting this.
Dave: No, no, I was just leading in, so you could talk about ALI a little bit.
Rob: Oh, right. So, she was very, very good about it, even though I nearly broke her hand and we thought we would have to bring her to hospital, but she is coming back for Agile in Ireland, the Meetup group, that’s myself and a few of our friends – myself and days of friends, for the people that are listening, have organized this 2015, and we have a conference – we have the third annual conference coming up this April and Mary is one of the keynote speakers in it.
Dave: Yeah, it’s a great conference. I was at the first one in the second one, and I plan to be at the third one.
Rob: Yeah, we’re just waiting for you to put in your call for speakers you know; so that.
Dave: Well, we will see.
Rob: Good stuff. We need more startups talking about how to do this.
Dave: I might could do a small session. I wouldn’t want to do a big one because I wouldn’t feel like I have the right content for the majority of the audience because it seems that the majority of your audience at ALI is more business-facing and less technical.
Rob: So, it was really interesting, Dave, that’s an excellent question. The first year we got, because of the keynotes, we’re finding an awful lot and that affects how people come. So, the first year, we had Woody Sue, and talking about mob programming.
Dave: That was great.
Rob: It is brilliant, and I got to witness mob programming because he ran a workshop in Ammeon the day before and we had people coming in from all different companies, and having people standing up and moving around, and delivering software. We had only taken 15 minutes to rotate, amazing. Because of him, we got a large number of developers coming into learn from him, right? There was a significant number. Our regular community that comes to meet ups with the scrum Masters of product owners, Agile coaches, that’s for the regular group. In the second year, you are absolutely right, then our keynote last year was Jeff Cusack was our keynote and Henrik Kniberg, and because Jeff is far more business-focused and Henrik is just one of the best Agile coaches on the planet, it was heavily Agile, and that a lot of business because Jeff brought that side, and we have watched this, right? So, we have built this entire Meet up community and conference using the Lean startup principles that we build, measure learn, and because of that learning and the passions that we’ve seen, this year, we had made a conscientious effort for our keynotes to be spread across development, testing, business side of things, definitely Agile because that’s fading where we have come from. Lean, in general, the Mary Pappiendieck, so we are bringing a broad our community and that was definitely the goal this year, yeah.
Dave: Oh, you guys should definitely try to speak, even if they are just lightning talks at some of the technical meet ups. Just saw that; I know that us developer types can keep our heads down a little too much and only go looking for the things that we know that they are looking for. So, something like ALI, Agile Lean Ireland, may seem like it is a bit out of our realm of interest where it is not; it is 100% something we should pay attention to.
Rob: Agile was written by software developers.
Dave: Oh, yeah, yeah, absolutely, absolutely.
Rob: Absolutely and, and there’s people right now in software development that criticize it and to degrees rightly that some of the manifestations of it and the implementations of there opin are horrific. It worse than waterfall, but it is still the purpose of it, its philosophy is still for the people who are doing the work to solve their problems, and for the development community to not be paying attention for this support for exactly that. It’s trying to look after the people who are doing the work, right? All its got is its goal and ALI’s goal, so we are absolutely right. We need to be reaching out and talking the language of the people who are doing work, and it’s not even – like, one of the great people that we’ve got coming in now is Agile HR and its revolutionary. It is huge in the United States. We’ve got a guy called Kevin Empi from Mark Matters who’s going to do a workshop before the conference here. Well, we hope, anyway. So, I hope you get signed up now, but the reason being is very simple: no one in Agile would do a retrospective. It wouldn’t wait for more than a month to do a retrospective. It is not right. You know that if something is failing if you’re not looking at how you are working. However, you are perfectly happy to do an annual retrospective on your performance and pay.
Dave: Yup, that is so funny. That is exactly something that I have always had trouble with. I thought HR is one of the most important things, but the way it is done is one of the least important things. It’s keeping the business from being sued, and that is all it is, but if you are not doing regular check ins which yes, team, I do need to schedule more one on one – I’m very sorry about that, but please talk to me anytime you need to, but yes, you need to make sure that the people know where they are. Otherwise, they start to drift. I mean, I don’t know if that makes sense to anybody else, but you start to drift away and need that personal connection with the company – your managers, to make sure that everybody is working in the same direction.
Rob: And, it’s very, very new to me. I’m still reading the books on it and all the rest with this. PM Morgan, I think already accepting like it has the Agile HR book. I must lend it to you. You would enjoy it, and it’s taking Agile principles and just applying it to HR, and this is such a logical place, just like you are saying, because so much of HR and recruitment is process-focused. Quite simply process-focused, and all for, just like you’re saying, to not be sued. Documents is process-focused, but it should be learning. If an interview technique failed, why not retrospective them and improve, and get better quality candidates and keep learning? And, it’s brilliant in its simplicity and you are just trying to ask the questions, where else? Why shouldn’t we be bringing this out to further groups? So, one of my clients, I was in with them yesterday and the development team, and they were doing well by themselves, but I just wanted a bit of coaching to make sure that what they’re doing makes sense on the outside eyes, and I met the CEO, because they are still just be on startup, right? They are taking away, and I met the CEO, and I introduced myself. I said, I’m helping your development team. He said, “Oh, brilliant. Whatever you did must’ve worked because there’s definite improvement in their productivity,” and then they said, “You should talk to our marketing team. If they might enjoy that visualization of work, retrospection, seeing what is working, learning faster and all the rest of it.” Why not marketing? Why not sales? Why not all these groups?
Dave: Definitely. No, really, I think everybody tries to be perfect from the beginning way too much. I was guilty of that with this podcast. I went a year without posting an episode because I was trying to make it perfect and I’ve given up on that, and I’m just trying to make it good, and we’ve started within our own team related to our product, trying to get it good enough for now. We even got a GEFN in our slot channel. Yup, that’s GEFN, good enough for now which means we know it’s not perfect, but it delivers the value. It can let us understand that the users like this, do they not like it? If they don’t like it because it’s not fully fleshed out enough, so yeah, more experimentation in all areas of life other than maybe hard drugs, but still don’t know about that one.
Rob: Yeah, like a married African and bored.
Dave: I remember that.
Rob: Yeah, my wife is a teacher, but she just likes of the visualization and the fact that they were not tripping over each other, and I worked with a group in the civil service, and guys just know exactly what they are going to be retiring, to the date, how far away, 40 years, they are, and they were telling me they had basically invented kanban by accident. Well, certainly, they invented scrum because they used a form of visualization to work and they had a daily morning meeting that they call the Daily Grumbled that talk about the stuff they were doing yesterday, the stuff they were doing today, and what did they need to escalate to management. They invented the three questions by accident.
Dave: That’s fantastic!
Rob: Because it solved the problem, right? And, I was just teaching grads last week in our grad program in Ammeon, and I was saying to them that it was amazing, Dave, it’s amazing, the universities are all teaching Agile. We learned it out in the field, right? Because we were not taught, and the variation in the teaching that’s going on in our universities in Ireland is shocking – terrible, and some of them, you are Agile, if you have these 2 kinds of mindset, it was astonishing, but just getting them to say, this is not coming from academia. This is learning by doing and by practicing and keeping focused on that. It matters, so you keep going, keep pursuing perfection and get no wrong.
Dave: That’s exactly it. I’m never satisfied, but that does not mean I’m stressed out about not being very at. Nothing will ever be good enough. It’s always good enough for now because there’s always improvements you can make, there’s always new features you can add, or one of the things many people forget, features you can remove.
Rob: Yes, so it is so important. One of my clients state its a big study and I try and embed this with an awful lot of my clients, that they feel disconnected, the engineers feel disconnected from the business and don’t know whether it’s adding value, and I say, well, you have tools, right? It depends on the technology they are working on, but if you control the software, is there no metrics that you can be gathering if you are a cloud-based software or web-based software, but it doesn’t really matter. There’s always someway that they can put in metrics, and you can have all those metrics and yes, you can send them on to the business so that they are not just coming from a net promoter’s score that’s coming on from RXC. You can often see from the use of how webpages work. A lovely example is that people who are doing help documentation, right? Nobody ever reads the help for the crack; they believe that they are really smart so what we did was we put in Google analytics. It has bolstered shipping out PDFs. We have hosted it online, stocked in Google Analytics before it, and could stop support calls and start building features as a result because you could track the journey through the help. Nobody is reading it, so the pages that were being read for features and where they were stopping and picking up the phone to support, you had to immediately solve to help because it was failing them, it was driving them in to sport, and in more than that, start queuing of the feature to be built because to hell with calling sports, that is still expensive. You want to that is the next feature to be built, to be solved.
Dave: That’s fantastic.
Rob: And, that costs virtually nothing. In fact, they saved money by not shipping PDF and building it and spending all that time, and you just take a direct feedback from a very, very relevant live source.
Dave: Oh, I never thought about adding analytics to your help.
Rob: It’s simple, right?
Dave: Yeah, like even our FAQ. If we just add that, then that means we can do a better job in the on boarding process of describing what things are or possibly in the messaging, so yeah, that’s fantastic.
Rob: And, you see you are drop-offs too, right? So, people are getting to certain levels that are dropping off, that’s huge, it’s trickery for something like an install guide. The alarm bells need to be going off so fast because you are like, why have they stopped installing, right? There’s something gone seriously wrong. It’s annoying them in some way to know, and just simple techniques like that can add huge value. You can see the gears spinning here I know this was your idea first.
Dave: No, I’m definitely adding analytics to my help and FAQ.
Rob: I should be charging for this.
Dave: Is there anything else you want to tell us about?
Rob: So, one thing we’re doing now is we do an awful lot with love, like I see the Irish government and Irish government have Enterprise Ireland and the IDA, and other organizations, they have a program called the Lean program where they do – they pay for consultancy for seven days for Lean start, and we would use that for kind of embedding Agile and whatnot. LEAN close thing is a six-month transformation type program. Often, Ammeon would do that for DevOps doing a bigger project, but significant savings, and a Lean transform, you’re transforming the whole organization. To be fair, Ammeon can’t even do that by ourselves; we have to join up with other consultancies to do those because you’re going into finance, you’re going in across the board, but what we found when we were going out talking to people was there was something that they needed before that, and it was kind of just an induction type course, and we call it the Accelerator Program. It’s kind of a fun, little thing where it’s a kanban board with lots of different topics. and also learning about Agile, learning about scrum, learning about kanban, learning about DevOps, learning about Lean start and all the rest of it, and I get people usually over half a day to go and prioritize their own board, right? Take ownership, give them the permission to do that, and then say, “So, this is what you want to learn, and then burn down that just as you would,” if they want to learn about kanban, show them using their own work during the day as an example of the cycle time, how to measure with little’s law , or scrum in the burndown and whatnot, and so we’re using that as a precursor to the Lean start, Lean plus, and Lean anything, and so we’re still learning and you cannot slings using these startup techniques where we’ve sent out flyers to people that we know who are giving us review and feedback to improve that and keep growing it up. So, it’s still, the Agile in Ireland is in a very interesting place. Some of the big enterprises have done it, a lot of the American companies have had in enforced, dropped in on top of them. You and I know this one well.
Dave: Which doesn’t always work if there’s not buy-in as with any major initiative in a large company.
Dave: Or even a small company, really.
Rob: Precisely, and where we’re seeing an awful lot of work now is the regulation industries and that’s a really interesting place to be because those industries, their natural reaction was, because one of the Agile principles was working software over comprehensive documentation and they read that, and went, “We need comprehensive documentation.” There is no “over.”
Dave: Which is great while you’re writing documentation for months as you’ve got a bug out there that’s critical, and you’re just leaving in there because you can’t fix it until you’ve done the documentation.
Rob: Precisely, but they’re not coming around to realizing that their competitors have found the ways to achieve both, get that bug fixed while getting documentation written to a sufficient level so that you can pass your audit, you can pass your compliance, you can pass your quality control, and that’s where the big piece of work is still working, and then the last piece of work that’s doing awful lot now is DevOps is slowly, slowly kicking off, particularly in the large enterprises now. DevOps was where the development teams were accelerating, handing it across to the Operations teams who are traditionally delivering once every two years. Suddenly, they now had to deliver once every two weeks and went, “Which one of this 52 or 104 do you want us to actually install and maintain, and look after?” and so, working with that, it’s really interesting. It’s a very interesting space right now to see how the mindsets are shifting. Meanwhile, the developers are going, “Yeah, that was 2001. The entire technology stack has moved on and you guy are behind the curve.”
Dave: As always.
Rob: As always, and developers, that’s the way it will be. Good stuff.
Dave: So, for any people in startups that are listening, what one thing should they do today?
Rob: What one thing should they do today? Get out of the building. Very simple. It’s just go and get out of the building, go talk to people and let that person not be your mother or any form of blood relative. Find somebody that is a persona that is a customer you’re hoping to target, right? And, listen to them; shut up and listen to their problems.
Dave: And, here’s a good piece of advice: if you feel too awkward to do it, can you even remember what somebody at a coffee shop looked like who you talked to yesterday? You can’t, so they’re not going to remember you even if you make a fool of yourself, so who cares?
Rob: Who cares? That’s right.
Dave: You’re going to learn something and that’s the most important thing.
Rob: Correct, that’s exactly right.
Dave: And, who should contact you if they’re interested in Ammeon’s service?
Rob: Look, if you’re doing software development and you need just even a fresh set of eyes, I think it’s worth giving us a shot. We go in and we have a cup of coffee, and a lot of the time, we might say, “This is you need to be focused on a more relevant area,” or sometimes, if you’re doing just fine, don’t panic. Keep going. You know what I mean? And then, we try, and again because of our work with Enterprise Ireland, we feel like we’re doing a service for the country, for Ireland, and so we would try and shape all our programs so that Enterprise Ireland would subsidize up to 50% of anything that we do which makes consultancy services affordable for groups that cannot otherwise – couldn’t afford us. So, that really helps.
Dave: Very interesting. I have to keep that in mind. How can people reach you?
Rob: So, if you go to [email protected], that would get me, or www.ammeon.com.
Dave: I’ll add links in the description.
Rob: Then you can find us no problem at all.
Dave: Cool, and if you’re in Dublin, make sure to attend AgileLeanIreland.ie’s event which is in 126 days, am I remembering that right?
Rob: Correct. You’re very good, I know that our early birds are just about to set out, that our call for speakers are finishing up on the 30th of November, and it’s going to be on April the 25th and 26th of April.
Dave: You won’t be disappointed.
Rob: No, we make sure that we put on a good show.
Dave: It is fantastic. It’s definitely good. Thank you very much for joining us, Rob, it’s a pleasure to talk to you always and I learned something as I always do every time I talk to you.
Rob: Good! And me too, yeah, thanks, Dave.
Dave: Thanks very much.
Dave: Until next time, remember, any sufficiently advanced technology is indistinguishable from magic.