Host Intro

It gets us to the next session, which comes from Gayathri Shriram from TCS and Mark Anning from Openreach.

Requirements aren't talked about a lot within this community, but we were so intrigued by this submission because they made a case that requirements must be done well to get good outcomes from technology. And I don't care whether you call it a user story, an epic, a requirement. I mean, this is all about, you know, how does a solution ideator and a solution builder jointly work together to create something that doesn't exist yet? And this involves joint cognition, joint problem solving.

So they bring up some amazing problems and things that go wrong that they brilliantly explore. So up next, Gayathri and Mark.

Mark Anning

Welcome. Really excited today to be here with Gayathri, my colleague. What we're going to talk about is charting the course to requirements excellence.

Gayathri Shriram

I'm Gayathri, and I work in Mark's team as an agile coach and OKR coach. Something about me: I believe that each one is unique and we have all the power and strength to achieve whatever we want in life.

Mark Anning

Thank you, Gayathri. And as for myself, I lead the Openreach team of Agile coaches. Collectively, Gayathri and myself have over 40 years' experience in this field. If you broaden this to my whole team, well over a hundred years collectively. Incredibly powerful team that I'm really proud to be part of.

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? I was going to share two words with you, and just think about what these mean to you.

First word: sub-con. Subcontractor. Just take a moment. 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 Gayathri and myself work together, and indeed how TCS partners with Openreach.

Anyway, enough about ourselves. Let's have a little overview of our two companies.

Gayathri Shriram

Starting with TCS. TCS is a global IT service, consulting, and business solution organization, and we are on the forefront of digital technology, helping organizations in the digital transformation journey.

Due to our commitment to quality and our ability to develop end-to-end solutions, we are chosen partners of many top brands, companies, which is Openreach. And we are proud to be associated with Openreach.

What we do is we empower business, we enrich solutions, and also we create a sustainable world.

Mark Anning

Thank you, Gayathri, and that pride, it is certainly reciprocated. It's a shared pride between our two companies of how we work together and what we're achieving together.

Now, Openreach, you may know, we run the UK's digital network. Now how is that for a compelling statement? A cause that all our people rally behind. We have our own distinct culture in Openreach, separate from BT. Absolutely.

Now, two companies partnering together, this is really the key takeaway. This is what made this whole exercise a success. But topic for today: I could dwell on that, I could speak on that all day, I really could, is what follows.

Gayathri Shriram

So what is really the course of structures? We will start with the problem: why, so the origin, why did we look into this requirements excellence? And then next we will go to 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.

In our journey, we faced a lot of challenges. 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.

Mark Anning

Thank you once again, Gayathri. And to stress here, what is so remarkable about our part of Openreach, our division of Openreach? So Openreach as a whole, it is the scale and the pace with which we are able to roll out this network.

Gayathri, 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 part of Openreach, several key things we saw happening. One was avoidable bugs. 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 far more rework, and thus waste, than we would have wished for there. 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? In one word: frustrating. You know, it is like we had this jigsaw. The jigsaw had missing pieces. We didn't even have an entire view of what the jigsaw should look like. It really was like that.

How did this manifest itself in the ways of working with our part of the company? Unfortunately, it actually led to a little bit of a blame culture and to finger pointing. You know, this is going on: "Oh, it's an issue with your product owners, isn't it? You didn't understand the requirements." "No, it's not, it's an issue with development." "No, not development. It's in live." 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 somewhere between 500 and 700 people as reside in our division? But moreover, not a fire-and-forget, how can we make these improvements sustainable? A little bit on the problem statement there.

So the approach that we used. Now, requirements excellence, requirements maturity. Isn't this just something of an oxymoron? I mean, can a requirement ever be viewed as being mature in this volatile, uncertain, changeable, ambiguous world? Things are changing. What does requirements maturity even mean?

And that's exactly it. And something we discovered is it's not actually requirements 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, and those people who ultimately are delivering that need to realize those customer, those user outcomes.

Now, of course, 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 previous transformation initiatives, but hey, you've got a basket of measures. What happens? It looks like everyone is meeting the measures, but then you look at the desired outcomes and stuff isn't changing. What's going on?

Well, through portraying these things as targets, you actually change what you're measuring, and you often breed, certainly unintentionally, a kind of tick-box mentality, a cargo-cult mentality where people are just going through the motions, don't understand why; they're just doing it. We were particularly cognizant of that. We did not wish to do that at all.

So how did we position our measures? 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 going to talk about in quite some depth in a few moments, ways to achieve this.

This is what we'll cover: Requirements Maturity Assessment Tool, RMAT. Sounds a little bit scary, doesn't it? Assessment tool. Well, it isn't. It isn't. It's to understand the gaps. What are these gaps? The Requirements Maturity Toolkit, RMT. 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 Gayathri 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.

Gayathri Shriram

