3 ms·

As I allude to above - if your release cycle etc isn't great today, then today is a great time to start tracking cycle time. One you can show people how bad thi

by ljf 8y ago

As I allude to above - if your release cycle etc isn't great today, then today is a great time to start tracking cycle time. One you can show people how bad things are today ('look, idea to dev complete is 2 weeks, but idea to live is 2 months'), and you can also show how well the small changes you make to the release process, actually went towards improving things. Also don't forget - try not to measure the 'amount of work' - instead focus on the amount of value released. x10 developers don't do 10 times as much work/code/releases - but figure out and engage in what they can do to make the company more money, and the most benefit - /with the LEAST/ work. Focus your team on the problem at the heart of the user story, and not on the solution too early.

klenwell 8y ago
The distinction you mention here (idea-to-dev vs idea-to-live) could be really useful for us as we've been debating two paths for an MVP that we're currently working on. It's actually the management team that has been putting off release in favor of a more fully-formed MVP, whereas my team is eager to get a more minimal working version (that we're pretty sure our users would appreciate and is ready for production) into our users' hands. One of my big concerns is that if I devote my time to focusing on figuring out these metrics (which still feel somewhat academic for our team at this point) then I'm going to be pulled away from more pressing concerns like reviewing PRs, providing technical guidance for the team, and simply working to get shit (or, rather, software of acceptable quality) out the door.
- ljf 8y ago
  I'd argue that you are in a 'strong' place if the mgmt is putting off releases - not the team. If you can be in 'can we release yet, can we release yet' frame, rather than 'when will this be ready to release?' frame, then you have a strong feature/value focused team. Again measuring the delays that are caused by mgmt, rather than you and you team, is really valuable. And as to time to sort out these metric - lean on jira etc to create these reports automatically - metrics and reporting should be as easy and as simple and as valuable as possible, or people simply won't track them - or care about reviewing them.

by ljf 8y ago

klenwell 8y ago

The distinction you mention here (idea-to-dev vs idea-to-live) could be really useful for us as we've been debating two paths for an MVP that we're currently working on. It's actually the management team that has been putting off release in favor of a more fully-formed MVP, whereas my team is eager to get a more minimal working version (that we're pretty sure our users would appreciate and is ready for production) into our users' hands. One of my big concerns is that if I devote my time to focusing on figuring out these metrics (which still feel somewhat academic for our team at this point) then I'm going to be pulled away from more pressing concerns like reviewing PRs, providing technical guidance for the team, and simply working to get shit (or, rather, software of acceptable quality) out the door.

ljf 8y ago
I'd argue that you are in a 'strong' place if the mgmt is putting off releases - not the team. If you can be in 'can we release yet, can we release yet' frame, rather than 'when will this be ready to release?' frame, then you have a strong feature/value focused team. Again measuring the delays that are caused by mgmt, rather than you and you team, is really valuable. And as to time to sort out these metric - lean on jira etc to create these reports automatically - metrics and reporting should be as easy and as simple and as valuable as possible, or people simply won't track them - or care about reviewing them.