00:00:00

It gets us to the next session, um, which comes from Gar Shiram, uh, from TCS and Mark Ning from Openreach. So, requirements aren't talked about a lot within this community, but we were so intrigued by this submission, um, because they made a case that requirements must be done well to get good outcomes from technology <laugh>. And, and I don't care whether you call it a user story, an epic requirement. I mean, this is all about, you know, how does a solution, ideator and a solution builder jointly, uh, work together to create something that, uh, doesn't exist yet? And this involves joint cognition, joint problem solving. So they bring up some amazing problems and things that go wrong, uh, that, uh, they brilliantly explore. So, uh, up next Di Hy and Mark,

00:00:45

Welcome, uh, really excited today to be here with, uh, dietary my colleague. Uh, what we're going to talk about is charting the course to requirements excellence.

00:00:58

I'm <inaudible>, uh, and I work in Mark's team as an adult coach and KR coach. Uh, something about me. Uh, I believe that each one is unique and we have all the power and strength to achieve whatever we want in life.

00:01:14

Thank you, RI And, uh, as for myself, uh, I lead the Openreach team of Agile coaches. And, you know, collectively simply Gare and myself have over 40 years experience, uh, in this field. If you, if you broaden this to my whole team, well over a hundred years collectively, incredibly powerful team, uh, that I'm really proud to be part of. But, but more than that, more than the experience. It's this little icon here, a little handshake icon. What does that mean? Why is that so important? Um, I was gonna share two words with you and just like, just, uh, think about what these mean to you. First word, sub con, subcontractor, just take a moment. What, what images does that word conjure up in your mind? Second word, partner. Okay, partner. Now just think about the difference between quite simply those two words and what it means to how dietary and myself work together and indeed how TCS partners with Openreach Anyway, enough about ourselves. Let's have a, a little overview of our two companies

00:02:34

Starting with T Cs. Uh, TCS is a global IT service consulting and a business solution organization. Uh, and, uh, we are on the forefront of, uh, digital technology helping organization in the digital transformation journey. Uh, due to our commitment to quality and, uh, our ability to develop, develop, end-to-end solutions. We are, uh, chosen partners of many top brands company, which is, it's Openreach. And we are proud to be associated with Openreach. What we do is we empower business, we end enrich solutions, and also we create a sustainable world. And that's <inaudible>.

00:03:17

Thank you Ry. And that pride, it is, it is certainly reciprocated. It's a, a shared pride between our two companies of how we work together under what we're achieving together. Now, Openreach, you, you may know we run the UK's digital network. Um, now how is that for a, a compelling statement? A cause that all our people rally behind. We have our own distinct culture in Openreach, separate from bt. Absolutely. Okay. Now, two companies partnering together, you know, this, uh, this is really the key, the, the key takeaway. Uh, this is what made this, this whole exercise, a, a, a success but topic for today. I could dwell on that. I could speak on that all day. I really could. Is is what follows.

00:04:18

Yeah. Uh, so what, what is really the course of structures? We will start with the problem. Why? So the origin, why did we look into this requirement excellence? And then next we will, uh, go or do our approach, what is the strategy that we applied in order to solve this problem? Next, we will just go through, we needed some tools and techniques on our journey to solve the problem. We'll dwell upon the tools and techniques that we used in our journey, okay? In our journey, we faced a lot of challenges. What, how did we overcome those challenges? We'll speak on that. Last, but not the least, we'll give you reach of a destination. What is the impact we created? Let's see.

00:05:02

Thank you once again, GTRI and, uh, and, uh, to stress here, what is, what is so remarkable about our part of Openreach, our division of Openreach? It's, um, so Openreach as a whole, it is the scale and the pace with which we are able to roll out this network. Gare, myself, our department, we actually design, we build and maintain all the systems that enable Openreach to function. A little bit of context for you there, but let's move into the problem that we observed. So in our, in our part of Openreach, uh, several key things we, we, we saw happening, okay? One was avoidable bugs. Okay? Not only avoidable bugs in a live environment, but bugs being spotted, bugs being found far too late in the software development lifecycle. We also observed actually, uh, far more rework, uh, and thus waste than we would've wished for there.

00:06:10

Okay? Finally, we felt sure that we could reduce our lead times, our feature lead time. It takes us to get our products, basically from concept through to cash. Simple as that. Now, having observed these things, all importantly, how did it feel to our people? Okay. Uh, in one word, frustrating. You know, like, it is like, like we had this jigsaw. The jigsaw had missing pieces. We, we didn't even have a, an entire view of what the jigsaw should look like. Really was like that. Uh, how did this manifest itself in the ways of working with our part of the company? Unfortunately, it, it actually led to a little bit of a, a blame culture. And to finger pointing, you know, this is going on. Oh, it's an issue with, uh, your product owners, isn't it? You didn't understand the requirements. No, it's not, it's an issue with development.

00:07:05

