Getting to "Done" in Agile Development

[article]

So, when we put these two challenges together, we find that many outside groups may be happy to treat an agile team like any other team and anticipate for a linear product delivery according to a traditional delivery schedule of six to eighteen months. This blends with the ability of modern software development teams to develop and run their own instances of a system, and, in some ways, we are not far from the prototypes of an earlier generation of software development. Customers can see the features, but they can't really experience them, yet. What they are seeing is a simplified implementation or something that has not yet been proven through an organization's delivery process. This results in a hidden reserve of undone work that will be a business liability when the organization finally gives the green light to launch. The organization may find an array of unexpected issues, which never showed up during conference room demonstrations throughout the project.

If Something Hurts, Do It Often

Agile projects are fundamentally learning endeavors based on the concept that a team can receive the necessary feedback and insight to build the right product in the right way if it expands its own boundaries of understanding. Following that convention, there is a truism within the field that projects should confront their big issues early and often or, as some would say: "If something hurts, do it often."

If staging a release through our deployment process is painful and lengthy, we should keep doing it. We should do it more often so that we get good at it and it is no longer an impediment. We should do this to prevent the situations described earlier. Avoiding pain not only harms our project outcomes but it also creates a false sense of confidence. Avoidance lulls people into a sense that everything is going well when, in fact, there is massive unexposed risk buried in the project. It not only denies the organization a real opportunity to improve its operations but it is also a reckless way to deal with our customer's money.

So, what exactly are we putting off in those situations described above? We are not moving entirely through the value stream. Value stream analysis is a lean concept used for measuring and illuminating all of the steps required to take an idea and turn it into a valuable product or service. Failing to understand the full process and optimizing on a smaller part of that stream can undermine delivery. This is similar to when I worked with the agile team that was able to rapidly turn out functionality in a controlled environment, but became bogged down when going through an integration and release process.

The figure above illustrates the challenge that faces many teams. In our hypothetical example, there are six distinct steps that must occur for the team to deliver value, beginning with a customer explaining the requirements and ending with the configuration of the application after its release into a production environment. The team committed to two week iterations and demonstrated functionality to its customer after completing testing, calling that "potentially shippable" product. However, the work must go through two more steps in order for the organization to realize value. If the team is communicating its velocity based on its ability to move functionality through the first few steps, then we have no insight into how long it takes to do the actual release or the post-configuration launch. These steps may not require much work, but until we move through them, we won't actually know. Of course, many teams will face a technical or business limitation preventing them from frequently implementing their code to production. So, teams may need to incorporate release-like activities into their iteration.

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