Agile values tacit over explicit learning. It’s not that explicit learning isn’t valuable, it is; but it’s the tacit learning — where things become embedded and part of our nature — that is the most valuable.
If there were one piece of tacit knowledge that I wish I could transfer (think Vulcan mind meld) it would be the benefit of early and incremental delivery and the associated feedback loop.
To me the benefit of early feedback is obvious, and I can’t imagine any reason not to do it consistently, but sometimes even within my own organization I have to struggle against traditional project thinking, where some arbitrary date or perhaps some arbitrary list of features, often many iterations away is targeted as ‘the release’.
I don’t know where the roots of this type of thinking comes from, but they seem to be very deep and embedded. Difficult to change.
A couple of examples of the last year made me sad. One recent and one early last year.
In the recent example a small team has been developing a web-based application. Pretty Scrummy. The Product Owner is good, providing the team with an ordered backlog of features to be implemented, and responding quickly to any questions that the team has. The team is solid, committing to and building a shippable product increment each Sprint and retrospecting to continue to improve. Sprint Reviews are also being held with the Product Owner and the feedback has been positive, but here is where things are also falling short of ideal. The Product Owner has this idea that once the features are completed that there will be “a release”. Actually the product has been shippable for quite a while, but instead of making it available and collecting feedback all along this entrenched project-style thinking of a ‘release’ has persisted. Most recently, as the remaining features for this “release” are being finalized the Product Owner has started talking about UI enhancements. Perhaps holding the “release” while these UI enhancements are being implemented. I call foul! The product isn’t yet being used by anyone outside of the development context and already we’re considering adding enhancements and therefore time and cost without any proven evidence that the product is valuable and will be used by the real end-users for the system. I’m actively coaching the Scrum Team around this now. I think I’m getting them course corrected, but I’m sad that my earlier attempts to influence and have the result of each Sprint released, used, and the related feedback collected and considered so that the Product Backlog could have been improved continuously didn’t result in action. How much waste has been generated? Perhaps none, but there is equal risk that the waste generated has been substantial.
The example from early this year is exactly the type of “project” that highlights just how wrong it is to not release early and often. Again overall the “project” was quite Scrummy. Product Owner with an ordered list of features and available to the team? Check. Great team with good agile engineering practices? Check. Potentially shippable product every Sprint? Nope. The work had been segmented, with our team responsible for creating a front-end while another team, in this case the clients own team, would be building the back-end services that the front-end would call. Not ideal, but often “projects” aren’t. We built our front-end, Sprint by Sprint. Each Sprint the team committed and achieved their commitment using mock-based services. But no back-end services were available, so there was no integration and things weren’t really “done”. There was good transparency. The client knew what was causing the undone work. Still they pressed forward. The originally planned front-end features were completed according to schedule. A successful “project”. How much waste was created? The front-end has never been used. All of the time, money, and a significant amount of team goodwill wasted. Very sad.
While there are contexts where project and release thinking make sense — think hardware for example — in a modern software delivery context it is seldom the case, and holding on to legacy project-style thinking results in plenty of waste.
Are you guilty of project thinking? Is clinging to the familiar creating waste in your organization?
I’ll continue to challenge myself, my organization, and our clients to be open minded in our thinking and approach to achieving business value. I challenge my readers to do the same.
