Part 7 in a 12-part series. This post covers products and services that are working right to show progress.
In part six of this series, Blake McMillian wrote about How We Communicate Matters. He explained how communication has changed over just the last few years. Highlighting effectiveness, quality, and richness of communication impacts team outcomes.
Effective communication influences the theme of this post.
Principles behind the Agile Manifesto
In the physical world, it’s hard to get away with manufacturing products or providing services that don’t work. Conversely, building software is a bit different story.
Maybe it’s because software is intangible in a sense. The intangible nature of software is a post for another day!
Yet, it doesn’t mean teams don’t build working software. It means that working software is a key measure for teams to assess themselves.
For a moment, I’ll pick on Microsoft. I upgraded to Windows 11 and understood not all the features or functions would work like Windows 10.
I didn’t expect my speakerphone to fail along with the “reduced functions” line. To be fair, I had the warning and accepted the risk.
I’m sure updating plug-and-play drivers are in the backlog, somewhere.
Things Working Right
In general, many products and services join the market working right from their introduction to customers.
But, this is not always the case. Sometimes, products and services are available working somewhat right.
I recently came across an article about construction updates to Penn Station in New York City. The writer highlights a somewhat right change to the station; $1.6 Billion NYC Train Station Doesn’t Have Enough Seats (msn.com).
Think about the story above the next time your team proposes just releasing a product or service that “might” work or is “somewhat” right. Is it worth the consequences?
Missed opportunities abound due to avoidable misses. When stuff works right the first time, we all win.
If a working product or service is the measure of progress, then trying to avoid complicated solutions should be a target. At times, waste is created simply because the solution gets over-engineered from the start.
Consider this when designing and building the next product or service, regardless of type.
You can learn more about Agile Principles in Part 8 of this series.
Principle 1, Principle 2, Principle 3, Principle 4, Principle 5, Principle 6, Principle 7, Principle 8, Principle 9, Principle 10, Principle 11, Principle 12
