Customer Centric Agile

Customer-centric agile is a methodology that combines agile practices and customer-centricity to create products and services that meet customers' needs. In this approach, the customer is placed at the centre of the product development process, and their feedback is used to inform every aspect of the product or service.

The customer-centric agile methodology emphasizes collaboration between cross-functional teams, including designers, developers, and product managers, to ensure that customer needs are met at every stage of the development process. The approach also emphasizes the importance of rapid iteration and continuous improvement, with regular feedback sessions and testing to ensure that the product meets customer needs.

Customer-centric agile also emphasizes the importance of creating a culture of customer-focused innovation within the organization. This includes creating a shared vision and purpose around the customer, empowering employees to make decisions based on customer feedback, and creating a culture of experimentation and learning.

A customer-centric agile methodology is a powerful approach to building products and services that meet customers' needs. By combining agile practices with a customer-centric mindset, organizations can create products that are innovative and effective and meet their customers' needs and expectations.

Transcript

Detached audio: 0:00

Ivanna, just wanna say thank you very much. Joining us. It's been quite a while in the making, hasn't it? It's been a few. I can remember when we first sort of talked about this, it was quite a few months ago. I think it might have been before Christmas even. So, so thank you very much for joining.

iwona_winiarska: 0:14

Thank you so much for having me and having also this opportunity to, uh, just share my insights, my thoughts, my experience, so I really appreciate that.

Detached audio: 0:23

It's our, it's our pleasure. So, so we've, we've got a really interesting, uh, title, uh,

Track 1: 0:29

called, uh, Customer Centric Agile.

Detached audio: 0:32

Do you wanna just say, Ivana a bit about your particular interest in the topic?

iwona_winiarska: 0:38

Sure. Um, I think that's a very good question and I'm wondering myself how it started, because for me it's like a journey. Uh, when, uh, instead of delivering projects and just outputs and thinking, you know, what is the next project I'm going to deliver? Uh, when I started thinking about users or customers at the end of that line, and that was, uh, actually also when I got into Agile, uh, myself. So as far as I remember, it was in 2015. And, um, I also discovered that there are better ways of working. Uh, so at that time I was working for a, um, advertising agency in a very fast place environment. Uh, very interesting work. But then on the other hand, I just learned new things. And I think this, um, what I learned at that time helped me understand what actually really matters. And no matter, you know, what type of industry you're in, if you're working in it as I do, or if you do, if you're selling shoes, if you work in finance, um, if you're an accountant, you, it's really important to consider people, um, at the end of that process who receive your services or your product. So for me, it was really an eye-opening thing, uh, when I started thinking about, uh, other people, whatever, what I, what I do, how they're gonna use it, how they're gonna benefit from that. And, um, as I said, I've been working in it for about, uh, 15 years and I think that that aspect of considering people at the center of everything we do was kind of missing, especially in different technical teams I was working with. Um, later on I also moved to DevOps, which is even more a technical area, and I felt like, come on, there is something we need to do differently, you know, whatever, what we do. And no matter if you have, for example, customers who buy your services or even your colleagues in the same organization that you do the work for them, um, their customers as well. And I think that approach, uh, is, is really important and it helped me personally, uh, and professionally to, to deliver I guess, better job.

Detached audio: 3:02

Cool. So Ivana maybe. Uh, so we, we did a previous, um, episode looking at Agile, particularly in the public sector context.

iwona_winiarska: 3:13

Okay.

Detached audio: 3:13

So, uh, and I think when we, when we got the feedback from that, there was a lot of people really interested in Agile, but maybe hadn't. Used it fully so they still sort of had that interest. So would it be all right if I attempted a, a short definition of, of of customer centric Agile and then you can say, John, you've completely got the wrong end of the stick. Or, you know, it's a bit like that and we can sort of build on it. Because for me, this is the sort of reading through this and preparing for this session is where I've had a bit of a penny dropping moment.

iwona_winiarska: 3:44

Yeah, of course. that sounds great.

Detached audio: 3:45

So, I think, I think what, what, what you are proposing in terms of, like you say, putting people in the middle of, of everything, we're gonna call them customers cuz they could be real absolute external paying customers, but they could also be internal

iwona_winiarska: 3:58

That's right.

Detached audio: 3:59

Is is it, it does a, a couple of things. The first thing is, is, is you, you were saying about projects have a start and a finish. So there's a real sense of you do a project to finish it, and then it's like, well, what. Whereas I think with the customer-centric view, it's just continuous. It's basically, as long as you've got customers, you've got something to be getting on with. And, and, and so I've seen lots of places that have made the leap from project thinking to product thinking, you know, so they, they're thinking of a product life cycle and all the rest of it. But for me, I think you've, you've moved on another notch because it's like, well, actually. the thing that really lasts the test of time is customers, cuz products have a life cycle. Projects have a start and finish, but customers, if you are in business, will always be there. So I thought it was really interesting that you are pivoting on what the customer wants, uh, rather than just going, I mean, obviously that could lead to a set of products, but it's mainly, uh, what the, what the customer is after and, um, and then there's all sorts of questions I wanna ask you about what that then means because, uh, you are sort of wiring yourself up to the

Track 1: 5:16

electricity mains, aren't

Detached audio: 5:17

you? You're not, you're not dodging any kind of, if you're going to, to listen to what the customer wants. There's no room to hide, if that makes sense.

iwona_winiarska: 5:27

Yes. Yes, it does make sense. I totally agree.

