How Agile Delivers - Part 2

In a follow-up to our first podcast, we continue the discussion on Agile.

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 

Transcript

Andrew:   0:08
Soso welcome back to the IJYI Way we are back here in sunny Ipswich, actually, it's clouded over a bit now I say that was the first week that hasn't seen Super Sunny here, but our attitudes are super sunny because we are agile. Martin doesn't like Super Sunny. I was thinking of Steve Balmer, who came on stage one time in the big Microsoft conferences. I was at and came on and went Hey, I'm super jazzed. Yeah, what's he super jazzed about? It was, actually, I think Microsoft Silverlight Remember that? Yes. So who could get jazzed about silverlight these days? Old people? S

Andrew:   0:47
We are back here talking about Agile. We have agile experts. We've got Chris Pont CEO. Ben Rogers, who's senior quality engineer with him is a voice of reason. Alan Jackson, chief operating officer and Robyn Birkby business analyst and also Martin Dumbill, business development manager. We're back talking about agile now, So the reason we're doing these now is because we're coming up to the 20th anniversary of the first meetings that led to the publishing of the Agile Manifesto in 2001 and last week we talked about the four big values of Agile, which, of course, if you can't remember I I can't I have them written down. No, which is individuals and interactions over processes and tools working software over  comprehensive documentation customer collaboration over contract negotiation and responding to change over following a plan. Of course, in 2001 this was a huge diversion from traditional ways of making software. So now we then have been talking about 12 principles that underpin that and I want to kick off with this one because it says, build projects around motivated individuals, give them the environment support they need and trust them to get the job done. Now that's Ah, interesting seems very forward looking. If you go back to 2001 does it the look of that sort of purpose driven organisation stuff, which is a big trend right now in sort of business coaching and that sort of thing. So were they really way ahead of the game or has a lot of stuff change since they published that in 2001.

Martin:   2:51
Well, I think it was a reaction because they'd already been doing similar principles in things like manufacturing, you look it, things like the Toyota Way. They've been doing them since the seventies, eighties, so I think it was forward thinking for IT at the time. But I think in the wider operational space of running businesses and promoting change within businesses, I don't think it was And I think to some extent it's still slightly behind. The ability is getting better with innovation, and technology has become a lot more accessible to do that. But I think it was very much a reaction that's helped to bring it on par with other operations.

Chris:   3:31
And I think you know, part of what that principal acknowledges is if you stop micromanaging people, they start thinking for themselves, and they just start doing what they're told. Whereas if you give people the freedom to experiment, you inspect and adapt, then they're able to come up with new ideas both within the software, but also with the process that's building the software, so it's part of what the the agile retrospective is all about. Look at how deliveries happened over the last sprint. See if there's any problems or anything that works particularly well and either stop doing the things that cause problems or keep doing the things that worked. Worked well.

Ben:   4:12
I think one of the key points to mention about that and going back to  the last podcast when we were talking about qualities giving people ownership and being part of that agile process, if they take ownership of things like the quality of what they're delivering, you get a better output at the end, because people get pride in their work and they feel like they're actually engaged and a part off what it is that they're putting out and creating for the customer.

Alan:   4:39
Yeah, I had this sort of thing about having multiple levels of sign off with documents and things like this in the past to say, If you if you add if you have three people signing off the document and then you add a 4th one it doesn't make the document any better quality at the end. What it means is persons two and three will just think that someone else they'll get it so no one actually pays any attention, and no one actually takes the ownership because even person 4 would say well, should have been picked up by 1,2 and 3 and I'm just here to rubber stamp type of thing. So if you take all of that out the way and just say that you're responsible for the quality of this and you put minimal and minimal amounts of gates and process around it and then you put intelligent, motivated people in the mix, you end up with a better quality deliverable and you end up with better ownership from a sort of delivery point of view. If you then go to people and say I'm not happy with this, then they will hold their hands up and say, Right, I will sort it out because that is my responsibility. And you say you have less of these kind of dictator type conversations where you try and make people do their jobs. I think the last thing for me on this point is that I came from a development background as well. Then moved into project management and extremely quickly realised that I had very few of the answers to the problems which were coming up and those answers were to be found in the team with the people who were actually going to solve the problem. So having tried to be too controlling, having messed it up a number of times, I came to firmly believe in this this principle as being the only way now there might be other people out there who do know all the answers and good luck to you, but certainly for us, that's not the case. So we have. It's out of necessity that we have to embrace this particular principle?

