Philippe Guenet

Today, I will talk to you about a journey.

I work for GFT, which you probably don't know. GFT is a business and technology consultancy, and we tend to be fairly famous for nearshoring, onshoring, and we specialize in financial services. We are sort of boutique at scale, in effect. We have about 4,500 people, with centers around Europe, and centers in Central Europe and South Europe for delivery centers, cheaper cost location, and South America.

One colleague of mine said we are the biggest IT consultancy you never heard of. So, that position. And we've been doing Agile for a long time in banks. As far as I can remember, we've been pitching Agile when people told us, "That's not for us. It's not working." And indeed, we've been going through a lot of teething issues.

I'm caricaturing a bit the project here, but taking real elements. I can't tell you the client, I can't tell you the domain, I can't tell you anything about the project, because we keep that confidential to our clients. But it's a typical live scenario, and I think we've heard a lot of success stories, and you probably will relate to more difficult stories, in effect.

And this one was pretty much a pre-committed budget, deadline, regulatory compliance, so you had to hit a certain element of objective, being compliant. What the scope was is always quite woolly, and that evolves through the course of the project. So Agile is not necessarily done by choice. It's done by necessity, and things will change across.

Initially, my first estimate for this project was 24,000 man-days, very simply done on the back of a fag packet, really. Looked at a couple of modules we delivered with a number of use cases, looked at all the use cases we had, and said, "Just multiply and factor. That's what it's going to be, unless we change the way we work."

And nobody believed that. But to date, it's probably the most accurate estimate that ever existed on this project.

Now, it went into a planning phase of two months or thereabout, to net out at 17,000 man-days for this project. And that was already pretty much 20 people doing this, trying to flush down the scope, understand it better, and that was already 800 days consumed.

Eventually, we decided to go for an architectural evolution instead. The argument being that, focusing and asking my team, "Do you believe this is going to be delivered as a greenfield?" They say, "No way. There is too much to change, too much unknown. That's never going to deliver."

So we went for an evolution instead. Fundamentally, if you think about it, we're trying to replace a Java stack on top of a database with a Java stack on top of a database. And the problem is not the technology. The problem is the processes around it. So if the legacy came to a point that it wasn't manageable, the new greenfield application will come to the exact same point.

Evolution was actually much easier, in terms of man-days, to achieve the objective, but that was a journey of refactoring that had to be taken as well.

And so we used SAFe. We also went through the planning cycle. We're shaving scope to make it fit. But every time we shave scope, the scope kind of reappeared like the Whac-A-Mole game, in effect. And that scope reappearing was at the tune of about 40, 50% per release train.

And it still delivered on time. But it doesn't take a rocket scientist to say something had to give. And indeed, the quality had to give. The amount of refactoring we should have been doing along the way didn't get done, so we really had a very hybrid product in the end. And the team, of course, got burnt out. A lot of the delivery was utterly inefficient in that process.

And in the end, actually, there has been, since then, a lot of improvements around DevOps, reducing cycle time, cleaning up some elements of the architecture, refactoring. And now, actually, probably the same throughput is achieved with half the number of people. And the people have not changed. The stakeholder has.

So there was really a governance issue.

As a consultancy, we of course get blamed for that, but we don't really have any power to fix it most of the time. And I don't know if there's any continentals around here. The famous phrase from that bird that I grew up watching as a cartoon is, "It's so unfair." It's now on Sky, apparently, I just found out.

But as a consultancy, we've got to be the expert. And I would love to play that video. I don't know, 15 million views, I suppose quite a few of you have seen it. If you haven't, please have a look at it.

We have to be the expert. And here, the expert is being asked to draw six perpendicular lines to each other and not bothering about geometry being an obstacle.

So we have to find, and I played that to all my delivery managers, to say we have to find answers. We have to find ways of convincing those people that this is not logical, this is not working.

In trying to find those answers, we analyzed the problems. And there's plenty of reasons for waste in the delivery of a project, but I've selected three of them and gave a rough estimate of what element of waste are created.

So the product owner not sufficiently engaged meant that we had to do a lot of UX evaluation for those people to make the decision before it went all the way down to development. Very waterfall. We had to rework a lot of the un-elaborated stories. We had to actually wait time for answers because the elaboration was never enough, and that interaction in Agile, in the distributed environment, is wasteful sometimes.

And we also had to over-engineer a lot of the requirements that they said were absolutely must-have, when they were clearly not something to meet the expectation from the regulator. And if you think, that's probably about 30% waste into the project.

