5 ms·
Hmm, I find it extraordinarily bizarre. My life has been filled with people charging down the wrong path because they have elevated system/process over goals.
by RogerL 13y ago
Hmm, I find it extraordinarily bizarre. My life has been filled with people charging down the wrong path because they have elevated system/process over goals.
For example: Agile/Yourdon/waterfall/XP/ISO9001/whatever. Our goal is a working system on time and budget (or whatever your goals are). The strategy is, perhaps, iterative waterfall, or agile, or more likely, some hybid approach (hint: how likely is small scale scrum to work to build a new Boeing, and how likely is the ideal Boeing process likely to create a great social web app). Systems are based on a number of assumptions about your goals; assumptions that may not apply, or that may change over time. If you aren't continually testing your chosen strategy (I prefer strategy over system, but I more or less mean the same thing here) against your goals, you are likely to be anywhere from sub-optimal to completely wrong.
So I live in a world where everyone is currently chasing Agile, without questioning whether it even fits the problem, or what its weaknesses are (even if it fits, it has weaknesses, and you should be aware of it so you can mitigate them). I live in a world where people grind through business processes, without questioning whether this is taking us where we actually need to go, or whether things have changed and our goals, which inform the system, still apply. To use the example in the article, it makes no sense to search for another job if you are retiring in a year. If the externals change and system does not, you are in trouble.
- tieTYT 13y agoGood post, but I just want to point out that it hinges on your strategy = his system. The more comments I see, the more confused I am about what his definition of a system is.
- Zancarius 13y agoI'm not sure I do either, but the first analogy that popped in my head when I read about Mr. Adams' approach was one of weight loss. I don't think it's a particularly good analogy, but it's the best I can come up with as an illustration of his "system-oriented" approach. In a goal-oriented system, someone might choose to lose 30 pounds as their goal, then they'll work toward that goal through exercise or diet. Upon achieving it, they'll either continue (setting another goal) or fall off the wagon (going back to previous habits and gaining the weight right back). I've known enough people who have tried to diet repeatedly--and have succeeded in their weight loss--only to fail miserably and gain the weight back within a few weeks. In a system-oriented approach (or maybe you could call it a habit-oriented system?), you focus on building up or improving your habits so that they meet whatever goals you set. Using the example of losing weight, you'd focus on diet and exercise by making fundamental lifestyle changes to your behavior and eating habits that simply happens to produce weight loss as a byproduct. People who exploit this system by changing their habits consistently keep the weight off because their day to day behavior has fundamentally changed. To put it another way, their habits would have to be dramatically altered in order to go back to putting on the weight they lost as a consequence of this approach. Now, what I'm at a loss on is how this might apply to businesses, software development, or the likes other than to suggest it's a matter of developing good habits. To use his restaurant example: Instead of focusing on income goals, focus on making the best food in town and serving customers quickly. On second thought, maybe there isn't anything more to it other than habits? Maybe there's no "secret?" Develop good habits and plod along until something falls into your lap as a byproduct.
- a3voices 13y agoI think for software development, the system can be simple such as "I'm going to get a lot done every day." And then for each day, figure out what "a lot" means. When you finish a small goal, immediately reorient yourself to figure out the next goal.
- Zancarius 13y agoI still think that's goal-oriented, or at the very least a hybrid approach. I wonder if the better term might be "objectives," e.g. each day, I have an objective to fix at least X bugs and make Y commits. But then that seems to increase the relative danger of encouraging yourself to do more make-work just to reach some slated goal at the end of the day. That does give me some insight. To translate this to a habit-oriented system, you could improve or streamline your commit process, reorganize things to deal more readily with possible distractions (or deal with distractions in a single chunk of the day, such as the morning, to leave more time available for coding in the afternoon), and work on honing your habits. By doing so, getting certain goals done each day--and increasing the number of goals reached--would be a side effect of improved habits. I guess I've been stumped because I'm looking at it from the wrong perspective (and I'm not especially prone to insight). Dumping goals entirely and focusing on the tools and techniques to get there seems more pertinent than establishing some baseline to work toward for a tangible reward. In some ways, it's like the football team example: If the team focuses on improving their fitness and practice habits (making progression itself a habit, such as the mile run by 5 seconds every few days), their competitiveness will improve as a consequence and become more predictable.
- galfarragem 13y agoAnother analogy: relativity theory (goal-oriented - macro solutions) vs quantum theory (system/process-oriented - micro solutions)
- Zancarius 13y agoI like that one.
- kamaal 13y agoAgile/Yourdon/waterfall/XP/ISO9001/whatever - Are not systems, they might be processes. But that is a wrong term to define them. They best come into a thing called 'standardization' which is basically the art of reducing every one to a same measure to enable them to be managed easily. >>So I live in a world where everyone is currently chasing Agile No, Agile is only for people where incremental improvement is possible in exchange of super cheap failures. People in construction businesses, space technology, medical electronics, micro processors, aircraft industry and many others would run into expensive disasters if they choose agile.
- UK-AL 13y agoIts perfectly possible to use Agile in those situations, and some do. You can't manage whole projects using agile, because it only works on small teams. For building a aircraft for example, you may have an agile team developing firmware for specific part of the plane. You develop strict tests, implement it in an agile way, then only let it pass to next stage once those tests are okaying it. In fact that's how you should do agile.
- RogerL 13y agoSure. And small part of a system != whole system. Anyway, kind of off the point of the OP, I got rant-y there.