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 ...


10

I would suggest not making these "continuous ongoing tasks". Rather than have generic "update documentation and review code for bad practices", define very specific work or tasks with clear objectives. Identify types of documentation that needs to be improved or specific problems with specific portions of the codebase. This will let you prioritize the ...


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 ...


4

The term "guild" appears to originate in discussions about the method used at Spotify. The Scaled Agile Framework refers to this concept as a "Community of Practice", but this term isn't unique to SAFe - it was originally proposed in 1991 and is not unique to software development. Given your organization size of ~300 with ~100 of them being software ...


3

I like to partner this responsibility with the ownership of transparency. Much of the value a scrum master can add is helping create clarity so that people with more expertise can see the answers more easily. Let's take a look at applying these to your examples. Technical expertise. This is actually a pet peeve of mine. I am a technical coach and I almost ...


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 ...


1

In my experience, this often occurrs when doing scrum. As you have already discovered, monitoring progress becomes impossible and the tasks do not fit within the scrum framework. Problem Such continuous / ongoing tasks usually never end until the project ends. Hence, they cannot be planned into a sprint. You may be able to split some tasks into specific, ...


1

The simple way to answer this question is to look at what is considered an impediment (emphasis mine): An Impediment is anything that keeps the Team from getting work Done and that slows Velocity. Impediments come in many forms: a sick team member, a missing resource, lack of management support or even a cold team room. If it's blocking the team from ...


1

I'm going to state some obvious facts but bear with me. Takeuchi Nonaka's article in HBR talks about a New Product Development Process, does not talk about Agile Software Development, does not talk about Scrum as it is defined by Ken & Jeff: Scrum (n): A framework within which people can address complex adaptive problems, while productively and ...


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