4 ms·

I started scrum mastering a team in November and the team suffers from too many things at the same time for sure. I have to take a more proactive planning role

I started scrum mastering a team in November and the team suffers from too many things at the same time for sure. I have to take a more proactive planning role and I could definitely try out that on call stream idea. I am naturally a quite chaotic person, I have trouble helping other people create order when I'm already having trouble keeping an eye on all the streams that exist in the team. Any tips would be appreciated. I wish people would stop bringing up the Pareto principle. "Some things are consistently bigger than other things." Can we talk about why things are bigger than other things instead of saying it's because of some law of nature?

crowdswisdom 5y ago
> I wish people would stop bringing up the Pareto principle. "Some things are consistently bigger than other things." Can we talk about why things are bigger than other things instead of saying it's because of some law of nature? I see what you're saying, but it sounds like you haven't really internalized the principle.. because you're viewing it as a tautology rather than the useful heuristic it is. You can and should still have the probing discussions. But having 80/20 as a rule of thumb will actually help you know where to probe. So you might want to give it another look. > I am naturally a quite chaotic person, I have trouble helping other people create order when I'm already having trouble keeping an eye on all the streams that exist in the team. Any tips would be appreciated. There's so much to say about this topic.. it's hard to give many pointed tips. But my advice would be to 1) read far and wide about product management (blog posts like this one, books, research, etc), and especially focus on first principles. 2) Experiment with your team! and 3) *Do not* think that doing one of those weekend certification courses or seminars or whatever is going to help much. Points 1 and 2 will give you far far more insight.
- Teafling 5y ago
  Thanks for your thoughtful reply! Re: pareto principle, I've never actually looked at what the principle means. "80% of the consequences come from 20% of the causes" is quite useful, as I understand it it means "don't assume that causes of consequences are randomly distributed". I think I see it often misunderstood the way I misunderstood (/misunderstand?) it: "As with most things, there is the 80/20 rule (Pareto again), exceptions are sometimes warranted in important situations." this sentence just says "you should stick to the rule about 80% of the time" Re: advice, thanks for taking the time! I hadn't considered research, but luckily I already agree with 3) :P
cpeterso 5y ago
> I am naturally a quite chaotic person, I have trouble helping other people create order when I'm already having trouble keeping an eye on all the streams that exist in the team. Any tips would be appreciated. For tracking my own work, David Allen's "Getting Things Done" (GTD) was a huge influence for me (though it can be a bit cult-like and many people get too distracted optimizing their GTD system instead of actually getting things done). As for managing a team's work, two important tenets of scrum that I think many teams have a hard time sticking with are limiting work in progress and retrospectives. Limiting work in the sprint backlog and each team member's own plate during the sprint is critical for actually getting work across the finish line. Retrospectives can be hard, especially when people are feeling pressure to keep moving forward, but retrospectives are how a team can optimize and gel, which is most important during those times. apenwarr's (long) "An epic treatise on scheduling, bug tracking, and triage" is a great resource: https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213
- Teafling 5y ago
  Thanks for your thoughtful reply! Glad to hear your thoughts on what's important, and I'll give the treatise a thorough read
kqr 5y ago
> Can we talk about why things are bigger than other things instead of saying it's because of some law of nature? It's the opposite of a law of nature: it generally doesn't apply to nature which is bounded by physical constraints. It happens in artificial fields like economy, software engineering, etc. I'm not sure if there's a general principle, but I heard an intuitive explanation for why it happens in software engineering: it's a recursive field. Software is built from smaller software built from even smaller software and so on. This allows almost unbounded complexity (as opposed to e.g. houses, which are not built from tiny houses ad infinitum.) With unbounded complexity comes fat tails, and therefore the Pareto principle. Edit: well, thinking about it, it does apply to some things in nature, like the sizes of bodies of water.

crowdswisdom 5y ago

> I wish people would stop bringing up the Pareto principle. "Some things are consistently bigger than other things." Can we talk about why things are bigger than other things instead of saying it's because of some law of nature? I see what you're saying, but it sounds like you haven't really internalized the principle.. because you're viewing it as a tautology rather than the useful heuristic it is. You can and should still have the probing discussions. But having 80/20 as a rule of thumb will actually help you know where to probe. So you might want to give it another look. > I am naturally a quite chaotic person, I have trouble helping other people create order when I'm already having trouble keeping an eye on all the streams that exist in the team. Any tips would be appreciated. There's so much to say about this topic.. it's hard to give many pointed tips. But my advice would be to 1) read far and wide about product management (blog posts like this one, books, research, etc), and especially focus on first principles. 2) Experiment with your team! and 3) *Do not* think that doing one of those weekend certification courses or seminars or whatever is going to help much. Points 1 and 2 will give you far far more insight.

Teafling 5y ago
Thanks for your thoughtful reply! Re: pareto principle, I've never actually looked at what the principle means. "80% of the consequences come from 20% of the causes" is quite useful, as I understand it it means "don't assume that causes of consequences are randomly distributed". I think I see it often misunderstood the way I misunderstood (/misunderstand?) it: "As with most things, there is the 80/20 rule (Pareto again), exceptions are sometimes warranted in important situations." this sentence just says "you should stick to the rule about 80% of the time" Re: advice, thanks for taking the time! I hadn't considered research, but luckily I already agree with 3) :P

cpeterso 5y ago

> I am naturally a quite chaotic person, I have trouble helping other people create order when I'm already having trouble keeping an eye on all the streams that exist in the team. Any tips would be appreciated. For tracking my own work, David Allen's "Getting Things Done" (GTD) was a huge influence for me (though it can be a bit cult-like and many people get too distracted optimizing their GTD system instead of actually getting things done). As for managing a team's work, two important tenets of scrum that I think many teams have a hard time sticking with are limiting work in progress and retrospectives. Limiting work in the sprint backlog and each team member's own plate during the sprint is critical for actually getting work across the finish line. Retrospectives can be hard, especially when people are feeling pressure to keep moving forward, but retrospectives are how a team can optimize and gel, which is most important during those times. apenwarr's (long) "An epic treatise on scheduling, bug tracking, and triage" is a great resource: https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213

Teafling 5y ago
Thanks for your thoughtful reply! Glad to hear your thoughts on what's important, and I'll give the treatise a thorough read

kqr 5y ago

> Can we talk about why things are bigger than other things instead of saying it's because of some law of nature? It's the opposite of a law of nature: it generally doesn't apply to nature which is bounded by physical constraints. It happens in artificial fields like economy, software engineering, etc. I'm not sure if there's a general principle, but I heard an intuitive explanation for why it happens in software engineering: it's a recursive field. Software is built from smaller software built from even smaller software and so on. This allows almost unbounded complexity (as opposed to e.g. houses, which are not built from tiny houses ad infinitum.) With unbounded complexity comes fat tails, and therefore the Pareto principle. Edit: well, thinking about it, it does apply to some things in nature, like the sizes of bodies of water.