I'm arguing a lot for 'counting stories' in my place, replacing (other) estimates. We're having a mature product and need to decide on which problem to work on next - and for that ROI is the only metric I know of that has some sanity in it. What do you propose here?
Counting makes sense to me. Gut feel might be fine—“that seems like enough for one week”. ROI is the metric I care about as an investor. As a human I care about the humans affected by my decisions, but that’s hard to count.
So when I estimate the value of two solutions to be roughly equal, it makes sense to break down both into stories and then just see where I can get most of the solution with fewer (roughly equivalent sized) stories?
Or do a little of both until the superior answer is revealed. Depends on cost of delay, cost & likelihood of being wrong, certainty in your estimates. (Writing an article about this right now.)
At the last startup, we were about to run out of money (all the C-Suites are on 1/2 salary). We have to sign a contract with big customer, and if that doesn't happen on day X it's game over. I think in this case dead line IS REAL.
I agree in most cases what you state is true, but I think there are many cases where deadline is real, and I have no idea how (or what process even after thinking about for the last few years) can get us into a better place...
Let's work backwards from the best possible outcome--we did everything we could to influence the customer's choice & then they made their choice. (Notice I don't say "they bought"--we can't control that.)
How are we going to do everything that we can?
* Frequent demos
* Close collaboration so we don't step on each others' toes. The downside of mistakes is amplified in this environment.
* Lots of scope slicing--"Okay, that's enough of that for now. Go do this other thing."
* Celebration of wins--energy level is key in this kind of situation
* Frequent check-ins--I'd probably have a whole-team sync twice a day
Time is usually linear. Deliver on Friday is essentially the same as delivering the next Monday. Your scenario is the relatively rare one where the two are vastly different.
Even if time is frequently non-linear, all you can do is all you can do. Or less. Those are your two options. The one where you achieve more than is possible because you really really have to? That's not one of your options. Making do with less? Almost always possible.
That sense of "game over" is artificial tho'... Most startups fail, people move on, founders often start another startup (and mostly fail and start another one and so on). If these startup deadlines were "REAL" then we would see more consequences than the continual churn of Silicon Valley / Venture Capitalist ups and downs (and the other places this happens -- but, hey, I'm in the Bay Area so this is the area I know).
VCs even perpetuate this by preferring founders who've had a few failed startups under their belt so that they've (hopefully) learned some lessons and might be more likely to succeed.
Startup culture is particularly vulnerable to throwing out best practices and just sprinting, hell-for-leather at some artificial target -- and, yeah, been there, done that, including stumping all over Sand Hill Road to get funding for yet another "great idea".
Great article. During the meeting on Monday, is it like setting a sprint goal? Or is design sharing what's important for them this week, product what's important for them this week, then engineering etc.
Yes, I read that :D I wasn't too precise I guess. I interpret that in two possible ways
1. Everybody brings up some individual and some team stuff. And all of it is important. Think 1-2 things to accomplish this week.
2. Or it's a team goal, and there is only one thing
I guess, whatever works best for the team. I think, now that I write about it, what about other stuff that is also important, but not the most important thing this week. For example, there is one thing that we need to ship, but design is done already, and so there is another important thing just for the designer.
But yeah, I guess we will work on that. As long as we accomplish the thing we set out to, all good. Thanks.
I think the number of people is not the critical factor.
If you have 50+ people acting really like a team, with a shared vision of what is needed to achieve for the period, and not a cluster of fiefdoms arguing loudly over a set of misaligned priorities, probably it will be a good meeting and will lead to a promising development week...
If you have 60 people in a 120 minute meeting, then in order for everyone to have a voice it would be a max 2 minutes per person, which isn't much. With such a low level of participation you might as well remove a bunch of people and send them a recording or the notes which they can observe at their own leisure.
If you have 20 people in a 120 minutes meeting, that's still only 6 minutes per person. Maybe a bit more reasonable, but still I would expect half or more would not give any meaningful contribution in a situation like as the more talkative and active people will be the ones doing the most talking.
So ... still not sure. To me any meeting over 5 people tends to have abysmal participation levels. But maybe that has a lot to do with the specific people I've been in meetings with so far. There might be teams or workplaces that get more out of bigger meetings, I can't say for sure.
I think a meeting is successful when everybody in it hears and understands what was discussed and decided, not necessarily when everybody talks.
The advantages a good meeting with many people should bring over a good meeting with less people are:
-- Some issues or risks not perceived by those leading, or more active in, the meeting can be spotted by the 'quiet crowd'.
-- More 'first-hand' knowledge of the discussions and decisions, by the people who should ultimately 'implement' those decisions. Written notes normally can't carry all the context, details and nuances...
But there are downsides or risks associated with those 'advantages', also:
-- Too many, possibly irrelevant, issues/risks can be 'spotted' making the meeting derail or overextend.
-- Verbal 'context, details and nuances' can be easily forgotten over time, or worse may hallucinate away from the essence of what was discussed and decided, so 'written notes' are needed to keep the essence in sight during the implementation.
> I think a meeting is successful when everybody in it hears and understands what was discussed and decided, not necessarily when everybody talks.
This, so much.
I worked at Adobe for a while and they were big on "consensus" such that if a small group of people couldn't reach a decision, they added more and more people until the working group was large and consensus was achieved. It drove me crazy, but I realized that it did have the benefits of a) making leaders understand they were pitching ideas to more than just their peers and b) getting a lot more team-level buy-in and understanding.
I'd been at Macromedia for six years prior to that acquisition and their way was much more autonomous, with small groups making decisions and folks mostly just trusting them and making it happen. Macromedia was much more accepting of "failure" and tended to try a lot more ideas out rather than try to agree on the "best" idea at the outset. But there were also instances of "failure is not an option" on some projects and those could quickly become death marches to hit a publicly-announced product deadline.
I'm arguing a lot for 'counting stories' in my place, replacing (other) estimates. We're having a mature product and need to decide on which problem to work on next - and for that ROI is the only metric I know of that has some sanity in it. What do you propose here?
Counting makes sense to me. Gut feel might be fine—“that seems like enough for one week”. ROI is the metric I care about as an investor. As a human I care about the humans affected by my decisions, but that’s hard to count.
So when I estimate the value of two solutions to be roughly equal, it makes sense to break down both into stories and then just see where I can get most of the solution with fewer (roughly equivalent sized) stories?
Or do a little of both until the superior answer is revealed. Depends on cost of delay, cost & likelihood of being wrong, certainty in your estimates. (Writing an article about this right now.)
>Deadlines are mostly just lines. Nobody dies.
At the last startup, we were about to run out of money (all the C-Suites are on 1/2 salary). We have to sign a contract with big customer, and if that doesn't happen on day X it's game over. I think in this case dead line IS REAL.
I agree in most cases what you state is true, but I think there are many cases where deadline is real, and I have no idea how (or what process even after thinking about for the last few years) can get us into a better place...
Let's work backwards from the best possible outcome--we did everything we could to influence the customer's choice & then they made their choice. (Notice I don't say "they bought"--we can't control that.)
How are we going to do everything that we can?
* Frequent demos
* Close collaboration so we don't step on each others' toes. The downside of mistakes is amplified in this environment.
* Lots of scope slicing--"Okay, that's enough of that for now. Go do this other thing."
* Celebration of wins--energy level is key in this kind of situation
* Frequent check-ins--I'd probably have a whole-team sync twice a day
Time is usually linear. Deliver on Friday is essentially the same as delivering the next Monday. Your scenario is the relatively rare one where the two are vastly different.
Even if time is frequently non-linear, all you can do is all you can do. Or less. Those are your two options. The one where you achieve more than is possible because you really really have to? That's not one of your options. Making do with less? Almost always possible.
Been there too. Only adjustment we could make was scope otherwise it wasn’t a deadline, it was deathmarch.
It look a lot of work on that scope change though, very hard work.
That sense of "game over" is artificial tho'... Most startups fail, people move on, founders often start another startup (and mostly fail and start another one and so on). If these startup deadlines were "REAL" then we would see more consequences than the continual churn of Silicon Valley / Venture Capitalist ups and downs (and the other places this happens -- but, hey, I'm in the Bay Area so this is the area I know).
VCs even perpetuate this by preferring founders who've had a few failed startups under their belt so that they've (hopefully) learned some lessons and might be more likely to succeed.
Startup culture is particularly vulnerable to throwing out best practices and just sprinting, hell-for-leather at some artificial target -- and, yeah, been there, done that, including stumping all over Sand Hill Road to get funding for yet another "great idea".
Great article. During the meeting on Monday, is it like setting a sprint goal? Or is design sharing what's important for them this week, product what's important for them this week, then engineering etc.
"What is most important for us to accomplish together this week? How are we going to do that?"
Yes, I read that :D I wasn't too precise I guess. I interpret that in two possible ways
1. Everybody brings up some individual and some team stuff. And all of it is important. Think 1-2 things to accomplish this week.
2. Or it's a team goal, and there is only one thing
I guess, whatever works best for the team. I think, now that I write about it, what about other stuff that is also important, but not the most important thing this week. For example, there is one thing that we need to ship, but design is done already, and so there is another important thing just for the designer.
But yeah, I guess we will work on that. As long as we accomplish the thing we set out to, all good. Thanks.
Often ,if I wait long enough, folks do a better job of answering their question than I possibly could.
> On Monday morning the whole team (engineering, product, customers, testers, designers, managers, marketing, sales, whoever is on the team)
Can you elaborate on this a bit? This seems like it would be like 50+ people, which isn't a size of meeting I would normally expect to be productive.
I'd say a rotating cast of around 20 works well. Some core folks will be there most weeks, including all the juniors.
I think the number of people is not the critical factor.
If you have 50+ people acting really like a team, with a shared vision of what is needed to achieve for the period, and not a cluster of fiefdoms arguing loudly over a set of misaligned priorities, probably it will be a good meeting and will lead to a promising development week...
If you have 60 people in a 120 minute meeting, then in order for everyone to have a voice it would be a max 2 minutes per person, which isn't much. With such a low level of participation you might as well remove a bunch of people and send them a recording or the notes which they can observe at their own leisure.
If you have 20 people in a 120 minutes meeting, that's still only 6 minutes per person. Maybe a bit more reasonable, but still I would expect half or more would not give any meaningful contribution in a situation like as the more talkative and active people will be the ones doing the most talking.
So ... still not sure. To me any meeting over 5 people tends to have abysmal participation levels. But maybe that has a lot to do with the specific people I've been in meetings with so far. There might be teams or workplaces that get more out of bigger meetings, I can't say for sure.
I think a meeting is successful when everybody in it hears and understands what was discussed and decided, not necessarily when everybody talks.
The advantages a good meeting with many people should bring over a good meeting with less people are:
-- Some issues or risks not perceived by those leading, or more active in, the meeting can be spotted by the 'quiet crowd'.
-- More 'first-hand' knowledge of the discussions and decisions, by the people who should ultimately 'implement' those decisions. Written notes normally can't carry all the context, details and nuances...
But there are downsides or risks associated with those 'advantages', also:
-- Too many, possibly irrelevant, issues/risks can be 'spotted' making the meeting derail or overextend.
-- Verbal 'context, details and nuances' can be easily forgotten over time, or worse may hallucinate away from the essence of what was discussed and decided, so 'written notes' are needed to keep the essence in sight during the implementation.
> I think a meeting is successful when everybody in it hears and understands what was discussed and decided, not necessarily when everybody talks.
This, so much.
I worked at Adobe for a while and they were big on "consensus" such that if a small group of people couldn't reach a decision, they added more and more people until the working group was large and consensus was achieved. It drove me crazy, but I realized that it did have the benefits of a) making leaders understand they were pitching ideas to more than just their peers and b) getting a lot more team-level buy-in and understanding.
I'd been at Macromedia for six years prior to that acquisition and their way was much more autonomous, with small groups making decisions and folks mostly just trusting them and making it happen. Macromedia was much more accepting of "failure" and tended to try a lot more ideas out rather than try to agree on the "best" idea at the outset. But there were also instances of "failure is not an option" on some projects and those could quickly become death marches to hit a publicly-announced product deadline.