I feel like there's a standard blog post that can be posted in response to opinion pieces like this, and it would be titled "x is not a panacea".
Why I'm not a big fan of Scrum
341–350 of 387 posts
Re: Why I'm not a big fan of Scrum
#342Earlier quoted context omitted.
it is totally reasonable for stakeholders to want to track your progress through a project. If you have a good way of doing that then great, you should use that. Scrum people believe that scrum is the simplest way of measuring that. But at some stage you have to estimate the constituent parts of the project in order to get an idea of its size, and for those estimates to be useful in tracking your progress you have to…
> for those estimates to be useful in tracking your progress you have to do it in advance In advance of what? The only constraint on a useful estimate is that is comes before the task is finished - it needn't be considered as credible at the earliest possible time. Also, your response doesn't really address my post..
(I went to bed so didn't take long to reply before)
I am clearly not expressing myself well. I am talking about a situation where some stakeholders are expecting a complete picture of roughly how large the project is and would like to be able to track how far your team is through this project on a regular basis.
I am putting scrum forward as a methodology for, in as short a time as possible, measuring the size of that project in a meaningful way by merely breaking it up into as small pieces as possible and attaching numbers to those pieces, intended to measure the size of each piece relative to the other pieces, and then over time discovering how long it takes to complete a piece of a given size.
> Assume each person giving different estimates for their own work, but not up front - ongoing as code is written.
The situation I outlined above (the time when scrum helps out) requires you have a stab at estimating all the constituent parts of the project at the beginning of the project.
> an estimate is an estimate, not a commitment. Committing to an estimate makes it a commitment, not an estimate.
True, but the point of estimating in scrum is to assign relative sizes to the pieces of work, not a number of hours, so this isnt a commitment to finish at a specific time but just to say 'I think this is one of the larger pieces of work in this project.' The person I was replying to sounds like they are on a bad team/project where people use their estimates to blame/finger point, and they are ascribing this to scrum as if the team wouldnt be doing this otherwise.
And in case you suggest that estimating without ascribing a time value is not meaningful, it is used to track how far you are through the project, and over time you refine what the finishing date will be given the emerging velocity.
> I might expect a dice roll to be 3.5, I'm not committing to the next roll being 3.5 - analysis should inform policy, in this case expectations informing stated commitments, but the two are not the same.
The analysis comes in discovering the velocity. The expectations evolve over time. But knowing your velocity is of limited use if you dont have an estimate of the overall size of the project.
> The difference is choosing to commit to an estimate you have high confidence in
This is the method for getting confidence in your estimate. You have an overall number of 'points' in the project and you learn how many points you can tackle on average every X weeks.
Re: Why I'm not a big fan of Scrum
#343This was my favorite point out of them all: > What about contributing to open-source software? Reading the code of an important external dependency, such as the web framework your team uses, and working on bugs or feature requests to get a better understanding was not part of any Scrum backlog I've ever seen. Working at various startups, I have developed a methodology of contributing back to open-source projects we u…
Fixing a bug in OS software and consequently avoiding a workaround should count as double points in Scrum
Biggest mistake in scrum is to give points for bug fixes, even if they're not yours.
Re: Why I'm not a big fan of Scrum
#344Been doing scrum forever. Even before it existed. And yet I never had to use points, ever.
Scrum Meeting:
- Follow the list of topics for today
... (may include)
... Show progress and new features
... Get feedback
... Discuss blocking points and resources needs
... Get update on supplier status (if buying/selling anything to 3rd parties)
- Decide what are the priorities for this week
- Schedule the meeting for the next week (send the list of topics you'll talk about)
That's overly trivial. It mostly comes down to schedule a meeting every 1-2 week, show/say current status, repeat...
No need to call that scrum and put fancy names on it.
Re: Why I'm not a big fan of Scrum
#345Earlier quoted context omitted.
That's why I sometimes say at my workplace that we should make our projects in Flash. Faster to make an interactive UI this way and get the approval of the management/customer, no time wasted on useless things like having the program actually work in an efficient, useful and secure way.
I knew some folks in the 90's that prototyped in Shockwave. They did UI and animated uses cases. I was impressed by how quick people got their blob-type people animated use cases that were basically little cartoons. Seemed like way too much work, but I guess it worked for them.
I've learned the hard way just how effective such prototyping tools can be if you only care about... prototypes. Or the visual stuff. Seeing a designer whipping up a running example in 15 minutes in Construct2 that was equivalent to what me and two of my friends spent last 8 hours coding has taught me to respect those tools, at least in particular use cases.
And my point is, if we're focusing only on short-term client-recognizable value, we may as well just make shiny prototypes. Who cares about the pesky internals anyway.
Re: Why I'm not a big fan of Scrum
#346Earlier quoted context omitted.
When I read this I assumed you meant a dial that represents the current level of technical debt, rather than a dial that represents how much technical debt you're allowed to accrue . The other interpretation might be a neat solution. Allow developers to indicate publicly what proportion of the time their last tasks took, they should have taken had there been no technical debt. It would handle the communication from d…
At the very least you need both dials! If you have only the one that management sets, saying how much time to spend refactoring, it will always be at 0. (Okay, they don't literally have to be dials, but there has to be some communication of the kind you describe, so management has some idea how much time is being lost.)
That seems utterly wrong to me.
I'd expect any manager worth is salt to put that at a 10% or 20% (basically anywhere NOT 0) and uses that number as a reminder to devs that part of the job description includes MAINTAINING the system in proper condition, not just piling up new stuff on top of the existing random stuff.
Same as a car needs regular maintenance, a dev project needs regular maintenance.
Re: Why I'm not a big fan of Scrum
#347Earlier quoted context omitted.
That's surely worth something, but it's easier to think of estimates as a 90% outer bound: "I am 90% sure that the task will be completed by date X." Uncertainty can be incorporated, and you don't need to learn a new conversion factor from time to points.
That doesn't work when you can't predict what other tasks might interrupt you between now and date X. That's why estimating in units of effort is much more reliable than units of time. The drawback to units of effort is that estimates eventually bubble up to non-technical people who don't discern the difference between effort and time, and for most projects there are going to be some time-based constraints on the sch…
That doesn't work when you can't predict what other tasks might interrupt you between now and date X
You can still take a probabilistic approach to tasks that might interrupt you.
Re: Why I'm not a big fan of Scrum
#348Earlier quoted context omitted.
One question I have is how does one actually objectively measure technical debt? I mean by anything more than a guess or intuition. Does every singleton/global variable count? Does every comment with a HACK count? What other factors contribute to technical debt, and by how much?
I believe the technical debt could be measured as: The time it takes to change code that is already written. For instance, if you want feature N+1, but to do feature N+1 you need to change feature N, then the amount of time you spend changing feature N is the technical debt. So when you are estimating, you could say: We need to refrob the whozzit to make it compatible with foo 2.0, then that work could be captured as…
I do believe that this N+1 - N captures the idea well.
One issue though: If the requirements have changed, that is not a good metrics.
i.e. We did that theme blue for Iphone, now people wants it to be green AND on windows. It's not necessarily technical debt, it's cancelling everything we've done to make something else entirely (even though it may seem superficially similar).
If the requirements and/or features for N+1 ignore or counter the requirements/features from N, it's not necessary technical debt, it might be you've just got no idea what you're coding and you're running in circle.
Re: Why I'm not a big fan of Scrum
#349Earlier quoted context omitted.
I am Product in a large corporation, and it's a certainly a fine balance. In a previous life, I was a developer, and I dealt with similar issues. I have a lot of respect and empathy for the the Tech team. Therefore, I asked my Tech team to inform me when things are getting out of hand -- that's the responsible Product thing to do . I instituted that technical debt is part of our KPIs. If it's not captured, it's not a…
The problem with raising issues with a framework like Scrum is that despite many share references, most people are in environments which apply Scrum in a slightly different way. We talk about organisations applying Scrum but what we're really referring to are groups of people, and depending on those people, their mindset, their history and their current role requirements - they will use the Scrum model in their own i…
> despite many share references, most people are in environments which apply Scrum in a slightly different way
Exactly. In fact, the linked text is a prime example: it professes to address the "standard Scrum as described in the official guide", and then goes on to condemn the notion of story points. Now, I happen to agree with those story-points criticisms, but guess what: that official guide says nothing about story points at all! :o
Re: Why I'm not a big fan of Scrum
#350Earlier quoted context omitted.
> technical debt is part of our KPIs. If it's not captured, it's not actionable This is where I suspect manager-types and developers have a vigorous divergence in values. Professionals routinely encounter situations where something is wrong and needs to be "actioned" but its wrongness isn't effectively measured by any metric (other than the opinions of the experienced people looking at it). There is a certain species…
On the other hand, at the end of the road - or the rewrite - something should have been gained in terms of money, risk or time. Being shitty is not reason enough, but it's almost always possible to reason and quantify and weigh the cost versus the benefits.
> it's almost always possible to reason and quantify and weigh the cost versus the benefits
I don't think so. As a pretty good analogy, can you quantify the benefit of replacing knob-and-tube wiring in an old house? Now consider that the house across the street keeps its old wiring for the next twenty years without anything bad happening.