▲ | alganet 8 hours ago | |||||||
If that's the problem, then it's easy. Do not think about the tools. Think about small improvements that can move the team in a more productive and sustainable (agile) way. Simple things. Like putting a timer on long meetings until people get used to not extending it. Or putting a limit on the work pipeline between the developer and the tester to avoid overwhelming testing sessions. In my opinion, you are not supposed to start from scratch. The chaos often comes from this "let's blank slate everything and adopt all agile things we can find". Once again, the same mistake of focusing on tools instead of interactions between people. C'mon, it's not that hard. Doesn't need to have strict rules. | ||||||||
▲ | bluGill 7 hours ago | parent [-] | |||||||
> Think about small improvements that can move the team Which team? My team of 5 people or the entire project of several hundred? Focusing on the small teams finds a lot of local maximums that are very bad for the entire project. Many of the small changes small teams want to make are not possible because they would impact some of those several hundred other developers. Often small pain for us is much better than the pain our change would force on those others. | ||||||||
|