Robyn:   6:18
I think it also comes down to the sort of people that we particularly hire . But all software projects and the people who are working on these problems are problem solvers. Developers are problem solvers. That's what they want to come in and do they want to solve problems. So by giving them a problem to solve and giving them the power to be able to solve it, however they please, as long as it's within these bounds or satisfies these criteria, that is the aim is to solve this problem. It shouldn't matter how they solve the problem,

Martin:   6:51
I think we talked about in a previous podcast. You know the skills within IT and what that's driving. And I think the adoption of agile has really changed the skill set within the industry because you don't now get individuals who are purely developers or purely testers. For example, you know, you have people come in who are almost hybrid in terms of, you know, they can test, but they can also do a bit of development work or some analysis or project management. I think, you know, sitting around this table, you've got people who have done different roles within that process. And I think, you know, I think agile has got a lot of a lot to do with that, to be honest, because it places that requirement on the people involved, and it then drives that skill set and drives that enthusiasm for a quality end product,

Robyn:   7:44
It also drives the people forward. It motivates them it. It helps improve their career. They they can drive it in the ways that they want to drive it and having the ability to be able to have some control over your career, in some some control over even just the work you're doing. That's what motivates people. People like to be able to move forward and feel change.

Andrew:   8:07
If you actually go back to 2001. This was a radically different world we're talking about, wasn't it? There's there's no broadband, very low Internet sort of usage in terms of the systems we take for granted today with e-commerce and that kind of thing. They're was no mobile. There was WAP wasn't there, there was WAP and there was possibly wap commerce. I'm going, I'm going. I'm not sure I didn't do it, so I I wouldn't know. But I mean, people talk about WAP Which is while it's access protocol. For those of you who are under the age of 48 it was a very different world. We've got this proliferation of devices, platforms of interoperability and yet they seem to have correctly defined a process that would would stand the test of that massive disruption.

Alan:   9:00
I think they just understood the type of people that work in this business. They understand developers they understand, obviously worked with when they put this together very sort of capable and motivated people. They understand how those kind of people work, so you know, it's just not to go on about Brexit or anything, but there is a case for experts. You know, you do need to listen to experts. Some people are just more experienced, more capable and better at certain areas of the job, so that's great. But that doesn't mean they get to dominate. That doesn't mean they get to dictate. And that doesn't mean they get two drive their vision over everybody else's. And also those experts tend to become very thinly spread. So you're gonna get used across 5,6,7,8 different projects if you know that much about one particular thing. I mean, mostly because you can't Nobody wants to hear about that one particular thing all the time. You get spread around, so the team ultimately has to acknowledge the expertise that person take their input, but then self organise around implementation and that person also has to hear hear feedback on how their ideas actually affect what the team know. The team will know things that they don't know as well. So I think these guys have put this together, you know, they just understood the nature of the people they were talking to, when they wrote it.

Andrew:   10:16
Now does this then lead us into a quick diversion about Dev ops, which I know we've already done a podcast on it, two, in fact, but there is an interesting idea here, which is one of the principal says. Agile processes promote sustainable development. Sponsors, developers. New users should be able to maintain a constant pace indefinitely. And I think if we take that previous one about self organising teams and then we tie that up with this idea of maintaining a pace and having people working across sponsors, developers users Were they predicting the DevOps thing some sort of, what, 15 years before DevOps was actually a thing?

Chris:   10:59
I mean, it is continuous development. So, you know, with a waterfall project, obviously you end up having spikes. You end up with a very solid deadline that means that you gotta work hard to achieve and that's not to say that we don't work hard within an agile team. It means that that pace is sustained and you're constantly delivering at a  sustainable pace you're not experiencing those peaks and troughs that you would within a waterfall project

Andrew:   11:31
Does that have a big implication for something you said in the last podcast, Ben. About quality has to be built in across the whole process. So the idea that you finished building the system than you do massive testing process and then you realise all the things that don't work. And have to release loads of fixes for it, going back to the old days of Microsoft's Silver Light and the bad old days of being super jazzed at a conference. And finally, at last, that's actually that's actually the Steve Balmer alarm. That's what he does now is he's, you know, he's He's listening out. See if anyone mentioned Silverline we've won some active script. So there we go. Was it active now? What was it? Active X? Who remembers Activx way? Activex and wap. We're back in those days. So sorry, Ben. So this idea that we've got continuous attention to technical excellence and good design comes enhances agility. So that's one of the principles there on that kind of goes back to what you were talking about with sort of building quality across the process. Is there a challenge, though, in building sort of software engineering quality processes into a team that's more diverse than it ever was before? With business analysts and various other sort of people? In it? Or is that just a silly question?

