How Failure Produces BETTER Software Projects

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