Detached audio: 5:30

Why doesn't everyone do this? Why, why, why hasn't this become a massive movement? Or, or is it about to become a massive movement? Or maybe everyone does it? And I'm the only one who's sort of looking at this thinking this is such a good idea, uh, for, for, for running. Um,

iwona_winiarska: 5:47

Yeah. Um, I know that it may sound a little bit like a trendy word to be Agile or to be customer centric. Um, and personally I've met a few organizations who want to do, you know, things as the rest of the organizations. Um, however, it's really important to truly understand what that really means. And it's not easy. It's, I think it's super difficult. Um, but I guess the, for me, the reason, the way how I understand it, um, is that, We can deliver better products and services to our customers. Uh, if I take it further, and if I can add a little bit more context to that, what, what this really means is that we can avoid solutions that are not fit for purpose. And what that really means is that we can save a lot of money potentially. Uh, for example, if we build something that doesn't meet our customer needs, then uh, we wouldn't be spending so much money on something that actually doesn't work. Um, on the other hand, uh, we can. we can deliver better products. Even if the product is wide, we can position it in the way that it really solves the customer problem. And I think what this is all about, uh, is not just, I guess trying to do something for the customer, but it's really about solving the problems, um, no matter what the problems are again, or what the type of customer really is. Uh, for me, it's about solving exactly what that particular customer really needs. Um, and obviously there are a lot of other benefits like saving money, like doing it better, designing it better. Also, by the way, when I say designing, I mean designing not as, you know, styling or aesthetics, but it's really how we gonna design that product, how it's gonna work, how a customer will know about the product, how they're gonna use it. What happens then after they finish interacting with that product.

Detached audio: 8:00

Yes. Yeah. Cause that was a question I had for you, um, Ivana, which was, um, we're not saying literally deliver what the customer has asked for. So if the customer, I mean, in some cases, maybe yes. Yeah. But, but in most of the cases, it's about looking at the problem that the customer. The, the customer might present to you in, in lots of different ways, but it's like really understanding it and then looking behind that as to what the actual problem is that needs to be solved.

iwona_winiarska: 8:30

Yes, that's

Detached audio: 8:31

and then focusing on that because some people, again, whenever you talk about methods or approaches, there's a lot of people take it very literally and they'll say, well, you know, if I did everything my customer asked me for, I'd be doing different things every week. And uh, now there is an element to that cuz this is what I find really interesting cuz. if you go customer centric, you sort of become, I don't want to make the sound too much of an Americanism, although we do have folks across the Atlantic who listen to the channel, but it's kind of sort of super Agile You have to plan for, I think you call it pivots, where there is a proper change. And I suppose that isn't just for folks that are D servicing a consumer market, but that can also be if you are in a highly competitive. Yeah. So if you are working for, in quotes, internal customers, the market can change rapidly there as well if it's very competitive. So this kind of, well forget about all of that because we've got a project to deliver and we're just gonna carry on and deliver. What I think what you're saying is no, you have to be very alive to changes. Um, now that that sounds, you know, that sounds amazing, but it sounds like that could be quite a challenge to set up to be. You know, to be able to respond that quickly. So how, how do you do that

iwona_winiarska: 9:52

Oh, that's, uh, that's a very good question. Um, so I, I totally agree with what you said. It's not really about delivering what the customer, what our customers really want, but it's very often. It's like, kind of like putting a mirror in front of them and showing what you know, this is what you told us, this is how you do these things now. And um, and perhaps that might mean something, X, Y, Z. It's actually showing the situation as it is. And very often our customers, um, they just don't know what they want. Uh, they might, they, they think again that they want different things. Uh, but I think for us as IT professionals, Azure pro professionals, it's important to help our customers to actually identify what is that need or that problem that they trying to fix and help them with that. So it's, it's taking them on the journey and I think the way how to do that, the easiest way. I think is, is collaborating with them. So it's about involving them in that designing process so that we can create a product together with them, or that particular, it can be, doesn't need to be a product, it can be just a part of the product or that certain, uh, customer journey. Um, so through collaboration, early feedback, um, a lot of conversations, workshops, uh, facilitation is key here. I, I think we can learn more about our customers and then design that solution with them. Uh, and that involvement and that engagement is key.

Detached audio: 11:38

Yeah, so I don't think we're gonna be particularly controversial on this because I mean, I completely agree with you. Um, one of the things we picked up when we were talking about public, uh, sector Agile, and something that I just observed generally with Agile is just because Agile gives you, you the ability to start really quickly. So if you wanted to, you could, you know, just get stuff done, you know? Let's get some developers in why aren't we coding? You know, that kind of, but actually, uh, and I think this is just, this is just universal in my opinion. It's about having really rock solid design and, and and what I wanted to, I just wanted to, uh, to do a couple of observations. See, see, see if this chimes with you at all. So I think when they look at projects, products, Customer centric, anything. One of the biggest sort of markers for quality is not just were the requirements met, right? But also were the requirements Correct. You know, were they the right requirements in the first place?

iwona_winiarska: 12:45

Mm-hmm.

Detached audio: 12:46

and and I think sometimes technology teams interact with the business or with the customer or folks have got a genuine. Stake in the business, but not in a equal measure. So maybe we send people who are junior or, you know, it's, it's, and, and so that relationship isn't there for me to say, or for you to say to me, John, actually, I'm not quite sure that's what you really want. Have you thought of this? Whereas if, uh, we could have a, a different relationship where I might. Well, that's what you've said. That's what we're gonna deliver. No questions are, you know, we'll, we, we delivered what Ivana asked for. She wanted, you know, a chair with three legs and, uh, you know, and all the rest of it. And that's what we've delivered sort of thing, which, which I would call, uh, meeting the target and missing the point kind of thing.

