Welcome back to the IJYI Way! This week we’re discussing how Agile delivers and how we use Agile here at IJYI.

Our podcast stars this week are:
Chris Pont, CEO
Alan Jackson, Voice of Reason and COO
Robyne Birkby, Senior Business Analyst
Ben Rogers, Senior QA Engineer
Martin Dumbill, Business Development Manager

Andrew
Welcome back to the IJYI Way podcast. We are coming to you live and direct from….. where are we??? Oh steady on,  nurse!?  **Laughter**

Andrew
Welcome back to the IJYI Way podcast this week as we’re talking about where it all began no, not IJYI but agility agile methodologies and joining us to talk about this topic and how we all got involved in agile. We have in no particular order to my left. Mr Chris Pont, CEO. And a newbie for the podcast but not a newbie to IJYI and awesome Dev is Ben Rogers, Senior Quality Engineer. And joining us again the voice of reason. Alan Jackson, Chief operations officer and with Alan, another familiar voice for you on the podcast. It’s Robin Birkby Our Business Analyst and finally completing the lineup is Martin Dumbill, Business Development Manager. I’m Andrew Walker. I’m a freelance writer. I’m an old friend of IJYI. In fact, I’m so old. I remember the days before agility when agile was actually the way he referred to a singular person whose name was Giles. Nothing? No? If your name is Giles and you’ve been offended by that joke, do get in touch with us at IJYI Ltd on Twitter or send us an email to My name is Giles, and I’m offended at IJYI.com. Okay, so we are having this special two parter about agility because it’s bean so hugely transformative to the way that software is developed and of course if we go right back to the roots and start this story. The agile manifesto was originally published in 2001. But of course the process that began it began in the spring off 2000. So we’re coming up on the 20th anniversary of Agile. Chris, how did you first get involved in Agile? What’s your first memory of agile methodologies?

Chris
So I’ve done many different roles within the software development team from junior developer, midlevel developer, senior developer, technical architect, solution architect. And I remember a time when I arrived at a new client site and I you got handed a stack of 3 inch thick stack of functional specs and was told to read this and you’ve got a team of 12 somewhere, you need to keep them fed and watered and keep them working on software. You know, work your way through those requirements and let us know when you’re done and that really didn’t make a great deal of sense. So when we eventually did an Agile  transformation on the project it had a massive impact and it meant that we were delivering a lot more regularly on and the business could get to see exactly what was happening. They got to see this software taking shape in front of their eyes. So, you know, it had a massive effect on what we were doing.

Andrew
Ben, what were you doing the day the agile landed?

Ben
Oh, I think the thing was for me how agile existed for some time before I was involved in it a lot of what I was doing for probably the 1st 10 even 12 years after the agile manifesto was published, I was still working in an old waterfall or V model method so for me I was kind of a late starter to a certain extent and I would say that a lot of the early projects I was working on were what I’d come to refer to as fragile or wagile in that they with some sort of strange attempt to mix the two methodologies so that you had some elements of agile and some elements of waterfall trying to coexist and I think when they talk about it later. But I think it’s really the case that until it’s fully embraced, you don’t understand and don’t see the real benefits of an agile approach. But as I say, I think it’s only been in the last 10 or so years that I’ve been involved in 100% agile projects and seen the benefits that that can bring.

Andrew
Alan, What were you doing the day that agile dropped on you?

Alan
Oh on me? I thought you meant dropped generally, I was at university, so I probably wouldn’t remember. My first experience of agile was 2007. I got a job working for Standard and Poor’s. They were undergoing an Agile transformation. At the time, they had a new IT Manager for the EMEA region, and he was a massive fan, a chap called Jora Gill, and he was a huge fan, so he was turning EMEA into an Agile haven because most of the organisation was still more traditional as it were so I came in and got dropped straight into it and the big thing that I immediately noticed as a developer working in that environment as I was in front of the customer an awful lot more. All of a sudden I was sat there with someone at my computer mocking me because the computer said no and various things like this. But I was having to adjust very quickly to working with people who weren’t IT focused and you know , you quickly understand the company and the business you’re working for you have to you understand it a lot more quickly than you would in any of the previous jobs that I had done. So I knew the systems in previous roles but didn’t really know what they were used for. And therefore I couldn’t help make any good decisions or inform the business at all on how to make those systems better. So S and P, I found myself right in front of the people who, using them on guy felt much more a part of helping them succeed through this offer rather than I’m just building what I was told. So, yeah, I remember.

