 Can you guys hear me? So I saw this Dilbert a few days back. I think it was just published two, three days back. How many of you have seen this one before? And I thought it was extremely timely that it happened to come at this time of the conference. And at least in the service organizations that I have worked for a long period of time, this continues to be a fairly major barrier between how we as service providers deliver the project for our customer, and how the customer sees the value coming back to them. So let me, I want to start by just giving a little brief about myself. My name is Shudipthu. I work for a company called Digite. We are in the ALM space. We have a product for software Kanban development called Swift Kanban. And it's been one of the pretty successful products in the space of Kanban software development. One of the things that I'm very passionate about is how agile can be adopted to fixed price projects. And there's a fairly strong myth or there's a fairly strong belief that agile cannot be adopted to fixed price projects. And so what I have done is over the years and working with different teams in a consulting capacity, try to build out models and structures that could break that barrier and actually make agile possible in fixed price projects. And of course, it needs to be adapted. There's a verbatim implementation of that. So there are two components of that. And I do these two workshops separately. The first is where we do a capacity planning exercise with teams. And the second is from the capacity planning, we derive budgets. And then we use earned value metrics to be able to track whether the project is getting done on time on budget. So that is the context under which this session has been thought of. So let's talk about a few basics. How many of you actually have really stable teams in your projects, teams that have never changed in size for the duration of the project? Right? So that's a fairly rare occurrence. And a lot of the agile thinking is based on agile thinking, agile dashboards, metrics are based on the fact that I'm going to use my throughput and velocity of the current team to predict the future. But if your team changes continuously and their profiles change continuously, if your team is in a ramp up mode and then they go down, that concept cannot be applied as is. So that's the fundamental problem that we are trying to solve. On the other hand, in fixed price projects, you often get asked these questions by your managers that how many resources do you need? Give me a resource plan. When do you need these resources? If you're running slow, they will ask you the question, OK, tell me, how can you make it up? How many resources do you need to bring it back on track? They'll ask the customer will give you a scope enhancement and then say, OK, can you get this done in time? If not, how many more additional days that you need? So those are the kind of problems that we're trying to address in the talk today. And it's not very, I'm going to give you actual methods of how you could do it. Of course, it's just a guideline. That's an insight. I will leave it to you to adapt it in your respective situations. But I hope that it brings value to you in terms of how some of these concepts can be applied. There is also thinking that because of the famous triangle of scope, scope, cost, and timeline, that in agile, scope is variable. And therefore, the minute you say scope is fixed, agile doesn't apply. And I've had discussion with people like Ron Jeffries on that. And I agree the principle that, yes, if scope is fixed, then agile doesn't apply by definition. But that, I think, misses the point that there are values in the agile manifesto that any team can benefit from, correct? Better team interaction, shorter release cycle, early feedback. There's nothing wrong for a waterfall, even a waterfall project, to be able to deliver value from a better team interaction, whichever way they figure out how to implement that. So I think it's important to get out of the dogma and say, oh, you cannot be agile just because you're doing a big rock execution. Yes, ideally, that should not be the case. But if that's your situation, you can still adopt and see which of the principles you can apply to the extent that you want to. So moving forward, the key question that we have asked in this scenario, in this fixed project scenario in the IT service organizations, is how much capacity do you need? How much capacity do you have to deliver this project? Correct? Whereas the question from the agile thinking comes is that what is your enterprise velocity? What is the team's velocity? How many story points can you get done in a particular sprint size, month, four weeks, six weeks, whatever be it? Correct? So the question moves from an enterprise capacity measuring to a throughput velocity tracking. And then, of course, the question moves on from, OK, how many people do you need versus are you giving enough throughput? If you're not giving enough throughput, how can you increase the throughput to make sure that the scope happens on time? And of course, in this fixed project environment, we are resistant to taking scope changes. It's been always been considered a very painful process. You make the customer go through a change control process, lots of sign-offs. And anybody who's done the change control process knows that every time you want to sign up on a customer on a change control, it's not a pleasant discussion to have, correct? Because there are commercials involved, there are effort estimates involved, blah, blah, blah. So you go through that painful experience. Whereas clearly what we want to encourage is scope changes if you know that the business needs that scope change now. The third thing that I'm going to use, I'm a practitioner of the Kanban method. How many of you have used the Cumulory Flow diagram? That's good a lot. So for folks who are not, I'll just focus on this green line. The green line essentially indicates the rate, the number of cards which are getting done completed in the last lane, if the last lane is the completion of your value stream over a period of time. So which means the slope of this line gives you the rate of completion of your cards per unit time, correct? So therefore whenever you are projecting, if you're asked the question that how much time will it take you to complete the backlog, you would essentially go ahead and say the backlog that when would this slope line meet the backlog? That's your estimated date of completion, correct? And we'll use this principle later in this session today to be able to understand what is the impact on capacity. So capacity planning obviously in this kind of environment in this fixed project mode typically happens in two sessions. One obviously is in the beginning of the project when you need to give a resource plan to a staffing organization or your resource management organization wherever you need the resources from. You need to give them a resource plan. And then as the project executes, since we accept the fact that scope changes, requirement changes, realities change, assumptions change, there's a process of continuously looking at the capacity plan and figuring it out what do I need to do, how do I need to adapt to still make sure that the scope gets delivered on time, right? So at the very beginning the process of capacity planning is pretty much the same way that we have done traditionally in the old fashioned days, which is you will take the epics, you'll break it up into MMFs, you'll break it up into user stories and you need to do some level of resource splitting to say, okay, week one I need two resources, week two I need three resources. So you pan out your resources over a period of time. We are not talking about a detailed MPP style breakup planning of how much time for requirements, how much time for design, anything of that nature. But we are saying just do a broad level planning to say this story takes this much time, this MMF will take this much time and it will also help the stakeholders also get an understanding that, okay, when will I get the stuff? You know, when can I expect some of the stuff? So if you do this, and one important point, you don't need to do it for the whole project, you might want to do it only for the next three sprints that you're planning to do it or the next quarter that you're planning to do it where you have the high level of visibility and you've taken the scope which is under contract and you've broken it down, you've analyzed it. So you don't need to do the whole thing right up front but take it to the scope that you have visibility on. And once you do that, you will go ahead and then build up a summary resource plan which will obviously have the skill profile, the different skills that you need spread over a period of time. So that's your initial plan. If you are doing budget tracking which is not strictly in scope of the discussion today, we use this to actually define the original baseline plan value for earned value computation. So I'm not getting into that, but that's a separate scope but I just wanted to make sure that you understand that capacity plan is the first step to be able to do that kind of tracking if you are in the fixed project world of execution, fixed cost project. So now that I've done the first initial plan, there's a process of how do we do a continuous planning? How do we keep visiting this? And the way we have figured it out is that instead of having just one lane for backlog, you split it up into several lanes. So in this particular example, we have split up into three lanes. The first of course everything goes into the pending lane. Then we have stuff, whenever the product owner thinks that the next set of cards are going to be ready for execution a month down the line, they'll move it from this lane to this lane. And then whenever they do a little more analysis and they say that it's going to be ready, the team is going to be ready to pick it up a week down the line, they move it from this lane to the third lane. So roughly you have split up into the first backlog, a prioritized backlog which will give you visibility that you want cards to be done within the next month and a third backlog sub lane where you essentially give visibility to what you're going to do within the next week. We're going to start working on within the next week. And if you have defined your backlog this way, you can also add policies now to facilitate capacity planning. So what you do is for the first lane, you would say that okay every time I want to pull a card out of this lane, I'm going to validate the resource profile that is needed for this card and communicate the resource profile to my resource managers or staffing managers, right? Because remember you would have given them an original resource plan three months before. You need to continuously refresh them because your scope has changed, your plan has changed. Everything is not going exactly as per plan. So therefore you are going ahead and refreshing them to say okay, I'd earlier given you this requirement, I'm now going to give you a revised requirement and I'm giving you a good four weeks lead time to be able to staff that requirement for me, right? The second one is we come to the next lane and in the next lane, you essentially say that okay, before I move a card from this lane to the third lane, which is the one week lane, I'm going to actually ask and make sure that the resources are available. And if the resources are not available, I'm going to put a block on that card. There's no point of my starting that card in the development value stream and then getting stuck because an increasing whip of the system because I don't have the needed resources. So I'm going to put a block on that card, simple method to make sure that yes, I'll validate that the resources needed are available and if not, I'm going to put a block on the card. And the third thing that I would do is that even for the cards which were prioritized for execution within a week, you could suddenly have a situation where a critical resource goes on a medical leave, personal leave, whatever. If you have a situation like that, I'll go ahead and put a block again. So essentially what we did was split the backlog, put policies for capacity planning to make it a continuous process and not a one-time event. A few things to highlight. How frequently would you do this? Whenever you're doing a backlog grooming, you would have a certain frequency for backlog grooming. Typically I've seen it happens or roughly a month in many places. So whenever you do your backlog grooming, that's what you'll do. Set WIP limits for the upstream lane in the backlogs higher than the downstream lane. So that if your cards, if a particular card you cannot pick it up because of capacity shortage or capacity issues, you have other cards in the pipeline in the funnel ready for taking to the next lane. And the third thing which I've seen teams miss is that when you're planning for capacity, you need to also keep into account what the team is working on today actively. So you need to look at the active lanes versus the wait lanes, see the cards which are there and then see what is the tentative due date for these cards. Only then you can make out that this team is going to be available two weeks from the line, he's going to be available to pick up the next card only two weeks from the line. So don't just look at your team size and backlog. You also have to look at the cards which are in the active lanes at that point of time. Okay. So now we have done a baseline capacity plan. We are continuously planning and we're giving heads up to the staffing organization. So now the question comes is what happens when I get a scope creep? So as I said before, the cumulative flow diagram will give you the current teams throughput, right? And then you would take that throughput, you would map it to your revised scope and see what is the revised throughput and then see what are the options that you have. So let's do that. So this is a real example, live board obviously the information has been grayed out for confidentiality reasons. Now this team is working with a current throughput of 16 odd story points per day, right? So cumulative flow diagram, a single click exercise gives you that team's throughput at any point of time. And most of the Kanban tools in the market would do that including my own Swift Kanban. So you can use that. And now what you're going to do is you're going to do a simple thing. If he's given you a 100 man days of scope change, you're going to add these cards into your backlog, right? And just plot the cumulative flow diagram again. So it shows that the when for this team when I added 100 man days of work to the backlog, the tool predicts that for you to finish it within the same planned date, your throughput needs to increase from 16 odd story points per day to 80 not story points per day, right? Contrast this with our age old waterfall Microsoft project planning days. What would we have to do? We'd have to do critical path planning. Then we would have to figure out resources which are not in the critical path, shift them to the critical path, figure out what is the revised critical path date. I can bet if you're doing a 300 task, 400 task MPP, that's more like a two day job for you. This is simple because bottom line all that matters is throughput, the team's throughput that they're currently working on. So once I know that I need to increase my throughput by 12% so that I can deliver the enhanced scope within the same timeline, now I can have a healthy discussion with all the stakeholders including the customers, right? I can tell them, okay, Mr. Customer, either you give me a budget for 12 more persons so that I can add some more resources and perhaps a little more, we know that if team size always doesn't add same to the throughput, you need some extra more, but whatever, 12% plus delta, or you can keep to the same capacity and you know that the deadline will extend by 12%, right? Or you can say, okay, let's prioritize on the scope, which is what the typical agile teams would do. So, okay, let's take out something because this is more important right now, let's work on this right now. Or in many cases in realistic situations, you would do a combination of all the three, right? The customer will say, I cannot delay the project by one month, okay, I'm gonna delay it by two weeks and but let's take out these two cards, put these four in, so you will iterate with them and come and figure out a final consensus that the team and the stakeholder, the customer is happy with, okay? So that's the process. The process is that you would go ahead and use the cumulative flow diagram and the throughput to be able to predict that. Let's take a simpler situation. There's no scope creep, your project is still behind schedule 12%. Okay, you know that at any point of time, by just plotting the same cumulative flow diagram, you will know that for this scope, which was originally planned, what is the revise and date? So if you know that your project is 12% behind schedule, again, same throughput magic, you will go ahead and have the discussion with your management team to say, okay, I need 12% more resources to be able to get the job done. So the same principle that you're applying in different contexts in different ways. So a quick recap, projects in service companies in India do not have the luxury of stable teams. Many, many situations, very commonly experienced. We still need to answer to our management's how many resources we need, when do we need, if you have scope change, when will that get done, if my project is running behind schedule, how many resources do I need? These are very, very commonly asked questions. Anybody who's done project management will know this in this industry. We can use the Kanban board and define policies to make capacity planning a regular part of the planning process and to make sure that you are communicating to all your stakeholders what their resource needs are and what your needs are. You can use cumulative flow diagram and figure out if the project is behind. Use the throughput calculation to see what is the incremental throughput that you need so that you can deliver it within the same scope and within the same timeline. And if you can't, work with the stakeholders, a combination of objectives, a combination of options that will help you meet the same objective. That's about it. As I said in the beginning, I've given you some thoughts. I hope it is helpful. I'm not saying that's the only way to do the thing, but it has worked for us. Please feel free to use it and adapt to it as it applies to your scenario. If it doesn't, discard it. You can reach me at this Gmail address and there's my website there also for any clarifications. Any questions? You have to write, there is no throughput at that point of time. So you're just using a project manager's gut feel estimate at that point of time to plan resources and then figure out what is the duration going to be. In most cases in these situations, they have gone through a presale cycle. There's an estimation process that has happened. There's a scope defined. People have done a lot of homework before they would have given a fixed bid estimate. So you use that information available to make that initial resource plan. So I think, fair point. So I don't think that's in the scope of what we're discussing as per se. But yes, fixed bid, in this situation, that's a reality. Now whether my personal input to all the managements and that's where Hoosover comes to me is you have a process that is working for the presales and the estimation process. You don't need to break that. I don't think we have anything from the agile community side that is better and smarter in that estimation process when you're making fixed bid estimates. So whatever works for you. The only thing that I keep on highlighting is that just like the retrospectives, you can keep doing retrospective on your estimation and your presales process to keep refining that. But there's nothing between a scrum or a kanman that can really make that more efficient or more better. So one of the tricks that we have used is that, and this again, it comes from the very old principles, nothing really new with agile, is that yes, there's an estimate, but when you pass the design stage, re-estimate. And then once you have re-estimated at the completion of the design stage, then the team is expected to own that estimate. But if there is a variation between the original estimate and the estimate at the completion of design, then you'll go to management and say, this is the reality. So either we plan for it or build risk or contingency for it. Yes? I would not do the estimation for the resource. I will do the estimation for the story. Correct? He said there is something he's not taking care of. Correct. So we do proper re-estimation on- Within limits. If it is a marginal thing, I would not, but if it is a significant shift under our major design component that was missed, then yes, that answer is yes. Next question. I'm curious, are you, is this more for like one-off kind of RFP style thing? I'm just curious, like within this environment here, is there a tendency for you to get those one-off things or do you tend to get like multiple-off and same-plans as well in the long term? What would you say? So there is a very large percentage of projects in the Indian IT service industry, which are done as fixed price projects. Oh no, they are on a regular basis. And not even the first project, even the subsequent major enhancements and versions to enhancements are all fixed. You have a long-term demand. I wonder, I would change at that point. It happens and there are many customers who graduate from the project-based engagement to what we call as dedicated center-based engagement. So they have to build the trust and then they move to a time and material billing model. But this is a very, very common occurrence here. Thank you.