4 ms·
Simpler and more executable than that, actually. 1) Basic premise of waste: People need to be told what to do, people wait to be told what to do. 2) Eliminate t
by jksmith 3y ago
Simpler and more executable than that, actually.
1) Basic premise of waste: People need to be told what to do, people wait to be told what to do.
2) Eliminate the waiting by standing up a value stream where everyone is part of the value stream team. Sections of the stream can be activated in a parallel fashion through autonomy of action.
3) Managers quit telling people what to do, and instead become value stream engineers - focusing on efficient flow of value like it's the company's inventory, from creation to delivery to the customer.
4) This move has different demands on remote work, but since it promotes autonomy of action, the more ham-fisted demands of legacy management are deprecated.
- Kerrick 3y agoI think you just described something I haven't been able to figure out for over a year. I loved being a manager and then director at the previous small-ish software company I was at, and then I hated it after being acquired and integrated into the acquirer's culture. I stopped being able to be a "value stream engineer" as you put it.
- madspindel 3y agoAnywhere I can read more about this? Blog post or book recommendation? I understand that you want to keep it simple and all but I feel I need more practical details.
- digikata 3y agoLook at the term Theory of Constraints https://en.wikipedia.org/wiki/Theory_of_constraints https://en.wikipedia.org/wiki/Theory_of_constraints. There is a "business fiction" book called "The Goal" by Eli Goldratt that is pretty approachable. He actually wrote a number of books at different levels of detail. Initially the concepts were addressed for manufacturing ops, but there are some fundamental similarities for scaling software teams, focusing where you produce value, and where you can create waste and misfocus if you try to keep everything/everyone busy at 100%.
- MarkMarine 3y agoThere is a book written in the style of the goal but for software, called Phoenix Project. Quite good.
- digikata 3y agoI hadn't come across this before. I'll have to check it out. Thanks!
- jksmith 3y agoAgree on Goldratt, and the book his daughter wrote and recently released, called 1) "Goldratt's Rules of Flow." Theory of constraints is a rich subject with heavy roots in industrial engineering. Look for Don Reinhardt's 2) "Principles of Product Development Flow" as the gold standard. Also most all of Edwards Deming work touch on systems thinking from the industrial engineer perspective. See 3) https://deming.org/ https://deming.org/. Additionally, see books like 4) "Systems Thinking and Other Dangerous Habits," and 5) "Team Topologies" as examples of why legacy management are probably doomed if they don't learn how to scale teams via a coherent system. Finally, Senger's 6) "The Fifth Discipline" is total classic on why we need to shift our legacy management mental model to an organizational system that is continuously improving via systems.
- mjevans 3y agoIt's like data structure driven programming then. Language doesn't really matter as much as the storage, in work layout and transformation of data. Focus on the data management as the framework / skeletal structure and everything surrounding it becomes more clear.
- Izkata 3y agoSounds like a backlog (value stream) with Kanban (pick up work asynchronously as available).
- jksmith 3y agoI've worked with some kanban teams who were absolute animals. Kanban is great if your board workflow doesn't get too complicated, and the team is constrained from doing scrum. Ex. locomotive software has to be fully deployed on a train before it can be checked off. That's a tough ask with scrum, but kanban can work well in this case. Whatever the case, it's back to managing flow, not people.