No, not development. It's in life. You can imagine the sort of squabbles not a place anyone wants to be in. So our challenge was how might we ourselves working in partnership as a team of agile coaches, change the behaviors of some somewhere between 500 and 700 people as reside in our division, but moreover, um, not a far and forget how can we make these improvements sustainable? A little bit on the problem statement there. So the approach that we use now, requirements excellence, requirements maturity. Isn't this just something of a, of an oxymoron? I mean, can a requirement ever be viewed as being mature in this volatile and certain changeable, ambiguous world? Things are changing. What is requirements even meet requirements, maturity. And, and that's exactly it. And something we discovered is it's not actually requirements to excellence at all. What really matters here, plain and simple, it is a shared understanding, a common understanding, and it's a common understanding between our users, our customers, the people with the need, the people who have a job to do, okay?

00:08:24

And those people who ultimately are delivering that need to realize those customer, those user outcomes. Now, of course, yeah, measures feature in this don't measures always feature. But key point to remember with measures, and this is probably the key takeaway, in fact from this slide, what happens when you turn a measure into a target? You might have experienced this sort of thing in, in previous transformation initiatives, but hey, you've got a basket of measures. What happens? It looks like everyone is meeting the measures. Uh, but then you look at the desired outcomes and stuff isn't changing. What's going on? Well, through portraying these things as targets, okay? You actually change what you're measuring and you often breed, um, certainly unintentionally a kind of a, a tick box mentality, a cargo cult mentality where people are just going through the motions, don't understand why they're just doing it.

00:09:26

We particularly cognizant of that, did not, we, we did not wish to do that at all. So how did we position our measures? Okay, plain and simple as a mechanism, as a tool, as a vehicle to understand gaps in what we are doing and address those gaps fundamentally, to realize those outcomes. Reduced lead time, reduced bugs, reduced rework. Okay? So I've been laboring the point I know, but really what this boils down to is hearts and minds of our people. That is what we need to change here. Everything else we're gonna talk about in quite some depth in a few moments, ways to achieve this. This is what we'll cover requirements maturity assessment tool sounds a little bit scary, doesn't it? Assessment tool. Well, it isn't. It isn't. It's to understand the gaps. Okay? What's, what are these gaps? The requirements maturity toolkit. How are we going to address these gaps? We need to make it easy for our people fundamentally. And then out of a whole range of techniques that dietary will cover in a moment or two, two, we'd really like to call out here. And that is behavior driven development and objectives and key results. Thank you.

00:10:54

Let's deep dive into our approach and, uh, first starting with the requirement maturity assessment tool. So what is the challenge that we faced? We, uh, we saw that there is new standard way to measure the requirement maturity of the trial. So that necessary as to create a five maturity levels called the as requirement maturity assessment. Uh, wherein, uh, we have, uh, defined the five levels starting from level one to level five, but keeping our focus on the hearts and the mind has, mark said, we need to keep focus on that instead of just telling, Hey, let's do the assessment. We have to get the result. The approach that we used was, Hey, do you see the problem of the requirement? Yes, I see this, there is a problem requirement. Okay, can we solve it together? Yes, let us solve this together. Do you know that ASIS position?

00:11:41

No, I do not know. Come on. Let's use this assessment, assist you as position, and you wanna choose where you want to go from here. Choose the assessment from here. I want to go there. So this requirement maturity assessment helps to understand the pain points. What are your current main points? Baseline the asis, choose the improvement areas where you want to go, and then work with your type agile coach and, uh, implement the improvements and continue with the inspect and adapt process. So what do you achieve by this? You have a baseline, uh, set set of things where you are, you are, you know where you want to go. So this requirement maturity assessment will, it acts as a lighthouse, which will point you show the mirror to you. Okay? I, I, this is where I am, this is where I want to go. So you have identified the caps and prioritize the next steps.

00:12:30

Let's next look into what it actually goes into this assessment sheet, right? As you can see on the screen, this is what, when we started dwelling on this requirement assessment sheet. See, the requirement maturity is not a solo one. It needed an amalgamation from different disciplines. Uh, so starting with the problem, uh, that we face, it's the persona. You need to understand your persona. Uh, what is the problem that you are solving? UX comes into picture, then you need to collaborate with the designers, developers or the stakeholders. DD comes into picture. Then the process that you are enabling, it connects you all together. It might be anything that you use. And then a common phase where one group of progress, confidence comes into picture, feature benefits come into picture. So all these be, uh, thought of and put it as different levels, the who snapshot you are seeing of screen.

00:13:22

So now we have the r, r, and P team where assessment tool, we know what goes into it. Uh, let's look into the toolkit that helped the product owners in the journey. So now we, we know where we are, where we want to go. We, our journey has started because the journey has started. We, we will find different challenges. Now, there should be somebody to help the product owner on this. So what we faced, the challenge was there was some misunderstanding. Scope three delays. There is no, there was no consistent day, uh, for that a product owner can move towards, uh, improved requirement maturity so that this necess as to create a requirement maturity tool, which will help the product owner from the start where you understand the problem with the problem statement, uh, template with filled in conflicts. Everything was in a centralized space conference where quickly they can, uh, take the help of these templates, build the strategy.

00:14:15

