It is possible to create releases very often without taking them into deployment. Of course this is not something you aim to do, but it is somewhat easy none the less. There can be various reasons, but probably most common is some bottleneck in the process or in the interface between two processes.
If you have a conveyor belt that transports boxes, what will happen if you don't move the boxes away from the other end? They will pile up. Before you know it, if you don't stop the belt, you'll have a mountain of boxes. You probably react in time before this happens. (Also in software development you can utilize for example Kanban to visualize things and to identify the bottlenecks.)
Another example. Let's say you participate in a testing of a new mobile phone model. You get a brand new toy to play with. But then you find out there is a nasty flaw in your product. An irritating bug that destroys your user experience. Naturally you inform the manufacturer. And then they send a person to your home to fix your phone.
Or maybe they will not send anyone to repair it. Probably they will actually just send you another phone. With software products we sometimes don't operate as pragmatically. Instead of just sending a new version, we make a correction to the existing version. This is called patching. Sometimes it just cannot be avoided, but the need should always be carefully assessed.
Keep things visible. Aim to increase transparency. Think carefully about what is really happening and how you could tweak the system to reach a whole new level in efficiency!
No comments:
Post a Comment