Ben:   13:04
I think the thing is, it's actually in many ways. If you're embracing an agile approach where you've got a collective team which is made of a diverse scope of different disciplines, in many ways quality becomes easier because you're building in people with those different viewpoints with those different approaches. And if you can bed in that quality approach as just a systemic culture within an agile team and that ownership, as they say is mentioned before the ownership is part of it, then it actually becomes easier because everybody is taking responsibility for their part of the process. And I think, sort of harking back to one of things that has been said already there is, you know, agile had to come I think because of the speed of change in technology, we had to have a methodology that could adapt and change as fast as the technology was changing. We mentioned you said about WAP at the time of the agile sort of the manifesto came in. Things have changed so dramatically in the last 20 years. As far as technology is concerned, we have to have a process. We have to have a way of adapting to change over time and to adapt to the quality pressures that will come of being able to put something out and turn something around very, very quickly in some cases.

Andrew:   14:33
Now, on that front, I wanted to ask a question about different kinds of agile methodology because one of the things that you hear about our different approaches, 

Martin:   14:46
It's a framework, right? So you know, you'll take parts of a methodology, such as scrum, but you'd apply it to something else as well. But you know, extreme programming or whatever 

:   14:58


Robyn:   15:01
I think Martin's  on the right track, though, because it is a framework. If you if you imagine it like a trellis and then you're growing your clematis in between you, you could do what you what you want to do in Amongst that It's a framework to guide you and to keep you on the right track. But you can do with it what you please and make it suit your particular need. So it gives you the ceremonies. It gives you the responsibilities of each of the members of the team. But beyond that, and how you apply it to your project, that's up to you and your team and how what works best for you.

Alan:   15:38
So I mean, scrum is quite a bare bones sort of implementation. It doesn't actually give you that much in terms of guidance. It gives you the key roles within the team either the product owner, and the team has pretty much....and the scrum master of course I shouldn't forget, and that's kind of where it stops. I mean, if you want fit into those three rolls and then gives you the sort of four meetings or five meetings that you do every couple of weeks or every sprint doesn't define that, particularly and then gives you a few other bits of guidance. That's essentially they're saying, you know, if you and then it recommends you, then take those and implement them in a way that suits you. So we, for instance, don't follow those four or three roles as religiously a textbook would suggest So we have Robyne, for example. Robyne is a business analyst, which is nowhere to be seen in the textbook. But acts effectively as a proxy to the product owner because there is an acknowledgement in our world that the product owner is an extremely busy person comes from the client. They have a day job generally and they're not always the best person to take the job. Because the common mistake is to give you a product owner who has time, as opposed to has authority, decision making, power, assertiveness and all the other things they might need. So Robyne bridges that gap and Robyne takes away some of the activities or provides some of the expertise in some of the activities of that person wouldn't necessarily have done before, which are essential to the product owner role and also communicates with the dev teams. So we introduce a role just as an example in the middle of scrum that doesn't exist, but it's for a very good reason, and it's to get the job done and that's not anti scrum that's just working within your environment. You then get other organisations that take it up a notch. People argue that agile or scrum doesn't scale so you can't do big stuff in big organisations with scrum seven people all working on a specific small thing. That's fine but some people say you can't skate up. I don't agree with it personally, but people then introduce other methodology. Such as safe, which is the sort of scaled up, agile framework, introduces a bunch of new roles, lots and lots of other different types of people that work in and around it. And the idea of it is it's supposed to allow you to integrate agile deliveries into a large, typical large organisation structure that might have lots of architects and lots of business sign off lots of quality sign off, long winded release processes and things like this. It tries to provide the touch points into those parts of a large organisation which are missing So some people do that it's all still agile. It's all still in its at its essence, got the same intent how well it sort of works is up for debate.

Robyn:   18:29
And I think the idea of the framework is to give you an opportunity. It's the opportunity to touch base with the rest of the team. It's an opportunity to be there, look back or look forward to figure out whether you're on you're doing the right thing. The daily standups. You could just stand there and say what I did yesterday, what I'm doing today and what might be blocking me and that's as a framework works really well. But you can do that well, or you could do it badly You could have. People who aren't engaged in that meeting aren't making the most of that meeting, who weren't trying to solve the problems in that meeting, and you can have others where you actually get a lot of insight and can move forward from what you were blocked on yesterday. So each of those meetings or ceremonies are all an opportunity to be able to progress with the with the project. But that's why where what I mean about you have to make the most of of what you can with the framework

