See Your Agile Delivery Traps

Does your team deliver what they want, when they want to? Maybe your team delivers, but depends on another team to deploy. Many teams have trouble delivering the value they so carefully create.

Here are three delivery traps I've seen in agile teams:

The team doesn't have “done” criteria.
The team requires “hardening” to really finish a feature.
You can't tell what's done but not yet released.

1. The team doesn't have “done” criteria.

Too many teams still talk about “done” or “done-done” or “done-done-done.” All these dones are way over-done.

Consider developing a team working agreement that says, “We don't consider anything done unless we could release it to a customer.” That agreement means the team knows what tests the story needs, the team wrote and ran the tests and the tests passed.

This working agreement might mean the team and the Product Owner need to spend time discussing examples, refining the stories to smaller pieces of value, and asking developers to help create tests.

2. The team requires “hardening” to really finish a feature.

Back when we shipped physical products, hardening a product meant you might test (and possibly change) an enclosure, so the computer and all equipment were safe. When we refer to hardening software products, we might verify reliability, security, and performance.

When agile teams talk about hardening, they too often mean, “Let's test because we didn't do it before.”

Agile approaches work because the cross-functional team collaborates as a team (Product Owner, developers, testers, anyone else you need) to define and deliver the product. The team decides what the product is, and how they will know the quality of the product.

If your team is not a cross-functional team with the testers you need, you are on the way to an agile approach. You might even do better to understand why you don't have the testers and what you can do about that problem, rather than create partially-complete features. Partially complete work is inventory and is a drag on your system of work.

3. You can't tell what's done but not yet released.

I like to track what's done but not yet released. I have concerns when a team depends on another team for deployment, or if you release a feature set slowly over time. When you release small features in service of a larger feature set, you might need to release with flags to turn on or off certain features. See the board on Creating Milestones with Iteration-Based Agile.

You'll need to create your guidelines, but defining what done means, making sure each story is done when the team thinks it's done, and tracking the state of what's actually release might help.

See the other three trap emails in honor of Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver: collaboration traps, measurement traps, and estimation traps. I hope you enjoyed them.

Become an Influential Agile Leader

A couple of weeks ago, I sent out a special email about the Influential Agile Leader, a workshop for people leading agile transformations. If you are trying to make your agile transformation a success, today is the last day of the super early bird registration for the Influential Agile Leader workshop. We move to early bird registration on March 1, 2018.

New to the Pragmatic Manager?

Are you new to the Pragmatic Manager newsletter? See previous issues.

Here are links you might find useful:
* My Books
* Online Workshops
* Coaching
* Managing Product Development Blog
* Create an Adaptable Life
* Johanna's Fiction

Till next time,
Johanna