So you have established a software development process. Now what?
This question always comes up at a point when development teams have settled into their initial process and each team member understands the work flows, its tools and its artifacts.
It sometimes becomes difficult to explain why the processes that have been just implemented are just “initial” processes and that they now need to get down to the tasks of evolving these processes.
So why do you need to evolve an established process that everyone appears comfortable with? The answer, I believe, lies in determining the end objectives of any software development process, and those are to (1) maximize throughput (or minimize time to market) and (2) reduce work in process inventories.
While the first is easily understood and justifiable, the second is a bit elusive and as some may say, nebulous and theoretical. So let’s try and understand who is saying it and why they are saying it.
To many organizations, caught up as it is, with a routine and a host of day to day distractions, the thought of reducing work in process inventories probably never even crosses the mind.
I mean, is that important or can I just “get on with my job” is the attitude that flows back at you, especially if you are engaged as an external consultant. Here is a very apt graphic that captures the tone of the engagement at this point in time:
This question always comes up at a point when development teams have settled into their initial process and each team member understands the work flows, its tools and its artifacts.
It sometimes becomes difficult to explain why the processes that have been just implemented are just “initial” processes and that they now need to get down to the tasks of evolving these processes.
So why do you need to evolve an established process that everyone appears comfortable with? The answer, I believe, lies in determining the end objectives of any software development process, and those are to (1) maximize throughput (or minimize time to market) and (2) reduce work in process inventories.
While the first is easily understood and justifiable, the second is a bit elusive and as some may say, nebulous and theoretical. So let’s try and understand who is saying it and why they are saying it.
To many organizations, caught up as it is, with a routine and a host of day to day distractions, the thought of reducing work in process inventories probably never even crosses the mind.
I mean, is that important or can I just “get on with my job” is the attitude that flows back at you, especially if you are engaged as an external consultant. Here is a very apt graphic that captures the tone of the engagement at this point in time:
So now what? You have seen the problem and have wheels to offer, but your client says, “No thanks. We are too busy”. Or, “This is too theoretical! People are getting bored.”
Firstly, and let’s just get this out of the way – What the hell is “work in process inventory” for a software development organization? For software development organizations, “work-in-process inventory” is any software artifact, the creation of which has consumed some effort, and the said artifact has not been deployed to production yet. That includes all code files, test or database scripts, or documentation that is being worked on.
To really get to grip with this, you got to take a look at costs. Assuming an average blended rate of $1 per hour per seat at a development centre in India. Now say, the TL of Team A has spent 2 hours reading the specification, an hour in discussion with the architect, and another hour in a discussion with the creative team on the user interfaces.
Together, the total time spent by the TL for this one requirement is 2+1+1 = 4 hours, which at the rate of $1 per hour works out to $4.
Total effort including the architect and creative designer works out to 4+1+1 = 6 hours, or $6.
Now suppose the TL switches context to another requirement and spends 2 hours in a discussion with the business analyst to develop, say, design options. Total effort by the TL and BA put together is 2+2 = 4 hours or $4, taking the total “work in process inventory” cost to $6 + $4 = $10. Both these requirements are a long way from production.
Now consider a centre with 100 developers. This amounts to 100*8=800 hours of capacity per day. Assume a cycle of 2 weeks, i.e., 800*10 = 8000 hours. Take a scenario where 35% of the effort (not too bad for many organizations) is spent in each cycle on artifacts that never move into production or one reason or the other (low priority, resource constraints, technology hiccup, upgrade needed, etc). That is 35% * 8000 hours = 2800 hours, which in cost terms is $2800 per cycle, given the same $1 per hour rate (this rate is difficult to achieve with just a 100 person team and is likely to be in the range of $2.35 to $3.00 per hour) .
Over 26 cycles (theoretical maximum per annum for this team), that amounts to $ 72,800.
Given a blended average annual CTC of $13,500 per person, the figure derived here works out to 5.4% of salary cost (COR). In other words it is like having an additional, hidden bench of 5% throughout the year. If you take the more likely cost per hour figure for this size of development centre, the bench works out to between 14-20%.
Now what? The solution lies in identifying who is really affected by increasing work in process inventories. In other words, who owns the cost metrics. This will, in most cases be either the portfolio or service delivery head, or the head of engineering, usually someone who owns the project management function within the organization.
Engineering, as we saw earlier, has the two objectives:
Incidentally, another dimension to WIP inventory is Technical Debt, but measuring that is even more nebulous, so we will cover that in another article. What is the solution? Meaning, how do you go about reducing WIP inventories? That’s precisely what Kanban is all about and the subject of yet another article. For flow process, this is fairly straightforward as long as there is a common definition for work prioritization. For batch processes, it is a more involved process and organization’s will get there over time through staged process evolution (Process Roadmap).
Does it make sense?
Firstly, and let’s just get this out of the way – What the hell is “work in process inventory” for a software development organization? For software development organizations, “work-in-process inventory” is any software artifact, the creation of which has consumed some effort, and the said artifact has not been deployed to production yet. That includes all code files, test or database scripts, or documentation that is being worked on.
To really get to grip with this, you got to take a look at costs. Assuming an average blended rate of $1 per hour per seat at a development centre in India. Now say, the TL of Team A has spent 2 hours reading the specification, an hour in discussion with the architect, and another hour in a discussion with the creative team on the user interfaces.
Together, the total time spent by the TL for this one requirement is 2+1+1 = 4 hours, which at the rate of $1 per hour works out to $4.
Total effort including the architect and creative designer works out to 4+1+1 = 6 hours, or $6.
Now suppose the TL switches context to another requirement and spends 2 hours in a discussion with the business analyst to develop, say, design options. Total effort by the TL and BA put together is 2+2 = 4 hours or $4, taking the total “work in process inventory” cost to $6 + $4 = $10. Both these requirements are a long way from production.
Now consider a centre with 100 developers. This amounts to 100*8=800 hours of capacity per day. Assume a cycle of 2 weeks, i.e., 800*10 = 8000 hours. Take a scenario where 35% of the effort (not too bad for many organizations) is spent in each cycle on artifacts that never move into production or one reason or the other (low priority, resource constraints, technology hiccup, upgrade needed, etc). That is 35% * 8000 hours = 2800 hours, which in cost terms is $2800 per cycle, given the same $1 per hour rate (this rate is difficult to achieve with just a 100 person team and is likely to be in the range of $2.35 to $3.00 per hour) .
Over 26 cycles (theoretical maximum per annum for this team), that amounts to $ 72,800.
Given a blended average annual CTC of $13,500 per person, the figure derived here works out to 5.4% of salary cost (COR). In other words it is like having an additional, hidden bench of 5% throughout the year. If you take the more likely cost per hour figure for this size of development centre, the bench works out to between 14-20%.
Now what? The solution lies in identifying who is really affected by increasing work in process inventories. In other words, who owns the cost metrics. This will, in most cases be either the portfolio or service delivery head, or the head of engineering, usually someone who owns the project management function within the organization.
Engineering, as we saw earlier, has the two objectives:
- To maximize throughput (by reducing time to market), and
- To minimize WIP inventory
Incidentally, another dimension to WIP inventory is Technical Debt, but measuring that is even more nebulous, so we will cover that in another article. What is the solution? Meaning, how do you go about reducing WIP inventories? That’s precisely what Kanban is all about and the subject of yet another article. For flow process, this is fairly straightforward as long as there is a common definition for work prioritization. For batch processes, it is a more involved process and organization’s will get there over time through staged process evolution (Process Roadmap).
Does it make sense?
No comments:
Post a Comment