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.
Mathematical Computerscientist, father and nerdy guy next door who loves to fix stuff.
I work as Technical Lead for Roomle and servant to my 18 month old son. Besides that... there is hardly enoug...
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.