Doing scrum harder won't help you escape "feature factory", in fact there is no management methodology that is better at enforcing "feature factory" (in the negative sense) than scrum. (Oddly, if I wrote an essay I might say "feature factory" is a great goal in that an automotive factory can assemble a car faster than a auto repair shop could because they have processes and equipment that is optimized for manufacturing what they manufacture.
Any management system chooses to manage certain things. For instance if you adopt Kanban you do some of things you should do in scrum such as "write tickets which can be either done or not done". You only let people work on a limited number of tickets at a time so work in progress doesn't spoil. It's a management methodology for a coffee shop but can bring software project home.
Scrum adds all sorts of ceremony which could be mixed value: in a true "software factory" you have a clear plan for how you implement features (primary a framework that means you don't have to do systems work) and you really can estimate things with 10% accuracy with a small amount of overhead. If you are not in control of the things that Scrum doesn't manage estimates are going to be inaccurate makework. Exhausted by retrospective meetings where people don't feel psychologically safe and just because 2 out of 10 people think a concern about the process is high impact doesn't mean that it not high impact. (e.g. if eng magagers treated "i have a problem with the build" as if it was "i just found out I have cancer" life would be different) Good decisions about database and architectural changes that can have a 10x impact on feature velocity aren't made in retrospectives, they are made when those decisions are made -- and the process for making the right decisions there is key.
Roughly there has to be a split between "framework" and "application" development and the framework is thought about in terms of greasing the skids for application development, there has to be a codesign between software and application development process. If it is not easier for application devs to do it the right way than the wrong way the framework is wrong. Database schemas and a careful analysis of "what information is available where" throughout the system is important. You should delete some of the muda (waste) practices of Scrum and add practices to specifically manage the effects of half-baked development in places where it harmful. (e.g. The impact of a bad decision in the database layer that gets into production as opposed to a bad line of JS can be 1000x or more)
---
I'd also say OKRs are one of the best ways to kill a startup that's been invented. They are great for a place like Google where they provide an elaborate mechanism for sociopaths and narcissists to come out on top. In a startup where we are having to zig and zag for big customers with big needs I don't need to have 15 goals on my agenda that were there just because VC's told my CEO to tell my eng manager to tell me I needed to have 15 goals. For a company in crisis (pre product-market fit) there is only one goal
Any management system chooses to manage certain things. For instance if you adopt Kanban you do some of things you should do in scrum such as "write tickets which can be either done or not done". You only let people work on a limited number of tickets at a time so work in progress doesn't spoil. It's a management methodology for a coffee shop but can bring software project home.
Scrum adds all sorts of ceremony which could be mixed value: in a true "software factory" you have a clear plan for how you implement features (primary a framework that means you don't have to do systems work) and you really can estimate things with 10% accuracy with a small amount of overhead. If you are not in control of the things that Scrum doesn't manage estimates are going to be inaccurate makework. Exhausted by retrospective meetings where people don't feel psychologically safe and just because 2 out of 10 people think a concern about the process is high impact doesn't mean that it not high impact. (e.g. if eng magagers treated "i have a problem with the build" as if it was "i just found out I have cancer" life would be different) Good decisions about database and architectural changes that can have a 10x impact on feature velocity aren't made in retrospectives, they are made when those decisions are made -- and the process for making the right decisions there is key.
Roughly there has to be a split between "framework" and "application" development and the framework is thought about in terms of greasing the skids for application development, there has to be a codesign between software and application development process. If it is not easier for application devs to do it the right way than the wrong way the framework is wrong. Database schemas and a careful analysis of "what information is available where" throughout the system is important. You should delete some of the muda (waste) practices of Scrum and add practices to specifically manage the effects of half-baked development in places where it harmful. (e.g. The impact of a bad decision in the database layer that gets into production as opposed to a bad line of JS can be 1000x or more)
---
I'd also say OKRs are one of the best ways to kill a startup that's been invented. They are great for a place like Google where they provide an elaborate mechanism for sociopaths and narcissists to come out on top. In a startup where we are having to zig and zag for big customers with big needs I don't need to have 15 goals on my agenda that were there just because VC's told my CEO to tell my eng manager to tell me I needed to have 15 goals. For a company in crisis (pre product-market fit) there is only one goal
https://en.wikipedia.org/wiki/The_Goal_(novel)
reply