Thank you. Let's deep dive into our approach, first starting with the Requirements Maturity Assessment Tool. So what is the challenge that we faced? We saw that there is no standard way to measure the requirement maturity of the tribe. So that necessitated us to create five maturity levels called the Requirements Maturity Assessment, wherein we have defined the five levels starting from level one to level five.

But keeping our focus on the hearts and the minds, as 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 there is a problem requirement." "Okay, can we solve it together?" "Yes, let us solve this together." "Do you know the as-is position?" "No, I do not know." "Come on, let's use this assessment, assess your as-is position, and you want to choose where you want to go from here." "Choose the assessment from here. I want to go there."

So this Requirements Maturity Assessment helps to understand the pain points. What are your current pain points? Baseline the as-is, choose the improvement areas where you want to go, and then work with your tribe agile coach and implement the improvements, and continue with the inspect-and-adapt process.

So what do you achieve by this? You have a baseline set of things where you are, you know where you want to go. So this Requirements Maturity Assessment acts as a lighthouse, which will point you, show the mirror to you. "Okay, this is where I am; this is where I want to go." So you have identified the gaps and prioritized the next steps.

Let's next look into what actually goes into this assessment sheet. 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. Starting with the problem that we face, it's the persona. You need to understand your persona: what is the problem that you are solving?

UX comes into picture. Then you need to collaborate with the designers, developers, or the stakeholders. BDD 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 we thought of and put it as different levels, the snapshot you are seeing on screen.

So now we have the RMAT, the requirement assessment tool; we know what goes into it. Let's look into the toolkit that helped the product owners in the journey.

So now we know where we are, where we want to go. Our journey has started. Because the journey has started, 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 creep, delays. There was no consistent way that a product owner can move towards improved requirement maturity.

So this necessitated us to create a Requirements Maturity Tool, which will help the product owner from the start where you understand the problem with the problem statement template with filled-in contexts. Everything was in a centralized space, Confluence, where quickly they can take the help of these templates, build the strategy, use the lean canvas, until you go to the end, which is building the MVP.

So what is the outcome that we hypothesized? Hey, this will enable you to go the minimum viable product 1.5 times faster. You will have improved alignment with your business goals, and most importantly, you improve collaboration and better user experiences is what you're going to get.

So talking about the improved collaboration, what is the next step? Use the BDD. How did we use the BDD and to realize this collaboration? Let's see that.

So coming to BDD, what we think of BDD is immediately we think of automation. No, we again kept about the hearts and minds first. People first. Collaboration is important. Conversation is important. So make sure that the teams are having the conversation. 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 copilots, use of copilots, your techniques and all, because we have started the collaboration people first. So then we started using the copilots for the ACs, and then BDD learning sessions, collaborating approach. We also created prompting techniques you can use to collaborate the profile.

So the impact that we saw was it expedited the acceptance criteria writing. There was a better understanding of the requirements.

Host Interjection

Sorry, Gayathri and Mark. We have five minutes left. So my recommendation would be go to the kind of incredible grid of things that can go wrong, testimonials, and help you're looking for.

Mark Anning

No problem at all. Absolutely. Yeah, we are certainly running to time. So a few words from Gayathri on OKRs, and we'll do just that. But objectives and key results: absolutely critical to realizing the value. So a few words on this slide, and we'll do exactly that.

Gayathri Shriram

Speaking on the OKRs, the value is there. From the output we had to shift the culture from the output to the outcome, and OKRs just did that.

Instead of saying just, "I want to go to the gym to exercise," so what? Why do you want to go? Not to exercise, but to make a better version of myself or to win 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 changed. The people started talking, "Okay, I didn't do feature X and Y. I increased the total homes passed. This feature decreased the truck roll." So that is the change that brought in the OKRs, which was very crucial in the journey.

So let's see the next one. What are the tools and techniques that we use? So it's like, if you have a blunt axe, it is going to slow you down. So tools and techniques are very important. To step up the team, we use the swarming technique, where all the developers 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 phase than we intended to.

So let us go and see what are the challenges that we faced and how we approached them.

Mark Anning

Yes, thank you. So as you can see, not inconsiderable challenges, as you would certainly expect. I'm going to 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.

And that shouldn't actually be a surprise because, hey, of all these variables, what have you got? You've got time, you've got cost, you've got scope. Only one of those variables is really true. It's time, because 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.

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, which of these techniques did our people find 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 Gayathri, really our impact.

Gayathri Shriram

Coming to the impact: did we really reach the destination? Yes, we did. Remarkable. We found that the design defects reduced to 81% quarter-on-quarter. The overall bugs reduced to 31% quarter-on-quarter. Fantastic.

But what we liked the most was the cultural shift. When people talk to us, the language they use, that caught a smile on our face, which is the way they talk from the shift from the output to the outcome. That made 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 sure that we keep on improving on this.

One thing we learned from the implementation is that 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.

Host Close

Lovely. Fantastic. Well, thank you.

Fantastic. Thank you, Gayathri and Mark.