Andrew:   19:20
Now on that subject you did say that. Obviously, you have meetings where you look backwards. You look forward, and it's an interesting idea to look forwards and say OK, fine. So 20 years from now I know that's the pace of change is accelerating, so that becomes an almost completely meaningless question to us. But I am going to ask it. Nevertheless, so agile is just coming up to being 20 years old 20 years from now. Are we still going to be agile? Is it something that's going to stand the test of time or is it changing? Are there new things coming along because, you know, if the best processes emerged from self organising teams, presumably another 20 years of it and agile look slightly different?

Chris:   20:02
I  think probably the the key there is that people will be morw comfortable with the process. We still get a lot of clients who are a little nervous that they're not signing off exactly what they're getting for exactly the amount of money that they feel is appropriate for that project. So I think you know the way that's changing. More and more people will become comfortable with it is a process. More and more people will trust the development teams to deliver on those and hopefully everything works a bit better.

Robyn:   20:31
And I think it has already stood the test of time because it is we're talking about agile here and the methodologies. But actually, agile has around for a lot longer before a lot before that, because it was in Toyota and think it was in somewhere else before and wasn't recognised as agile. So actually, it's bean around for a lot more years than the 20 years we're talking about.

Andrew:   20:54
Thank you. Martin has to leave us now a little bit before the end. So we're gonna say good bye to Martin Dumbill Business development manager. By there you go. Just to show it is live and direct. And things happen here were not just AIs. Now, before I come to Ben to ask about the future of Agile, this is something I forgot to throw in. Which is, of course, a lot of the agile processes that have evolved, like, DevOps and stuff like that rely on automated testing, automated processing and, of course, over the next 20 years, presumably automation is going to be playing a much bigger role in software development. So as agile moves on, do you see yourself being replaced by a new, intelligent machine?

Ben:   21:34
Well, if I can get a cut of his money, then great. No I think is the simple answer to that I think there was a lot of I think it's if you talk to anyone, anyone looking at machine learning or AI. There are some tasks that at the moment AI cannot do. And or rather we would rather use people to do it because, you know, if we're talking about that, are we talking about the risk of developers losing their job because of an A I that's going to write the code for us. The thing is, Robyn mentioned previously about problem solving and  for developers for Q A's that creative talent of looking around a problem, discussing it, coming up with solutions and, from my perspective, coming up with ways to break those solutions and, pick the holes in them in a critical, constructive way. Obviously, that's something which you need a human creative mind to come, right? Yes, the job will change, no doubt about that because, you know, for me over the last 20 years, my job and my jobs have changed as technology develops and we move into a more automated method. But that's not to say that will be all out of a job.  

Alan:   22:52
I think if you look back to the origins of all this, so you go back to manufacturing. Manufacturing has gone through a huge amount of automation in terms of build and testing and in various places in the cycle. But there is still an extremely important human element, especially in anything that becomes vaguely bespoke. And what we do is bespoke. We're not producing the same car and over and over and over again on a production line, and even if we were manufacturing, would tell you there's still a big human involvement in setting quality benchmarks, monitoring, spot checking, checking that the robots have configured doing all these kind of things. You know, you still need people. So in a bespoke environment like ours, you're definitely definitely going to need people. I think that quite frankly, we're greedy, so if you are, the more you automate the more people expect to be delivered, that's all that happens, so it just allows. It doesn't allow you to sort of take people out the equation. It just allows you to doom or get more bang for your buck. The person still there, it's just they've got 15 units of code coming out the other end rather than 10. Now that's what the automation side of it gives you, and people are still going still, especially in quality. I think, especially in quality, is going to be needed to Judge it because it's a subjective benchmark,

Robyn:   24:05
And I think largely it'll be the problem that changes there will always be problems to solve. There will always be. It might be a different type of project problem. It might be that we're we're creating the neuro network machine learning techniques rather than websites, but we're still gonna need some input. 

Alan:   24:26
You get the robot to build the website right there. There's still gonna be somebody stretching their brain doing that, doing the really hard stuff, and I think that's that's where it will end up. Ben's  job is still safe!

:   25:14


Andrew:   25:15
Thank you. Do come back for another episode of The IJYI Way we're now waving at the camera again.