Do your projects move forward with many assumptions that turn out to not be true as things progress? Today I'd like to share how learning of a team failure produces better software when you plan to exploit this ability.

The overall assumption that most projects operate under is that the project will be successful. However there are several smaller assumptions upon which this one is built. Often these smaller assumptions need to be verified to make decisions that keep the overall state of progress moving in a sustainable direction for the product.

Assumptions About The Skill Of The Team

If the team isn’t as skilled as assumed, projects will take significantly longer and more brittle to change.

Assumptions About The Quality Of The Release

If the team hasn’t put the appropriate quality checks in place, changes assumed to have a certain level of quality that don’t cause rework.

Assumptions About Full Understanding Of Scope

If the team is assuming requirements are complete, they look at scope change as failure.

Assumptions About Value Of Features & Changes

If the team is assuming changes being released are valuable to customers, but there aren’t measurable ways to know whether that’s true, waste could be being released.

Doing Less At One Time Is THE KEY To Learning Through Failure

Overall, the key to learning that we’ve “failed” in some way and need to adjust direction based on what we’ve learned FASTER is to do less at one time!

Doing Less Between Releases Minimizes Risk

If we make a mistake to a small change, the impact of that change should be smaller than releasing a large change. This minimizes the impact of rework or breakages.

Doing Less Between Releases Motivates Realignment

If a team iterates on a backlog that hasn’t been significantly changed since the project starts; the business has low motivation to realign. If a team is taking action on the feedback of rapid releases, the business must be more responsive.

Doing Less Between Releases Improves ROI

For every day that development continues without a release, there’s no return on investment. By releasing more frequently, the team has the opportunity to provide value to the customer with less capital.

Doing Less Between Releases Improves Skill

If we do a production release every 6 months, how good are people going to be at it? Doing less between releases forces the entire team to practice release practices more often. This results in a team with higher delivery skill.

Fail Faster By Having Artifacts That Provide Feedback

Having tools and processes that give us the state of a change at any time lets people know a failure to some process has occurred early. This enables people to take action on issues as they emerge and catch them before the change makes it out to customers.

Fail Faster By Using Cross Functional Teams

The lag time that occurs between separate departments for disciplines needing something and sub-contracting “as a service” causes releases to take longer. If we want to fail faster, we need to have all the people needed to release the product dedicated to it and working together so there is no lag time to service outside of the immediate group.

Fail Faster By Holding Retrospectives

Have a meeting to talk about what went well and what didn’t over the past release (Scrum) or several releases (Kanban). This is an easy way to learn earlier that the team is failing to follow processes that are working for the project.

Fail Faster By Releasing To A Limited Audience

Rather than learning that there’s an issue with a release from a large number of voices from your customer base, have a system in place to release to only a small subset of total customers. This is known as ring releasing or canary releasing.

Fail Faster By Having a Measurable Pass/Fail

Many projects release a large number of features. If some KPI changes positively, it is difficult then to know which of those features or changes caused the positive change. Use A/B testing to verify that investments actually impacted a KPI.

Fail Faster By Focusing On Valuable Outcomes

Most projects have a large number of features. Rather than keeping everyone busy “burning down” a large list, figure out how much money the business is losing by NOT having each story (cost of delay). Work on the highest cost of delay ideas with FOCUS since those are the most economically viable!

Fail Faster With Justin-In-Time Scoping

If a team does detailed requirements on a large quantity of work, it creates psychological attachment and wastes money. Teams should instead only get the details of the top items on the list periodically.

Fail Faster With Monthly Budgeting

If we assume that we’ll learn we need to change what’s built every release, we need to re-budget every release with project % complete accounting. Rather, budget monthly to provide the capital needed to take action on changes to customer needs with less pain.

Join my Patreon:  https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech:  https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide:  https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube. 

Visit me at thrivingtechnologist.com