Agile isn't so agile
I've been craving a proper process at work for some time. And these past couple weeks I have experienced the proverbial "be careful what you wish for" scenario. I got merged in with a team with a proper Agile methodology and while I love a number of aspect I HATE with a fiery burning passion some other things. Top things to point my hate cannon at are estimating stories, story points in general and fixed time boxes.
The rest of Agile I think is generally quite good.
Estimating stories. For this one I think the real problem is the structure of the company. We don't really converse with the "customer" or stakeholders, so developers write the stories. And usually the developer who will code it. This kind of defeats the purpose to group estimation. The majority of the time the primary developers sticks. And if it varies, never by more than one increment on either side. Also, the estimates don't "really" matter. We estimate tasks in hours under the story later anyway.
Basically, if the stories are coming from outside parties or non-technical stakeholders internally, THEN having developers throw a gut-feel estimate out there is worthwhile. And that IS what most Agile teachings say should be happening. Here, however that isn't the case.
My beef with estimating however doesn't end at the group estimation. The story points themselves are also lunacy. The propaganda is that story points ARE NOT time estimates. YET, it is EXPECTED that over time a team will gravitate to a specific velocity so that a product managers can reliably estimate how many story points can be completed within a TIMEFRAME.
I hate to break it to you, but as long as that expectation exists, that is EXACTLY the definition of a unit of time. It is simply being obscured behind some magic number. The reality is that once your teams velocity stabilizes you can easily take your velocity and calculate exactly what the expected time is behind a single story point. And even if you don't, over time, by virtue of the fact that you are able to produce such reliable estimates you are either consciously, or subconsciously doing exactly that.
Story points are there to bridge psychological barriers associated with estimating time. They are a way of getting people who don't want to estimate time, to estimate time. So, group estimation in general seems like a humongous waste.
Arbitrary time boxes, or iterations, or sprints, or whatever you want call them are also stupid. I read an article suggesting taking however many of your highest priority stories that you think you need to take to make a meaningful release, estimate how long you think that should take and make that the size of your iteration. Right now I feel like we shove as much as we can into an iteration and sometimes the resultant feature set of the iteration doesn't result in anything shippable or testable. Or iterations we have so many useful things we could have shipped several smaller builds. Rarely does it feel like a single iteration contains the "right" amount of new features to ship something. And both of the other scenarios present potential pitfalls. So why do it? Sadly, I think the right answer is predictability in the release cycle for PM's and upper management.
Anyway, the end conclusion is this. Agile is supposed to make your team faster. The things I hate above and see slowing down my team may not impact yours. If you truly want to be Agile, you might want to start with a cookie cutter approach and then every few iterations review the process and see if there are meaningful places and ways to improve the process for your specific team and environment. If your team has a phobia of estimating in time, then story points may make sense. If you gets stories from outside dev, then group estimation up front may be more accurate than an individual guesstimate. And if your product is small enough or at a more stable point in its lifecycle, fixed iteration lengths may be perfect.
I'm not trying to say any of my gripe areas are inherently flawed. But I am saying that adhering to any specific aspect of the cookie cutter Agile methodology just because someone says that aspect is critical is wrong. No methodology will be perfect for every team and every product.
The rest of Agile I think is generally quite good.
Estimating stories. For this one I think the real problem is the structure of the company. We don't really converse with the "customer" or stakeholders, so developers write the stories. And usually the developer who will code it. This kind of defeats the purpose to group estimation. The majority of the time the primary developers sticks. And if it varies, never by more than one increment on either side. Also, the estimates don't "really" matter. We estimate tasks in hours under the story later anyway.
Basically, if the stories are coming from outside parties or non-technical stakeholders internally, THEN having developers throw a gut-feel estimate out there is worthwhile. And that IS what most Agile teachings say should be happening. Here, however that isn't the case.
My beef with estimating however doesn't end at the group estimation. The story points themselves are also lunacy. The propaganda is that story points ARE NOT time estimates. YET, it is EXPECTED that over time a team will gravitate to a specific velocity so that a product managers can reliably estimate how many story points can be completed within a TIMEFRAME.
I hate to break it to you, but as long as that expectation exists, that is EXACTLY the definition of a unit of time. It is simply being obscured behind some magic number. The reality is that once your teams velocity stabilizes you can easily take your velocity and calculate exactly what the expected time is behind a single story point. And even if you don't, over time, by virtue of the fact that you are able to produce such reliable estimates you are either consciously, or subconsciously doing exactly that.
Story points are there to bridge psychological barriers associated with estimating time. They are a way of getting people who don't want to estimate time, to estimate time. So, group estimation in general seems like a humongous waste.
Arbitrary time boxes, or iterations, or sprints, or whatever you want call them are also stupid. I read an article suggesting taking however many of your highest priority stories that you think you need to take to make a meaningful release, estimate how long you think that should take and make that the size of your iteration. Right now I feel like we shove as much as we can into an iteration and sometimes the resultant feature set of the iteration doesn't result in anything shippable or testable. Or iterations we have so many useful things we could have shipped several smaller builds. Rarely does it feel like a single iteration contains the "right" amount of new features to ship something. And both of the other scenarios present potential pitfalls. So why do it? Sadly, I think the right answer is predictability in the release cycle for PM's and upper management.
Anyway, the end conclusion is this. Agile is supposed to make your team faster. The things I hate above and see slowing down my team may not impact yours. If you truly want to be Agile, you might want to start with a cookie cutter approach and then every few iterations review the process and see if there are meaningful places and ways to improve the process for your specific team and environment. If your team has a phobia of estimating in time, then story points may make sense. If you gets stories from outside dev, then group estimation up front may be more accurate than an individual guesstimate. And if your product is small enough or at a more stable point in its lifecycle, fixed iteration lengths may be perfect.
I'm not trying to say any of my gripe areas are inherently flawed. But I am saying that adhering to any specific aspect of the cookie cutter Agile methodology just because someone says that aspect is critical is wrong. No methodology will be perfect for every team and every product.
Comments
Post a Comment