|
|
AS OF 5/17/2008 4:48AM EST
|
December 1, 2006 —
We’ve all seen the “Kill Your Television” bumper stickers that encourage us to fix all of our family dysfunction by moving away from that giant time-suck called prime time. If I could create a similar bumper sticker to address the professional lives of software teams, it would be: “Kill Your Inventory Manager.” The implication is that you can fix your team’s dysfunction by moving away from the giant time-suck and paralyzing friction of inventory management in software development.
 As a profession, we have gotten extremely good at managing inventory. It has taken us years—but, boy, we build some giant tools and systems to manage it. We have come to believe that planning is a weekly act of re-prioritizing the inventory list and progress is measured by the number of items that are completed. With modern bug-trackers and requirements management systems, we can even transfer the burden of inventory tracking to our customers by exposing the bug/issue list front-and-center on our Web site or open-source project page. In the worst cases, life deteriorates to a level where the team essentially works for the inventory manager and where customers believe they are there to test. Is this the best way to build highly usable, valuable software?
If you are thinking to yourself right now that software is similar to a manufacturing setting in which inventory is a necessary evil—wake up. For the past 20 years, the best manufacturers (think Toyota and Dell) have worked to reduce all forms of inventory, realizing it makes them fat, slow and uncompetitive.
Inventory management systems were originally built to support a waterfall, or assembly-line, approach to software development. Metaphorically, these systems are akin to horizontal shelves that accumulate inventory in the factory and warehouse. What is the problem with in-progress work stacked neatly on shelves and ready to be completed? Hidden in those piles of work and systems are very bad defects tied to technical debt, important requirements and lots of partially completed items that are development complete, but not “done” enough to release or test. Managing, prioritizing and re-prioritizing these piles are a waste of the team’s time that increasingly slows the delivery of real, working product.
In addition, the accumulation of work on these horizontal shelves encourages teams to make releases into large bites of major architectural changes that will “fix everything.” Working on large release batches with the help of an inventory manager tends to encourage teams to just work “for” the inventory manager with an elaborate workflow. This behavior builds walls between teams and decreases communication by forcing communication through documents, thus creating waste due to the energy lost to friction.
The authors of the Agile Manifesto (www.agilemanifesto.org) knew this. The first item of the manifesto stresses, “Individuals and Interactions Over Process and Tools.” The extreme response to this statement would be to throw out your team’s current inventory and workflow management systems!
Bear with me and this experiment for a moment. Starting tomorrow, cut off access of your mainline or new development team (not your maintenance team or customer support group) to the following systems:
• Requirements management system in the form of system or document.
• Defect management system for flowing work through the team.
Now that there is no “inventory,” start collaborating with your team to develop a rapid, steady flow of working software. Following agile methods, try putting just three to five of your highest-priority items into a short, two-week iteration. Operate in cross-functional teams of no more than 10 people, and track your priorities on sticky notes on physical or virtual whiteboard. (With your team focusing only on three to five items, it’s easy to do without your inventory management.)
As a result of working without an inventory manager, your team will focus on choosing the right backlog items, keeping debt low, testing early, automating tests and making and meeting commitments. They will do this through constant team communication, daily stand-ups and pairing, effective planning every two weeks, and measuring their progress through working, tested software that delights users. Where in this world do you need an inventory manager?
Is it that easy? The short answer is yes and no. To move to agile iterations, you must prepare in two parts:
1. You must pay down defect or technical debt that requires your team to use an inventory manager in the first place. (These are things that are starting to “smell bad,” and your team knows exactly what they are. Examples include critical defects, technical hacks that need to be refactored, automated build updates and refactoring tools.)
2. You must establish a clear priority to your work that allows you and your stakeholders to feel good about the next three to five items you will be working on.
For teams getting started with agile, this preparation typically takes from one to four weeks of the team’s time. It is generally easier and faster to get preparation done before starting your first iteration, but it’s sometimes very hard to clear that much space in the development calendar. In some teams, preparation is done prior to starting a true agile iteration and in other teams, it is factored into their first set of iterations.
Moving to agile is simple but, at the same time, it changes everything. Just like throwing out your inventory managers, agile adoption can be hard, but I know you can do it. Once you start the move with a few teams, the positive feedback of speeding the delivery of value will not let you go back to waterfall, ad hoc or iterative development of inventory.
There are tons of resources, coaching firms, and tools out there to help you move and scale agile. Go ahead, “Kill Your Inventory Manager!” and get started.
Ryan Martens is founder and CTO of Rally Software Development, which provides tools and services for agile development.
|