iwona_winiarska: 13:41

I like that. I love.

Detached audio: 13:43

So, so that, you know, so I think getting the requirements and the design upfront also means being really considered about who is actually in that initial team and, and having, you know, that's where you need all your experience and you know, every, you need to throw the kitchen sink at those meetings because you are gonna pay for. For the rest of the, the life of, of, of, of the work. And you could end up going down the wrong avenue. You know? I suppose also, sorry Yvon, I will shut up. Um, but I'm thinking if you are also saying, you know, we're gonna have to be very responsive, so we might have to change things rapidly because that's the, uh, that's the market we're in. That's another design consider. Because in software, we all know if you wanna just do something once you can, you can code it in a certain way. And then when they say, I want to change it, you say, well, you didn't tell us you wanted to change it. Now we've got to rewrite it all. You know, there's a, there's quite an overhead isn't there, to creating products that are configurable. Um, uh, so God, yeah. Just so much in there to unpack.

iwona_winiarska: 14:50

there's definitely a lot of things. Um, and actually as we talk about this, I just realize how complex it is, or it might be, although it's actually very simple. The principles are very simple. I think it's when we apply to real case scenario, I think it's not always that easy, uh, to be customer-centric. Uh, but, uh, I think just to touch on a few points that you've mentioned, um, what I really like, uh, and this is, this is my, again, personal experience when there is, you know, like, um, new team and uh, new initiative and, uh, the team defines the mission and we have that first kickoff meeting and then, Usually we'll start with technical teams who just develop things. Uh, so very often like the, the first stages, which are about discovering and understanding, um, the current solution or, you know, the lack of product or the current pro product. Uh, and then trying to define that new solution is very often missed in that cycle. And people, and I, and I do understand that, that people want to deliver value quickly. They're very passionate. Um, obviously some of the team we're working with, they are junior, but there are also more experience. And also there are, you know, different types of backgrounds and people basically want to do a great job, uh, and they want to deliver things quickly and in the best way they can, which I completely understand. But very often we just. Kind of forget about that initial stage. Uh, the client tells us, you know, this is the brief, this are the requirements. We need a chair with three legs, and this is what we build. So the first actually stage, uh, is, is development. Um, and I think that that's not definitely what I would recommend. I would, I would propose, like we all take a step back, we go back to, to the, you know, um, blackboards, and we start actually thinking about, okay, so who are our customers? What are they trying to achieve? What are the needs? Um, et cetera, et cetera. What are the limitations, why they haven't done it this way before? What's stopping them? What's preventing them from doing this a certain way? And. even before that. Uh, it's good to talk to real customer. So what I mean by that is that on a support of, uh, user research or customer research or gathering customer feedback, there are ver there's a variety of different techniques everything can use. Uh, so it can be face to face, it can be via, uh, you know, a sweet talk or using different communication tools online. It can be even a survey. It can be even an email asking them for feedback. And I think that's really important that we can ask people what, what they really, not just what they want, but you know, what are they trying to do, how do they do it, and how we could make it better. Uh, that's very important before we actually start doing any things. So, um, you've mentioned also public sector and I think that, um, What I really like about public sector is that, um, they serve the, the, the, the whole kind of, you know, product or service life cycle in a way that there are different stages and different phases. So the first one is discovery. Then you move on to, to alpha. Then in Vita you actually start with, uh, building things, developing programming. And I think that really makes sense to first understand, for example, what, what we're trying to achieve, what are the needs of our customers? or users in that scenario. But then also what are our internal needs as, as an organization, as the business? Um, what is our strategy? Is that aligned with our strategy? So it's really, I think, um, just to be even more controversial, I think, uh, it's important to consider customer needs, but also balance those needs with, um, with our needs as an organization as well. Because ultimately everyone will ask about return on investments while we doing things we need to be profitable. So obviously this are also very important questions to, to very in mind and to make sure that we can balance everyone's needs and to do it in the way that the customers are happy as well as our organization and the employees.

Detached audio: 19:39

so Ivana, I think what you are, what you've just articulated is essential business strategy. but delivered through an Agile delivery. So you know, you are talking about satisfying your customers, but doing it so that you are. So it's sustainable. The company can continue, you know, and, and all those, all, every element that you've just described for me is, is it's almost like a proxy for a business strategy, which is what I find fascinating. Um, so it's a couple of things I was thinking of. I, when I was first reading about this, I was thinking of traditional customer, you know, buy, coat, use. You know, mass market sort of stuff. But I was actually also thinking in any business, you know, like a business to business, a b2b, um, actually, uh, there's, um, you know, there's a school of thought that says businesses can become very sort of inside out focused. So they will say, you know, we want to do this, but actually they, they've kind of even themselves have lost the voice of the end. So when you are in that early design stage, and again, I think this goes back to how senior and experienced and confident this team needs to be, they might come back from a meeting and say, you know, we need to speak to marketing because I think we need to run this past marketing to get a view of what the actual external customer. The actual end customer might be thinking. Do you see what I mean? And I, and I think that's, that's a really big ask for a lot of technology teams that just aren't even, they haven't even got this lens necessarily switched on. They're taking. That first set of requirements on face value. I dunno if you've ever heard people say, you know, that's the business the business have told us. It's almost like,

