I think it's great that you're thinking through strategies to remove blockages and get the team moving smoothly. I hesitate to even mention this, since your note seems solidly focused on the process, rather than the human element here.
But my experience is that the human element is harder to measure, and can get lost in the quest for a speedy process. 100% CPU usage is admirable on hardware. It's a recipe for burnout and high turnover to run a team at capacity all the time.
It may seem ideal for everyone on the team to quickly hand off tickets and move them through the process as fast as possible. But that tends to require a lot of context switching.
Context/task switching has costs in productivity, as well as human stress level and cognitive fatigue. It's really important to account for this when thinking about what delays are "unnecessary." Letting team members switch tasks at natural moments in their day is a non-trivial benefit to letting a PR or testing cycle wait for a bit.
I used to work on a team where we'd do PRs first thing in the morning, regardless of when they were submitted. That way, nobody got pulled of their train of thought, and devs could work on something else for the rest of the day without getting pulled back onto comments/fixes on the PR. It meant that PRs might sit for nearly a day before anyone looked at them, and that was fine. Having our day broken into two or three large chunks instead of 25 smaller ones was more than worth it.
There are lots of advantages to breaking down stories into their smallest shippable units. One of those advantages is that natural task-switching moments become part of the team's usual workflow.
Born pythonista, likes to play around in the world of web development. Sometimes tries rusty swift stuff. Likes to teach, learn and coach. When not coding, enjoys wife, kids, soccer, guitar and acting
Thanks for your input. Avoiding too much context switching is also really important. I think each team has its own characteristics and can find its synergy and then a developer will strike a good balance between working on her/his task and switching to helping other tasks to move.
If we make all developers able to observe the situations where the team is wasting time and eliminate them, that's a very good step forward, but indeed trying to reach a "100% CPU usage" will hurt.
Yep. The team will naturally find an equilibrium that works for them. But I've seen through hard experience that when a team is under pressure to meet certain metrics, other metrics will be sacrificed, even if that sacrifice is self-defeating in the long-term. Team values and goals need to be explicitly stated, and repeated, or they get lost in the day-to-day work of trying to pay the bills.
I think it's great that you're thinking through strategies to remove blockages and get the team moving smoothly. I hesitate to even mention this, since your note seems solidly focused on the process, rather than the human element here.
But my experience is that the human element is harder to measure, and can get lost in the quest for a speedy process. 100% CPU usage is admirable on hardware. It's a recipe for burnout and high turnover to run a team at capacity all the time.
It may seem ideal for everyone on the team to quickly hand off tickets and move them through the process as fast as possible. But that tends to require a lot of context switching.
Context/task switching has costs in productivity, as well as human stress level and cognitive fatigue. It's really important to account for this when thinking about what delays are "unnecessary." Letting team members switch tasks at natural moments in their day is a non-trivial benefit to letting a PR or testing cycle wait for a bit.
I used to work on a team where we'd do PRs first thing in the morning, regardless of when they were submitted. That way, nobody got pulled of their train of thought, and devs could work on something else for the rest of the day without getting pulled back onto comments/fixes on the PR. It meant that PRs might sit for nearly a day before anyone looked at them, and that was fine. Having our day broken into two or three large chunks instead of 25 smaller ones was more than worth it.
There are lots of advantages to breaking down stories into their smallest shippable units. One of those advantages is that natural task-switching moments become part of the team's usual workflow.
Cheers!
Thanks for your input. Avoiding too much context switching is also really important. I think each team has its own characteristics and can find its synergy and then a developer will strike a good balance between working on her/his task and switching to helping other tasks to move.
If we make all developers able to observe the situations where the team is wasting time and eliminate them, that's a very good step forward, but indeed trying to reach a "100% CPU usage" will hurt.
Yep. The team will naturally find an equilibrium that works for them. But I've seen through hard experience that when a team is under pressure to meet certain metrics, other metrics will be sacrificed, even if that sacrifice is self-defeating in the long-term. Team values and goals need to be explicitly stated, and repeated, or they get lost in the day-to-day work of trying to pay the bills.
There's a really good discussion of Agile and thinking about velocity in Ep. 15 of Tech Done Right.