The whole toolbox metaphor is fine on the surface. My problem with it stems from the incidentals in the discussion. In my experience, most people who reference having a “software toolbox” are really hiding from a more direct questioning or discussion of specific practices or methods. Instead of advocating for those methods they believe work, or more importantly, listening to others advocate for their methods, many in our field throw up the “toolbox” as a defense mechanism. It makes for a clean exit too. The problem is this mechanism limits learning for everyone involved. The “software toolbox” is a conversation ender, not a conversation starter.
With that said, I am going to put my toolbox where my mouth is.
First, my obligatory disclaimer: Individual results will likely vary. Past performance does not guarantee future success. Your specific context and corporate culture are critical factors when deciding which tools are best for you. This is not intended as a comprehensive list.
Troy’s State-of-the-Art Software Toolbox:
- Small Iterative Development Cycles: Software work is knowledge based. Knowledge in software is best improved by frequent feedback cycles. Early information feedback allows the team and customer to learn and improve at a much faster rate than when iterative approaches are not used.
Source: Extreme Programming, Scrum
- Explicit Work-In-Progress Limits: Even when working iteratively, teams will often have too much WIP. Ever observe a Scrum team start every single user story by the first day? I have, and without an explicit policy limiting work-in-progress, teams and managers will try to push too much work into the system. WIP limits allow a team to begin finishing work instead of starting more work. Team context switching is minimized, giving the team the opportunity to improve quality.
Source: Kanban for software
- Just-In-Time Planning: Plan just for what you can do, and nothing more. There is no waterfall-style comprehensive requirements document with this approach. Nor is it the heavy backlog grooming practices frequently seen in some Agile teams where user stories are analyzed and specified in detail months before they are implemented. Just-in-time planning also means no commitment-based time-boxed iterations. Optimal planning occurs when the the team is provided with the best thing to work on next, no more and no less.
Source: Kanban for software
- High Discipline, Low Ceremony Engineering Practices: Emphasize practices that encourage collaboration and short feedback cycles. TDD/BDD and a continuous integration server are a great start. After-the-fact, formal code reviews are typically too late to add anything other than rework. Code metrics are fine, but be careful what you measure. Are your code metrics making the code easier to understand and change, or are you happy just to apply “standards” to your code? Covering code with tests is a good thing. But higher code coverage doesn’t automatically mean your code base is functioning the way your customer wants.
Source: Extreme Programming
- Kaizen: Continuous improvement may come from inspect and adapt, PDCA, or other methods. It doesn’t matter if you prefer one over the other as long as you build an information feedback loop into your process. At the basic level, provide enough oxygen to the team to reflect, share ideas, and improve. Some teams may require regularly scheduled retrospectives, others may perform mini retrospectives or spontaneous Kaizen events during the project.
Source: Extreme Programming, Scrum, Kanban for software
Will these work for you? I don’t know, that’s for you to decide. I just know that they work for me today. If I were a part of a brand new software team tomorrow, this is where I would start our discussion. And hopefully we grow to an even better place.
“Merely having an open mind is nothing: the object of opening the mind, as of opening the mouth, is to shut it again on something solid.” -- G. K. Chesterton
