NDC 2010 was great. This post is inspired by Tom Gilbs ”Lean quality assurance” talk:
Often we set out to build high quality software without really considering what that entails. How can you really know, when project has finished, that you have created quality software?
Clean code, test coverage and executable specifications created iteratively together with the primary stakeholders seem to be the main focus for most agile projects, at least, in agile theory. There are other concerns that can easily be overlooked when people go into “agile mode”.
Numeric entry and exit
As a stakeholder in a project you don’t really care about testing and executable specifications. You care about the ilities. Usability, Maintainability, Reliability, Security and Scalability are some that come to mind. Often requirements emerge as the software is developed, but many of these are well known in advance, at least to the stakeholders.
How can we identify these requirements and ensure that they are met at the end of the project?
A coder will leave it to chance. A software engineer will measure and verify that the requirements are met.
To identify the requirements you first need to identify the stakeholders. This is a process in its own right. Later you can start identifying the requirements.
According to Tom Gilb you can measure *any* requirement numerically. Later in the process you can use these numbers to evaluate the quality of the software (or some other item) you are producing. A requirement is considered done when your software meets the numeric target for that requirement. “Numeric entry and exit” is a term that describes this way of thinking. 
How can you measure things like usability of a feature? The answer is obviously “it depends”. One metric can be the percentage of grandmothers that understand the feature on the first try. If 80% get it, you have a usable product, and you have met your target for that specific requirement.
Obviously dissecting your requirements this way requires a lot of time and effort. For some projects doing it this way makes no sense, for some it’s too cumbersome and expensive, and for some it totally makes sense.
You get what you measure
Later.
In software development we often end up with local optimization. Developers focus on getting the development work done, testers focus on getting the testing done, and the analysis team focus on getting their work done. This is a problem, because local optimizations does not optimize the whole.
The development process should be optimized for global productivity. Work should flow thru the development pipeline without batches of work accumulating within the pipeline.
In the following diagram imagine the work flowing from left to right. First it enters the analysis team, then it’s developed, then tested, then finally it is delivered to the customer. A work item is indicated using the letter “x”.
----- Flow ------->
| Analysis | Development | Testing | Delivered to customer |
| xx | xx | xxxxxxxx | xx |
----- Flow ------->
This shows a situation where the testers are a accumulating work because they cannot process all the work the developers are handing over. Notice every team is working with top efficiency. This way of working introduces problems.
Problems caused by large batches
What are these problems we are creating ? If you look at the entire development process as a queue of work going from left to right, you will see that more work in process creates a longer queue. A longer queue means that the time it takes for one item of work to pass thru the entire queue is longer. This means that the delivery time of our software increases ! When work in progress increases, the delivery time increases. This is obviously a problem for many reasons that I will not go into right now.
There are other problems with the above work flow as well. Developers continue developing before their previous work is validated by the testing team. This means that they are creating work based on possible false assumptions. When this propagates thru the system it creates even more problems.
Limit the work in progress
The key is to limit the work in progress. In the previous scenario the testing stage of the software development process is the bottleneck. To avoid the accumulation of work in progress we need to increase the thruput in the test team, or lower the rate at which work is arriving. One solution could be to move some of the developers over to the testing team. Another would be to slow down the work upstream (to the left) of the test team, by giving the craftsmen there some “slack”.
Having people not doing the work they should be doing is often a problem for managers. They measure success by how efficient their team is. Suddenly we are back to local optimization. Having slack is actually a good thing. In the right enviroment it creates opportunities for learning and innovation.
In rigid functional teams, it is hard to do anything to modify the flow. People are happy with local optimization. In cross-functional teams it is easier to modify the process to accommodate the flow.
Some additional thoughts
1) It is easy to think of work in an software organisation as small items of work flowing thru the pipeline. In reality the work items varies in size as they flow thru the pipe. Also the issue of rework puts a little brake on the happy path. Keep this in mind as you take your next steps to improve the flow :)
2) There are things to be said about having the testing team upstream from the development team and making the batches of work smaller. That’s something for another post.
3) Focusing only on the work in progress withouth thinking about keeping the team members happy from a social point of view is a good way to fail in the long term.
Feel free to comment :)
Inspired by:
Kanban Chalk-Talk (http://vimeo.com/7814701)
