4 ms·

I've found that "certificated scrum masters", "certificated project managers" and their ilk are the problem. Anyone who says we must follow a specific process

I've found that "certificated scrum masters", "certificated project managers" and their ilk are the problem. Anyone who says we must follow a specific process because that is how agile development is done is missing the point. The actual agile manifesto makes a lot of sense IMO. http://agilemanifesto.org/ http://agilemanifesto.org/

bassman9000 9y ago
Does it? E.g. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that? Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual? Continuous attention to technical excellence and good design enhances agility. And takes time. Ops, sprint's time is over. I guess that refactoring can wait. The best architectures, requirements, and designs emerge from self-organizing teams. Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership. There are definitely good ideas in this manifesto. Ideas that have been applied for years, before even the manifesto came to be. Some others are just wouldnt-it-be-nices.
- bendiksolheim 9y ago
  Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them. What’s the point in delivering something both you and the customer know is wrong, when you can turn around and fix it instead? The point is delivering something of value instead of delivering something you agreed upon half a year ago. Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that? The text says "couple of weeks to a couple of months", not 2/3 weeks. If a task requires a longer attention span than two months, you should probably break it down and deliver something of value earler on. As you say yourself: "the market won’t wait for you to implement them". To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource. What a nice way of motivating people. Every person in a good team is of big value, and cannot easily be replaced by anyone else. Creating a good team requires thought and planning. If Scrum is about diluting the individual, then Scrum is far more wrong than I originally thought. This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual? When you motivate people, and give them tasks they like, they tend to perform their best. Turning people into cogs in a machine, as Scrum seems to like, is not a good way of motivating them. As the manifesto says: value the individual and motivate them, and they will get the job done. And takes time. Ops, sprint's time is over. I guess that refactoring can wait. And that is why you don’t care about sprints. You do one task, preferably as small as possible, and deliver it when it is done. That’s it. I have never understood why I should spend loads of time planning what I should do the next N weeks, when I can just do it instead. Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership. Having strong leaders around a self organizing team is not necessarily problematic. Self organizing teams are more about giving the team freedom to work the way they want. A manager or leader can then contribute by removing obstacles and ensure the team has everything it needs instead of micromanaging everything. The most important part of The Agile Manifesto, in my opinion, is "Individuals and interactions over processes and tools". If you care more about the process than you do of the people in the team, you are doing it wrong. EDIT: formatting.
lillesvin 9y ago
> I've found that "certificated scrum masters", "certificated project managers" and their ilk are the problem. Anyone who says we must follow a specific process because that is how agile development is done is missing the point. If the best argument they can come up with for the process is "because that's how agile development is done" it's because they don't actually understand the process but that doesn't necessarily have anything to do with them being certified or not.
- walshemj 9y ago
  From experience Agile methods require a different and in general more experienced developers - some one fresh out of uni who only studies cs because of the $ is going to struggle
- wnevets 9y ago
  > it's because they don't actually understand the process That's my point. They paid money to get "certificated", get jobs as project managers or scrum masters but have no idea how development or agile actually works. I've have come across a lot of these types of people.
  - lillesvin 9y ago
    But being certified or not doesn't have anything to do with it—you can misunderstand the principles of Scrum just fine on your own. Arguably, certified Scrum Masters would be more likely to actually understand them given their training. And there's a huge difference between "project manager" and "Scrum Master", and if you've met someone that claims to be able to fill both roles in the same team then they're either misunderstanding Scrum horribly or they're that one rare unicorn that managed to make it work that one time. (And, in case you're interested, "certified" is the standard term. In case you're not interested, my apologies for bringing it up.)

bassman9000 9y ago

Does it? E.g. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that? Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual? Continuous attention to technical excellence and good design enhances agility. And takes time. Ops, sprint's time is over. I guess that refactoring can wait. The best architectures, requirements, and designs emerge from self-organizing teams. Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership. There are definitely good ideas in this manifesto. Ideas that have been applied for years, before even the manifesto came to be. Some others are just wouldnt-it-be-nices.

bendiksolheim 9y ago
Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them. What’s the point in delivering something both you and the customer know is wrong, when you can turn around and fix it instead? The point is delivering something of value instead of delivering something you agreed upon half a year ago. Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that? The text says "couple of weeks to a couple of months", not 2/3 weeks. If a task requires a longer attention span than two months, you should probably break it down and deliver something of value earler on. As you say yourself: "the market won’t wait for you to implement them". To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource. What a nice way of motivating people. Every person in a good team is of big value, and cannot easily be replaced by anyone else. Creating a good team requires thought and planning. If Scrum is about diluting the individual, then Scrum is far more wrong than I originally thought. This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual? When you motivate people, and give them tasks they like, they tend to perform their best. Turning people into cogs in a machine, as Scrum seems to like, is not a good way of motivating them. As the manifesto says: value the individual and motivate them, and they will get the job done. And takes time. Ops, sprint's time is over. I guess that refactoring can wait. And that is why you don’t care about sprints. You do one task, preferably as small as possible, and deliver it when it is done. That’s it. I have never understood why I should spend loads of time planning what I should do the next N weeks, when I can just do it instead. Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership. Having strong leaders around a self organizing team is not necessarily problematic. Self organizing teams are more about giving the team freedom to work the way they want. A manager or leader can then contribute by removing obstacles and ensure the team has everything it needs instead of micromanaging everything. The most important part of The Agile Manifesto, in my opinion, is "Individuals and interactions over processes and tools". If you care more about the process than you do of the people in the team, you are doing it wrong. EDIT: formatting.

lillesvin 9y ago

> I've found that "certificated scrum masters", "certificated project managers" and their ilk are the problem. Anyone who says we must follow a specific process because that is how agile development is done is missing the point. If the best argument they can come up with for the process is "because that's how agile development is done" it's because they don't actually understand the process but that doesn't necessarily have anything to do with them being certified or not.

walshemj 9y ago
From experience Agile methods require a different and in general more experienced developers - some one fresh out of uni who only studies cs because of the $ is going to struggle
wnevets 9y ago
> it's because they don't actually understand the process That's my point. They paid money to get "certificated", get jobs as project managers or scrum masters but have no idea how development or agile actually works. I've have come across a lot of these types of people.
- lillesvin 9y ago
  But being certified or not doesn't have anything to do with it—you can misunderstand the principles of Scrum just fine on your own. Arguably, certified Scrum Masters would be more likely to actually understand them given their training. And there's a huge difference between "project manager" and "Scrum Master", and if you've met someone that claims to be able to fill both roles in the same team then they're either misunderstanding Scrum horribly or they're that one rare unicorn that managed to make it work that one time. (And, in case you're interested, "certified" is the standard term. In case you're not interested, my apologies for bringing it up.)