151–160 of 382 posts
Earlier quoted context omitted.
But you have to include 'estimates', which ruins everything (in non-trivial cases, yadda, yadda).
Everyone tacitly assigns a time value to "points" anyway.
Earlier quoted context omitted.
> no true Scrum implementation would have property X. That's not the point. Scrum does not say anything how good your organization is. Scrum won't fix these problems. Thus you can have a great Scrum setup and still fail. Of course you can have bad management and a 'true scrum implementation'. Your mistake is to assume that Scrum fixes all kinds of management practices or that 'true scrum' also means all kinds of othe…
What? I don't assume Scrum should or can fix bad management practices. I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire. Scrum doesn't help. Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless. I'd rather use custom, ad hoc, duct-taped together management practices that get th…
What? Scrum fixes all bad management practices?
> I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire.
There we need evidence that it is actually so. Haven't seen any convincing data for that.
> Scrum doesn't help.
The sentence before claimed something else: Scrum makes it worse, quickly.
> Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless.
True, but that's not the case. Scrum can be used with advantage in average to good companies - but the reality is that good software product development is not that easy and has many ways to fail - for example the software could have a huge security problem, it could have architectural problems, it might not earn enough money, etc. - nothing which the scrum process will fix. There are many areas on the management and other levels, which scrum does not address: payment, office, product, market, hiring, ethics, ...
Scrum is really on a tiny framework addressing a few basic things in small team organization.
> I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology.
Personally I'd rather work in a company willing to learn how to successfully develop software in some reproduceable way.
Earlier quoted context omitted.
Are you suggesting Waterfall projects are faster? I don't think you are, but that's how I read your sentence. Also I don't know what IS9000 or BS5750 are but they sound like they had amazing naming committees.
Oh bum I meant ISO9000 BS5750 is the Uk equivalent (and I worked at my first job on a joint project with the BSI on BS5750) But and its a big but some times you need the rigor a properly done waterfall process provides Air traffic control for example. You seriously don't understand the trade offs you make with "agile" vs waterfall? I have done both very successfully.
The issue I've had with every other project management approach is the illusion of structure. I'm not an expert on all or any approach. But my experience is that everyone wants me to be able to project, since absolute certainty, what my team can get done in 12, 24, 36 months. And I can't. No one can. It's all bull shiitake.
Scrum does not solve this problem. But it's honest about it.
It says: "We can't tell you what could be done in 2 years. But we can probably tell you fairly accurately what we can do in the next 2 weeks. And if you let us proceed in these honest 2 week intervals, we'll probably get way more done than if we all agreed to the collective insanity of the waterfall lie."
If you've done waterfall successfully, meaning you delivered a project on time, on budget, and on scope based on your original estimates for all three, then congratulations, you're a mythical beast.
I, for one, cannot do that. I've failed every time. Every team I've worked with has failed every time. I've never seen it work.
My biggest beef with Scrum (and why I think it's a scam) is that they renamed everything, all the processes. Historically, there are three important sides, and roles, for each project. Product management - takes care what the customer wants to have build. Project management - takes care of what is delivered is on schedule and that there is enough material/personnel to build it. Architect/engineering lead - takes care…
I don't think there was anything like the kind of consensus you're portraying about what these things were called. Different shops used their own terms for things; "architect" meant radically different things from one pre-scrum shop to another, "engineer" even more so. "PM" would be used interchangeably; different people from the same company would tell you it was "product" or "project". I don't like renaming things…
So if Scrum (or any other methodology, for that matter) wants to define a new role (to what end?), they should explain, how they are related to these concerns? What tasks that were traditionally done by the triad are supposed to be done by the new role, and why? And moreover, how are the concerns from the triad dealt with in Scrum?
That's what I miss from Scrum. There is no connection to what was before, aside from using waterfall as a straw man (it's not a methodology to begin with). It's an ideology, its own world.
The result of Scrum being an ideology is, somebody who becomes scrum master in Scrum, and effectively doing project management work (in the better case), by default, has no idea that there is a field called "project management", and that he should study that field. So they don't know, for instance, the classic like Fred Brooks.
Earlier quoted context omitted.
The norms aren't always applied badly. I have existence proofs of the norms being applied well in multiple different teams.
Quoting from my parent comment, > "And Scrum is misapplied so often that this clearly applies ..." It's not about always being misapplied. Just that it's misapplied so often that in the larger scale decision making, it's a problem with Scrum. I don't deny there are isolated examples in which Scrum is applied well and works well. I also don't care, unless those examples represent the majority of cases in most average…
We are probably at the point of trading ancedotes, but I'd say in the majority of cases where I have seen it applied it has worked more than it has not. Even a poor implementation has yielded some benefits. And those pieces that have not worked there are reasons why.
Earlier quoted context omitted.
I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally. I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the mid…
I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. How exactly does agile prevent you from talking to your teammates and getting feedback from them?
Earlier quoted context omitted.
My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice. There are no quick fixes. People can im…
My experience is that a good team does a good job. A bad team doesn’t. Of course that's your experience. If you judge teams based on outcomes, then you're going to conclude that teams that succeed are good, and teams that don't must be bad. Unfortunately that offers no guidance in how to become a good team. The goal of software management as a practice is to find patterns of positive behavior that make good teams. Ag…
What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?
Earlier quoted context omitted.
I recognize the disfunction. What happens is that the owner of the backlog becomes the controller of how much time gets spent on what. With feature pressure, it's all new features all the time, with no scope to address debt.
IMO, this is where a good leader (SM, tech lead, whoever - I don't mean a literal manager) advocates for sanity on behalf of the rest of the team. Mostly, this just requires somebody to say "No." every so often in the face of ridiculous demands. As SM, it's my job to ensure that not only will the PO listen to concerns from the team, but the team feels empowered to provide that criticism. If neither of those happens,…
I think the main issue is that people are doing scrum wrong, applying traditional management to an agile process.
Earlier quoted context omitted.
My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice. There are no quick fixes. People can im…
I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally. I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the mid…
Sadly once a team scales up past a certain size its not practical to have developers also going out, finding out what people want built, and handling all the feedback on that. You need someone (or a team of someones) gathering the often conflicting requests coming in, and prioritising them against each other.
Having said that, I do believe once a piece of work makes it to a point where people are likely to start working on it the developers who will be doing that work should be involved in the process. They should understand not only what is being requested, but also why its being requested, in my experience that often results in them suggesting alternative solutions that either bet solve the problem, or provide a 90% solution with significantly less cost. It also gives them the context needed when deciding on technical trade-offs involved in different design choices.