In the last decade, we have realized that we cannot plan all up front in a linear process to develop software. We are solving complex problems, which require us to use an empirical process, lean UX practices, and a supporting technology platform that allows us to build, measure, learn and apply the learning in a repeatable fashion. This allows us to move from trying to predict everything about the future towards shared learning from the present.
Although we are getting gains from people using agile practices to get increments of work done, most enterprise organizations are not taking advantage of developing iteratively. They still put effort to fully polish a feature before releasing to see how customers respond to that feature, primarily because they are funded and managed as a project, instead of a product lifecycle. “If we do not fully build this feature, we may never get the budget again” is the tiresome excuse I always hear.
Planning upfront processes work when you are trying to minimize mistakes, as fixing them is too costly. When we build tangible products (non-software), it costs money for material to build, then package and ship them. Even when software was first commercialized, we needed to minimize mistakes because it was a significant cost to create & ship a bunch of floppy disks or CD-ROMs. In the modern era, where our products are not physical and we have the Internet to distribute — software is shipped continuously. We have an opportunity. Having the ability to ship and respond rapidly has helped us evolve from building it all up front to building what is only currently needed, and build, measure, learn as you go. Then go back to evolve a feature release after release.
The digital age has given us the opportunity to build iteratively. Shifting from predicting to continuous learning, sensing, and responding. In areas where this is happening, we are seeing new innovations and engaged customers. Despite this success, many organizations (especially large ones) are not taking advantage of this. They are trying to predict and deliver.
In the book Lean UX by Jeff Gothelf and Josh Seiden they used the phrase, “It’s not iterative if you only do it once”
Jeff and Josh also articulate:
A shift from “Requirements” towards Assumptions
A shift from “We Know” towards “We Believe”
A shift from “Let’s Build It!” towards “Let’s Test It!”
What are you doing to invest in minimizing the friction for teams to release? Have we invested in dev ops, continuous integration to reduce the cost of releasing that would enable your product to be continuously connected with the teams?
What are you doing to change practices to shift from the project to a product mindset for investing in work? It’s time we align our funding to take advantage of these continuous streams of work.
What are we doing from an incentive perspective to reward a culture where learning is a first class citizen? Do we have the right incentive mix of team delivery, team discovery, and team learning? Can you pilot it in a slice of your organization?
This is the next phase of our endless journey. Scrum.org will be introducing a course to help teams learn techniques to take advantage of explicitly utilizing this sense and respond mindset. Scrum.org worked in collaboration with the Lean UX authors to better help to integrate these to help teams become higher performing.
If we cannot predict the future, the next best thing is to learn and react as the future unfolds.
I would like to leave you with 3 things:
- Invest in the tooling and automation to reduce the cost and effort to release. The easier it is to release and stay continuous, the better we can support iterative delivery.
- Change your funding model. Move from project funding to product funding. Also, take advantage of iterative delivery by implementing iterative funding. Fund initiatives as you learn and validate.
- Balance your incentive and performance measures. Create incentives for learning and discovery.
Every keystroke is precious so I will end here.