Category Archives: lean

Book Review: Lean Software Development – Build Integrity In

Lean Software Development: An Agile Toolkit for Software Development Managers Lean Software Development by Mary and Tom Poppendieck

Chapter 6: Build Integrity In

What I Learned

  1. Perceived Integrity is affected by the customer’s whole experience of a system: how it’s advertised, delivered, installed, accessed; how intuitive it is to use; how well it deals with idiosyncrasies; how well it keeps up with changes in the domain; how much it cost; how timely it is; how well it solves the problem. The measure of perceived integrity is roughly equivalent to market share, or mindshare. If you had to rebuild your computer tomorrow, how many products would you load? If your bookmarks were wiped out, how many would you add back immediately?
  2. Conceptual Integrity means that a system’s central concepts work together as a smooth, cohesive whole. The components match and work well together; the architecture achieves an effective balance between flexibility, maintainability, efficiency, and responsiveness. Conceptual integrity is a prerequisite for perceived integrity.
  3. The key to achieving integrity is through detailed information flow, from customers and user to developers and between the upstream and downstream processes of the development team. In line with the Agile Manifesto – Individuals and interactions over processes and tools, Customer collaboration over contract negotiation.
  4. Refactoring and continuous improvement is of utmost importance. This is a tribute to Pat Kua after he complained that I missed out that part in my review of Clean Code. No code (or product, or practice) comes out perfect the first time we write it. We start with something that works, learn from its weaknesses, and improve on it. Pat talks about the red-green-refactor practice in TDD (Test Driven Development) which is basically starting out with a failing test (red), making it pass (green) and then making the code better (refactor). This practice can also be extended to be applied to iterations, where we have retrospectives (refactor) to figure out how we can do things better in the next iteration, etc.
  5. Testing – my favorite software topic of all times. Developer tests assures that the code does what the developer intended it to do. This includes unit, system, integration tests, etc. Customer tests assures that the system will do that customers expect it to do, and are run throughout the development, not just at the end. Customer tests are sometimes also known as acceptance tests. So why are tests important? Why are some people so obsessed about thoroughly testing a class or a feature? And why should they be run throughout the entire development process and not just at the end? Wouldn’t it be better if we dedicated a 50-person team of testers for 3 months after the development is done? Tests are invaluable because:
    1. They unambiguously communicate how things are supposed to work.
    2. They provide feedback on whether the system actually works the way it is supposed to – and we would ideally want this feedback as soon as possible, not at the end of the project.
    3. They provide a scaffolding that allows developers to make changes throughout the development process – I recently just bought Michael Feathers’ Working Effectively With Legacy Code (and I’m quite excited about it) and read the chapter on Testing and he says that tests act less like a safety net to catch you when your code goes bad, and more like a cloak that wraps around the code and keeps bad things from seeping out to other parts that you’re not currently changing.

    If you are running tests manually anyway, going through the motions of making sure the system still works as it should every time you change a piece of code, wouldn’t it be great if we could turn those motions into a test and build a test suite that gets automatically run every time we check in? It turns out, we can!

Book Review: Lean Software Development – Eliminate Waste

Lean Software Development: An Agile Toolkit for Software Development Managers Lean Software Development by Mary and Tom Poppendieck

I picked up this book wanting to know what the hype was about Lean and how its principles can be applied to Agile software development in general.

Chapter 1 Eliminate Waste

What I Learned:

  1. Anything that does not create value for a customer is waste.
  2. Learning to see waste.
    The 7 Wastes of Software Development.

    • Partially Done Work – e.g. Writing requirements for stories that might or might not be played in the near future.
    • Extra Processes – How much paperwork is necessary? A good test for paperwork is to see if there is someone waiting for what is being produced. Consider writing customer tests instead of requirements.
    • Extra Features – Developers have the tendency to want to write cool code, just in case. But extra code means extra effort for maintainability, it increases complexity and is also a potential failure point. Code that is not used could also become obsolete
    • Task Switching – Dividing someone’s time between a project management role on one project and a developer role on another project seems like a time-saving move. But would that guarantee each project to finish within their timeframe?
    • Waiting – Delays are common in many software development environments. But does that mean it is okay for delays to happen? Delays keeps the customer from realizing value as quickly as possible.
    • Motion – When a developer has a question, how much motion does it take to find out the answer? Various artifacts move as well and each handoff of an artifact is fraught with opportunities for waste.
    • Defects – These are inevitable in software development but waste caused by a defect is the product of the defect impact and the time it goes undetected.

    3. Value stream maps show that non-development activities are the biggest bottlenecks in a software development value stream.

I do sometimes go about activities just for the sake doing them but rarely find the time to step back and assess whether it’s valuable to the customer or if I’m wasting time. Keeping an eye out for waste is a good tool to have and is related to a previous post of mine about delivering business value.