iwona_winiarska: 21:27

times. Yes.

Detached audio: 21:28

it feels like, you know, technology isn't part of the business, but I think we're getting to this crossroads where,

iwona_winiarska: 21:33

Yeah.

Detached audio: 21:34

What you've just said is you could, you could have rewritten that just purely in business strategy language and said, what's the, what's the 1 0 1 of a company? Um, it's just increasingly things are being delivered by technology. So, so I was thinking you said it's not easy. I love that because I always say if it was easy, everyone would be doing it. So the fact it's not easy should excite certain folks. Cause it means if you get to master this, they can give you competitive advantage because it's not easy. So it's well worth pursuing. Um, and difficult things are normally worth pursuing. Yeah, I think easy come, easy go is the expression. Um, and I think one other one I wanted to just throw in is when you're having that first discussion, uh, I was wondering whether you could share any, what I would call red flags. And I'll give you a red flag to give you an example. So you, you go in and you speak to someone in the business and they'll say something, it needs to be cheaper,

iwona_winiarska: 22:35

Mm-hmm.

Detached audio: 22:36

but I always think if a business says something really obvious, we're not really anywhere near the problem space because the, the follow-on question might be, well, what needs to be cheaper? Why is it cheaper? What are you actually referring to? Who's told you that? You know, all these different pieces, but, um, I'm just wondering whether you have. Tips that you can give people, which are red flags for when you're in that first meeting and you're maybe not getting the content or the engagement that you need. So, you know, when you come outta that session, we've, we haven't really scratched the surface. We haven't really got stuck in to any kind of, anything we can, um, get our teeth into. So that was one question. Sorry. Uh, there's so many things going on in, in, in my mind for what you said. Um, but the other one was about resisting the urge to do development too.

iwona_winiarska: 23:25

Mm-hmm.

Detached audio: 23:26

I I think you should hold on until you're absolutely bursting to do software development and not a second sooner, cuz I think people start too soon and there's this sort of ill-informed view that, well, the developers can iterate because this is Agile. But actually you end up in a really weird sort of pragmatic loop and you'll, you'll be going down some sort of cul-de-sac pretty. If you start too early. So I think a lot of folks probably start a bit too early. In my experience, I've people, uh, previously have said, John, we need developers. We need developers immediately. And I'll say, well, show me the design. And then if it all goes quiet, sorry. There's a whole load in there to, to unpack. There's anything there that, that, that struck you to, to comment on at all.

iwona_winiarska: 24:14

Um, I, I, again, I, I agree, uh, that we start to early, um, and I think that's, uh, in my work actually in certain situ. uh, but in majority of the products or services I was working on, uh, it, it didn't work. And definitely that's, that's not the best approach without understanding the problem. Um, any Right. Um, our customers don't have, you know, the designs. They haven't sought through exactly what they're planning to do. And very important when you ask them that question, why? So as you said, if someone is saying because they want something to be cheaper, what does that really mean? An example I can give you for this one is when I was working with one government organization, everyone was saying, we just moved onto cloud. It's very expensive. We don't have much experience. Uh, we're paying a lot of money. It doesn't really meet our needs and we haven't moved a lot of applications onto cloud yet. And we want definitely to make it cheaper. Um, and then I just started asking more questions around like, what does it mean really cheaper? What, what was expensive? Or is it about, you know, the, the bill that you get every month from, you know, Google Cloud platform, Amazon Web Services or Azure? What, what does that really mean? Is it about the bill or is it about something else? And, and then when you have that conversation, um, you find out that what they actually mean is not, they don't want to decrease the bill that they pay for using cloud. Uh, they just want value for money. So, for example, if there are certain resources, you know, on cloud that you don't need them, like for example, there's all the machines on overnight, you don't need it because the services are not critical or they don't need to be supported 24 7, then actually you can just turn it off. or if there are any other things that you don't use or you just use for training, you can very, very, in a very simple way, you can just, you know, design that also, like technology solution, how it's gonna work for you so that you can, um, have it cheaper. But it doesn't mean that it's necessarily making that kind of, you know, um, cost. Um, Laurie, it's what I've learned is just really about, uh, actually paying more, but paying more for something that makes sense that we are using, that we benefit from, that our customers will also benefit from as the end result. So I think very often we just use our own assumptions, what we think people say. Uh, but I like for this one, I like kind of uncovering that language, decomposing the language to truly understand what people do really

Detached audio: 27:13

Yes.

iwona_winiarska: 27:14

And in 99% of the cases I learn new things that they mean something different, what they say.

Detached audio: 27:21

Well then you, then you advance the thinking for the, for everyone because you, you've had a, a proper discussion about what the problem is.

iwona_winiarska: 27:28

exactly.

Detached audio: 27:29

yeah. And everyone normally looks back and says, oh, it's so simple, but

iwona_winiarska: 27:34

Yes,

Detached audio: 27:34

it takes a lot of time to simplify things. Yeah.

iwona_winiarska: 27:38

Absolutely. And uh, and this is what we said, it's not easy. Um, it requires a lot of other techniques, you know, the way, how you ask questions, open questions so that a customer can actually find out what, what they, what do they really need rather than what they think they want to do. Obviously no one wants to pay high bills at the end of the month, um, but we can make it more effective or, you know, um, tailor that kind of service or product towards everyone's needs. And I think that's, that's the goal we're trying to achieve here.

