This post was originally posted on my blog
Scrum is my personal development methodology of choice. A key reason I like Scrum so much is because it...
For further actions, you may consider blocking this person and/or reporting abuse
Great advice, James. Our team has been trying different retrospective strategies, but they still feel a bit wishy washy. I think we're suffering from a lack of data and having concrete action steps to conclude the meeting.
What are your thoughts @jess and @ben ?
I think it makes sense. I think we're still a bit new and small to take on some of these practices, which I think rely on a bit more consistency on inputs than we can accomplish at this time. Any given week might swing between like 170 "developer hours" and, say, 50 depending on who's doing what and keeping track of that strikes me as a bit too much overhead right now.
That being said, I think we should try to be ahead of this. Continue to refine as we grow so that at each stage we have the right amount of monitoring.
What do you think @jlhcoder , we're a pretty tiny team and wear many hats. We have demos and retros (though demos are less strictly baked into the process) but right now they are more qualitative than quantitative.
Tiny team, many hats. Sounds like the more reasons for demos and retro.
In my experience, having lots of hats increases the risk of talking to less about it. But talking about it/showing it is also a good way to rethink it yourself.
I myself found lots of problems (code and concept) by showing it to someone who would have only said "looks nice", but while telling them what I did there were the famous "wait a minute"-moments ;)
Nevertheless I wouldn't go for to much metric in a small team. As you said: lots of overhead. But at least a "what did we want to achieve" vs "what did we achieve" is always possible and reasonable I think.
@ben @andy I'm really into all of this but we don't have buy in from everyone on estimation/points right now which is why we don't track any numbers. Though, I think we should start reviewing which tickets we accomplished throughout the week during retro.
...let's discuss during retro 😆
Thanks for the article.
Although I don't agree with almost anything you've written.
According to the demo:
Most of medium - big companies are highly political.
If you start finding bugs in your software next to stakeholders, they are gonna use it (no matter how great your idea was) against you, whatever goes wrong in the timelines, that always tends to be fixed or even shrink, while the scope grows.
According to the retrospective:
You are focusing there only on the team's speed.
I guess you are working in very specific work environment, where the work culture & ethics, team building activities etc. are already cared by people responsible for it, although in most companies those best practices could go south badly.