Getting to "Done" in Agile Development

[article]
Summary:
When the tasks in the "Done" column needed more attention, the team created a "Done Done" column. Later, they created a "Done Done Done" column. In this article, Brian Bozzuto discusses how you can stop adding columns and honestly get to "done" without having to kid yourself.

Three of the Agile Manifesto's twelve principles reference the value of producing working software. It directly names working software as the highest priority—a deliverable to be completed often and the primary measure of success. Scrum practitioners should note the goal of every single sprint is to complete "production ready" code. The point to teams is clear: Agile teams should endeavor to deliver working software capable of rapid deployment on a regular basis. The message to stakeholders is also clear: If you see it in a demo, you can quickly put it in your production environment. But, what happens if that's not quite the case? 

Done, Done, DONE

I saw it on my first Scrum team. This particular challenge expressed itself clearly on our little task board. We started with three columns representing the states of work of a given story: "Not started," "In process," and "Done." It seemed innocent enough and I was enamored with the elegance of such a lightweight framework. How was I to know what would come next? The problems began when we neared a release and started integrating our work with another team. Inter-team dependencies began to bring the system down. When system administrators tried to move the code to new environments, incomplete release notes caused havoc. Additionally, upstream data sources weren't receiving changes propagated on the same schedule as our team.

Our ScrumMaster tried to hold us accountable by asking us what "done" meant. The far right column of our board was changed to "Done, Done," implying our standard definition of done was just not good enough. Although this change to our board was half in jest, it was an indication of our failure to account for cross-team integration. It got worse. Later, we found that even though the business signed off on our stories, they weren't fully approved. The system people voiced major performance concerns when they saw just how often we were going to call some of the internal services. It seems that "Done, Done" wasn't actually good enough for us, either; we had to update our board to read, "Done, Done, DONE." I think we would have kept doing this as we discovered additional requirements to actually launch our product. Mercifully, by this point, we ran out of real estate on our humble rolling whiteboard; however, the impact to the team was not over. In the end, we spent nearly two months preparing for a production roll out. The team’s speed of delivering new features plummeted as we dug through the "Done" and merely "Done, Done" work fixing bugs, writing release notes, and changing configuration files to move through our environments. Our business sponsor was not pleased with two months of additional work for functionality she believed was already complete.

So what was at work here? Every day, senior developers and testers worked together in our team. We felt our code was bulletproof and our product owner was signing off on each story as we went. In my experience, there are two primary culprits at play in situations like this that conspire to undermine the team's ability to realize "potentially shippable" code. These culprits have many manifestations; but let's take a look at some of the most common instances of both.

Pages

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.

StickyMinds 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