Detached audio: 28:11

Got it. Uh, just, you mentioned open questions and most of the folks I, I think watching will know what that means, but for those that don't, um, a closed question would be, do you like this screen? And the answer would be yes or no. That's a closed question because you, you've just, you've not really got much back from the person you're speaking to. An open question might. Can you tell me all the things that you really like about this, uh, screen and then maybe some of the. You don't like? I mean, that's a really, that's not a great example Havana, but the open questions, one of the sort of really early things you pick up in consulting and it's such a powerful, um, thing to use. And, and the other one is the, just keep asking why isn't it you just, if you, I can't remember if it's the seven why's or however many why's, but, uh, keep asking why until the person opposite says I need a cup of coffee. And then, uh, then you've probably got to the right.

iwona_winiarska: 29:07

yeah, yeah. Uh, 100%. It's so important. And I think again, for me it was, it was my personal journey when I started having this conversations on a different level to when I was really trying to understand, uh, my customers, um, I was going to mention another thing. When we talk to our customers, um, obviously active listening, open questions, but then also asking open questions. I would add maybe on very different levels. So what I mean by that is, is that we, um, we can also, uh, for example, through observation of a customer in that real environment, we can observe how they actually interact with our product. So, uh, I think if we want to take it even to a higher level, we can, we could potentially, depending on our, you know, possibilities and, and again, logistics and the product, we could organize a kind of situation where we can observe our customers. Um, because again, everything that will be coming from customers will be in certain way. Sensored, uh, through them or by themselves. So whatever, what we hear from them is that kind of one particular scenario. But actually seeing our customers interacting with a product

Detached audio: 30:35

Yeah.

iwona_winiarska: 30:36

is, is a different thing. Uh, and again, it's not easy to facilitate that process to, you know, create that environment or to even ask for permission. Uh, it's really difficult, but I think we can learn so much and we can have a to totally different type of insights from this. Uh, also, for example, asking questions like, how do you feel about certain things? How does it sound to you Using different expressions or different stars as we know, some people like seeing things, other people are good listeners, they like talking. Um, so it's about, I think designing also that approach and that engagement, how we can best target that particular customer or that. Customer group. Um, so we can have that communication channel and ask them questions about how they feel, uh, how do they, as you said, how do they like something, what do they don't like about certain things? So yes, it's, it's so interesting. There's so much to this. Um, I think, um, what's, uh, what I would definitely strongly recommend is that everyone, no matter what your role is in your organization, in your own company, um, even if you talk to anyone, even your friend, I think practicing this different techniques and trying to have that empathy and actively listen to someone that's, uh, that can really open your eyes,

Detached audio: 32:02

Absolutely. And there's so many things going on just in that sort. Customer stroke user research that you were referring to? Uh, I I, I've done the observation in the lean contacts with, I think they call it the day in the life of where you, you follow someone for the day or normally it's over a few days, uh, to see, uh, to observe, you know, what they're doing. Uh, I think the other one is you've got to be really careful about feedback because people who feedback to you might be the loud minority. You've always gotta think about the silent majority, potentially. Um, and also when people do, are asked directly for feedback, sometimes they'll filter it by being polite, uh, or they'll be so upset with a product that they just don't really want to give anything. They'll be a very sort of almost. Misdirecting feedback because it's just not something they're interested in. So there's, there's sort of sampling techniques. There's all sorts, isn't there? And I suppose there's a lot of technology emerging that that's increasingly allowing you to see a product being used. And actually the sample size is, is everyone. So you don't have to worry about sampling anymore. But that used to, used to be a, a, a thing. And I suppose the other one I've seen used, um, to varying degrees is the sort of the model. But again, I suppose you've gotta be careful that you don't create this sort of artificial world that doesn't really exist. Um, so sometimes I find Model Office is more useful for the project team to get the head around conceptualizing what it is that's being, uh, created. Um, but, um, yeah. So I wa I wanted to, uh, to ask you a quick question about, just to go back a little bit. What we'd said about don't start doing any development until you're bursting to do it sort of thing. But I wanted to kind of qualify that because I think from, from researching this, if you do take all that time upfront and you also think about the scenario of future change, you are then putting yourself in the position to be able to rapidly respond to change. And I'll, I'll. A really poor example, if we designed a car really quickly, that could only go forwards, and then we discovered we needed to go in reverse. We'd have to completely re-engineer parts of the car. We'd have to come up with a gear box that we hadn't thought of. But if we'd really thought about it, you know, early on, even though the customer wanted us to move forwards, initial. all sat down and thought, you know what, it's probably quite likely they're gonna want to go in any direction. So they probably need a steering wheel and a do, I mean, I'm trying to sort of conceptualize it, but, and a lot of that thinking is about having experience, isn't it? In the particular space that you are talking, it's quite difficult to kind of just come up with that from scratch. Um, so do you sort of seek out particular subject matter experts when you're doing design or, you know, how, what's. How do you know, how do we kind of mitigate against being in the room and doing the what? We don't know. We don't know kind of, uh, scenario.

iwona_winiarska: 35:16

