Turning entire features into small isolated pieces of code making up sub features allows engineers to turn commits into pull requests. Tldr unoccupied time of engineers should not be filled with meaningless busywork in the name of agility. This phase is what turns good teams into great teams and perfectly-oiled machines. Having the ability to share knowledge, learn and improve in the Learning phase makes the Solve and Delivery phase “just work out”. To achieve the operational excellence you’re looking forward to it’s again vital to keep learning. Teams will then put in irrelevant busywork in the name of agility. Unfortunately this is often perceived as wasteful as it’s of very little value to the business, which is busy fighting the battle of marketeers. Teams should take the time to pay off tech debt, having the ability to learn, improving the delivery pipeline (this is very important as we don’t want to waste too much time here, remember?), writing documentation and refactoring the code base. Embrace continuous learning #Įngineering bandwidth that is not fully occupied at all times is not a bad thing. Try to turn this time into valuable time, give it to the engineers. This might mean that some capacity lies unused at some times, but the impact of delivery is not diminished. It should preferably have to do with the previous iteration and the team must commit to the improvement(s) as part of the Learning phase. Improving is doing, get it done.įocus on what’s needed to improve the iteration and only the iteration. We’ll end up doing the undoable and quickly lose focus. I think that it’s better to stop noting down golden ideas along with every possible improvement or complaint per iteration. That’s not the intention of the Learning phase, it will blur our vision. We focus on creating a shared vision through strategic thinking, what do we want and how do we go about it.ītw, it’s important to note that we should not bring all kinds of ideas in per iteration, nor should we try to capture all the things that could be improved. There’s a phase dedicated to this, where we map ideas and experience to plausible solutions, the Solve phase. The team has one direction to go about: identifty and solve problems. We need to lay focus on producing greater output from the engineers, as that’s of most value to the entire team and the market. This is enabled by adopting automation best practices, evolving out-of-the-box infrastructure capabilities and continuous learning. The delivery should rather be unexciting, clear, automated and happen fast, very fast. Keeping the time between identifying the solution and delivering the solution minimal by automating as much of the delivery phase we allow ourselves to put the other 2 phases in the spotlight. Learning and solving are key, it shifts the way of thinking and viewing. Deliver: implement and deliver the solution.Solve: design solutions in order to implement and solve the problems.Learn: identify the problems and solve previous problems.I earlier mentioned that I think the delivery of software is a 3 step process, what I meant is as following: Taking the time to learn and overcome problems we encountered in a previous release is vital to continual improvement. A relentless focus on going faster incurs technical debt, which leads to going slower.” 3 step iteration # Failing to schedule in enough recovery leads to overtraining, fatigue and eventually illness or injury. In the same way as training for phsyical endurance events, such as a marathon or a cyclo-sportive, the recovery days are just as important as the training days, as that is when the body adapts and becomes stronger. “High-Performing organizations recognize that they need to go slower to go faster. To emphasize the above tweet I would like to cite a part of ‘Pattern 7.1 - Go Slower to Go Faster’. Jonathan Smart changed part of my view on delivering software after reading “Sooner Safer Happier”. Take a good look at this tweet and read it again, and again. The cheapest cost of intelligent failure. It is about soonest time to learning with time to reflect and pivot. Making the wrong thing faster makes us wronger. We don’t want a Feature Factory, it’s not about velocity. This article is a tribute to a colleague that’s unfortunately leaving my team, we carefully maintained a synergy, when it came to delivering software, we had it our way and it worked out great. Lets talk about that, and how we can iterate faster and be more efficient. I think that software delivery is preferably a 3 step process that does not involve rushing features to market. But where there is steadiness and stability, a mindset that prioritizes shipping features with urgency can cause a lot of problems down the road. Right of the bat I want to point out that this article isn’t directly applicable to start-ups, where things have to be built from the ground up.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |