4 ms·
That response is ineffective, because the managers will simply pressure the engineers to give better estimates. The penny game (where I work we call it the bee
by kyllo 11y ago
That response is ineffective, because the managers will simply pressure the engineers to give better estimates.
The penny game (where I work we call it the beer game) is a good learning exercise, but in software development you really don't want to be having different "stations" handing work off to each other in the first place, because that leads to delays and quality issues. Each station will develop its own little backlog and pretty soon a feature cannot make it from start to finish without spending weeks waiting in the design queue, then the dev queue, then the test queue...
Instead, you need to have a small, cross-functional team focusing on the same piece of the product at the same time, collaborating and giving rapid feedback on each other's work--that's what agile and XP and scrum are for. And you need a pull system instead of a push system, to regulate the amount of work in progress--that's what kanban boards are for.
- gclaramunt 11y agoI don't like kanban either, still manufacturing
- nradov 11y agoAnd yet we have existence proofs that Kanban works, in the sense that it allows many teams to quickly deliver value to customers. So what don't you like about it? We shouldn't reject innovations out of hand just because they happen to originate in manufacturing.
- Chris2048 11y agoBy that logic, homeopathy must also be legit.
- mtviewdave 11y agoBut doesn't specialization naturally push towards the creation of stations? If your cross-functional team contains both a database engineer and a UX designer, I don't see how either can help with the other's job.
- fireflash38 11y agoI find it's helpful to at least be aware of what is going on with other 'specialists'. That way you can hopefully get some mental (or physical!) prep done long before it gets to you.
- kyllo 11y agoIt really can help if they are actively communicating with each other--the user interface is how the data gets into the system, so if the database engineer understands the interface it can provide context for where the data comes from, what it means and how it is used, and that can inform data modeling decisions. Understanding how the data model is laid out, how much structure is needed, what fields are required/optional and what types they are etc. can also inform UI/UX design decisions. And this is an example of two roles that are at opposite ends of the frontend/backend spectrum. For roles whose work products interface directly, there's an even stronger need to collaborate. Specialization is good in that it allows people to focus on using their best skills, but it's bad if it fragments the product development team and inhibits communication and decisionmaking.
- mtviewdave 11y agoCertainly active communication and the prevention of siloing can help speed development and reduce defects. But the Penny Game illustrates that backlogs and queuing issues will occur even if each station is in perfect communication with all the others. So you can't eliminate queuing issues with close collaboration and rapid feedback. You can only eliminate it by eliminating dependencies and specialization, which I don't think is possible in modern software development.
- kyllo 11y agoWell yes, on a basic level when you have specialization and division of labor, you will always have dependencies. But when you tighten the feedback loop and shrink the batch size of the work, you make the dependencies smaller and more granular, so the queue gets smaller and fluctuates less, and you get better flow of work through the process. Here's a simple visual that illustrates why this is the case: https://lh4.googleusercontent.com/QGyl3JPoMH1wU0pNoGIsucQCOfLu0R9MKZ4kfj3ioNBA_5gdXLVM_YWQ7kRSlKO3dxzzHGyrhMi68l8MjmYjriUyYRQKbUkVuvw2KMeHWRlSjGQ8ey__OfpC8JDTeDEosA https://lh4.googleusercontent.com/QGyl3JPoMH1wU0pNoGIsucQCOf...