You use the lean canvas until you go to the end, which is the building, the MEP. So what is the outcomes? That is the, we hypothesized, Hey, we, this will enable you to go the minimum viable product 1.5 times faster. You'll be, have, include alignment with your business goals, and most importantly, you improve collaboration and better user experiences, what you're going to get. So talking about the improved collaboration, what is the next step? Use the B, d, d. How, how did we use the B, D, D and uh, to, to, uh, ize this collaboration? Let's see that. So coming to B, d, D is, uh, what we think of BDD is, uh, immediately we think of automation. No, we, again, kept about the hearts and minds first. People first. Collaboration is important. Conversation is important. So, uh, make sure that the teams are having the conversation.

00:15:08

They are not working in silos. Everybody knows the big thing, the big functionality. Once that is in state, then you can use all your co-pilots, use of co-pilots, your techniques and all, because we have started the collaboration people first. So then we started using the co-pilots for the acs. And then, uh, BDD learning sessions, collaborating approach. We also created prompting techniques you can use, uh, uh, to collaborate the profile. So the impact that we saw was it expedited the acceptance criteria rating there had, there was a better understanding of the requirements. And then <crosstalk>, uh,

00:15:43

Sorry, Gerry and Mark, uh, we have five minutes left. So, uh, uh, my recommendation would go be, go to the, uh, kinda incredible grid of things that can go wrong. Testimonials and help you're looking for

00:15:54

Mm-hmm, <affirmative>, no problem at all. Absolutely. Yeah, we are, we're certainly running to time. So, uh, a few words from GARE and OKRs, and we'll do just that. But, uh, objectives and key results absolutely critical to realizing the value. So few words on this slide, and we'll do exactly that.

00:16:13

Yeah. Uh, speaking on the OKRs, right, uh, the values there, from the output we have, we had to shift the culture from the output to the outcome. And ok, R just did that. Uh, instead of saying just, uh, I went to the, I want to go to the gym, uh, to exercise. So what, why, why do you want to go? Not to exercise, but to make a better version of myself or to win a, a trophy so that we need to change? So we used the OKRs where sessions were conducted and we did put the change on the right hand side. You can see the language got change. The people started talking, okay, I didn't do feature X and YI increased the, uh, total house fast. This feature increased, uh, decreased the 12. So that is the change that brought in the OKRs button, which was very crucial in the journal.

00:16:59

So let's see the next one. Uh, what are the tools and techniques that we use? So, uh, it's like if you don't have a, uh, if you have a blend axe, you are not going, you are, it is going to slow you down. So tools and techniques are very important. And, uh, uh, to step up the tea, we use the swam technique where, uh, all the developers, they work together, make sure that they together do the job and finish it fast. Increasing the efficiency use of copilot, making sure OKRs are used, making sure things are done in parallel. So this catapulted the team in a much faster, uh, phase than, uh, we intended to. So let us go and see what are the challenges that we faced? Mm-Hmm, <affirmative> and how we approach them.

00:17:42

Yes, thank you. So as you can see, not in considerable challenges as you would certainly expect. I'm gonna call out just one in the interest of time. Funny I should say that Key challenge time teams are scarce, time, scarce product owners especially. Yeah. Um, and that shouldn't actually be a surprise because hey, of all these variables, what do you got? You've got time, you've got cost, you've got scope. Only one of those variables, you know, is really, uh, it's really true. It's time. 'cause you never get time back once you've spent it. So, key challenge, how did we address these? It's through bringing these techniques and practices into business as usual ways of working. That is the key. Yes, you need a bit of training, common language, common understanding, but then put it straight into practice. And this is exactly what the team of agile coaches did.

00:18:36

So how does this hang all together? This is our perception of our actions, the outcomes, and ultimately the impact or cashing the check as our director would always say. So, our perception of how this stuff hangs together, what we did, but alongside this, um, which of these techniques did our people find most, certainly most valuable themselves, loud and clear. A sample of the outputs from one tribe only. Feature benefit found really clear. And this indeed was backed up by a number of verbatim comments. Here I'm sharing just a few, but have a listen. By adding feature benefit, the team understood what the product was actually intended to do, and we can now strive for continuous improvement. The efficiency and effectiveness of these activities improved our performance and consistency. Just a small sample there. And onto the final slide for dietary, really our impact

00:19:43

Coming to the impact, did we really, uh, uh, uh, reach the destination? Yes, we did. Remarkable. We found that the design that effects reduced to 81% quarter, round, quarter. The overall, uh, bucks reduced to 31% quarter round, quarter, fantastic. But what we liked the most was the cultural shift. When people talk to us, the language they use that quarter smile in our face, which is the way they talk from the ship, from the output to the outcome that made of the made of our day. So we have achieved so much. We have set a standard for ourselves now. It is our responsibility that we maintain this and we have to make, make sure that we keep on improving on this. What one thing we learned from the implementation is that, uh, in the realm of requirement maturity, it is just not enough that we connect with the intellect. We have to make sure that we use the power of the heart and the mind, because therein comes the true commitment and true transformation changes are born there.

00:20:43

Lovely.

00:20:44

Fantastic.

00:20:45

Well, thank you

00:20:47

<laugh>. Fantastic. Thank you. Uh, Gare and uh, mark.