it's very interesting and I must, I made that on my last project. That was actually the kind of, uh, um, different perspectives. I was there in, well, uh, from different people. You know, on one hand you have a very motivated, um, sort of organized Agile team who's very passionate and they want to start doing things. On the other hand, you have quite complex, uh, architecture and a big service, complex service that you're building consisting of sub services or sub transactions. And then there is that point, okay, shall we start with something to deliver that minimum viable product? And, um, this is, and this is, and it might be controversial, where, you know, you need to kind of find the best solution that, uh, fits your product and also your context and your teams and organizational clients you're working with. Um, and again, that's. that wasn't easy. Uh, because obviously we want to make sure that the teams have something to do. They can progress, they can also, um, you know, do their own research and, you know, or discovery and try to understand the customer. But from the, uh, design perspective, uh, very often it appears that if we knew exactly what we are building as that, you know, outcome at the end that we're trying to achieve, it would be really helpful. Um, and I think, um, again, although it's not easy to answer that question, I think it does really depend on our strategy. And, um, I'm gonna quote one of my favorite books, seven Hobbies of Highly Effective People. Start With the End Goal in. can, one approach could be to design a car that can just move forward, uh, but ultimately if you know that you're gonna have a fully functional car that you can also reverse, um, I think that perhaps wouldn't meet your needs or your customer needs. And I would ask a question, is it worth doing or is it worth spending more time during discovery or even some prototyping trying to, uh, create some designs of that car earlier so that you can see if, um, if there is a better way of doing it with, you know, all of the functionality. And, and here, although I'm a very enthusiastic Agile practitioner, Um, I think that what we're trying to achieve in Agile is not necessarily just do the things that are the wrong things that will not meet our customer needs. Um, so it's about designing something that makes sense, even if we know that we need to take a step back, do a little bit more discovery, design, uh, try different options, design options. Uh, sometimes it's not just one option, but you may end up having like, you know, 10 different designs. Um, and, and that's, that's the thing. It's, it does, it's not quick. Uh, it's not just that it's not easy, but it's also not quick. It's not fast. It involves probably a lot of stakeholders from your organization. uh, you might be talking to. And, um, and, and that's, I think that kind of complexity, uh, that it's added that it's added on top of that, trying to design the best solution that is fit for purpose from the short-term perspective, but also long-term perspective. Um, so for this one, I also, um, what I do is that I try to take that pragmatic approach so that it's not just, you know, being Agile or cost, but it's doing something that makes sense for us, um, in that

Detached audio: 39:09

Yeah, I think, uh, yeah, it does. It makes a lot of sense. So I'm trying to remember if it was Peter Coy or it's, was it Kobe, the Seven Habits of Highly Effective People? Was it coy or someone else's name? I can't remember. His a. I remember it's sort of a silver colored book. I read it eight years ago. Uh, yeah, that's a, that's a good one. We'll see if we can put a link to that for people to, to see that, uh, in the, in the, in the, uh, in the description. Um, the other thing I was gonna say is, um, You know, you think you associate Agile or a lot of people associate Agile in technology with software development. Uh, you know, we're talking about the the alpha, beta kind of process. I actually think that you could also insert a kind of a build or buy question, but again, wait until you've done that design thinking. Because if you create the design and you say, okay, if we take this into software, we can providing we're effective and we've got a good budget. And there is, you know, this is a long term thing. We can develop something. Yeah.

iwona_winiarska: 40:16

Mm-hmm.

Detached audio: 40:17

But we might say actually that's gonna be pretty expensive. Um, it might not, you know, but it could. And there is a product that's out there, um, but it only satisfies sort of 80% of our requirements is that your cat

iwona_winiarska: 40:33

it

Detached audio: 40:33

the second. Second

iwona_winiarska: 40:34

Yes. He's very active right now.

Detached audio: 40:36

alright. It's an Agile cat. What's, what's the cat's name? We might as well uh, announce its name given it's, it's appearing on the, on the podcast. What's its, what's its name?

iwona_winiarska: 40:47

uh, his name is

Detached audio: 40:49

Shinobi.

iwona_winiarska: 40:50

which actually means in Japanese, uh, Japanese Ninja.

Detached audio: 40:54

Perfect. Well, that's about right.

iwona_winiarska: 40:56

acting like that.

Detached audio: 40:57

Although I think Ninjas meant to be sort of very quiet and sneak up on you. I think. Um, Chino's been a bit noisy.

iwona_winiarska: 41:04

He is indeed. Apologies.

Detached audio: 41:06

no, I love all this. I love, I love that. Um, so, uh, so, so just going into that build versus buy, and then maybe you've got some software and then maybe, um, Mr. Pito makes an appearance where you say, okay, we've, we've really understand the space. Actually 20% of what's needed delivers 80% of the requirement we could get. Through software. Uh, should we buy the software? And I'm, I'm, look, I'm just throwing this in, Ivanna. I know. You know, but it is, for a CT io it's a, it's a constant decision about are we taking on too much development? Um, should we think about products, the build versus buy kind of thing.

iwona_winiarska: 41:51

