Multichannel Success Podcast Season 3 Episode 7 - Transcript
Why Agile is dead
David Kohn [00:00:11 - 00:00:38]
I'm David Kohn and I'm here today with my regular partners David Worby and Mark Pinkerton of Prospero to talk about the death of Agile, or to paraphrase, how do I get more development done more quickly and at less cost. Now, I think it would be helpful for our listeners if the two of you were able to define for them what is Agile and why is it relevant to them, why is it relevant to e-commerce professionals. David.
David Worby [00:00:39 - 00:01:12]
Well, I think it's relevant because it's a buzzword. A lot of people are using capital A Agile methodologies to deliver change in their businesses. It's not the most traditional way. It's quite new. I guess probably when I was doing it, the traditional methodologies included Waterfall, which is still being used, but Agile has become the default option, and many businesses aspire to delivering change via an Agile methodology, which we can talk a little bit about the core components of. Mark, do you want to go first?
Mark Pinkerton [00:01:12 - 00:01:17]
Yeah, I think, as you've just said, waterfall-based projects were kind of the norm,
Prince2 dominated as a methodology. Anybody who did an old IBM implementation in the 90s will probably remember that. But as the 21st century has gone on, Agile has, as you say, become completely the default and something like three quarters of companies now use Agile as the principal methodology. The reason why they have done that is because Agile has been shown to deliver projects better, cheaper, faster. But it is a collection of methodologies wrapped up as one sort of overall mindset. You have to have an Agile mindset, because without that, it's horribly challenging.
David Kohn [00:01:56 - 00:02:08]
Because without that, it's horribly challenging. Let's look at that mindset. I mean, that seems to be Agile with a small a, rather than Agile with a capital A. What are the components of that mindset?
Mark Pinkerton [00:02:08 - 00:02:58]
So, I mean, I would always go back to the original sort of Agile manifesto, which was from 2001, something like that, where you've got the key components of Agile. The highest priority is actually having multiple short-term drops of software. So code that works, ideally every two weeks, as opposed to phase one at the end of Q1, phase two at the end of Q2, which is kind of the sequence we had under Pure Waterfall. Also, in Agile, is the fact that it focuses on working software, not on documentation, which can be a challenge in some circumstances. And it also works on the basis of having a collaborative environment with teams working together in small scrum teams.
David Worby [00:02:59 - 00:03:36]
Yeah and I think that we'll come on a bit later to some of the challenges, but some of the fundamentals of capital A Agile that cause challenges are around how you define the vision, how you define what you're actually trying to deliver with this asset called people and cost, and for me there seems to be around Agile less of a determination to define the end point and more of a journey. So there's kind of a vision of what might emerge at the So there's that.
David Worby [00:03:36 - 00:04:19]
Completely. end and certainly in the case of how it emerges there's a lot of variability given to the people in the team to determine exactly how they deliver it and what you actually deliver at the end point. And I like that idea in one sense because it means that no one person really knows what the end should be and a collection of people who are minded to think that way are set the responsibility of defining that. But as managers I think that can be quite frustrating because it means you've got open-ended potential budgets and you've got open-ended timeframes in which that vision that you haven't necessarily specified may be delivered. So that's a tenet but it's also a challenge.
Mark Pinkerton [00:04:19 - 00:04:35]
But it's also why Agile teams tend to be small teams, is the whole sort of Amazon two-pizza rule with big American pizzas, you know, so you don't have more than a dozen people on a team working on things.
David Kohn [00:04:35 - 00:04:48]
Well, I think just to take that a bit further, before we go into look at some of the pitfalls and the challenges, why Agile? What's good about it? Why use it rather than some of the more traditional methodologies?
David Worby [00:04:48 - 00:05:33]
Yeah, and I think the uptake of it is significant. So there is something about it that appeals to people. Apart from the fact that it's new and progressive, I think there are other there are elements of it that I think are really forward thinking. First of all, is the concept of delivering an MVP. In short order, you deliver something that's working, and you coalesce around the working product in the subsequent timeframe to improve it, finesse it, optimise it, and get it to be even better. That concept I think is great because for businesses it means you, in short order, you see something. You see something that reflects in broad terms what you're trying to achieve, and I think that's a huge value for businesses.
Mark Pinkerton [00:05:33 - 00:05:57]
But, you know, I mean, you know, one of the challenges around that is the fact that when the MVP lands, it can be way under the end product, because you've got to iterate to get to the perceived end product. So a business person can often be very disappointed with what the MVP will be. Yes, yes, yes.
David Worby [00:05:56 - 00:05:57]
Yes.
Mark Pinkerton [00:05:57 - 00:05:59]
So that's about managing expectations.
David Worby [00:05:57 - 00:06:03]
That's about managing expectations. That can be done albeit that it's
Mark Pinkerton [00:05:59 - 00:06:01]
That's about managing expectations, yes.
David Worby [00:06:03 - 00:06:55]
sometimes difficult. I think one of the other things we should just say actually we're we're looking at this through the lens of multi-channel success so we're not thinking of big tech led businesses we're talking about multi- channel businesses principally in UK and Europe adopting this so we in doing that we're acknowledging that there's many more elements to their world than just developing tech so they've often got shops they've got catalogs they've got call centers and therefore the business has a good sense of the other stakeholders that are involved in delivering change it might be marketing it might be operations it might be finance so there are other people involved but often scrums are limited to technical people and people who are going to be running that code in day-to-day life and I think that can sometimes be a problem.
Mark Pinkerton [00:06:54 - 00:07:12]
I would challenge that because I don't think scrum teams are just technical. They have project people, they have suitable disciplines. If you need a UX person, you would have a UX person on every scrum team. If you need design, that's why you have design libraries and design protocols.
David Worby [00:07:13 - 00:07:20]
I'm going to push back on that because in all my experience of seeing Agile, I've never
seen a finance person in an Agile team, I've never seen an operations person, I've never
seen a marketing person. I've seen marketing people and I've seen operations people. They get dragged in occasionally because they're theoretically supposed to be part of it, but
Mark Pinkerton [00:07:33 - 00:07:40]
And that's back to one of the challenges, but the key reason for using Agile is that]
it is faster to do stuff and there are organisations, big sort of behemoth type organisations like banks, like Bosch, who make power tools and everything that goes in a car from an electric motor point of view, who have gone very Agile in terms of the way that they produce stuff. So that's not just about software, that's actually about making stuff as well. And they have either massively increased their throughput or that they have actually cut their development time in half. And I think that's a good example for use in a multi-channel world because it's not like Google or Apple or Facebook where clearly they're tech led.
David Kohn [00:08:21 - 00:08:43]
But just to probe into this a little bit more, what sort of projects does it suit? What sort of organisations does it suit? My perception has always been that it suits smaller organisations, that more than bigger organisations it suits smaller projects rather than bigger projects. What's your perception?
Mark Pinkerton [00:08:43 - 00:09:11]
My perception is that I wouldn't use it to build a new London bridge, but I think, you know, the definition of small and big is relatively arbitrary in this. I would expect any sort of software-based development up to a really big size to use Agile, and really big would be, I don't know, I mean an operating system for a car is pretty big, I would expect that to use Agile.
David Kohn [00:09:12 - 00:09:21]
So again, just to probe this a little more, so let's say I'm a multi-channel retailer and I'm putting in a new ERP.
You're suggesting that Agile is as good for that as it would be if I was putting a new search engine or a new recommendation into my website.
Mark Pinkerton [00:09:30 - 00:09:37]
That's an interesting challenge because I think my experience of ERP is relatively limited
David Kohn [00:09:31 - 00:09:34]
That's an interesting challenge because I've not, I've...
Mark Pinkerton [00:09:37 - 00:09:51]
to people putting in SAP, which has always been in a waterfall, or Microsoft Dynamics, which is also generally they use waterfall methodologies. Well, Mark's going to say yes and I'm going to say no.
David Worby [00:09:48 - 00:10:38]
Well, Mark's going to say yes and I'm going to say no, and I'm going to say no because I think that as a project in a multi-channel environment, where let's say digital is 25% of the business, the other 75 requires the ERP to power tills in stores, pulse technology, customer data, all that kind of stuff, that that is a high risk, that's a heart and lung transplant there all in one, in one go, and I don't think the open-ended nature of Agile allows for that to be carefully enough considered. The concept of allowing developers and scrum teams to determine the end point of a heart and lung transplant, to me, is introducing a level of risk that I think is probably unacceptable.
Mark Pinkerton [00:10:39 - 00:11:12]
My challenge to that would be that I think there are ways that you could chunk up the ERP work into elements that you could deliver a working solution for, which you can then iterate. You may not make it go live at that point, but you could put in a new stock management component, which you've made, or multiple components that you've made in an agile way, and then swap over to those components.
David Kohn [00:11:12 - 00:11:14]
So
David Worby [00:11:12 - 00:11:14]
So Mark's saying yes.
Mark Pinkerton [00:11:12 - 00:11:14]
So Mark's saying yes and no. So I'm saying yes.
David Kohn [00:11:13 - 00:11:17]
In fairness, if I'm allowed an opinion on this, I'm probably more with David here.
David Kohn [00:11:17 - 00:11:37]
Things like order management systems, ERPs, there's no way of implementing them in parts. You pretty well have to put the whole thing in in one go. And that's why I'm intrigued as to whether or not Agile is a good methodology for building something like that. And particularly where there's this concept of an MVP.
Mark Pinkerton [00:11:37 - 00:12:18]
Well, the reason why it's a good methodology is because it is almost impossible to pre-determine exactly the requirements that you need when you press go on an ERP solution, which is why so many of them are terrible. How many SAP projects do you know that have overrun, you know, I've worked with a fashion retailer where it went from being a two million to a nine million project, massive costs overrun from those sorts of things, and they had, I don't know, up to about a dozen business people working full time on the project to try and get the requirements understood and nailed.
David Worby [00:12:18 - 00:13:23]
To answer your question, from a knowledge perspective, Mark and I have a client who we won't name, but they're a large German food retailer beginning with the letter A, and they have a process through which they've adopted Agile for a particular part of their development. And it's a huge thing. It's a massive project, and it's delivering great change. Now, it's hugely costly, and it's a very large organisation of people, but it is delivering change through an iterative Agile approach for one of their countries around the world. So, although we talk about maybe a small multichannel retailer trying to replace an ERP system, I wouldn't advocate an Agile approach to that. I can give you a good example of a much, much, much, much bigger project that is delivering. Now, we are talking about significant investment, and maybe efficiency might come under the scrutiny at some point, but that is delivering good change for them.
David Kohn [00:13:24 - 00:13:38]
One of the things you've both touched on there is the issue of budgetary control. Does it suit a fixed price project or is it totally unsuitable for a fixed price project?
Mark Pinkerton [00:13:31 - 00:13:33]
I think that's a challenge.
David Kohn [00:13:38 - 00:13:40]
That's one of its big challenges.
David Worby [00:13:38 - 00:13:51]
That's one of its big challenges, because what you're saying is in the waterfall world, one might define the end point quite precisely. We know we're there when the following has been achieved. And I will pay you at that point.
Mark Pinkerton [00:13:49 - 00:13:51]
And I will pay you at that point.
David Worby [00:13:51 - 00:14:02]
You can cost that with some degree of success, with maybe some cushions in there. You can define that, and therefore you have control over your time and budget constraints.
Mark Pinkerton [00:14:02 - 00:15:08]
Whereas in Agile you have control over the budget in that you have probably a fixed team size and you therefore know what your monthly outlay will be on that fixed team. The whole concept of Agile is that you have a delivery engine that then you manage so that engine is working at as close to 100% capacity as you can go for the foreseeable future. The challenge is then trying to get that delivery engine to actually produce all of the things that you want of it because you can't flex it up and down. To launch products faster and more efficiently, find out more at GoSwift.com
David Kohn [00:15:21 - 00:15:26]
Hello again. I'd like to move on now, guys, to some of the pitfalls. I think we've touched
Mark Pinkerton [00:15:21 - 00:15:22]
Hello again.
David Kohn [00:15:26 - 00:15:37]
on one or two of them, but we headlined this podcast, The Death of Agile. Why are we even talking about the death of Agile? What are the problems with it?
Mark Pinkerton [00:15:37 - 00:16:17]
I think the seminal reason why we're talking about the death of Agile is because over the last probably four years there have been articles appearing about the death of Agile and certainly the one that I read most recently that was kind of triggered perhaps this whole podcast was the fact that McKinsey have set up an Agile transformation office as a part of the sort of methodology of managing Agile which is completely the antithesis of Agile because you don't have a PMO, you don't have the Project Management Office which is effectively what they've generated an Agile version of. It goes against the whole methodology and philosophy of Agile.
David Worby [00:16:18 - 00:17:39]
Yeah, so I think in a vacuum it's very difficult to talk about the death of Agile. It's the context that matters. So we're talking about multi-channel retail. And I think in that sense we're saying Agile is dead. Slightly controversial, but it has a lot of problems and therefore we would be wary. One of the things we haven't talked about in those challenges though is the very nature of how multi-functional teams are created. And if you are a multi- channel retailer where you have all these other stakeholders who are not immersed in technology and how you bring them in to that decision-making process that happens every day or every week in your scrums or your stand-ups, it's difficult. It's difficult for groups of developers who spend all their 40 hours a week developing code for this project to then have someone drop in for an hour a week from another discipline. And it's equally difficult for that individual dropped in because they don't have context. They don't have an understanding of the whole thing. They have a day job to do. They might be organising a variety of other marketing activities or operational activities or back-of-house stuff. And then they're dropped into this team in which they are supposed to influence the outcome. That's very difficult when you're a real part-timer.
David Kohn [00:17:39 - 00:17:50]
And Mark, you've talked off camera about the difficulties of scaling, is this the sort of thing that you're talking about, the difficulty in getting different departments to collaborate?
Mark Pinkerton [00:17:50 - 00:19:38]
Well, I think it's twofold. One, if you, let's address that one first. I think, yes, it is difficult to get teams to collaborate. And we had one client, which was a fashion retailer, where the agile team was the in-house IT team, and they had literally no input from the business. And therefore, they were having to decide every possible variation and cover every single possible outcome with what they were coding, which just led to madness. And things were just ground to a halt as a result of that, because they didn't have any direction coming in. But that's at both a high level and an operational level, that was. But we've also seen clients where they have, you know, three, four hundred people in an in-house development team, and that's not producing the output that it should do either. Even though they are fully agile, they've got scrum coaches, they've got product owners, they've got all of that sort of stuff. But they didn't have a shared vision. They couldn't all enunciate what they were trying to do. And the other point was that they didn't have any sort of transparency. Agile only works if people all have a good understanding of the vision and that everything is transparent, so that you can work out the dependency on, you know, say you're doing something over here in team A, and actually there's a dependency coming at you from team B and another one from team D, that you can actually go and talk to those people and find out and work it out collaboratively, and therefore do the right thing in what you're doing. And if you don't have that transparency, it's just not going to work.
David Kohn [00:19:35 - 00:19:55]
And if you don't have that transparency, it's just not going to work. What you touched on there, which has always struck me as being one of the potential issues, is the lack of clarity from the business as to what they actually want, and almost Agile becomes an excuse for not really thinking about what do I really want.
David Worby [00:19:55 - 00:21:00]
I think that that lack of determination to define the end point is one of the biggest challenges for me. You know in the old days we used to have BAs and their job was to in effect become the business voice for what this project was all about. To determine or to help determine that end point and now of course we don't really have BAs anymore. We may have project managers of course but generally speaking these things are managed through the scrum. The scrum master would be responsible for that now and I think they're widely perceived to be more technology focused than they are business focused. So we've lost a little bit of that business definition that we used to have and I think whilst Agile doesn't require that, if I was a business leader today I would feel very vulnerable embarking on a lengthy costly overseas journey to change my whatever system without having a clear understanding of when I was likely to get there and what the cost would be.
Mark Pinkerton [00:20:56 - 00:21:39]
The challenge for any organisation is actually that the people who are doing the day job, day to day, might not know what good looks like and therefore how can they determine what those requirements, to use the old fashioned term, would be for that particular module. Is this the definition of done? It's partly the definition of done, which is another challenge because you have software people, coders who will produce something and, you know, say it's a search mechanism and it works because it produces some results, but actually the definition of done needs to be that it produces user-friendly results that are understandable and make sense.
David Kohn [00:21:39 - 00:21:53]
Well, I think you touch on something there that I find a really interesting aspect of this is what's done to the developer may very much not be what's done to the business owner.
Mark Pinkerton [00:21:53 - 00:21:59]
Yes, which is why you have to clarify what the definition of done is, which is a technical
term from the Agile Press methodology. You have to say what good enough actually is.
David Worby [00:22:05 - 00:22:20]
Which I do find rather ironic, that at that level one has to define very specifically what does it, yet the overall project hasn't really got any specific definition of where we're landing. It's just over there. I do find that rather ironic.
David Kohn [00:22:20 - 00:22:40]
Yes, I think finding that balance between the freedom, if you like, to develop at a pace and with the MVPs and the subsequent improvement, finding the balance between that and this concept that it's very important to know when you've got enough, that's what's missing.
Mark Pinkerton [00:22:39 - 00:23:28]
But this all comes back to trying to get this development engine to operate as efficiently as possible. So, you know, the whole process of having, you know, I've got these 25 things on a backlog, I'm making sure that I'm actually going to do six of these this week or this sprint because I have an understanding of roughly how long these things are going to take. But they could be relatively random from that list of 25 things. David has an issue with that because he feels like the business isn't in control of it. I have much less of a problem with it because I think philosophically it's about trying to get that engine to work as efficiently as possible in a sustainable way. Whereas if you try and overload it, you know, just effing do it this week.
David Kohn [00:23:29 - 00:23:46]
It strikes me that based on what you've said there, that organisational stability, continuity of people becomes particularly important, particularly in this world of low documentation. Would you say that's an important factor?
Mark Pinkerton [00:23:46 - 00:24:23]
Yeah, absolutely. I think the whole premise of Agile is based on having highly motivated, well-skilled people that you're trying to make the best use of. And if you have a less skilled workforce, less motivated workforce, then you're going to have problems. Particularly where you have people, you know, how long do people last in an e-com or a marketing environment in a retailer? The answer is 12 to 18 months. Increasingly less. Increasingly less. And, you know, therefore people are going to leave the project and come onto the project.
David Worby [00:24:23 - 00:25:03]
And an aligned issue with that is the fact that I'm sure a lot of our listeners who don't have internal development capability of any scale will be using external resources to deliver projects of this kind of size. And some of those vendors will come in with an agile approach because that's the way they work, some maybe won't. So one of the questions I think was worth just a few moments of discussion is whether you should therefore become agile in order to support an SI or a third party who's going to come in and help you deliver a piece of work. And whether that is essential or whether you can carry on the way you always used to work. What do you think Mark?
Mark Pinkerton [00:25:03 - 00:25:44]
I think there are elements where that's incredibly useful. I think one of the biggest changes we made with one of our earlier clients was getting them to move to more of an agile timescale so that we had releases every two weeks because it meant that you could understand the changes that had happened whereas they were doing one every quarter. So you built up all this stuff into one release. You didn't know what had worked and what hadn't worked. It's just that something in there was wrong. Whereas if you've got it happening every two weeks then you can iterate and end up fairly closely understanding what benefit you've got from the things that have gone live.
David Kohn [00:25:43 - 00:26:11]
So I think we're moving now into some of the things you should do if you want to resolve the issues, if you want to get over the pitfalls, and just taking the conversation we've just been having, what skills do you think are now required by the e-commerce manager, the product owner, what do you think is different in terms of the way they operate in this environment versus how you might have operated three or four years ago?
David Worby [00:26:11 - 00:27:14]
Yeah, I think we've touched on some of the things that you kind of have to adapt to. A lack of clarity about the end vision, if your collective team is going to be working in Agile way. You have to be prepared for more iterative change. So for your customers, they're going to see more frequent change, rather than waiting for a period of time and having a bigger piece of change that might come at the end of a run of four, six, eight weeks. So the consequences of that into the business is that your marketing teams and your CRM teams who are in touch and talking to customers need to be more aware of the fact that things are constantly changing, which from a management point of view can be quite challenging. So the way in which the technology customers engage with is going to be different this week as it was last week, and that can sometimes cause confusion and might need some explanation. So you're probably going to have to be quicker at your customer comms to accommodate more frequent change.
Mark Pinkerton [00:27:14 - 00:27:46]
Yes, I agree with that. I also think that the people, you have to make quite a big effort to recruit people who have the right sort of mindset for Agile, by which mean they have to be slightly curious, they have to be prepared to share knowledge, they have to not be protective because that's just not going to work in an Agile way. They've got to be happy to share and happy to think, oh, if this is going to work this way, then something way over here needs to change and I need to bring that into the equation.
David Worby [00:27:46 - 00:28:30]
From a business point of view, being prepared to be less, I don't know quite what the word is, but maybe less in control, talking to business owners who are going through an Agile project, they need to be more comfortable with a higher level of ambiguity than I ever remember having to manage when I was doing it. They, in effect, seed a lot of responsibility for some of the strategic decision-making teams into the technology arena. And they therefore have to be comfortable that the direction of travel is right, rather than the fact that this widget is delivered done today. And that takes some adjusting. Yes, it does.
David Kohn [00:28:29 - 00:29:04]
Yes, I certainly think, speaking from my own perspective, the mindset maybe four or five years ago was I know I'm right and this is exactly what I want. And accepting actually that you'll get something delivered and then you'll be able to improve it is quite a mindset shift. And I think it's the right mindset shift because generally exactly what you want isn't exactly what's right and in fact it may be significantly not right. And the whole process of continuous improvement and marginal gains is one that everybody listening to this should embrace.
Mark Pinkerton [00:28:57 - 00:29:18]
Yes. Yeah, and it's very much the difference between having a sort of top- down, hierarchical way of organising things, whereas Agile, the whole Agile mentality is around being more, I would argue, more customer-centric and more bottom-up.
David Kohn [00:29:19 - 00:29:43]
Indeed. I mean, just to take that, and we did touch on this, I guess many of the people listening to this will not have a big in-house team, they will be working with an agency. They've probably got a list of issues that's 200 items long. Is there a different way in which you as the e-commerce manager should be looking at that list and how you relate to your agency?
David Worby [00:29:43 - 00:30:02]
Well, I guess there are some things we've talked about today and some that we haven't that might not be bad ideas to think about, even if you're not going to upend your whole team to become agile. So the idea of involving development resource in the fundamental understanding of what you're actually trying to do, that's a good thing.
Mark Pinkerton [00:30:02 - 00:30:12]
Absolutely, and it can allow you to do what we call t-shirt sizing fairly early on, i.e. that's a really difficult thing to do or that's an easy thing to do.
David Worby [00:30:12 - 00:30:52]
And the concept, which we never used to have in the old big drop days of an MVP, I think is equally valuable. Yes, it has frustrations, and yes, it isn't the end product, and people have to learn to understand that you've got to start somewhere. But for a business owner, I remember the very first time I saw an MVP, four weeks after we said go, made me feel fantastic. And OK, it wasn't perfect, and it never would be, but to feel like you can see something in real life so quickly that can be the change around which you all coalesce your efforts is quite motivational. Yes, absolutely.
David Kohn [00:30:51 - 00:30:56]
Absolutely. Momentum is critical, I think, and making things happen is a lot better than Momentum is critical, I think. Yes.
David Kohn [00:30:56 - 00:31:01]
Things happen. watching things not happen. So we're approaching the end of this, so I'd like to ask both of you.
if you can give one tip to the people listening as to how they can improve their agile process, or more broadly, how do they improve project delivery? How do they get more done better,
Mark Pinkerton [00:31:16 - 00:31:28]
I think there are several ways. I think Agile will develop over time. We've not talked aboutchanges happening to Agile, not surprisingly, on a constantly iterating basis. I do not believe the death of Agile is happening anytime soon. I think there are developments where the methodologies will morph, so things like spiral development, which is currently being used by NASA for developing big projects, will help structure things, whereas the day-to-day stuff is still happening in an Agile way. For me, because I believe in the Agile methodology, taking the Kool-Aid, I guess, the transparency thing for me is fundamental, because teams need to know where they are in the process. They need to understand where other teams are, but it's also motivational. But that means that you're flattening the hierarchy of an organisation, which can be hugely challenging.
David Worby [00:32:23 - 00:33:20]
I think it's very interesting that this spiral thing that we were talking about off air has been adopted by the Agile community as a version of Agile. I think that suggests a paranoia that goes beyond whatever I would have thought was reasonable. I think spiral is interesting, not least because it's NASA and therefore must get past the scaling challenge of Agile. But I think it's an alternative methodology and I think it's probably going to gain momentum. However, back to Earth, for our audience, I would not encourage anybody to go Agile unless there was an absolute imperative. But what I would encourage them to do is think about adopting some of the principles we've talked about today that do seem to add value. And I'll just say two things. One, multi- functioning teams. So often that's not done and it should be done. So multi- functioning teams who come together to help define what we're trying to do rather than some leader in a box determining what the outcome is.
Mark Pinkerton [00:33:19 - 00:33:28]
So do you believe in creating products and having multifunctional product teams inside or outside of IT development?
David Worby [00:33:27 - 00:34:06]
I think the collaborative nature of multifunctioning teams is very powerful and underutilized. And the second thing is, if you take this one step further, the creation of some type of MVP product is motivational for everybody. Now, you can't easily do that, I understand, unless you become agile, but I think there are elements of it you can pick off and adopt and make central to the way you move forward. So, message from me, whether Agile is dead or not doesn't really matter. There are things in there that really do work and they can help you become more efficient.
David Kohn [00:34:05 - 00:34:22]
Thank you. What I particularly like about that is the concept that Agile itself can deliver an MVP in terms of development and that that development process can continually be enhanced and iterated. On that note, I hope you found this podcast interesting and
On that note...
if you do have any feedback, please feel free to send it to any of us. Thank you.
Other similar Episodes in Season 2:
Episode 3 - Understanding headless and Compossable
Episode 2 - Strategy and Planning
Episode 6 - Optimising physical and Digital
Articles you may be interested in from Our Blog:
Why do many Headless/eCommerce strategic initiatives fail - 8 key reasons
Man vs. the Machine: The Future of AI in Retail and Digital Commerce