Getting to "Done" in Agile Development

[article]

Software Is Incredibly Expensive Inventory

Recently, I was in a local office supply store where I saw a four gigabyte flash drive on sale between the gum and candy next to the check out register. For about ten dollars I could purchase sufficient capacity to store all the work of a team in a device that would fit on my keychain. At first blush, it appears that the intangible nature of software and the low cost of storage means that inventory doesn't matter in software development. This is a seductive idea, and, unfortunately, today's configuration management tools only make matters worse. While this is not inherently bad, it makes the cost of branching so low people may ensconce themselves in their own environment.

Modern configuration management tools allow every developer to have his own branch of code so that he doesn't need to coordinate with others. The ease of branching means there are hardly any problems when I find another piece of code checked out—I simply add a branch and keep going. In fact, if we combine this with the rapidly growing number and increasing capability of local sandbox environments available to developers, I can develop entirely on my own—or within my team—oblivious to anything outside my immediate area.

If our first challenge involved how easy it is for other groups to deal with an agile team in a traditional way, this challenge involves technology making it too easy for development teams to silo themselves off from the world, and even each other. The development team accumulates massive amounts of work in process that has not been integrated into a product. This may seem fine; after all, we have an enterprise configuration management tool to deal with things like this. The problem is that we don't appreciate how expensive it is to carry all this work in process.

Any piece of functionality has a huge amount of context specific information that exists in the heads of the developers and customers who articulated what they want. The longer this code sits in some unvalidated state, the more we risk losing some of that information, and the more expensive it becomes to retrieve it. There is a profound difference between finding a bug the day after a developer wrote it and finding it a month later. In the former instance, the QA engineer can point out the issue to the developer and see it fixed that same day. In the later situation, the bug must be more carefully documented. As a month of work has gone by, there may be some uncertainty about exactly who introduced the bug and when that took place. People may not recall the precise functionality or all the changes made in that time. Testers in this situation may find themselves with orphaned bugs trying to figure out where it got introduced to the system so that someone can fix it.

The further we get from construction and validation, the more difficult this becomes. In traditional projects, teams try to surmount this challenge with documentation, and many agile teams embark on the same effort. Now they impose the cost of documentation on the developers, further slowing down the delivery of features and increasing the space between development and validation. It also introduces the cost of maintaining more documents and the challenge of conflict. When a design document, test case, and code do not match up, which one is the source of truth?

Tags: 

User Comments

1 comment
Kathy Iberle's picture

Brian, great article!  I recently wrote about very similar problems with "done-done" in another AgileConnections article: http://www.agileconnection.com/article/fix-your-agile-project-taking-systems-view

Your three-part "something akin to a Kanban board" is a great example of a Visual Planning Board which shows the queues.  This technique is often used in Lean project management, as shown here: http://www.kiberle.com/2013KB/PlanningBoardStates.pdf

Kathy Iberle

Iberle Consulting Group, Inc.

kiberle@kiberle.com

August 22, 2013 - 11:39am

About the author

Brian  Bozzuto's picture Brian Bozzuto

Brian Bozzuto is a principal agile coach at BigVisible Solutions. With an extensive background in health insurance and financial service companies, his current focus is supporting teams as they adopt agile and lean practices and deal with the challenges of organizational change. Brian's passion is helping foster better relations between business and technology to achieve more response projects and better business results. He has a broad range of experience applying various process improvement frameworks including Scrum, Kanban, Lean, and Six Sigma in large organizations. Brian has been certified as a Project Management Professional and Certified Scrum Practitioner. He is one of the founding members of the PMI Agile Virtual Community of Practice and the creator of the annual Agile Games conference in Boston.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09