41–50 of 75 posts
Earlier quoted context omitted.
I absolutely agree that there is no silver bullet. But there are quite a few lead bullets that when aimed accurately can make a real difference. None of them are prescriptive methodologies, though. They are all things like incrementalism, automation, and high quality code.
Incrementalism and automation may be "lead bullets", but "high quality code" is more the target you are shooting at.
Repeat after me: "Scrum is Agile, but Agile is not Scrum" The Agile Manifesto is a simple set of 4 values and 12 principles to aid in building software, that's it. The different signers of the manifesto had different visions of implementing it, Schwaber's was Scrum, Beck's was XP. Saying that a particular methodology isn't a silver bullet therefore it's Agile's fault is a bit like saying science is dead when we dispr…
I don't even agree that Scrum is agile. It's a one-size-fits-all prescriptive methodology with rigidly defined schedules, rituals, and roles. If I had the memory erasing device from the Men In Black movies, I would use it on people who advocate for by-the-book scrum.
But, I feel like the boss is more interested in the methodology than actually finishing our project, which is frustrating. He came from big corporate, went to all the seminars on scrum, and things it's the answer to everything.
In the trenches, methodologies don't get projects done. Dave Thomas's original description of agility seems an accurate description of how code actually gets made--and that description is deliberately not a description of a methodology. I ship working code every day, and my clients are happy, despite the fact that I'm not following any definable methodology. Coding is a messy process. Codebases evolve in many ways: T…
Zed Shaw had a very entertaining semi-satirical bit on this, involving a pulp-fiction cultural reference.
If you see them as a practice, it vary team to team, project to project, time to time. Agile is NOT dead. It was not there at all.
the notion that developers somehow intuitively know agile and management is ruining it is straight up BS. I know plenty of developers who jump on bandwagon x and then without any understanding proceed to screw the pooch for all of us. The drive to look smart is so important to some(maybe most) people that they'll gladly throw the whole team under the bus so they don't have to appear to not know. Believe it or not, I'…
Not in my experience. If there are a bunch of PMs and managers, you're going to find that they keep right on doing management and PM stuff, no matter what Agile Manifesto they think they latched onto.
Management: "This project is going to take you 13 sprints."
Right away, you're in trouble.
Management: "What's with your burn-down rate? We're four days into this sprint and we don't see any progress."
What replaces management is micromanagement.
Manager in the middle of the daily scrum: "Okay, let's go around and get status from everyone."
Yup. Status. For management.
Management: "You need to drop what you're doing and work on feature X for next week."
"But we're in the middle of the sprint."
"Oh, that."
To make it really work, you have to start nuking job positions. And at a big company that is hard.
I've been saying the same thing for quite some time. What I have no found the answer for is how to respond to managers that claim the "agile" process exists to measure developer productivity and accountability. Thoughts?
Agile is about a team and how to make it deliver a product as fast as possible. (that wording can be misinterpreted, but that is for HN audience not PHB)
The key tenet of agile is that people just can't estimate - so sure fine, use magic PM formula - experience, whatever, anything to have a budget approved, but as soon as the real work start, don't bother your developers with it, just get it done ASAP. Agile can help you to estimate better on the long run but not really because of agile directly, but because agile facilitates creating a consistent more uniform development team.
As for developer productivity, at best it will because more apparent who is slacking in a agile team, but if management listen to metric rather than their team lead or the developer themselves all they are measuring is people successful at producing the right metric.
Accountability, that's a corporate issue. When accountability is an issue in a company, it means that somewhere along the line it lost the ability to stay focused on the end product. Your teams are not working together toward the same goal so you need to find "people to blame". Not quite sure how that is related to agile, you do not make people working together by having them stand up everyday 15 minutes with others or fill a whiteboard with stickers.
The problem is that following a methodology like SCRUM, it is possible to produce a shit-ton of metrics, and that's what make managers wet. Those metrics are useful feedback for the team, but if you use it for anything else, you have just recreated the old 90's LOC stupid productivity metrics with fancy looking new terminology.
Earlier quoted context omitted.
I absolutely agree that there is no silver bullet. But there are quite a few lead bullets that when aimed accurately can make a real difference. None of them are prescriptive methodologies, though. They are all things like incrementalism, automation, and high quality code.
Agreed 100%. I like your metaphor of lead bullets. There's no silver bullet that will win a war, but you sure aren't going to win without putting the lead bullets in the right places.
In that metaphor, traditional waterfall is a land mine filled with plutonium shrapnel and anthrax spores.
Earlier quoted context omitted.
I don't even agree that Scrum is agile. It's a one-size-fits-all prescriptive methodology with rigidly defined schedules, rituals, and roles. If I had the memory erasing device from the Men In Black movies, I would use it on people who advocate for by-the-book scrum.
I'm contracting for a small company that uses by-the-book scrum. I like the idea of it and it allows us to easily see what needs to be done. But, I feel like the boss is more interested in the methodology than actually finishing our project, which is frustrating. He came from big corporate, went to all the seminars on scrum, and things it's the answer to everything.
Repeat after me: "Scrum is Agile, but Agile is not Scrum" The Agile Manifesto is a simple set of 4 values and 12 principles to aid in building software, that's it. The different signers of the manifesto had different visions of implementing it, Schwaber's was Scrum, Beck's was XP. Saying that a particular methodology isn't a silver bullet therefore it's Agile's fault is a bit like saying science is dead when we dispr…
I don't even agree that Scrum is agile. It's a one-size-fits-all prescriptive methodology with rigidly defined schedules, rituals, and roles. If I had the memory erasing device from the Men In Black movies, I would use it on people who advocate for by-the-book scrum.
Adding/Removing stuff is the whole purpose of the retrospective, the last feedback loop of scrum, feedback on the process itself. That should be the first thing you add and the last thing you remove.
"By-the-book" scrum is like applying all the GoF Patterns in your project. But yeah, I'm nitpicking, I know what you mean: I see around me plenty of positions for "Scrum master, good at removing impediments, x years line management experience, expert with Microsoft Project, no development experience necessary ..." and I'm thinking WTF ...