Now, we are also a management with no Agile culture. So any time there was a doubt on the delivery date, rather than trying to adjust that in flight, what happened is that we stopped half of the team to redo estimation, redo rescoping, and define what it is we will be delivering. But we consumed the team doing that. We were not progressing the development. And that probably equated to about 20% waste or thereabout.

And then the legacy process, where we kind of shoot ourselves slightly in the foot in that case because we went for an evolution roadmap. But that evolution roadmap was supposed to also do some refactoring along the way. But in pushing down more and more and more functionality and not ring-fencing that refactoring, you end up having non-ideal solution, notably DevOps, for instance, where the release took so many hours every week.

The build process wasn't great. The tooling we had to work from, the VDIs and infrastructure we had to work from, didn't even compile an application. So you are in a state where you are leaking time all the time. And since nobody puts a number on that, nobody worries so much about it. You just have to man up.

And if you think about it, if you take an efficiency baseline at 100%, those three things, it's cumulative. It's not additional, really. They are different aspects of waste that cumulate. So you end up with only 45% efficiency or thereabout. So as your team is being stretched, as your deadline is being challenged, you're actually running only 50% of your capacity is producing something useful.

So for us, that's clearly not something that is acceptable, and it's something that, as a profession, we have to fix because we got a duty to our people. Heroic delivery, if you manage your deliveries through heroism, there is a problem. Your team will burn out, they will leave, and then you have attrition issues. So we have that duty to actually the people, to keep them working in a sane fashion.

We have a duty to our reputation. If we create poor code and if we let the quality slip during the delivery, we'll end up with technical debt of our client, and we get the blame. And then we can't afford the project crash. If our stakeholders are let down, then we're getting a big problem with our clients. We have that duty to our clients.

So, bit of a revelation was reading The Phoenix Project, and Gene is not paying me for that. Reading also The Goal and starting to think, how do we apply the theory of constraints to IT?

One bottleneck at a time. So if we analyze the product owner problem, it's one of the worst there is because it's an upfront bottleneck. And an upfront bottleneck, you can never really see. In manufacturing, it's much easier to see bottlenecks. But an upfront bottleneck, you never really realize what you need to do with it, and you never really identify it easily.

Now, what happens if your deadline is in danger and you have more scope than you can deal with? What, in your experience, is a typical reaction of a project manager?

We put more people in. More developers, more testers on. But if your bottleneck is upfront, all those testers and developers, what they do is they create waste. Your throughput will be commanded by the smaller size of the delivery pipe. And as the theory of constraints says, you need to actually subordinate the rest to it.

So in that case, what we have is the developers, a large part of their time is done elaborating requirements, is done actually creating defects because those requirements are not clear enough. And then it goes into a defect cycle that itself is very, very consuming.

So solutions to that are having more measurements that are focusing on what the people actually do in development. Are they doing other things than developing code? And yes, they need to attend ceremony, and yes, there is a level of waste that is expected. But is it abnormal?

Then we need to look at things like balancing that flow. Have we got enough people that can drive the requirements, and how can we have that whole pipe being sort of equal and augmenting the throughput that way?

And then I also found, and everybody says that, but shortening the cycle time is essential. What we've seen is people, upfront analysts and product owners, they may feel that they have to feed the team, so they feed them with half-baked requirements. What happens is then they catch up at the defect cycle, and then you have an increasing number of defects. And the management of that is very wasteful.

So in shortening those release cycles, then we are in a position to say, well, what you are actually putting in the machine to deliver, you really have to think it's going live. So it has to be put in at the state of readiness that you are ready to accept it live.

The next aspect of what is scrum and excessive planning is you have effectively a large part of your team is completely consumed in supporting the planning exercise. They're not actually delivering software. They are delivering comfort for senior stakeholders. And people try to establish this as the truth and a comfort factor when, in reality, this is all speculative. You have no knowledge. It's not elaborated. You have no knowledge of actually what the demand is.

And you see small requirements, and I have one example was, do the migration of past year data. So that requirement, you feel, okay, I take the past year data, I fit it into the new schema, I display it in the same way. If there's slight difference, I don't mind.

No, no, no. The requirement was to have a UI that will compare exactly the matching field and the unmatching field, and pre-populate in certain cases, and so on. And it's only when you get to the elaboration. But you can't do the elaboration like that upfront.

So you really need to have a way of governing this in flight. Your estimate, we should accept 24 man-days. What do we want it to be? We want it to be 10. We want it to be 12. Let's have everything we do, that use case, we need to do it in half that time, and let's drive those targets.

