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.
If the team isn't as skilled as assumed, projects will take significantly longer and more brittle to change.
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.
If the team is assuming requirements are complete, they look at scope change as failure.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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