Yeah. Yeah, I think absolutely. I, again, um, I think I am quite pragmatic, so whatever, what works for an organization is, I think, um, it's, it's a good way forward. Uh, so I guess in that scenario, I would just consider what are the risks? If we can hit this 80% of the requirements, is that going to help us in any way? Probably yes, massively in 80%. But then what are the risks if we miss this 20%? And for example, if there is something significantly important that may change our direction. So that's obviously something we do need to consider. Um, and we need to have that agreement with our stakeholders, with the teams. What's the best way to do? Uh, but I think again, what's, um, perhaps not all of, um, the teams are talking about, um, is the risk and how we can measure the risk. And these are the scenarios that sometimes, like, you know, you don't know what you don't know until you actually come across that problem. So it's really, again, it's not easy to think about possible scenarios, but at least. You know, you can organize that exercise with your team, with your stakeholders to try and understand what would be that risk, um, from different perspective, different angles. It can be technology, but it can be also design, it can be relating to your customer. What could be the implications if you don't get it right. Um, would that be, you know, redesigning the whole solution or would that be just a quick fix? And very often we can do things by quick fixes or by, uh, evolving the product or iterating the product later on and just adding more functionality on top of that. But in some situations, you do really need to redesign the things, which is taking enormously, um, massive amount of time. And as we all know, for example, technical resources are very, very expensive. And it's actually really hard to get, you know, to have the right people with the right skills. So I would think about the risk, the implications. What if, uh, how might we solve that problem in a different way? Um, if we want something temporary, you know, there are so many pro, probably there's so many ways how we can, you know, solve that problem. Uh, so it, it, again, it, I think it depends on that strategy and what are the potential risks or assumptions that we might have about a certain solution moving forward. And then making an informed decision, which again, is, um, is not easy, but I think data can definitely help with that as well. Or certain metrics if we, if we use them before.

Detached audio: 44:40

One of the ways I think of what you've just described is, um, and, and particularly in the, in the context of customer centric Agile, so we're saying that this is something that we've designed in a way that if the customer or the market needs change, we can change and rapidly adapt. That sounds to me like something we'd wanna be famous for. I always say, you know, in tech, in the context of the technology we're building for this, What does technology need to be famous for? So in, in other words, it kind of tells you where your prime activity should be and, and then that's probably where you are going to put the biggest investment because there's a huge opportunity cost of doing software development in areas that you don't need to be famous for. Because it's not core. It's not something that, it could be something that's available off the shelf. But all that code that you have to maintain, everything else that goes along with the life of a, of a, of a, of a, of a computer based product becomes this massive opportunity cost that you can no longer, it sort of dilutes, cuz nobody's got a, an infinite budget. I mean, you know, everyone has to do something and even if you did have an infinite budget,

iwona_winiarska: 45:53

Mm-hmm.

Detached audio: 45:54

can't handle infinite change. So you've always got to kind of have. So, so that design thinking that you, that we were applying to this particular problem, I think you also in business technology strategy have to apply that design thinking to the enter entire enterprise, which really lets your brain go for a run.

iwona_winiarska: 46:18

It does. It, it does. Sometimes it, you know, if we don't lock ourselves in a certain box and we think out of the box, I think we can come up with great ideas. And then I think, you know, I think it's really limitless. You can come up with anything you actually want to do. Then obviously we just need to consider what, how feasible something really is or how much it's going to cost. But I think that there are so many opportunities, and I'm sure that there are so many things. You know, no one else has done it yet. Uh, that there's definitely a lot of potential. And I think, um, again, it depends on, um, on the organization. But, um, when you said about technology, I think we should use technology so that it can benefit our products, our solutions, and our customers ultimately. Um, there are obviously constraints because, uh, just to give us an example, you might be working, you know, sometimes organizations want to do magic. They want to do great things with new technology that they have available. Um, but very often they might have limitations in terms of how they have already set everything up, the infrastructure, uh, how something currently works, and especially for older organizations or. more traditional organizations or environments, it's much harder to make that change. And I think you're completely right. Uh, even if we had, you know, maximum budget, we can't have so many changes happening at the same time. Because, you know, when you try to modernize technology or to use new technology, that change always comes with people change with, uh, people's roles and responsibilities, with new ways of working, new processes. It's changing the whole organization. And that has a massive impact on every role and actually every department, not just it, but also, you know, hr, how you hire people, what skills you're looking for. Then how do you maintain and make sure that these people stay in your organization. Um, what, what is the retention? And, um, obviously finances, procurement, everything. It's really everything.

Jon-1: 48:42

Yeah. Yeah. No, it's, um, it, it, it's, it's absolutely massive. And I suppose, um, just sort of trying to summarize a little bit, um, the customer comes first. I mean, that's such an old saying, isn't it? But, but it's, it's. It's a really true, you know, we're absolutely saying this is, this is a real truth to that. So the customer always comes first. Um, it's better to collaborate, uh, than do sort of a command and control. So don't think of projects and we're just gonna get on and deliver stuff. You've got to have a lot of thinking and. we, I think you've described lots of different areas that you would go to, to test and validate your thinking and design. Um, and uh, yeah, you know, I think that's sort of put all that energy into your design and then you reap the benefits. Uh, you know, you get, you get to have that investment pays off over, over a series of, of years. And then your point that you were saying, You know, some companies having quite a difficult context to achieve change. You know, sometimes that's referred to as legacy systems of, you know, that's a common term and I love the expression, the expression I always use, which is you ask, you know, the farmer, can you tell me which way to London, you know, how, how can I get to London? And the farmer replies, I wouldn't start from. you know, that kind of classic sort of legacy, uh, um, jigsaw that you have to kind of unpick. Um, but I suppose if you take the customer centric view that you are talking about, you, you're sort of removing legacy by creating a very responsive product and team so that you are, you are trying to, as much as possible, just be able to roll with the changes rather than go down some kind of legacy. Cul-de-sac as it were.

iwona_winiarska: 50:37

Yeah.

Jon-1: 50:38

Cool.

iwona_winiarska: 50:39

