This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
What is everyone's thought on the third ideal? Improvement of the process daily work over the work itself. Do you think there is a point of over-optimization?
What is everyone's thought on the third ideal? Improvement of the process daily work over the work itself. Do you think there is a point of over-optimization?
@shanemrowley @URXJZDTEX What a great discussion on the Third Ideal! What I love so much about Dr. Mik Kersten’s work is how he classifies Debt as one of the four Flow items (the others being Features, Defects, Risks). What the tech giants (ala FANGs + Microsoft) have done so well is elevate dev productivity to an incredible level, putting some of the most senior engineers on helping improve everyone’s productivity. I love @UNKKCQGJ3 DevOps Enterprise presentation about his work at FindMyPast, which shows this same principle working in a smaller organization, and getting the same sort of outcomes. (The line of “you type ‘git clone’ and you see 43 merge conflicts came from that talk. Thank you @UNKKCQGJ3!!! I need to add you to the list of references blog post! https://www.youtube.com/watch?v=R7ZCVlPX-jo 🎉🙏:unicorn_face:
Porsche has a great story of avoiding bankruptcy by embracing Lean as per Toyota (ex TPS senseis helped them). They shown improvements in the time it takes to assemble a 911. 72% improvements between 1992 and 2010. More impressive mostly from continuous improvements rather than step change (except for 996), which is much harder to realise in a physical production chain vs IT. This allowed them to go on a road of new products boxster, cayenne, etc. And being the success that they are today. It is also interesting to see how Porsche and Toyota are very active in redefining selves on the energy transition journey, with much hybrids and getting into full electrics. The transition in the automotive sector is massive. Seeing such enterprise able to change, when in contrast many banks are paralyzed in Digital (mainly due to operational and cultural legacy), probably says something about having sound roots in operational excellence.
@shanemrowley improvement of the process over the work itself is a good point to pursue. I don't believe there is a point in over-optimization... it defeats the purpose
@gagneet At the risk of over-optimization, I think the concern is not knowing when you're there. At what point do we say, "our process is great now, let's start implementing features, bug fixes, etc"?
Overall, I agree with the ideal, but I feel like there needs to be a stopping point. I could easily see engineers spending months perfecting their processes. There's definitely a point of diminishing returns.
Overall, I agree with the ideal, but I feel like there needs to be a stopping point. I could easily see engineers spending months perfecting their processes. There's definitely a point of diminishing returns.
Yes definitely. Process is good to have to define the guidelines, but going after it to the exclusion of work is not the right way. Would prefer it to be a parallel activity which improves the work over time, rather than an exclusive piece.
This has happened at my work, We have been working on creating a build and deploy pipeline and as we are finishing it, we start talking about optimizing it. My thoughts are continue to do bug fixes but don't go back down that rabbit hole
This has happened at my work, We have been working on creating a build and deploy pipeline and as we are finishing it, we start talking about optimizing it. My thoughts are continue to do bug fixes but don't go back down that rabbit hole
On the question of “over-optimization” it might be useful to contrast work products and processes vs. complex systems (in which category we can include people): “definition of done” applies to the former, not the latter. Or maybe it would be good to explore the assumptions of the previous sentence? I’ve seen plenty of situations where people “over-rotate” on “improvement” - in a way; but what’s really happening is we keep trying new ways of solving problems because the ways we tried before brought unsatisfying results.
I think the key driver here is value. If process improvement brings value yes you do it, otherwise features takes priority. I am a big fan of "good enough" for the process improvement. One nice way to measure value is with cost of delay. To me process itself is a higene factor it has to be improved up to the point it takes out the discussion from the table.
I think the key driver here is value. If process improvement brings value yes you do it, otherwise features takes priority. I am a big fan of "good enough" for the process improvement. One nice way to measure value is with cost of delay. To me process itself is a higene factor it has to be improved up to the point it takes out the discussion from the table.
I agree with @erion.serti that value is the determining factor. I would take it one step further. Value is not determined by us value is determined by our customer so once the customer(s) needs are satisfied there is no reason to keep "perfecting" that item. I do believe you can always improve process in which you deliver the value, but refining the process should never displace the value to the customer.
I agree with @erion.serti that value is the determining factor. I would take it one step further. Value is not determined by us value is determined by our customer so once the customer(s) needs are satisfied there is no reason to keep "perfecting" that item. I do believe you can always improve process in which you deliver the value, but refining the process should never displace the value to the customer.
I think there is a point of equalibrium that needs to be established between development and process improvement. I will be the first to admit I do not spend much time on the development side of the house, but I have seen bad software implementations/projects that end up much like Erik stated in TPP the people who wanted the new software become so frustrated and disenfranchised that they no longer want it, even working against it. I have not studied the theory of constraits somehow I have missed that but it makes a lot of sense to me. No matter how much we improve something above the constraint we are still limited by the constraint. I am begining to think that tools like Lean, Six Sigma need to first understand the true work flow therby highlighting contstaints and then applying tools to eliminate the constraint and allow everyone to improve there own areas to the greater success of the deptarment/company.
When it comes to constraint elimination, I think it can be as simple and grass roots as just going to where the bottleneck is when you notice it and asking how you can help… sort of like Maxine did with the QA folks. In the past, I’ve noticed wip stacking up after it flows from me to someone else (a QA person, and ops person, maybe a dba, whoever…) and if you have the freedom and autonomy to do it (and sometimes the courage or willingness to apologize rather than ask for permission if that becomes necessary) , it can be a productive experience to simply get out of your lane, go sit down next to the person/team where work is bottlenecking, and just ask what you can do to help. Often, it shocks them. Some times there’s nothing fast and simple tech wise you can do, so it just becomes a good relationship building experience, and you can offer to get them coffee, or wash their cars, or walk their dogs or whatever. Some times, those teams can benefit from your skill, and you can help do something simple that widens the bottleneck. At any rate, you showing you’re not a jobsworth and you have some empathy and truly care about success broadly is usually a thing that people will respect unless you’re dealing with someone particularly cantankerous or untrusting.
Habituating improvement is also a factor to consider, as is the concept of marginal gains, each in themselves of limited value, but adding up to make significant positive impact. Teams change over time and both new hands and old laggards need to get and stay hooked!
Continuous improvement means change which need a paradigm shift as human beings by nature expect things to stay as they are. It goes in line with the 4th Ideals psycological safety. It is our duty as managers to create a safe environment where people can show their true colors. Only in safe environment people are willing to embrace changes and further improve.
Continuous improvement means change which need a paradigm shift as human beings by nature expect things to stay as they are. It goes in line with the 4th Ideals psycological safety. It is our duty as managers to create a safe environment where people can show their true colors. Only in safe environment people are willing to embrace changes and further improve.
@shanemrowley once upon a time when I finally got my "senior" badge I had a long discussion with my manager what it means to be a senior. His point was that seniors commit through others and that's how I view the third ideal. When you know a lot about how the process works and how it can be improved you are able to do much more helping others do a better job than simply coding stuff. If such senior makes an improvement that shaves of 1h of cycle time run multiple times a day you have just reduced time to deliver feature by 100h. Regular developers help by improving the quality of their work with senior guidance. I like to think about such improvements as an investment. If you spend 10s of hours on improving something that will run once in a year for a couple of hours you are probably wasting your time, by over-optimizing items that should have been left alone. On the other hand - we all know that those PoCs or one-time scripts that weren't supposed to be used in production never really die.
@shanemrowley once upon a time when I finally got my "senior" badge I had a long discussion with my manager what it means to be a senior. His point was that seniors commit through others and that's how I view the third ideal. When you know a lot about how the process works and how it can be improved you are able to do much more helping others do a better job than simply coding stuff. If such senior makes an improvement that shaves of 1h of cycle time run multiple times a day you have just reduced time to deliver feature by 100h. Regular developers help by improving the quality of their work with senior guidance. I like to think about such improvements as an investment. If you spend 10s of hours on improving something that will run once in a year for a couple of hours you are probably wasting your time, by over-optimizing items that should have been left alone. On the other hand - we all know that those PoCs or one-time scripts that weren't supposed to be used in production never really die.