So let's flip this around and start managing to it rather than try and elaborate and estimate upfront and do that upfront, because that doesn't work.

Now, we also see people that have not got that Agile education. It's not straightforward to think, how do I optimize my flow end to end? It's not straightforward sometimes to think about an answer that feels left-field, but it's totally logical in Lean. But most of the time, it's not evident. And you need to have that mentoring and education going throughout for that.

And the cost of planning, we need to measure it. It's diverting the team, and you need to reduce that as much as possible. I've had the anecdote and the case on that project I'm talking about where two months, not even two months, one month, before two sprints before the delivery, the team got stopped to go into a planning exercise for the release, just to see what we were going to put in the last minute into those sprints to make it possible.

Dealing with legacy, that's a tricky one as well. It's about discipline. What's the definition of done? Do we want quality? Everybody wants quality. Are we measuring that? Are we saying we are actually riding a debt of technology that is X?

A show of hands: is anybody measuring the technical debt that you're riding on a day-to-day on your projects or applications?

Good. That's not a lot.

So we should start to measure that. And it's easy to measure. If you do something that doesn't meet the definition of done, what does it take to fix it? You log a Jira: technical debt. And then you look at the trend. And very quickly, if you include that in your reporting, people will actually start thinking, well, we are growing a debt as quickly as we're delivering functionality here. That's not right.

So suddenly, the stakeholders start getting that influence about making the right decisions.

So those were point solutions, but the difficulty is, how do you get to industrialize that into your delivery process? And that's why it becomes tricky, because everybody can have an input, an idea, and evidently comment on something, but how do you prevent it?

And that's where I think everybody is aiming for this state of agility, that shooting for the stars, but we are in very much of a nebula and trying to ignite pieces of dust and gas to see if they catch up completely.

And what I'm seeing is Agile is describing very much what that state is and trying to apply that upfront. But this is a transformation program. This is a transformation where people resist that. This is a transformation where budgets don't allow that, where you need to be accountable for some things.

And management, essentially, and the business, I've seen them growing, thinking Agile is that thing that the technologies do, but it doesn't really change what I want. And they're trying to put that responsibility of product ownership on me, which means I'm suddenly responsible for the plan and I'm responsible for all the scoping. How is that my problem? That's what IT does.

So suddenly, that dynamic, we need to break it. We need to draw those bridges. There's a function in the bank, most of the banks, called change function, that has been there forever to do that function, to actually be the bridge between IT and the business.

And the business likes that. They don't want to be fully involved. The product owners don't want to spend their time with an IT team. They want to drive their business. So that makes it really difficult. It's a change program for the business. And unless we start talking in business terms about making an organization leaner, about reducing costs, the business doesn't buy into it.

So I'm developing a model, and we call that G3. And everybody wonders what G3 is, and it's a third generation of a model.

We had a generation one that was one team operating around UX and UI across the bank, and they brought specialism. And they got brought into projects, and that worked very well. So it wasn't particularly Agile, but we're working how they can interact better with other teams in Agile fashion.

But it brings this great ability of leveraging specialism. Specialisms that are hard to find, because it's all great and good to say we need to have cross-functional teams with unicorns of all sorts, but they're not easy to find. So how do you scale that specialism across? Do you need that specialism day to day in your delivery all the time? Not necessarily.

So we're seeing that in creating those transversal teams with a special purpose, we're actually driving more specialism, we're staffing that easily, and we're driving reuse.

So suddenly, when we try to drive transformation of technology by reusing data grid, for instance, in UX, by implementing a common way of delivering software to live, we are seeing that it's better to actually have those driven by horizontals. But those horizontals have to be embedded into the feature teams. They have to be part of those, and they help for as long as they are needed, and then they should leave. And when it's steady, they're not needed anymore.

So we're seeing that those horizontals would be needed around Lean Agile to create that framework of having measurements in place and having a waste approach that can be discussed with your upper management, and seeing that we're driving a better delivery.

We're seeing we have already a team operating like that in UX and UI. We're seeing great benefit of that by reusing components and driving that sort of unification of user front ends.

We are seeing a need and starting to develop, and I've already operated a few teams like that around data and big data. Massive transformation in banks, a lot of problems about duplication, about golden source, about security, secrecy and so on. And it's only by having a team that can drive that message into the implementation teams that you enable that.

And then DevOps, obviously, all the stories around unifying DevOps, the fact that DevOps probably needs a SWAT team that get that in place in the right way and then can run fairly steadily with the development team only, makes actually space for having teams like that.

And finally, we're also seeing that applicable in a non-tech area about regulatory compliance, where it's useful to actually drive something where you can reuse all the analysis of processes in the bank that you've done from one reg compliance to the next reg compliance. Doesn't always match, but once you've done two or three, you can map your entire architecture for impact assessment.

Next point is we are trying to implement a culture of tracking waste, and we're seeing that at different level.

There's a general waste where you look at the onboarding cost. Sometimes it takes a month to onboard a developer. The tools, working from some of the tools we've got, I measured about 8% actually productivity drop as a result of that. And that's not the tools. That's the tools we are imposed with.

Driving reuse, team rebalance. People have the tendency of getting as many seniors on their team as they can. Can we rebalance that? Is that needed? Once the best practice are implemented, can we have a team more pyramid-shaped? And suddenly you lower the cost.

Then we look at the process waste, and essentially the factors of waste in Lean, not all of them are applicable. But the motion waste, transport, and wait waste are actually very applicable to IT. So if we look at how this goes through those phases, and in an Agile way, you have to go through that anyway, it's just you iterate a lot. How you go through those phases and what is wasted in those steps. And if you measure that, then compare to your happy path, then you can have a view of your general process waste.

And then if you look at your available rework, so it's fair, in Agile, you need to try and test, and trial is a very good way of progressing. But if you start realizing you're spinning your wheels, you're actually wasting, and it's a fine line between the two. So here we track those things.

And then looking at the debt, we need to look at anything that is wrong in architecture, anything that is wrong into the code. What does it take to fix it? Let's log it so that we have that element of information.

And I'd like to get to the point where we can actually measure the interest rate in IT. Once we have waste and defects leading to incident, and incident and some rework and manual tasks are effectively the factor of your technical debt. It's the servicing on that debt.

So I'm aiming to have here a view of the interest rate. If you write a debt of that much, I'm pretty certain that it's a constant in IT that I'm still to find, where we measure that there's a disruption to your development process that drags, effectively, and there's a cost to it.

So this is very much work in progress. This is very much something we're trialing. And we have had early teething issue, no doubt. And the bandwidth of our developer, let's say, to be self-critical, to analyze waste, to measure, and everybody to start thinking in that fashion is difficult to drive on a scale.

There is a lot of disconnect around the organization and very little Lean culture in IT. And sourcing is an entire matter together. They're not necessarily connected about how do we improve the delivery of IT, and they want to see that in numbers straight away.

Integrating vertical and horizontal unit is difficult as well. Vertical, not so much, but we need to break that alignment of resources or teams to applications, and that's a difficult concept. You need to build a delivery unit where people can move a bit more, but you can actually recycle those people. So you recycle, you leverage your seniority, and that unit size ideally is around 60, 80. If you go lower, then you're more aligned to one project and one application.

But one reason for that, by the way, is if you want to break monolith, don't organize as monoliths. If you all organize against an application, well, that application will carry on existing as an application. So by creating those verticals, you need to break that.

Nobody really wants to highlight the waste. It's shameful, but unless you do that, you're not progressing that much. And management doesn't like, I was about to say, dancing the Gemba. Gemba is walking the floor in manufacturing. So you see, management doesn't like very much that.

So if we bring and elevate waste numbers to them and the proposition to solve it, then they become part of the deal. They become involved without having necessarily to walk the floor.

Driving the transformation from data, we have started with more advanced Agile dashboards, and people really like that. Data is missing, and we're trying to get away from any subjective RAG status. We're trying to drive all our delivery from dashboards that are factual, and we measure certain things, and they are here to tell us certain things, and then educating the people from that.

The early things are obviously the burndown, but also looking at utilization, focus factors, and determining whether the product owner is playing that role or not so well, are things that we have in the dashboards.

And lastly, scaling. We are starting with ourselves, and we call that eating our own dog food, because you have to try, you have to test, and you have to show.

We are looking at commercial model and incentives. So in trying to incentivize our clients to do that, we're looking at committing to a saving level. Even if it's risky, we're committing to that saving, and we're inventing an operating model where we can raise CRs if we can't realize the savings.

No. If we realize the saving, we're taking the risk. If they don't want the savings and it's a genuine one, we create some form of CR. So we're developing a model where we can manage run development as a managed service and create efficiencies and commit to those efficiencies.

And lastly, we're looking at scaling this to the enterprise level using automotive experience and fast cars.

I don't think we've found the Holy Grail yet. This is really a journey. And anybody that has been inspired, please talk to me, and tell me what you're doing as well, because I like to learn.

Thank you very much.