Andrew
So, Robin. I mean, you’re coming at it from a Business Analysts point of view. And often there is this association that agility refers to development, but obviously development is just an expression of another part of the business process. Right. So what was your route into Agile?

Robyne
Well, actually, I was a developer for about 10 years. I’ve never worked on a fully waterfall project. It’s all been variations of waterfal and Agile until I got to IJYI where it was all Agile. So for me, I’ve never had one of those document specs where you have to write it all upfront. And to be honest, I couldn’t imagine doing that because to have an entire mapping of how your system is going to work for months in advance and how everything’s gonna fit together. I just don’t see how that’s possible.

Andrew
Well, I mean, it turns out that generally speaking, I suppose, Agile has been really successful because it’s not possible with Waterfall. Something. Alan, you had a good phrase didn’t you which was friends don’t let friends do waterfall!

Alan
I don’t know if that was me but I mean it is possible to do Waterfall. People did it for years. It is possible. It’s just not, you know, statistically speaking, the most likely way to get a good outcome. You know, it sort of ignores the inevitable change and ignores the complexity of building software. And and also that, you know, most people who are specing software don’t always know what they want it to do. I think waterfalls very, very possible in cases where you’re building something for a very clear regulatory purpose, something that’s got legal requirements around its blooming obvious that it needs to be done a certain way. I still wouldn’t recommend it, but it is possible to do it that way. But most people, you know, for a bit of line of business software or something like this, they they really don’t know how they want it to work, and they certainly don’t know what their line of business will be doing in six months and exactly how they’ll be working. They don’t know what pressures will come under from there they’re board or from their paymasters. So Agile sort of takes away the risk of you getting it wrong ayear ahead of the project and allows you the flexibility to adapt to the changing environment throughout. So while agile still might not deliver exactly what you want 100% of the time. It just gives you a much better shot of getting it right or getting closer to where you want to be.

Chris
And I think the interesting thing for me is as people see that software being built. They tend to have other ideas, they see things taking shape, and they they get a different view on how they’re gonna use that software and how it’s going to impact their business.

Andrew
Martin, you are the business development manager here, so you must be on the sharp end. Speaking to clients. Do they do they expect now that they say, Hey, this is an agile project, right? Or are you using agile methodologies? Do they ask you about agility? Is that is it a shopping requirement now?

Martin
Not necessarily now, because I think adoption is so high. I think that going back to the point that Alan and Chris were discussing. I think for a long period of time the view for agile software development methodologies was one of trying to avoid failure. But you’ve gotta look at it the other way, and I think that’s how it’s being perceived now. Is that actually, not, only, yes. Does it mitigate risk of failure? But it adds additional value to the deliverable. So you know you can incorporate those emerging requirements those changing needs into the process and get a better deliverable out the end of it. So I think that’s what clients purchasers or whatever you want to call them. look too, from from an approach that flexibility to flex and to change their mind fundamentally, because you know nothing in the modern world, you have so many disruptors. Look at fintech. Look, a banking, you know, if you were to start a project now, who’s to say, you know, even by the end of this month, things won’t have changed, so that’s that’s what you need is the ability to change.

Andrew
That’s an interesting one, though, because, of course, the one of the things we often come up against with in my life you know, over the years with clients is they want to know exactly what they’re spending on, and this is there sort of a natural tension there. Between saying Well, we can deliver these things three months down the line, but maybe they won’t be necessary. We have to deliver other things within the budget. Do you come up against, sort of, you know, chief financial officers and people like that who want a laundry list and they won’t sign off on anything else.

