How Failure Produces BETTER Software Projects!
Agile Development • Kanban • Lean Startup • Quality Assurance • Scrum • Software Company Culture
A team that learns from software project failure produces better software - when you plan to exploit this ability.
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
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.
Resources
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.