|
|
|
|
|
by palata
1037 days ago
|
|
Use common sense, and organize your team in a way that works. Students tend to learn to do that in university group projects. Then they join the industry and we tell them "you need to gather everyday at the same time for what we call a 'stand-up', where we talk to each other". Guess what? The students were communicating without having to make formal stand-ups, and it worked. |
|
- Have somebody who is responsible for understanding the customer from a business perspective and be able to explain that to developers in the form of prioritized development items.
- Try to build something that works to confirm your assumptions and manage risk, ideally on a short-ish cycle of a few weeks. Always keep a working product. In some projects this is not (immediately) possible - in that case, it’s probably better to run a traditional waterfall-project, with the tradeoffs that come with it.
- Get together regularly to talk about less immediate topics and improve the work process.
- Plan and make forecasts using actual data from the past, not wishful thinking.
And that is basically Scrum. For me this is common sense, I wouldn’t know why you would do it in another way.
How it’s implemented in practice differs and it seems a lot of places don’t implement it very well. So far I haven’t heard many good suggestions from the developers suffering under these implementations on how to make it better though, hence my question.