Continuous improvement is the center of the Kaizen concept and it is something every software team should strive for. It boils down to this: you should continually look at your process to find ways to improve it. If you implement this ongoing process and you do all those small improvements over time you will become vastly better in what you do.
Feedback loops and foremost fast feedback loops help you look at your output and see where you are and if there is room for improvement. (Detecting problems early saves also a lot of time and money)
Software developers and software teams work best on good feedback loops. They write code and then run it to see if it works. The fix the code and run it again. The add an automated test and run it. The rework the code and run the test again. This is the first and fasted feedback loop.
There are more feedback loops in a software project:
You implement a new feature and then you share it with a peer for code review. This is the second feedback loop. It is for the feature as a whole, but still on the code level. This feedback loop is way slower. Maybe the reviewer is currently deep in development themselves or in some meeting or just has a day off. It can take a couple of days until you get feedback from this loop.
If the code is approved by the reviewer the feature will be put into the next release. All the automated tests are run to make sure everything the new features play nice with the established features. The release is then deployed to a so called staging environment. On the staging environment the new feature is reviewed and tested to see if it is ready for production. This can sometimes take a couple of days because maybe some other feature is occupying the staging environment or there are currently no resources for testing your feature. This is the first feedback loop on a project level and it can be quite long.
If the manager (or product owner, or QA, some other non technical colleague) has reviewed the feature on staging and is happy with it, the feature can be shipped to the production environment. Now real users can use the feature. A release to production can also take some time because sometimes we wait until a bunch of features is ready to ship. To have a nice release bundle, we can tell our customers in an newsletter about. When the feature is in production it produces log entries, maybe errors, usage metrics and most importantly: user feedback. This is the last and slowest feedback loop. It is also the most important feedback loop. Because if the users do not use your feature at all your effort in creating the feature was useless.
|Number||Loop||Interval||Level||Who is involved|
|1||Code → Run → See if it works||Seconds||Code||Developer|
|2||Commit → Run Tests → Refactor||Minutes||Code||Developer|
|3||Submit Feature → Code Review → Rework||Minutes to Days||Code||Developer|
|4||Submit Feature → Preview → Rework||Minutes to Days||Project||Developer, Management, Customer|
|5||Deploy to Staging → Manual Review → Rework||Days to Weeks||Project||Developer, Management|
|6||Deploy to Production → User Feedback / Metrics → Rework||Weeks to Months||Project||Developer, Management, Customer|
With WunderPreview we create a new feedback loop. Right when the feature is ready, the team gets a link to a running environment with the new feature. This link can then be shared with management, beta testers, investors or other stakeholder. (Its like having a staging environment for every new feature) Instead of waiting until the feature is deployed to staging, you can show your new feature right away. We call it continuous previews.
Continuous previews reduce the time to get feedback from other stakeholders. Feedback on:
The time for this feedback is reduced from days, weeks even months to just a couple of minutes.
Having this kind of continuous previews enables multiple things:
WunderPreview: Get a live preview environment for every new feature.
Works for every tech stack. 30 days free trial. No credit card required.