Martin
Yeah, and I think that’s one of it. It still remains to be. One of its biggest challenges is that you’re not signing up in black and white in writing for what you’re going to get at the end of either an iteration, a sprint or a release or a project. Because you know, the modern business, climate and environment, people want to know what they were getting. But the addition of the ability to deliver more should outweigh that. But you’re still going to get that mindset and usually it requires an educational process, shall we say to help people change their thinking.

Andrew
Okay, So on the subject of changing thinking, I’m going to take you right back. no. I’m gonna do a quick pop quiz. So if anyone has got the briefing notes, I carefully prepared. I want you to turn them over for me. I’m gonna just a quick pop quiz test here. Can anyone tell me what is the first of the four values?

Chris
Individuals and interactions over processes and tools.

Andrew
Yes. Okay, One point to Chris. Okay, that’s that is good. Next one. What is the second of the four values?

Ben
Working software over complex documentation.

Andrew
Very good. Very close. I’ll give it to you. I’ll give it to you. It’s working software over comprehensive documentation, but that was that was pretty good. Okay, Ben. So Ben and Chris, they get to have lunch today. There’s three people left and only two values left. So one of you is going hungry? I’m just gonna put that out there. So what is the third of the values?

Alan
I have no clue

Chris
It is responding to change over following a plan.

Andrew
That’s number 4 Chris. I’m actually going to take a point off, you know, So Ben is definitely senior quality engineer in the lead that feels like the right results

Alan
so I can draw with Chris by not saying another word!

Andrew
Okay, so the 3rd 1 is customer collaboration over contract negotiation and of course, the 4th 1 was yes. Responding to change over following a plan and what was really interesting is underneath there is a line that sort of puts all that in perspective, which is, that is, while there is value in the items on the right, we value the items on the left more. So the items on the left being individuals and interactions working software, customer collaboration and responding to change.

Alan
I think that’s really important. Sorry to jump in because we get thrown at us a lot you’re not going to do documentation agile projects don’t do documentation. I think we’ve said on previous podcasts is simply not true. You just prioritise working software working code over document over comprehensive documentation. I think it says specifically as well. So you know, lightweight docks like Wikis maintained by the developer as you go along with key points and things like that, are part of standard practise because we need to know what we’re building. The rest of the team needs to know what’s being built, so it makes perfect sense. Um, and we will, at customer request, you know, produce whatever documentation is required for hand over and support and it will be done. But, you know, it’s just if you were given a choice, you had five minutes left in your day. What you spend your time doing. So that’s all it is.

Robyne
And not only that, I’d say the backlog forms part of that documentation as well. It’s not like the back of items get deleted after weeks. They’ve still got all the details in. They’ve got the history of what was checked in what was and what was built at the time. So you can see the history of every backlog item that goes on.

Chris
and yeah, I mean, the one that always gets me is the individuals and interactions over processes and tools, because I’ve worked in quite a few places where everything was done over chattels or everything was done over e mails. Nobody gets up and talks to people anymore. So, you know, I was used to make a point of getting up from a desk. Go and visit people, go on standby by them and have a chat. Ask him how that weekend was Build those relationships and you know, that’s often how you end up getting things done.

Robyne
and that those relationships are important because I’ve certainly found whenever people have felt they need to keep it in an email or in a chatter, because they feel like they need to be able to prove that that happened. And that was the decision at a time. And if you’re getting to the stage, where you having to prove that this is what was discussed and agreed, then the relationships breaking down.

Andrew
Now that’s an interesting one, because that’s something that I think most people recognise. We ever worked in a large institution, or you’ve worked with a client in a large institution that one day that the slightly complaining email arrives and it’s bean see seed to everyone you’ve ever met is that Is that something that happens a lot? So that’s a sign that you’re not being agile with your relationship building right?