definitely. Um, and I think although we speak about the change as, as being very complex, uh, I think although it is very complex, I think it's, there is a way how we can, um, even design the, the change in a way that has minimal impact on people or it's done in a way. That is, um, not disruptive in our organizations. And I believe that every organization and every department and every team can start with where they are right now, uh, because these changes are happening over sometimes even years. And, uh, and obviously, um, yeah, it's, it's, it's very challenging to, to make any change rapidly, uh, in a disruptive way. Because ultimately when you know you want to do it quickly, you might get different results or you're not gonna get that, you know, user adoption within your organization as quickly as you would wish. So you need to really wait for these outcomes, and you need to manage change effectively to ensure that you've got the. Uh, on investment soon or within the period that is acceptable for you and your organization. Um, that's why I think there's so much to it. Um, when we think about Agile, for me, it's not just Agile. There's so many different things that we should be considering, like product, customer centricity, like change management, like strategy, leadership, um, is there's, there's really a lot of things that we need to consider. And I think, um, having also all the, you know, um, people supporting us, uh, specialists and experts in different areas, I think that's the way to move forward. Because obviously we, we don't know, especially at that early stage, what the right answer is. So that's why I think collaboration is really important to make sure that we all collaborate on that change, whatever, what it is. Um, it's making sure that we engage not just with the customers externally, but also internally. That's why when I speak about customers, for me, customers are also, uh, employees. Very often we might be building this different technology solutions for internal employees, uh, for data people, for other, you know, team that is benefiting from that. So that's why I think customer-centric approach can be applied, not just towards your end customers, but also with regards to any person you work with.

Jon-1: 53:21

Fantastic. So just sort of wrapping up really, but I think what you were just describing there is the big difference between a technology project and a business technology. Strategy and approach. You know, all, all those elements that you are describing is really enabling you to marry up all these different elements of the business. It's an external, internal environment. Everything else with a really coherent technology, uh, strategy, it's not easy to do. That's so. Uh, so we're gonna have some people listening to this thinking. Yeah. I wanna, I want a piece of the customer-centric Agile, please. Where would you, what, what would you say to someone who's listening to this who says, you know, I really want to, you know, they, they could be at various different stages. They might have been quite a long way down the Agile route, but they might have been doing a series of kind of stop starts or discreet things and haven't really thought of. Golden thread of the customer running through. So if, if you, if you were to give anyone advice who was listening to say, you know, how do I get started with this? What do they do rather, do they call you up? Or, I mean, how, what, what would you suggest folks do?

iwona_winiarska: 54:32

Sure, of course. You can call me up anytime you wish. Uh, I don't mind. Uh, but I, I guess, uh, the way, how I was starting with that is, uh, it's not a quick process to know everything. And I'm not saying I do know everything. I know actually not much because every situation is different, every organization and every client engagement I work on. Uh, but I guess starting small, uh, focusing on one aspect, trying to understand that aspect. Uh, for example, we talk about customer centricity, so, um, I would suggest perhaps I'm reading online or also attending different meetup groups. In London or worldwide. Um, I think they are really good. And, uh, what I found really helpful in my case was to listen, uh, different case studies and people's experiences. It wasn't actually going to any traditional courses, getting certifications, uh, but it was really about just talking to people, listening to those stories and trying to understand how they did something, what worked, what didn't work. So, uh, I still remember some of the stories and I think that's something that I, I learned something not through myself doing mistakes, but already someone else has done it, it didn't work out and I've got this learnings that then it really helps me to manage my kind of day-to-day work. Also work on new, uh, products. So I think, um, I think this is actually, that kind of practical experience is very important. Obviously with addition of trying to practice all of the principles as we talked about. Uh, so as I said, you don't need to actually, uh, try to, um, practice customer centricity in an IT team, but you can cus uh, practice customer centricity in anything you do when you go to a shop, when you buy some services or especially if you have your own company. Try to think about your customers. Um, and here, I guess I would just advise to perhaps check online different, there are different techniques, very good techniques, how you can understand your customers better. And then again, there is no role or, you know, one solution to that, uh, because all of the customers are very, very different. So it's does really depend on that context. And unfortunately, I wish there was a magic period, but there is no magic period. And I think every organization, every team, and every person needs to work out for themselves.

Jon-1: 57:16

With their own journey. Well, I'm sure, uh, certs will be able to get some of those links. We might be able to put, uh, a page together, uh,

iwona_winiarska: 57:25

definitely put more

Jon-1: 57:26

the video. So if folks are listening to this in the podcast, you can head over there, um, and we'll put a link in the podcast description so you know where to go. Um, but that's a sort of a starting point. So it sounds to me like, um, this is what fre. um, business technology strategy needs, you know, if you are going to try and deliver long-term value, which is the holy grail. Yeah. I honestly think having the customer centricity, making it a customer centric view is a, is a real penny dropping. It's so obvious, it's annoying moment for me, um, as a, as a kind of a lens, uh, to go into any business strategy. And it's a really good challenge because it's challenging everyone. Do we really understand our customer and do we really understand the problems that we need to solve for them? Because that's gonna give you just such a great insight and, and a kind of like a, I think the Americans would call it a north star to head for in terms of, um, of making decisions, et cetera.

iwona_winiarska: 58:35

Yes, that's right. I think, um, what's really helpful is that once when you do this exercise and you find out how wrong you've been about something, then it's a kind. Addictive to pursue that path in whatever what you do, because you know how things may change depending on what you learn from your customer, and I think that's really so much insightful that I can't imagine any other piece of work without being customer-centric. Brilliant.