I am back from a nice vacation in Brazil and ready to write a little more about Agile development. Last article I gave a 30,000 feet view about Lean, today I am going to get one of the principles (Eliminate Waste) and get a little deeper.
Waste
What is waste in software development? I described that on my last post as "everything not adding value to the customer is considered waste. In other words: In software development, waste is anything that does not improve the quality of code, reduces the amount of time and effort it takes to produce code, or does not deliver business value to the customer. That is too generic.
On Poppendiek's book she describes complexity as a great candidate on promoting waste. "Complexity calcifies our code and causes it to turn brittle and break. The prescription for complexity in software development is simple: Write Less Code !!
Complexity
Just about any company that starts with a single technology is agile by definition. It can deliver and respond to the customer with easy. As the company grows and achieve success it starts to become slow, unresponsive. They have developed a complex code base, array of products and technologies. Unless they get complexity under control they will strangle what made them successful. The responsiveness, the agility.
The problem with complexity is that is does not grow linearly it does in a exponential fashion. Soon it starts to dominate all other costs in the software development process. Wise software development organizations place top priority on keeping the software clean, small and simple.
So, how to deal with complexity? Here are some food for thought
Justify Every Feature
The very first step on controlling complexity is limiting the features and functions that make to the software base. It is like a diet... you will be able to control your weight if you control what goes in your body. So, every feature that gets developed should pass to a rigorous evaluation and prove that it will create more economic value than the cost throughout the lyfecycle. Loading a software with a laundry list of feature is the lazy way to do marketing. Worse than that it is a recipe for disaster since the complexity will increase with useless features (not so valuable).
It takes guts to limit feature set but it mostly pays off. A company that delivers a product with just the right amount of features shows that it understands its customer.
Minimum Useful Feature Set
On agile the ideal approach do deliver software is dividing the product in small feature sets that immediately deliver value to the customer; and release these feature sets in descending order or importance. That way the customer can quickly start using the software. So, a minimum feature set is the one that helps the customer do a portion of its job faster.
From the sustainability point of view software developed on a incremental way is easier to maintain because incremental development can be sustained for the life time of the software. Of course other disciplines surrounds the incremental process and promotes the easy to change characteristics of the software. Refactoring supported by unit testing is one of them.
Don't Automate Complexity
Sometimes software companies solve complex problems by wrapping the existing process in a complex web of software. Never automate complexity. Understand the problem and simplify the process then, if necessary automate. In other words you domain the technology, you customer has the domain knowledge of the business. It is your job to simplify and automate (solve) that problem the simplest way possible.
What is Waste in Software development then?
Poppendieck define 7 wastes
| Waste | Description |
| Partially Done Work | The inventory of software is partially done work. The objective is to move from the start of work on a system to integrated, tested, documented, deployable code in a single, rapid flow. The only way to accomplish this is to divide work in small batches, or interactions. Example of partial work is: uncoded documentation, unsynchronized code, untested code, undocumented code, undeployed code. |
| Extra Features | Waste in software is adding features that are not needed to get customer's current job done. If there isn't a clear and present economic need for the feature, it should not be developed. |
| Relearning | Rediscovering something we once knew and have forgotten is perhaps the best definition of "rework" in development. Knowledge needs to be captured and needs to be wide available to the development team. Another way to waste knowledge is to ignore the knowledge people bring to the workplace by failing to engage them in the development process. This is even more serious than loosing track of the knowledge generated. It is critical to leverage the knowledge of all workers by drawing on the experience that they have built up over time. |
| Handoffs | Passing knowledge in a strange science. You can document your architecture and give them to an engineer and most likely it will not be of much help. On the other hand if you sit with this person and be with him on the transfer, give him some pointers on some aspects of the software, testing, the history behind what was done, most likely, sooner your engineer will be able to ride by himself. This kind of knowledge is called tacit knowledge and it is very difficult to hand off using documentation. When a work is handed off a vast amount of tacit knowledge is left behind in the mind of the originator. If each handoff leaves 50% of the knowledge behind, 3 % of the whole knowledge is left after 5 handoffs. So, to minimize lost:
|
| Task Switching | Concentrate on one tasks at a time and finish it before switching to another task. Switching to a different task is not only distracting , it takes time and often detracts from the result of both tasks. Task switching time is waste. |
| Delays | Waiting for someone in order to have your work done is a big waste. That is why a process like scrum puts so much effort on maintaining the engineering unblocked. Again, communication plays a very important role on minimizing delays. Have your team collocated or collaboration tools that promotes open communication. Have your daily meeting and try to identify and correct any roadblock. |
| Defects | Every code base should include a set of mistake-proofing tests that do not let defects into the code, both at the unit testing level and acceptance level. Somehow software still finds devious ways to fail, so testing experts should start testing early and often to find as many of these unexpected errors as possible. Whenever a defect is found, a test should be created so that it can never happen again. A good agile team has an extremely low defect rate, because the primary focus is on mistake-proofing the code and making defects unusual. The secondary focus is on finding defects as early as possible and looking for ways to keep that kind of defect from recurring. |
Conclusion
We touched several subjects related to waste in software development and the text is self explanatory. I personally put a lot of importance of the defect aspect of building software. If we could "easily" convince engineer and QA that testing first enhances development speed, mistake-proof the code and helps on refactoring our lives maintaining and enhancing the software would be much easier.
In addition applying acceptance and unit testing has a deeper meaning than just mistaking-proof the code. Acceptance tests are best when they constitute the design of the product and match the that design to the structure of the domain. Unit tests are best considered the design of the code; writing unit tests before writing code leads to simpler, more understandable and more testable code. These tests tell us exactly and in detail how we expect the code and the ultimate product to work. As such, they also constitute the best documentation of the system, documentation that is always current because the tests must always pass.
Reference
Implementing Lean Software Development - From concept to cash. Mary and Tom Poppendieck