Alan
I don’t see it happens a lot, but It happens, you know, absolutely does happen. And there is a need sometimes the document parts of the conversation. You know, in the end, you are in a legally binding contract with another. Another party. So But again, the manifesto just says, you know, prioritised The interactions prioritised collaboration over the oversaw, throwing the contract around all the time doesn’t say, don’t do it. Just says try, try the other way for us. And really, really, really try the other way First, you know, you should be falling back on the contract as a last resort. I mean, my experience of this is the times you end up falling back on the contract is when they, when the trust er’s has broken down or didn’t exist in the first place, maybe they’re the times. For the vast majority of the time, you can just work directly with the product owner and have a good enough relationship that you can find your way out of most 99% of situations without it coming toe contracts. But they are there for a reason. Everyone knows why they exists.

Andrew
OK, so, Ben, I want to ask you as a quality engineer, you must apply agile principles across the whole spectrum of the software is produced because I’m looking at that. We have the values. But then there are the 12 principles underpin the values. Andi. I have them here. Do I’m going to do another quick but very interestingly and I think one that sort of sits. Value Number 12 is a regular interviews. The team reflects on how to become more effective and then tunes and adjust its behaviour accordingly. Is that where the quality engineering side comes in, or does it apply right the way across the process?

Ben
I would say that it applies across the process. I mean, we’ve had numerous discussions here. Energy and in other places are work previously. Quality isn’t something which happens at the end of a process. Often you’d have in the of old waterfall days. You would have a test phase which was tagged on at the end on DH. That would be where quality was was assessed and you sort of have defects, cycles and everything there. But agile puts quality throughout the process. But you’ll notice that in all of those 12 those 12 items quality is a word isn’t mentioned it talks. We talk about working software on DH. You know what? What? He’s working Software on DH depends on what’s necessary, what the customer needs, what the agreement is for the project. So quality isn’t expressly said in any of those items, but it’s what’s needed. In order to move, the project forwards what’s needed to meet the immediate requirements on DH. Then that it’a tive process that comes as part of agile will refine and you’ll get sort of you get more actions. Mohr pieces of work mohr Um, more backlog items that will refine things because we’ve already said, as Alan and Chris have said, I think Robin as well that often the customer doesn’t necessarily know exactly what they need. Yet I haven’t got the fully rounded view, and so we will need to refine and we’ll need to do it. But to do that, you have to build quality into the process right from the get go right from sprint zero all the way through the process.

Andrew
Okay, that’s an interesting one. No, I am jumping around a little bit here with the principle. That’s something you just said really struck a chord principle number two of the agile manifesto says that we welcome changing requirements even late in development. Agile processes, harness change for the customers, competitive advantage. Now I like that last bit. When I read, we welcome changing requirements even late in development, I thought, No, you don’t. No one does. Surely is that how do you feel about changing requirements later? Development? I mean, apart from quality. Throw it.

Chris
Well, I was going to say it is. It’s really up to the product only to prioritise those those requirements so late late on in the process, they can simply put a new requirement onto the backlog and put that right the way to the top on DH say that that’s a priority. The advantage that has over Waterfall obviously is that if if a competitors comes out with a new feature or something in the mark, marketplace changes. That means that you know you could make that piece of software have a killer feature that could really give them that competitive advantage. Then you just put that new item on the backlog of sticking out the top and you know that could go into the next sprint and get delivered alongside everything else. So you know it’s got that flexibility. Where is with waterfall? You’ve you’ve got You know that planning happens up front. It could be months and months and months before anything actually gets out the door. So, you know, there’s going to be huge delays before that new killer feature could be delivered.

Andrew
Now, that’s a great point to break our agile storey. As I know we have a whole lot more to explore. But we’re coming up to the end of our time for this episode of the easy way. We will be back. I’d like to say thank you very much, Chris Pont. Thank you. Thank you very much to Ben Rogers. Thank very much on to Alan Jackson. Thank you, Aunt Robin Burke. Me.

Robyne
Thank you.

Andrew
On course to Martin Dumbbell. Thank you. Thank you all and join us on the next episode off the way. We will be talking more about a jar. You will find us, Of course, on Twitter. In the meantime, at E G Limited on, you’ll find us online at e g dot com. We’re just gonna wave bye bye now to the camera. But by bigger that that so ironic on a podcast