Hot answers tagged

19

Why you shouldn't do it from a team perspective The most important rules of project management regarding teams are: The project can be a success only through intense teamwork. Empowered teams that trust each other are the most effective. One for all and all for one What you are trying to do, is very different. It was called "Divide et impera" by ...


9

You are not Apple or Microsoft. The reason why a software developer at Apple doesn't know about all of Apple's code is that there is a bloody awful huge amount of code and nobody can know about all of it. And there isn't one guy at Apple in charge of their repository. They have more than one :-) What you are thinking about is just totally misguided. If ...


3

Since I don't have previous experience, I don't know how right/wrong my idea is and I would like your advice: am I on the right track? If you don't have experience, and you are in the role of scrum master or project manager for a scrum team, the best thing you can do is step back and let the team make these decisions for itself. Your job as scrum master is ...


1

Other answers do a great job of describing what you should do instead of isolating everything. I agree with them. What you are really asking for is extreme, however I will attempt an answer focused on the technical aspects of doing this when you find it warranted. The assumption here is that you have found something that does need to be hidden and isolated ...


1

It sounds like your ongoing tasks in this specific case can be considered paying-off your technical debt. The default counter-measure of accumulating technical debt is usually improving your Definition of Done. For example: If you have an ongoing task for writing documentation for your undocumented code, you might want to add "All code changes are ...


Only top voted, non community-wiki answers of a minimum length are eligible