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 TeamIf the team isn\u2019t as skilled as assumed, projects will take significantly longer and more brittle to change.
Assumptions About The Quality Of The ReleaseIf the team hasn\u2019t put the appropriate quality checks in place, changes assumed to have a certain level of quality that don\u2019t cause rework.
Assumptions About Full Understanding Of ScopeIf the team is assuming requirements are complete, they look at scope change as failure.
Assumptions About Value Of Features & ChangesIf the team is assuming changes being released are valuable to customers, but there aren\u2019t measurable ways to know whether that\u2019s true, waste could be being released.
Doing Less At One Time Is THE KEY To Learning Through FailureOverall, the key to learning that we\u2019ve \u201cfailed\u201d in some way and need to adjust direction based on what we\u2019ve learned FASTER is to do less at one time!
Doing Less Between Releases Minimizes RiskIf 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 RealignmentIf a team iterates on a backlog that hasn\u2019t 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 ROIFor every day that development continues without a release, there\u2019s 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 SkillIf 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 FeedbackHaving 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 TeamsThe lag time that occurs between separate departments for disciplines needing something and sub-contracting \u201cas a service\u201d 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 RetrospectivesHave a meeting to talk about what went well and what didn\u2019t 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 AudienceRather than learning that there\u2019s 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/FailMany 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 OutcomesMost projects have a large number of features. Rather than keeping everyone busy \u201cburning down\u201d 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 ScopingIf 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 BudgetingIf we assume that we\u2019ll learn we need to change what\u2019s 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.
You can also\xa0watch this episode on YouTube.\xa0
Related resources:
\xa0
Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards