"The market is full of similar providers with readymade products for a fixed price."
In my experience, the market is full of people who CLAIM to have "readymade products" and who will ASSURE you that they'll be available for a fixed price.
Neither statement is typically true, however - nor is the idea that even "simple" client problems can be solved without any custom work.
If your firm's clients get mad when an agile process and its risks are explained, what they're really pissed about is that you won't lie to their faces during the sales process anymore...
wallets speak louder than words, and if your clients pay you more than once, they're telling you that you're giving them what they want. Notably, that means that you aren't lying, in their eyes.
Problems with any process can come down to the skill level of developers, but more importantly their attitude and team fit.
For example, if you have a team of like minded developers (with the right attitude), at about the same level. You can give them any process and call it what you want, and they'll achieve what they set out to achieve.
And vise versa, you can have a team of dysfunctional developers and give them any process - yet they'll most likely fail to achieve what they set out for.
Oh, and replace process with framework if that helps...
These are just some examples that wrong causes can get attributed. And yes, a lot of times there is a mismatch between the skills and the expectations of the developers. (Without judgment where the error is.)
> This company faces the problem that customers often complain about a lack of clarity about the process and insufficient quality of the produced websites.
> The department has understaffing and the requests are piling up. The waiting times are very high and there are many complaints.
Sounds like they just paved a new road IN hell, not TO hell...
I certainly grant that the faddishness of Agile methods is a giant problem, and I've grumbled about that before. [1] But I'm not quite getting his point here.
I agree that wholesale adoption of Agile methods is problematic. But one thing every Agile approach has in common is an inspect-and-adapt component, so I'd call wholesale, ritualistic adoption essentially un-Agile. The Extreme Programming people are most explicit about this: they say that by-the-book XP is a good place to start, but that they don't expect anybody to stay there.
But when I read his examples, it seems like he doesn't know that. (Or perhaps that's the people in his examples.) Agile approaches aren't supposed to make everything better. They're supposed to expose the problems with how you're working so you can fix them. In the first case, it exposed the client's lack of interest and the conflicts of interest inherent in their organization. In the second, it made clear that the backlog was unreasonably large versus staff size.
Those aren't unintended consequences of adopting Agile methods. That's what's supposed to happen. Hidden problems are now obvious, which is progress. He seems to suggest that more planning is the solution, but I think just the opposite: with both those fictional shops I'd encourage them to fix the visible problems, and try to do so in ways that shorten feedback loops and help surface other hidden issues.
The problem is that such an organizational change not just exposes the problem: it makes it worse. The intention also usually isn't "let's make things visible". So, the unintended consequence is that things are amplified. And no, in such a situation this will not feel like progress.
I don't suggest more planning. I suggest more profound thinking before changing things.
But why pick on Agile? The organisations clearly had problems that needed to be addressed which went beyond software methodologies. Should they choose a waterfall development model because it might hide the problems better in the short term?
I agree that more thought may be required. But that has nothing to do with Agile. If anything Agile should be commended for bringing the problems into focus.
The problem is that Agile approaches are perceived and promoted as a solution for these kind of problems. And I don't see well known Agile consultants do anything to change this view. That's why I wrote this.
For all X, most X consultants see X as a solution for your problem, almost without regard to the problem.
That isn't an Agile problem, except to the extent that Agile is the flavor of the moment. It's a problem with the industry. And really, with people in general.
Many people want to buy magic beans. Some people will sell magic beans, either because they are cynical jerks (which is rare) or because they don't understand beans all that well (which is common). That doesn't make beans bad.
Right, so the problem is actually with false promotion and not with Agile at all.
If you picked on the people or the culture making these claims it would make more sense to me. You spend time explaining why Agile can't solve a problem no methodology could solve, which seems rather pointless.
Agile and Waterfall, buzzwords in the same class in my world.
It's an odd thing to witness; when management finds a new cure-all for their software development and IT management woes (in my place, these concepts have been extended to DBA's, BA's, Cognos jockeys, etc), as there is an almost childlike enthusiasm and loyalty to this new silver bullet concept.
I feel like the rift occurs right about here, and the blinders go on for the suits while developers and other plebes shake their heads in disgust, as another wave of "paradigm shifting management strategies" sweep their inboxes with mandatory training meetings and promotional material from Gartner and the likes.
The biggest issue is that we all want the same thing: Good Software Development, but the business environment seems to hammer technical workers with the same insanity wrapped in a new packaging, sold down the line from some haughty focus group that contracted an outside company for a $100k "Agile training package".
The only place I've ever managed to get past all of this cruft is when freelancing with a small team directly with a client; this has never happened at my day job.
Never do we worry about specific methodologies, just three people coding and skype / irc / email with clients. Treat people like humans, and learn to say no when appropriate. Good software development is just organized, civil cooperation.
I cant recall the quote but someone once said the best devepopment methodology was to hire a bunch of 10x developers, lock them in a room with a mission statement and leave them to their own devices.
The problem with that is not much unlike waterfall, it provides little to no transparencyfor the employing party, very little accountability and almost no meaningful measureability.
"I cant recall the quote but someone once said the best devepopment methodology was to hire a bunch of 10x developers, lock them in a room with a mission statement and leave them to their own devices."
This is why the majority of start ups fail. Developers have a ridgid vision of product, and then they spend 6/7 months building that product and then at the end you find out no one actually wants that product. Even though the product is good, its just solves a problem no ones interested in.
You need have system to actually work discover if you are creating value. You need something to hold yourself accountable.
In reality most successful start ups have a phase of constant learning, just to discover who are their customers, and what they place value on. And they normally have various metrics to hold themselves accountable.
The best way I have encountered is agile development with experiments to find out what customers actually need. Then metrics to see how people react to changes. If your vision isn't going anywhere, then you need a fundamental rethink which again needs to be tested.
If people are capable of more profound thinking, I'm all for it. But most people don't think in a vacuum; they think when forced by circumstances. And then what they think about are the obvious sources of pain and the obvious actors.
From what I've seen, using scary stories to encourage people to think harder before experimenting just increases fear and inertia. That lengthens feedback loops that are usually too long already. I'd much rather people just try something thoughtfully now and learn from it.
The point being made is that the total system of an organization must be thought about and considered before adopting a new thing. Simply focusing on one thing only will not magically make everything better. Root causes must be addressed and symptoms relieved for the total system to function more smoothly.
I'm happy to upvote authors who want to talk about making the work environment better for everybody. But I'll also add that in my opinion this is a poorly structured essay.
The crux of the problem with process is premature generalization. People see a couple, or 4-5 examples of something, and then want to make a rule for all projects in an organization. There's waaaaaay too much variance for it to work like that.
Readers face a similar problem when reading about success in startups. There's a ton of books on how to make a killer startup -- but most all of them rely on a few examples or a handful of stories. They're long on selection bias and short on usefulness. Orgs do this same thing all the time.
There's also a mismatch in the model many technologist bring to organizing the work and the work itself. Since we work with things that move data around and functions that perform data changes, we begin to feel that a well-run organization is built on certain data and functions. It's simply the analogy that is most convenient for us. In reality, we're finding psychological and social factors are playing a much more important role than sets of rules, processes, or data structured and handled in certain ways. This is a big change for many to accept.
Still, always good to hear more voices. It continues to amaze me how you can take a kick-ass team of 5 guys and conquer the world. You can then scale that up to a kick-ass team of 100 guys -- and create one of the most miserable work experiences ever.
Shameless plug: for those interested in reading some of the stuff I've written about this, check out my blog devoted to the topic: http://tiny-giant-books.com/blog
I've been in groups where the management has said:
"Guess what! We're going to be Agile and do Scrum!"
Whereupon they sent a bunch of PMs off to be trained as Scrum masters.
On the first project, Management then said:
"Okay, go do that Agile stuff. And we think it will take you 13 sprints. Also, here's the stuff you'll be doing in the first sprint..."
Soon after, there were daily management meetings where people's burn-down rates were being discussed, based on the daily status reports that the PMs were collecting.
I share the same sentiment. And I hate to be micromanaged.
In a previous job a manager actually admitted to me that agile was a means to get more control over the developers and approach software development more like factory work, instead of creative work. A few months later I decided to leave, cause I need some sort of creativity in my approach to work, and for creativity I need freedom, not constraints.
Scrum is what good developers seem to do naturally anyway. They plan a little, and talk.
I think that larger projects need more planning than Scrum, but if you look at Scrum's successes you'll see they are largely on projects where a lot of similar prior work had been done. In a sense, the design and up-front thiking came "for free". You usually can't get away with that on something that hasn't been done before.
Creating, optimizing and tuning "processes" with a help of buzzword bullshit is a bread and butter using which the certain layers of management justifies their, otherwise worthless existence.
Developers often find themselves interrupted by needs to participate in processes that are necessary to "track or improve the progress" instead of focusing on making the actual progress happen.
It depends. Is an hour meeting every other week saying, "We tried thing A, it went badly. Let's modify A or stop doing it, instead trying thing B."
At the end of a project, do an overall retrospective, and perhaps make changes for the next project.
Small, incremental experiments and changes are great for process improvement. They can even feed up the chain and promote cross-team experiments, so long as there isn't a top-down directive to implement new thing B at the same time.
Do experiments, keep what works, discard what doesn't.
Its not about tracking for the sake of tracking. Its about finding problems in the development process and improving them. Its helps identify problems, and once identified you can make adjustments and fix it. In our sprints people can 'flag' stories if something is slowing them down, and normally you find it's consistent issue with multiple stories. If you remove it, then you have a instant productivity boost. When we implemented scrum we found a lot of stories were going back and forth between requirements and development stages, so we knew where the problem was.
It's also about guidance. The people implementing the project, probably don't have accurate representation of customer value, only the customer does. Teams often have vision of how things should be, but normally its inaccurate and you implement things with the wrong priorities. The constant feedback from the customer helps ensure the right things are being worked on.
The fix for a dysfunctional bureaucratic organization full of in-fighting is not a better software development process. How it usually plays out is that switching to a better software process is a tiny step in the right direction, but the organization is still dysfunctional and bureaucratic.
(Analogy: the person whose body was riddled with stage 4 cancer started flossing every day. She still died of cancer soon after, but her teeth were cleaner).
30 comments
[ 2.6 ms ] story [ 68.4 ms ] threadIn my experience, the market is full of people who CLAIM to have "readymade products" and who will ASSURE you that they'll be available for a fixed price.
Neither statement is typically true, however - nor is the idea that even "simple" client problems can be solved without any custom work.
If your firm's clients get mad when an agile process and its risks are explained, what they're really pissed about is that you won't lie to their faces during the sales process anymore...
Also the solution always seems to be inappropriate skills of the developers
And vise versa, you can have a team of dysfunctional developers and give them any process - yet they'll most likely fail to achieve what they set out for.
Oh, and replace process with framework if that helps...
"Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques."
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scr...
These are just some examples that wrong causes can get attributed. And yes, a lot of times there is a mismatch between the skills and the expectations of the developers. (Without judgment where the error is.)
With SCRUM dictating that you should have X meetings of Y hours length producing artifacts A, B, C, that sounds like a process to me....
> The department has understaffing and the requests are piling up. The waiting times are very high and there are many complaints.
Sounds like they just paved a new road IN hell, not TO hell...
I agree that wholesale adoption of Agile methods is problematic. But one thing every Agile approach has in common is an inspect-and-adapt component, so I'd call wholesale, ritualistic adoption essentially un-Agile. The Extreme Programming people are most explicit about this: they say that by-the-book XP is a good place to start, but that they don't expect anybody to stay there.
But when I read his examples, it seems like he doesn't know that. (Or perhaps that's the people in his examples.) Agile approaches aren't supposed to make everything better. They're supposed to expose the problems with how you're working so you can fix them. In the first case, it exposed the client's lack of interest and the conflicts of interest inherent in their organization. In the second, it made clear that the backlog was unreasonably large versus staff size.
Those aren't unintended consequences of adopting Agile methods. That's what's supposed to happen. Hidden problems are now obvious, which is progress. He seems to suggest that more planning is the solution, but I think just the opposite: with both those fictional shops I'd encourage them to fix the visible problems, and try to do so in ways that shorten feedback loops and help surface other hidden issues.
[1] http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
I don't suggest more planning. I suggest more profound thinking before changing things.
Edit: you edited your comment.
I agree that more thought may be required. But that has nothing to do with Agile. If anything Agile should be commended for bringing the problems into focus.
The problem is that Agile approaches are perceived and promoted as a solution for these kind of problems. And I don't see well known Agile consultants do anything to change this view. That's why I wrote this.
That isn't an Agile problem, except to the extent that Agile is the flavor of the moment. It's a problem with the industry. And really, with people in general.
Many people want to buy magic beans. Some people will sell magic beans, either because they are cynical jerks (which is rare) or because they don't understand beans all that well (which is common). That doesn't make beans bad.
If you picked on the people or the culture making these claims it would make more sense to me. You spend time explaining why Agile can't solve a problem no methodology could solve, which seems rather pointless.
It's an odd thing to witness; when management finds a new cure-all for their software development and IT management woes (in my place, these concepts have been extended to DBA's, BA's, Cognos jockeys, etc), as there is an almost childlike enthusiasm and loyalty to this new silver bullet concept.
I feel like the rift occurs right about here, and the blinders go on for the suits while developers and other plebes shake their heads in disgust, as another wave of "paradigm shifting management strategies" sweep their inboxes with mandatory training meetings and promotional material from Gartner and the likes.
The biggest issue is that we all want the same thing: Good Software Development, but the business environment seems to hammer technical workers with the same insanity wrapped in a new packaging, sold down the line from some haughty focus group that contracted an outside company for a $100k "Agile training package".
The only place I've ever managed to get past all of this cruft is when freelancing with a small team directly with a client; this has never happened at my day job.
Never do we worry about specific methodologies, just three people coding and skype / irc / email with clients. Treat people like humans, and learn to say no when appropriate. Good software development is just organized, civil cooperation.
The problem with that is not much unlike waterfall, it provides little to no transparencyfor the employing party, very little accountability and almost no meaningful measureability.
This is why the majority of start ups fail. Developers have a ridgid vision of product, and then they spend 6/7 months building that product and then at the end you find out no one actually wants that product. Even though the product is good, its just solves a problem no ones interested in.
You need have system to actually work discover if you are creating value. You need something to hold yourself accountable.
In reality most successful start ups have a phase of constant learning, just to discover who are their customers, and what they place value on. And they normally have various metrics to hold themselves accountable.
The best way I have encountered is agile development with experiments to find out what customers actually need. Then metrics to see how people react to changes. If your vision isn't going anywhere, then you need a fundamental rethink which again needs to be tested.
More planning (at least to me) sounds like "let's break this down into a list of tasks that need doing".
Basically profound thinking sounds like the creative exploration of the idea (and surrounding ideas) as opposed to a dogmatic execution of an idea.
From what I've seen, using scary stories to encourage people to think harder before experimenting just increases fear and inertia. That lengthens feedback loops that are usually too long already. I'd much rather people just try something thoughtfully now and learn from it.
The crux of the problem with process is premature generalization. People see a couple, or 4-5 examples of something, and then want to make a rule for all projects in an organization. There's waaaaaay too much variance for it to work like that.
Readers face a similar problem when reading about success in startups. There's a ton of books on how to make a killer startup -- but most all of them rely on a few examples or a handful of stories. They're long on selection bias and short on usefulness. Orgs do this same thing all the time.
There's also a mismatch in the model many technologist bring to organizing the work and the work itself. Since we work with things that move data around and functions that perform data changes, we begin to feel that a well-run organization is built on certain data and functions. It's simply the analogy that is most convenient for us. In reality, we're finding psychological and social factors are playing a much more important role than sets of rules, processes, or data structured and handled in certain ways. This is a big change for many to accept.
Still, always good to hear more voices. It continues to amaze me how you can take a kick-ass team of 5 guys and conquer the world. You can then scale that up to a kick-ass team of 100 guys -- and create one of the most miserable work experiences ever.
Shameless plug: for those interested in reading some of the stuff I've written about this, check out my blog devoted to the topic: http://tiny-giant-books.com/blog
"Guess what! We're going to be Agile and do Scrum!"
Whereupon they sent a bunch of PMs off to be trained as Scrum masters.
On the first project, Management then said:
"Okay, go do that Agile stuff. And we think it will take you 13 sprints. Also, here's the stuff you'll be doing in the first sprint..."
Soon after, there were daily management meetings where people's burn-down rates were being discussed, based on the daily status reports that the PMs were collecting.
Just another way to micromanage people.
I share the same sentiment. And I hate to be micromanaged.
In a previous job a manager actually admitted to me that agile was a means to get more control over the developers and approach software development more like factory work, instead of creative work. A few months later I decided to leave, cause I need some sort of creativity in my approach to work, and for creativity I need freedom, not constraints.
Without metrics, you can end up at whim of managers gut feeling rather than what actually has been done.
I think that larger projects need more planning than Scrum, but if you look at Scrum's successes you'll see they are largely on projects where a lot of similar prior work had been done. In a sense, the design and up-front thiking came "for free". You usually can't get away with that on something that hasn't been done before.
Developers often find themselves interrupted by needs to participate in processes that are necessary to "track or improve the progress" instead of focusing on making the actual progress happen.
At the end of a project, do an overall retrospective, and perhaps make changes for the next project.
Small, incremental experiments and changes are great for process improvement. They can even feed up the chain and promote cross-team experiments, so long as there isn't a top-down directive to implement new thing B at the same time.
Do experiments, keep what works, discard what doesn't.
It's also about guidance. The people implementing the project, probably don't have accurate representation of customer value, only the customer does. Teams often have vision of how things should be, but normally its inaccurate and you implement things with the wrong priorities. The constant feedback from the customer helps ensure the right things are being worked on.
(Analogy: the person whose body was riddled with stage 4 cancer started flossing every day. She still died of cancer soon after, but her teeth were cleaner).