Good cost discipline is a core capability of any successful enterprise and every manager knows the consequences of runaway costs. If not outright risking the viability of the business, broken careers, and loss of trust are often result of blown budgets. Software development gets a lot of attention because it is frequently one of the biggest – if the not the biggest – costs for many organizations. It is therefore not unreasonable for organizations to seek ways to reduce their software development costs.
Agile methodologies and practices are often offered as an approach for not only reigning in but also reducing development costs. I have been at many clients where the primary motivation for adopting agile or going through a “digital transformation” was to reduce IT costs by some significant percentage, often 30 to 40% within two years. This is mis-guided. First, this turns the agile coaches into the hatchet people because everyone knows staff are the biggest component of software development costs. A 30 to 40% cost reduction means reducing head count by 30 to 40%. This is not going to inspire a lot of trust, cooperation and enthusiasm for adopting agile practices.
Second, focusing almost exclusively on development costs reduction risks increasing costs in terms of delays, inventory, over-processing and movement – the wastes of lean. While development costs is accounted for and visible, these wastes of lean are invisible and unaccounted for. Yet their impact can be more devastating than the development costs that appear as line items on the corporate ledger.
To illustrate this, let’s examine a past client to demonstrate how a sharp focus on development costs creates waste. At this client management was judged on their development cost performance and there were six teams working on a variety of different projects. Well the term team may be a bit of an aggrandization, because these were not dedicated agile teams. Rather these were project specific work groups with a Scrum Master and Product Owner. Each “team” had responsibility for one project. People were frequently allocated to multiple “teams” to ensure their skills were efficiently utilized.
This multi-tasking across multiple projects increased the organizations work-in-progress, a source of waste. Most developers were on at least 2 teams and often had other operational responsibilities. The result was at any one time there were a large number of incomplete projects with incomplete features in progress. There was a lot of activity taking place but very little value delivered. This is a classic example of the lean waste of inventory. Where is the line item for inventory? At least in manufacturing they do account for work in progress and manage their inventory levels. Why don’t we do this in software? The cost this inflicts is very real, yet we ignore it.
Worse, it is well known that such multi-tasking introduces a context swap tax – the time it takes an individual to switch from one task and get into the flow on another. Some studies place this tax at approximately 20%, while others suggest this may even be higher – up to 40% (Psychological Review, 104, 749-791, Multi-tasking: Switching Costs. Retrieved July 17, 2012, from http://www.apa.org/research/action/multitask.aspx]). The implication of this is that to “efficiently utilize our staff” by keeping them close to 100% busy, we are effectively reducing their effective work week by at least one day, and perhaps even 2. In lean terms this is the waste of unnecessary motion, moving the machine or staff more than necessary. Where is the line item for this in our cost accounting?
Another cost saving was supposedly achieved by outsourcing testing to an overseas company some 12 time zones way. I’m assuming part of the pitch for outsourcing testing was not only were the overseas testers a quarter the cost of the domestic staff, but development work could take place around the clock. While it may be enticing to believe in a 24 hour development cycle story, it is certainly hard to achieve. Outsourcing of testing introduced the classic lean waste of transport where work is regularly shipped from one organizational silo to another. This created significant coordination delays between developers and testers. Clarifications, explanations, and rework cycles were significantly slowed by the time zone delay and this was exacerbated by the lack of a shared clear understanding of the system between development and test. These coordination delays along with other bottlenecks in the testing pipeline meant that test often ran two, and even sometimes three sprints behind the development teams, further increasing the work in progress. Of course there was no line item for capturing cost incurred for “transportation”
In an attempt to reduce these coordination delays, the organization unbeknownst to themselves, added in the waste of over-processing – doing more work than necessary to create value – to their invisible waste ledger. The business analyst wrote highly precise specifications that approached pseudo-code in their formality and it was not unusual to see 6 page user stories. The assumption was of course writing precise user stories would compensate for the lack of a shared clear understanding between development and test and therefore reduce coordination delays. This approach completely defeats the intention of a user story. User stories are not requirements that are thrown over the fence to an unsuspecting team. Rather, user stories facilitate development speed because they encourage a conversation between the team and the stake holders. These conversations quickly align the team and stake holders and reduce the coordination delays. Ironically writing detailed user stories didn’t have the intended effect because they just tended to confuse the test team even more. Where is the line item for the cost of over-processing?
So how could we start making these costs – the wastes of lean – visible? There are several tools we can use. First the use of a Kanban board can make “inventory” or work in progress immediately visible. Second, a cumulative flow diagram can show the relationship between work-in-progress and cycle time and help us answer questions like, how long does it take for us to get something done and what this the relationship between WIP and cycle time (getting something done).
Finally, show the true cost in dollar terms of all that “unfinished product” – that is value we cannot realize because the work is not done. Al Shalloway suggests “any waste in the system will show up as a delay” and this gives us a powerful tool to put a dollar figure to cost of this waste. All the wastes I described above, motion, inventory, transportation and over-processing will manifest themselves as delays in delivering value. Let’s see if we can express in dollar terms the cost of these wastes by calculating the delay these wastes imposed on the initiative.
The goal of the initiative was to reduce call center costs and increase customer satisfaction by creating a self service portal for customers. We had a team of 11 people, and our “aggressive” plan forecast it would take at least 12 months to deliver the system. From my point of view, this just did not seem like a 132 staff month effort. It was mostly get some data from the data base, update it, put it back – bread and butter IT work. I asked the team, what would happen if we appropriated the conference room we were in, set up our workstations around the table and focused exclusively on this one system? The consensus was about 2 months, 3 months at the outside. So, call it 33 staff months.
It was estimated the self service portal would save about $45,000 per month for the organization. That means every month the self service portal was not in service, the organization gave up $45,000 of benefit. The invisible waste resulting from the near exclusive focus on development costs meant the company was delaying the release of the portal by 9 months and giving up $405,000 of benefit. Where is the line item for that? Of course the problem is this line item does not show up on the IT ledger, it is not IT giving up $405,000. Rather, it is some other siloed department in the organization. It’s not IT’s problem.
Not only were these costs another department’s problem, these delays were silently built into the project plan. Developers are asked for timeline estimates and gave those estimates based on their existing development practices, and then project management developed schedules, resource plans and business cases for these initiatives based on those estimates and resource allocations. Now multiply that waste across multiple initiatives and you have a loss of value situation that should have impolite words coming out of the c-suite.
As a solution we proposed a simple backlog of initiatives, with true teams – not work groups with an Scrum Master and Product Owner – “pulling initiatives” when they were ready to swarm on it. In essence we proposed a simple form of lean portfolio management. When we proposed this alternative to our patron it was declined because it would mean risking the mandate to reduce per team cost. Our patron’s mandate was to get the cost of a “scrum team” down to 50K per month and he was now looking at completely outsourcing coding and testing. That was the line item on his IT ledger and not the loss of value the wastes created. His mandate was not maximizing throughput and delivered value.
Further, there were the political realities of the organization. Few project sponsors would accept their project being delayed so development teams could focus exclusively on getting another sponsor’s project done before starting theirs. Despite the fact they would get their project sooner, the thought of a “rival” manager getting their system earlier was so distasteful that they preferred to incur massive waste for the organization as a whole. Everyone acknowledged the cost of this waste, but there was no benefit to them for reducing that waste and in fact, there was a greater likelihood they would be sanctioned for not meeting their cost reduction targets if they tried.
While in my opinion this was not a successful agile organization, they were of the opinion their new operating approach was better than their previous classical waterfall approach. Their delivery was more predictable than what they had experienced in past. I suppose we can call that a success despite knowing how amazingly better the organization could be. The dark horse on the horizon is of course a competitor who does see how amazingly better they could be. A competitor who realizes it not all about costs, it is about all costs.
(c) 2020 Steve Adolph