4 ms·
I was having a discussion with one of the people higher up in the org chart about why we need to move beyond a pizza-box development model. Currently what happe
by Beltiras 4y ago
I was having a discussion with one of the people higher up in the org chart about why we need to move beyond a pizza-box development model. Currently what happens is that the CEO (small org, 10 people, he's effectively the CTO) makes small-talk with a dev about a feature that needs to be developed. The dev then goes and builds the thing based on the discussion (a week-10 day sprint), takes the resulting work to the CEO which will then flesh out what needs to happen in addition to the work done. There will be some iterations of this process until the code can be merged into main and the feature completed. It's not horrible really but it can be way more efficient. I'd really like it if we can move beyond this seat-of-the-pants programming and have a more robust documentation process. I've been a part of feature mills like that, I've built my own products (unsuccessfully business wise) and I've also done contracted work. Out of all of these I was most productive when doing contracted work. I think it was due to the customer having to really spell out all of the things wanted in the work product. The requirements analysis was far better than anything else I've ever touched. I don't know why it should be any less detailed when it concerns your own work. You should beforehand be certain that you know what you are about to build. You should state it in a document. The stakeholders should sign off on it being what they want built. All of this takes time and it should. The engineering part of it is mostly trivial. The hard part is building a consensus on what should be built.
- claytonjy 4y agoThat description of "pizza-box development" (unfamiliar term for me) sounds pretty good actually? Seems pretty agile: informal planning, time-boxed sprint, revisit with stakeholder, repeat. It gets so much worse when the implementers are further from the stakeholders or customers. What's the issue there? I've also worked in consulting and appreciate the explicit requirements, but I find the formality much less efficient than the process you describe earlier. It ends up being very "waterfall" and exactly the approach the Agile Manifesto attempts to counter. Perhaps you prefer a more waterfall, hierarchical development process, or the companies (big ones) or industries (highly regulated) that necessitate it?
- Beltiras 4y agoBuy a pizza for the devs, rip off the lid, sharpie draw the sprint on the lid while eating the pizza.
- commandlinefan 4y ago> a week-10 day sprint A week-10 day sprint on _one feature_? They haven't drunk the scrum kool-aid yet. Just wait until they do - then every feature will be a "story", and no individual story will be allowed to be assigned more than 8 "story points" (which for some reason means "one day"). If you think a "story" will take more than 8 "story points", you'll be asked to break it down into "subtasks" of no more than 8 "story points" each (you'll be asked to do this accurately in a few minutes in a standup meeting). Trust me, if you tell a higher-up non-programmer that there's anything wrong with the development model, they'll hear "we need to move to the 'scrum' everything-is-mandated-to-take-less-than-a-day development model".
- rramadass 4y agoDon't scare us like that :-)
- deterministic 4y agoThe most successful software company I have worked for used your “pizza-box” model all the time. With 150+ developers. It worked extremely well. The worst software company I have ever worked for spend 95% of its time documenting things and 5% of its time implementing things. It took forever to get anything done.
- Beltiras 4y agoSomewhere betwixt those a happy medium lies
- deterministic 4y agoNot my experience at all (25+ years of experience working for companies in 5 different countries). However YMMV of course.