Thus far in the series, we’ve focused on managing productivity at an individual developer level. However, sometimes developer productivity results from the best management of the developers and the rest of the team. Measuring individual developer productivity is convenient because it tells you how well a single developer is performing. However, even the best developers can perform poorly when they’re put into a cadence that doesn’t work for the project or the organization. Here we’ll look at iterations, and how quickly we cycle can make a big difference.
It’s important to realize that even waterfall development was initially designed to be iterative. The idea wasn’t that you’d do something once and then never work on it again. However, if you have project managers on the team, for example, who are used to building a bridge, some of their experiences might get brought along. When building a bridge, it has to be built right and built just the one time. Thus, very early on, projects were pushed into one iteration and long cycles of design, development, testing, and release.
The agile movement has revived the need for iteration, and focuses on quick turns of innovation. Whether your iteration is a week, two weeks, or a month, this is a substantially faster iteration pattern than the monolithic waterfall projects from the distant past.
A Lesson from Manufacturing
It’s no secret that American car manufacturing got its clock cleaned in the 1980s and 1990s by the Japanese. Much has been made of the Toyota Production System—what is now most frequently called “lean manufacturing.” One of the often-overlooked components of the system was the ability to change over from manufacturing one item to another very quickly.
In manufacturing, any time you change from manufacturing one component to another, there’s a cost to do the changeover. There are dies to put in machines and other bits of reconfiguration that must happen. One key difference between the American car manufacturing and the Japanese methodology is that the American system could take a day (or more) to change over the manufacturing line to a new product, whereas the Japanese took minutes. This meant that the line could be changed over more frequently with minimal impact and the result is being more nimble, agile, and responsive to the inventory needs of the consumer.
In managing the productivity of developers, there are costs for iterating too slowly, because they don’t get feedback soon enough. This is perhaps the greatest reason that people advocate agile methodologies. It moves the feedback from the business closer to the point in time that the developer wrote the code. This reduces the time it takes to implement a fix to the code or change it and the other downstream ripples from the incorrect code.
On the other side, however, iterating quickly has some cost. There’s the fixed overhead of starting and stopping a cycle. Every cycle has startup costs in allocating the work into the iteration, and completion costs that include QA effort, “show and tell” meetings, and so forth. The goal of setting the iteration velocity is to optimize the advantages of developers getting feedback and minimize the costs associated with iterating faster.
High Risk vs. Low Risk
One of the key drivers to the cost of the iteration is the amount of time spent on quality assurance efforts—particularly manual quality assurance efforts. It’s no small task to regression test a large system. It requires personnel with a specific passion for details and finding problems. The higher the risk of impact if a defect slips into the system, the more testing is required—and the higher the costs.
All things being equal, high-risk systems have high iteration costs due to higher quality assurance activities—again, particularly those manual quality assurance activities. When a system is new, or the impact of a failure of the software is low, the quality assurance need is low as well.
As a result, there’s not a one iteration—or cycle—speed that fits all. There’s one that might optimize the developer productivity, but whether or not that optimizes productive output of the system isn’t quite so certain.
Reducing the Cost of QA
If the big cost in cycle time is manual QA, the obvious question becomes what can be done to reduce the QA cost for each cycle. There are two basic answers. The first is automation, and the second is to reduce the amount of QA work done in each cycle.
Everyone knows that more QA automation is better, but it’s expensive to automate QA activities, and therefore it’s rare that anyone has 100% automation coverage of their application. In fact, few organizations have what they would consider to be 100% unit test coverage, because in many cases it’s just too expensive to implement.
So, although QA automation can reduce the cost of QA for each cycle, it’s often too expensive to achieve.
Reducing QA Work
Without reducing the quality or completeness of the work of the quality assurance professionals, it’s hard to reduce the work. Certainly, there are tools, techniques, and skills that can be developed to make the professionals more effective, but the options for improvement tend to run out quite quickly.
Common methods for accomplishing the objective is limiting testing to only those areas where changes are made, and not doing a full regression test for each release. This has the benefit of reducing the effort but at the extreme risk of an unexpected side effect. To mitigate this, organizations sometimes enter a non-even cycle. There might be four cycles or iterations of development with a subset of items being tested, and a fifth cycle that has an extensive QA component.
This adds a cadence where interim releases are still being checked for the new changes the developer makes—and the releases are pushed into a staging environment for testing but not into production.
By changing the cadence of the QA work to occur less frequently than the development iterations, you potentially can free some effort up to spend on QA automation, thereby reducing the overall cost of every iteration—even the complete regression ones.
Implications for Iteration Speed
In today’s world, we want to iterate faster, not just to improve developer productivity, but also to improve the customer experience so that they’re receiving releases at a much more rapid pace. However, remaining in a lockstep position where every iteration requires an immense investment in QA isn’t sustainable. To improve developer productivity, sometimes it’s necessary to change the whole system so that everyone is more efficient and wastes less time.
In your organization, it can be that the best way to improve developer productivity is to slow down the speed of iterations—or maybe it’s time to kick them into gear. You won’t know unless you’re willing to evaluate the costs of every iteration and whether you’re getting more or less out of the team considering those costs.