The Failure of Agile(blog.toolshed.com)
blog.toolshed.com
The Failure of Agile
http://blog.toolshed.com/2015/05/the-failure-of-agile.html
260 comments
What's the criteria for a process to be considered "working?"
Fundamentally, since the inception of software, many people have thought that it's complex enough that we need "processes" to manage its delivery. Sort of like we have for manufacturing. Those processes often slow things down, make it difficult to add new features quickly, etc.. Their goal is to give the customer what they expect and have it work though. Agile pretty much says "fuck process, it's not fun" and that's it's whole philosophy. If you've got some really solid and dedicated heroes then you might ship some software that's great and make some money, if you've got some weak links on the team then you might not.
My heuristic has been that when the problem domain is large enough that it's acceptable for members of the team to not have it all in their head, agile starts to have issues. I've also noticed that if you're a "hard problem solver" kind of person, it's less fun.
It does seem like it has success in some domains and such, I'm not sure that it's entirely agile though. The one failing point I can clearly point to with agile is that it appears to be very very difficult to actually, successfully implement, there are so many unhappy people with it.
Fundamentally, since the inception of software, many people have thought that it's complex enough that we need "processes" to manage its delivery. Sort of like we have for manufacturing. Those processes often slow things down, make it difficult to add new features quickly, etc.. Their goal is to give the customer what they expect and have it work though. Agile pretty much says "fuck process, it's not fun" and that's it's whole philosophy. If you've got some really solid and dedicated heroes then you might ship some software that's great and make some money, if you've got some weak links on the team then you might not.
My heuristic has been that when the problem domain is large enough that it's acceptable for members of the team to not have it all in their head, agile starts to have issues. I've also noticed that if you're a "hard problem solver" kind of person, it's less fun.
It does seem like it has success in some domains and such, I'm not sure that it's entirely agile though. The one failing point I can clearly point to with agile is that it appears to be very very difficult to actually, successfully implement, there are so many unhappy people with it.
> the only process that seems to matter is "have someone really good in charge".
I fully agree, and would thus like to recommend this manifesto: http://programming-motherfucker.com
I fully agree, and would thus like to recommend this manifesto: http://programming-motherfucker.com
I agree with you. Usually "agile" is used just as a religion: a mix of wishful thinking plus a way of pushing developers "because of the agile rules".
>"have someone really good in charge."
Pretty much. The person you describes sounds like someone who is willing to learn/improve/grow and not be confined by occupational labels. This leadership trait coupled with self-motivation is always a boon to a team, regardless of the project management style.
Pretty much. The person you describes sounds like someone who is willing to learn/improve/grow and not be confined by occupational labels. This leadership trait coupled with self-motivation is always a boon to a team, regardless of the project management style.
And the someone really good in charge needs to hire a team full of really good people, too. Good process and competent management does not mean you can slot in interchangeable cogs to do the work and expect good results.
Uh,
I can't see how a person can have "goodness" without that goodness having a structure which could be studied, systematized and taught somehow.
Whether that could be made into the kind of system marketed by gurus is naturally a different question and I'd be skeptical about that.
I can't see how a person can have "goodness" without that goodness having a structure which could be studied, systematized and taught somehow.
Whether that could be made into the kind of system marketed by gurus is naturally a different question and I'd be skeptical about that.
> I can't see how a person can have "goodness" without that goodness having a structure which could be studied, systematized and taught somehow.
How do you teach someone an attention to detail, good work ethic, and perseverance?
Those are character traits, not methodologies. If a PM has those 3, he'll be a good PM regardless of anything else. Actually, if someone has those 3, they'll be a good anything.
Agile or something else might make someone better, but they can't determine if someone is good.
How do you teach someone an attention to detail, good work ethic, and perseverance?
Those are character traits, not methodologies. If a PM has those 3, he'll be a good PM regardless of anything else. Actually, if someone has those 3, they'll be a good anything.
Agile or something else might make someone better, but they can't determine if someone is good.
You can teach them. I personally had a lot less attention to detail before studying math. Good work ethic and perseverance can be taught as part of reaching a bigger goal, for example in sports.
I have to be careful to adjust the level of detail down. And, frankly, that's one thing Agile is good for - the use of narrative.
I feel like shop work ( saws, sanding, filing, etc ) and music are better for that but maybe that's bias. Sports teaches some things, but there's an awful lot of sorting going on and some of the "adults" have weird reasons for being there. But I think of character as "what you do when nobody is looking."
Truly great coaches are worth it, though. The best one I ever had told me to get out of sports :)
I feel like shop work ( saws, sanding, filing, etc ) and music are better for that but maybe that's bias. Sports teaches some things, but there's an awful lot of sorting going on and some of the "adults" have weird reasons for being there. But I think of character as "what you do when nobody is looking."
Truly great coaches are worth it, though. The best one I ever had told me to get out of sports :)
Yeah I agree, but I suppose the person has to be willing to learn too. I can point to a couple of specific teachers and lecturers during my school years, and then the technical director at one job, who all influenced me a lot and shaped my work ethic and desire for attention to detail. Colleagues and friends may not have felt as influenced by the same people.
It takes two people. I guess I'm implicitly assuming that the student will be relatively bright and wiling to learn but will be lacking some of those soft skills at first.
How do they have those traits without being taught them? They are 'character' traits, but they are still taught. Surely we can agree you are not born with a good work ethic?
Some traits are inherent to a person. You develop skills over the years but some people "just are" more organised and disciplined.
I find as I get older I get more organized and disciplined. Maybe its because memory isn't as good at absorbing information as effortlessly as it used to be.
I've got more organised as I get older, not because I want to make the world a better place or anything altruistic. Over time I've learned that if you are organised it takes less effort.
I can't see how a person can have "goodness" without that goodness having a structure which could be studied
If Zen and the Art of Motorcycle Maintenance isn't required reading anymore, this could be a sign that it should be.
If Zen and the Art of Motorcycle Maintenance isn't required reading anymore, this could be a sign that it should be.
Can you teach someone to be good at what they do? Of course you can study people who are good at what they do. Perhaps other people who want to become good at what they do can learn from that. However, no one will become good at what they do purely by emulating someone else, since what they do won't be the same thing.
Besides. Things like Agile aren't "observing what people who are good at what they do, do". It's a formalized process based on the ideas that some people who are good at what they do have about WHY they are good at what they do. But do people who are good at what they do really know why they are so? They probably don't! Besides, they are going to mix in all kinds of things that they think they do, or they think they should do, or they think that good people they learned from did, in that formalized process. In the end, the process they describe may sound good to them, but have very little to do with what good people actually do or should do in any particular circumstance.
Besides. Things like Agile aren't "observing what people who are good at what they do, do". It's a formalized process based on the ideas that some people who are good at what they do have about WHY they are good at what they do. But do people who are good at what they do really know why they are so? They probably don't! Besides, they are going to mix in all kinds of things that they think they do, or they think they should do, or they think that good people they learned from did, in that formalized process. In the end, the process they describe may sound good to them, but have very little to do with what good people actually do or should do in any particular circumstance.
That is a ridiculous statement. But that 'definition' there are no good or bad people, good or bad engineers, good or bad project managers, scrum masters, managers or anything.
Not everyone can be 'taught' or just go by a structure. In fact I would strongly argue that those who just go by a predefinied step-by-step structure are always never the 'good' ones.
Not everyone can be 'taught' or just go by a structure. In fact I would strongly argue that those who just go by a predefinied step-by-step structure are always never the 'good' ones.
Can you teach it in less than 20 years? How do you know if you've taught it correctly?
The question isn't whether it is possible to teach it, but whether it is practical.
The question isn't whether it is possible to teach it, but whether it is practical.
I'd guess that the structure would have to be really big to cover all kinds of situations and corner cases.
Still, even someone really good can be rendered unproductive with bad processes and misguided strategy.
If a really good person can be rendered unproductive with bad processes then that person is not in charge.
Not very profound really. Someone really good in charge is most likely hiring really good developers as well.
There is a massive amount of work that goes on outside of writing code which contributes to the success of a project. Without strategic and tactical intelligence you're not going to get anywhere regardless of how good your devs are. In fact, the leadership and management functions are more important than engineering savvy. You can build a good product and fail, but you can also build a mediocre product and succeed. In the latter case, it's not the devs who got you there.
But yes, you're right; good managers make good hires. What's your point?
But yes, you're right; good managers make good hires. What's your point?
I've unfortunately never seen Agile work.
I had one project where we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess. That actually worked well for a year, until management had to fix it, because we weren't Agile. We actually went from 2hrs of meetings/week to almost two full days, I'm not shitting you (to be fair, they went a bit back on that and cut it down to one day fairly quickly, but we still wasted more time by becoming more Agile).
Then my job was to fix others peoples projects from companies that weren't familiar with the technology they used as a consultant. All of them were agile, SCRUM and SCRUM of SCRUM.
And it just didn't work, Ive never seen such dysfunctional teams before. Nothing worked. I realize I've probably only seen the bad side of SCRUM because whenever I got called in they were behind schedule and already fucked up the project anyways.
I think SCRUM can work, maybe, hopefully. But to this day I have yet to see it happen. You have to do it right, and even with basically zero experience with SCRUM I was able to tell that they weren't doing it right, they were just wasting time and not having ANY coordination whatsoever.
I think what others have said here is right, if you have a great team, it will organize itself anyway. If you have a bad team, jumping on the agile bandwagon won't help you.
Then my job was to fix others peoples projects from companies that weren't familiar with the technology they used as a consultant. All of them were agile, SCRUM and SCRUM of SCRUM.
And it just didn't work, Ive never seen such dysfunctional teams before. Nothing worked. I realize I've probably only seen the bad side of SCRUM because whenever I got called in they were behind schedule and already fucked up the project anyways.
I think SCRUM can work, maybe, hopefully. But to this day I have yet to see it happen. You have to do it right, and even with basically zero experience with SCRUM I was able to tell that they weren't doing it right, they were just wasting time and not having ANY coordination whatsoever.
I think what others have said here is right, if you have a great team, it will organize itself anyway. If you have a bad team, jumping on the agile bandwagon won't help you.
> I had one project where we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess.
Actually, having a team evolve its own process that works for the team is agile. That's all and exactly what the Agile manifesto calls for.
> That actually worked well for a year, until management had to fix it, because we weren't Agile.
Having management intervene and institute a process based on external, process-based preferences rather than evaluation by the team of what is and isn't working for the particular team in the particular context is exactly what the Agile Manifesto was a reaction against.
Agile was working for your team, then management came in and -- through an apparent lack of understanding of both what your team was doing, what worked for your team, and what Agile is -- did exactly what Agile is defined in opposition to, and broke it.
Actually, having a team evolve its own process that works for the team is agile. That's all and exactly what the Agile manifesto calls for.
> That actually worked well for a year, until management had to fix it, because we weren't Agile.
Having management intervene and institute a process based on external, process-based preferences rather than evaluation by the team of what is and isn't working for the particular team in the particular context is exactly what the Agile Manifesto was a reaction against.
Agile was working for your team, then management came in and -- through an apparent lack of understanding of both what your team was doing, what worked for your team, and what Agile is -- did exactly what Agile is defined in opposition to, and broke it.
And, since many seem here to be too busy slagging on "Agile" to RTFA, note that the solution being proposed in the article is essentially to try to create a methodology that consists solely of "you have to grow your own methodology using evidence and adaptation", so that there's nothing left to hijack.
Personally I think the author underestimates the ability of management to turn good ideas into checklists wholly divorced from the original idea, but it's at least an attempt.
But the fact that people decry psuedo-Agile with exactly the same criticisms that technically "Agile" was supposed to be is indeed some pretty strong evidence that "Agile" has failed to accomplish its original goals.
Note I say this without regard to whether Agile in either form is "correct". It's just that things are what they are, and there's definitely a great deal of difference between what the Agile Manifesto, a real document that exists in the real world using real words that aren't just "whatever somebody says they are" [1], and "whatever processes some team somewhere developed that may or may not have worked for them and are not being blindly applied to your team because I say that's 'Agile' and you can't object, because it's 'Agile'". I wouldn't get emotional if you want to claim both are bad things and bad ideas, I will only say here that they are not the same idea.
[1]: http://agilemanifesto.org/
Personally I think the author underestimates the ability of management to turn good ideas into checklists wholly divorced from the original idea, but it's at least an attempt.
But the fact that people decry psuedo-Agile with exactly the same criticisms that technically "Agile" was supposed to be is indeed some pretty strong evidence that "Agile" has failed to accomplish its original goals.
Note I say this without regard to whether Agile in either form is "correct". It's just that things are what they are, and there's definitely a great deal of difference between what the Agile Manifesto, a real document that exists in the real world using real words that aren't just "whatever somebody says they are" [1], and "whatever processes some team somewhere developed that may or may not have worked for them and are not being blindly applied to your team because I say that's 'Agile' and you can't object, because it's 'Agile'". I wouldn't get emotional if you want to claim both are bad things and bad ideas, I will only say here that they are not the same idea.
[1]: http://agilemanifesto.org/
Yes, I am guilty of this. I had too many bad experiences, so I never bothered.
This thread in general convinced me, I've done that now :)
I should have done this sooner, but I expected some tl;dr management stuff. If I had done so sooner I could at least have told them they're not Agile, and back it up.
This thread in general convinced me, I've done that now :)
I should have done this sooner, but I expected some tl;dr management stuff. If I had done so sooner I could at least have told them they're not Agile, and back it up.
> we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess.
Interestingly enough, I find that to be something more in line with agile than the way most teams treat agile process. The agile manifesto itself event says:
> Individuals and interactions over Processes and tools
Which in a way makes most agile processes a sort of oxymoron. At the end of the day we just need to understand that we're building software, and we need to do more of what helps us build software and less of what prevents us from building software. Agile (or what people call agile) can do both.
Interestingly enough, I find that to be something more in line with agile than the way most teams treat agile process. The agile manifesto itself event says:
> Individuals and interactions over Processes and tools
Which in a way makes most agile processes a sort of oxymoron. At the end of the day we just need to understand that we're building software, and we need to do more of what helps us build software and less of what prevents us from building software. Agile (or what people call agile) can do both.
This.
Basically, our process before was that the PM would plan a release with the customer and a few senior devs, distribute the tickets needed for that release to team members, and then the team shifted them around between eachother trying to make it work, sometimes we couldn't fit some tickets in, sometimes we were able to fit a bit more in. These were fairly long cycles like up to 3 months or even longer in one rare case.
Then we became Agile. When you have 20 devs on a project, your standups won't take 5 minutes. Estimating the tickets won't be done in an hour because too many dependencies. They tried to split teams up into two, but then team A had no idea what team B was doing and there was just way more overhead.
Most people will look at you in a weird way when you tell them you had 20 devs in one team. But what can I say, it certainly worked better than the other things we tried.
As I said, I'm sure it can work, but you need to do it right, and we certainly didn't.
Basically, our process before was that the PM would plan a release with the customer and a few senior devs, distribute the tickets needed for that release to team members, and then the team shifted them around between eachother trying to make it work, sometimes we couldn't fit some tickets in, sometimes we were able to fit a bit more in. These were fairly long cycles like up to 3 months or even longer in one rare case.
Then we became Agile. When you have 20 devs on a project, your standups won't take 5 minutes. Estimating the tickets won't be done in an hour because too many dependencies. They tried to split teams up into two, but then team A had no idea what team B was doing and there was just way more overhead.
Most people will look at you in a weird way when you tell them you had 20 devs in one team. But what can I say, it certainly worked better than the other things we tried.
As I said, I'm sure it can work, but you need to do it right, and we certainly didn't.
> Which in a way makes most agile processes a sort of oxymoron.
There's no "sort of" about it. Rigid, context-blind processes -- whether sold as "Agile" or not -- are exactly what Agile is a reaction against.
No process is Agile, and a team is only Agile insofar as it evaluates what works for the particular team in the particular context and places that ahead of preconceptions about what process should be that derive from other sources.
There's no "sort of" about it. Rigid, context-blind processes -- whether sold as "Agile" or not -- are exactly what Agile is a reaction against.
No process is Agile, and a team is only Agile insofar as it evaluates what works for the particular team in the particular context and places that ahead of preconceptions about what process should be that derive from other sources.
because we weren't agile
It sounds to me like you were agile, but not Agile. Capital A Agile has seminars and books and you can interview Agile PM candidates easily and people can feed confident "going forwards". Lowercase a agile has a lot of intangibles and can be hard to replicate if you have a turnover of staff. Both can suck, both can work.
I was once told I couldn't remove a task from the board and dump it in the bin because that's not how Agile works, but what could be more agile than quickly cutting out work we didn't need to do?
It sounds to me like you were agile, but not Agile. Capital A Agile has seminars and books and you can interview Agile PM candidates easily and people can feed confident "going forwards". Lowercase a agile has a lot of intangibles and can be hard to replicate if you have a turnover of staff. Both can suck, both can work.
I was once told I couldn't remove a task from the board and dump it in the bin because that's not how Agile works, but what could be more agile than quickly cutting out work we didn't need to do?
I also use the Agile vs. agile distinction. Big-A Agile is a product, while little-a agile is a philosophy. If you're blindly subscribing to the processes espoused by thought leaders, you're going to have problems no matter how good the philosophy. You need to be constantly evaluating, retrospecting, and iterating on your processes to make sure that they're the best they can be for your particular situation.
Good point, edited my post.
What you've described is not agile in my opinion nor does it conform to the principles laid out by the manifesto. I worked in what I consider to be a truly agile/scrum team and we had two week iterations with five minute standups each morning and a thirty minute demo on the last Friday of each iteration followed by an hour of planning poker to estimate items on the backlog. Then we left for the weekend, ready to start a new iteration the following Monday. The rest of our time was direct development and we (three developers 1 QA and 1 PM) created a great SAAS product in nine months from start to finish. The best part was that we were making an agile planning tool so when we got far enough into the project, we started using our project to plan its own development.
> if you have a great team, it will organize itself anyway. If you have a bad team, jumping on the agile bandwagon won't help you
I agree, however most teams fall somewhere between great and bad. Also, there may be many different stake holders and changing requirements in a project. In these circumstances some discipline is needed to ensure that developer hours are used wisely. The options here are:
1. No process. Rely on the team to self-organize.
2. A waterfall like process (All planning up front, long term development goals
3. An agile like process (Short term development benchmarks, daily stand ups, constant re-evaluation of goals)
Of the three, the first works well for a very small team, or a truly excellent teams. A bad team is going to fail no matter which is chosen. But, for teams in between, or for projects where there is confusion about requirements, I'd argue that option three is clearly the best of the bunch.
I agree, however most teams fall somewhere between great and bad. Also, there may be many different stake holders and changing requirements in a project. In these circumstances some discipline is needed to ensure that developer hours are used wisely. The options here are:
1. No process. Rely on the team to self-organize.
2. A waterfall like process (All planning up front, long term development goals
3. An agile like process (Short term development benchmarks, daily stand ups, constant re-evaluation of goals)
Of the three, the first works well for a very small team, or a truly excellent teams. A bad team is going to fail no matter which is chosen. But, for teams in between, or for projects where there is confusion about requirements, I'd argue that option three is clearly the best of the bunch.
Like any other set of knowledge, the real skill lies on knowing when and how to apply it. When asked to describe our process, I summarize it as "minimalist Scrum." To us, that means using some aspects of Scrum (small team sizes, prioritized work backlogs, and daily standups) and ignoring others (anything with the word "sprint" in it, pre-planned release cycles, and velocity estimation/tracking). Our culture is more built around continuous deployment.
We've found the process that works well for us, and I encourage everyone to be thoughtful and consider many approaches as they try to do the same.
We've found the process that works well for us, and I encourage everyone to be thoughtful and consider many approaches as they try to do the same.
All Scrum does is make it harder to lie. On great teams this seems redundant and on incompetent teams it's not that useful. However, on average teams someone is often lying which can cause a lot of issues.
I have seen Agile approaches work (in particular, I've seen and been on some great Extreme Programming teams), but I believe your Agile experience is the most common these days. What I see most often is bullshit labels slapped on the old idiocy.
However, I think this is mostly bunk: "If you have a great team, it will organize itself anyway."
I think you can get to some level of adequacy that way. But doing better requires conscious practice, a shared understanding of how the team works, and a disciplined approach to inspecting and adapting. That just doesn't happen with the laissez faire sort of self-organization.
Most of the assorted Agile processes came out of teams acting like that and then saying, "Hey, let's define and publish what we're doing." You're right that jumping on an Agile bandwagon doesn't help, but there are other ways to make use of Agile philosophy and practices than blind bandwagon-jumping.
However, I think this is mostly bunk: "If you have a great team, it will organize itself anyway."
I think you can get to some level of adequacy that way. But doing better requires conscious practice, a shared understanding of how the team works, and a disciplined approach to inspecting and adapting. That just doesn't happen with the laissez faire sort of self-organization.
Most of the assorted Agile processes came out of teams acting like that and then saying, "Hey, let's define and publish what we're doing." You're right that jumping on an Agile bandwagon doesn't help, but there are other ways to make use of Agile philosophy and practices than blind bandwagon-jumping.
We use our version of SCRUM with pretty good results for our maintenance and small features. For large projects though, we wind up with a bit of BDUF just to get a grip on what we're building. That ultimately morphes into our agile process as we get closer to the release.
It's certainly not the "right" way to do it, but it works very well for us.
Shops that are 100% full-on SCRUM seem to me to be mired in process, which is ironic.
It's certainly not the "right" way to do it, but it works very well for us.
Shops that are 100% full-on SCRUM seem to me to be mired in process, which is ironic.
I've used some form of agile process on every project that I've ever worked. On every project we've shipped features at a good pace and managed to keep on top of test coverage and technical debt. There's obviously a lot of people that have had bad experiences though. How do these problems manifest on the projects where you've seen agile fail?
[deleted]
Most of the agile problems I've seen have been organizations cargo-culting things they've read, rather than trying to actually be dexterous. Big-A agile versus, well, "agile".
Scrum has been the largest offender - squashing discussion in standups, allowing scrum to erode QA process, rote meetings that take 50% of the week, story points and refusing to discuss timetables in hours when absolutely needed, reporting status multiple times, having others estimate tasks who are not doing those tasks, etc.
These organizations that have done so have been some of the least agile, and waterfall-esque organizations can even be better. (They planned up front well, they changed a few minor things in the middle maybe, but cut out the overhead).
Scrum has been the largest offender - squashing discussion in standups, allowing scrum to erode QA process, rote meetings that take 50% of the week, story points and refusing to discuss timetables in hours when absolutely needed, reporting status multiple times, having others estimate tasks who are not doing those tasks, etc.
These organizations that have done so have been some of the least agile, and waterfall-esque organizations can even be better. (They planned up front well, they changed a few minor things in the middle maybe, but cut out the overhead).
Scrum has the particularly noxious side effect of driving underground any sort of drive to improve and to learn new things. An engineer in a Scrum team is an engineer, has his or her lane, and is largely expected to stay in it. Learning? Branching out? No, get your promised tickets done this week. That concerns me; while it's possible for a Scrum-based shop to invest in its people, it's not part of Scrum to really do so. And the people are what matter, at the end of the day, so I find it rather dehumanizing.
(This is a big part of why I'm moving towards consulting--so I can invest in me more often.)
(This is a big part of why I'm moving towards consulting--so I can invest in me more often.)
We use Scrum and I disagree with everything you said. It is not reflected in my experiences at all.
But that's the problem of arguing from anecdote.
But that's the problem of arguing from anecdote.
why is this "Scrum" specific? Sounds like working a 9-5 at most companies regardless of their development process.
> why is this "Scrum" specific?
Scrum's pre-committed units of work across the team promotes this; its one of the reasons that many groups prefer flow-based methods (which can support regularly-timed releases simply by shipping the features that are ready at the time of the release cutoff) rather than Scrum's cycle-based method.
Scrum's pre-committed units of work across the team promotes this; its one of the reasons that many groups prefer flow-based methods (which can support regularly-timed releases simply by shipping the features that are ready at the time of the release cutoff) rather than Scrum's cycle-based method.
I don't see how this is true. If you're building slack into your cycle there should be regular investment time available that a pure flow-based system wouldn't have.
If there's no slack in your sprint schedule, well there's your problem.
If there's no slack in your sprint schedule, well there's your problem.
In my experience, Scrum's work-unit factorization encourages thinking of developers as spherical cows that need no personal development, with slack as a concession to reality that patches the damage Scrum itself causes. And Slack is generally considered to be for technical investment, though, not personal investment.
A good manager could think past that, for sure, but I've never encountered a good manager that felt Scrum was good or necessary for their teams.
A good manager could think past that, for sure, but I've never encountered a good manager that felt Scrum was good or necessary for their teams.
"If you're building slack into your cycle"
Then management comes over and asks why you're slacking off.
Then management comes over and asks why you're slacking off.
I think most teams that implement/try to implement agile/scrum/xp and end up disliking it / failing at it completely miss the point of the retrospective step - and thus, skip that step.
Without the retrospective, it's just modified waterfall.
Without the retrospective, it's just modified waterfall.
We had them in about half of the scrum shops. The retrospective, in my experience, was yet another meeting where things didn't get done either. "We are having too many meetings" was usually not popular either. Don't get me wrong, I like good meetings that result in actionable decisions.
My personal view on scrum is it attempts to trick a software team into micro-managing itself, and it usually results in feeling like kindergarten as a result.
The better shops have been "agile", but not "Agile", and just did what worked, and made changes when they needed to.
I don't think a retrospective is essentially required, but the ability to change and throw out things that don't work -- and have only the right amount of meetings and to talk about the things that matter rather than a template - is.
When a retrospective is to make the team feel they have a voice to make changes, and in reality, nothing changes, that makes the retrospective itself rather soul-crushing theatre, so everybody just says nice things and hopefully nobody gets thrown under the bus when "what could have gone better" is discussed - but often, that still happens.
Scrum is, to me, something people pick when managers don't want to manage.
I like release-early release-often, MVP (in small doses), see http://michaeldehaan.net/post/118860078737/the-rock-paper-sc..., and many of those concepts. But I also don't like the idea that requirements constantly shift - which means architecture can't plan ahead.
I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. If you have a PM that doesn't allow time for such things, it can be rough.
(Not everything fits in two week blocks either)
My personal view on scrum is it attempts to trick a software team into micro-managing itself, and it usually results in feeling like kindergarten as a result.
The better shops have been "agile", but not "Agile", and just did what worked, and made changes when they needed to.
I don't think a retrospective is essentially required, but the ability to change and throw out things that don't work -- and have only the right amount of meetings and to talk about the things that matter rather than a template - is.
When a retrospective is to make the team feel they have a voice to make changes, and in reality, nothing changes, that makes the retrospective itself rather soul-crushing theatre, so everybody just says nice things and hopefully nobody gets thrown under the bus when "what could have gone better" is discussed - but often, that still happens.
Scrum is, to me, something people pick when managers don't want to manage.
I like release-early release-often, MVP (in small doses), see http://michaeldehaan.net/post/118860078737/the-rock-paper-sc..., and many of those concepts. But I also don't like the idea that requirements constantly shift - which means architecture can't plan ahead.
I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. If you have a PM that doesn't allow time for such things, it can be rough.
(Not everything fits in two week blocks either)
> Scrum is, to me, something people pick when managers don't want to manage.
This is a really good observation, I think, and lines up with my own experiences--every incapable manager I've ever had thought Scrum was a great idea. The ones I've known have been very linear thinkers with a tendency towards restricted domains of thinking, and Scrum reminds me a little bit of Orwell's "if you can't say it, you can't think it" idea. Scrum gives you a vocabulary that, if you hide in it, requires you to confront many fewer things and make fewer choices.
They're almost all the wrong choices, I think, but there are strains of manager that find choices anathema in the first place and so I can see the appeal.
This is a really good observation, I think, and lines up with my own experiences--every incapable manager I've ever had thought Scrum was a great idea. The ones I've known have been very linear thinkers with a tendency towards restricted domains of thinking, and Scrum reminds me a little bit of Orwell's "if you can't say it, you can't think it" idea. Scrum gives you a vocabulary that, if you hide in it, requires you to confront many fewer things and make fewer choices.
They're almost all the wrong choices, I think, but there are strains of manager that find choices anathema in the first place and so I can see the appeal.
>>I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc.
Sounds like your teams were underestimating task effort.
>>If you have a PM that doesn't allow time for such things, it can be rough.
Anything's rough with a shitty PM, which is what you've described.
Sounds like your teams were underestimating task effort.
>>If you have a PM that doesn't allow time for such things, it can be rough.
Anything's rough with a shitty PM, which is what you've described.
I think one problem is that Agile gives a numerical value to how much work has been done: story points.
Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
> I think one problem is that Agile gives a numerical value to how much work has been done: story points.
Agile does not. Even a number of the defined methodologies sold as "Agile" do not (Scrum, for instance, does not mention either user stories or story points -- it does indicate that backlog items will have estimates that are less-specific when the item is farther out in the tail of the work queue and more refined when it is near the head of the queue, but doesn't specify the terms in which those estimates should be gathered.)
> Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
If it is fairly stable (which should also be measured if it is going to be used), it is a meaningful number for planning what items are within capacity for a sprint. It may not be meaningful for other purposes even then.
Agile does not. Even a number of the defined methodologies sold as "Agile" do not (Scrum, for instance, does not mention either user stories or story points -- it does indicate that backlog items will have estimates that are less-specific when the item is farther out in the tail of the work queue and more refined when it is near the head of the queue, but doesn't specify the terms in which those estimates should be gathered.)
> Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
If it is fairly stable (which should also be measured if it is going to be used), it is a meaningful number for planning what items are within capacity for a sprint. It may not be meaningful for other purposes even then.
That's a problem with management. All of the agile/scrum resources I've read exclaim, in big bold letters, 'THESE ARE NOT METRICS TO EVALUATE PERFORMANCE; THEY ARE FOR ESTIMATION OF EFFORT'
Head shops have big signs stating that the goods for sale there are strictly for smoking tobacco too.
I've seen average story points reported that way too -- but I think it's just that people don't know not to report all the decimal places that Excel gives them.
> Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
Ok, explain this to me. Why is this not a meaningful number?
Story points are essentially hours and generally in the shops I worked in, they are converted to hours. If something takes longer, the hours are adjusted.
So really, that's a metric for maximum hours worked ... why is that not a good metric?
If someone is on a remote team and they're expected to work 40 hours a week, why is measuring the maximum hours they were on the job a bad metric?
Ok, explain this to me. Why is this not a meaningful number?
Story points are essentially hours and generally in the shops I worked in, they are converted to hours. If something takes longer, the hours are adjusted.
So really, that's a metric for maximum hours worked ... why is that not a good metric?
If someone is on a remote team and they're expected to work 40 hours a week, why is measuring the maximum hours they were on the job a bad metric?
What? No. Glad I don't work for you.
Nearly all developers I know estimate time (and storypoints) by some (often linear) function of volume and complexity. Volume estimation is usually not very difficult, but complexity is very tricky (and dynamic too). Estimating developer work hours by any proxy that depends on complexity will introduce a margin of uncertainty so large as fo render the number meaningless.
I'd think by and large you would evalute remote workers by theit work output, not by estimating how much time they've spent.
I'd think by and large you would evalute remote workers by theit work output, not by estimating how much time they've spent.
> I'd think by and large you would evalute remote workers by theit work output
Which is what? Lines of code? I think that's even worse.
How do you determine how much work to assign someone if estimates are meaningless? How do you determine if someone is productive or is doing one hour's work per week?
Aside from insults, I don't really see any answers. Have you ever been in a PM role?
Again, if you adjust estimates as you're doing the work ... as in, it's more complex than you thought, so you adjust the estimate ... why are estimates a bad metric and what metric (something that can be quantified) would you recommend?
Which is what? Lines of code? I think that's even worse.
How do you determine how much work to assign someone if estimates are meaningless? How do you determine if someone is productive or is doing one hour's work per week?
Aside from insults, I don't really see any answers. Have you ever been in a PM role?
Again, if you adjust estimates as you're doing the work ... as in, it's more complex than you thought, so you adjust the estimate ... why are estimates a bad metric and what metric (something that can be quantified) would you recommend?
Uhm, I think you're reading my post a bit uncharitably. I don't think I insulted you, for instance.
I never said that estimates were meaningless, but they are tools for planning with high intrinsic uncertainty, and translating that uncertainty to evaluations gives unfairness. People are very sensitive to (perceived) unfairness and the idea that they will be treated so will give rise to resentment, not to mention incentives to game the system and overestimate. Hence endless bickering about points.
If agile failed for any reason it was misunderstanding human psychology.
Personally I don't think human performance in creative professions is well suited to quantified analysis, especially when team efforts are involved. So I don't really have an answer there.
I never said that estimates were meaningless, but they are tools for planning with high intrinsic uncertainty, and translating that uncertainty to evaluations gives unfairness. People are very sensitive to (perceived) unfairness and the idea that they will be treated so will give rise to resentment, not to mention incentives to game the system and overestimate. Hence endless bickering about points.
If agile failed for any reason it was misunderstanding human psychology.
Personally I don't think human performance in creative professions is well suited to quantified analysis, especially when team efforts are involved. So I don't really have an answer there.
Nope, the features always won in priority because the project manager / scrumlords would keep it that way, and didn't value the technical plumbing that would actually increase velocity and reduce churn and improve code quality.
But yes, it's a people problem.
But yes, it's a people problem.
> Don't get me wrong, I like good meetings that result in actionable decisions.
Which is what a retrospective _should_ be! "what went wrong, what went right, how can we change our process to keep those wrong things from happening again?" It doesn't necessarily need to be a meeting. The introspection needs to happen, though. No matter what type of process you have - if it's not being constantly reevaluated for efficacy, it's just cargo cult.
Which is what a retrospective _should_ be! "what went wrong, what went right, how can we change our process to keep those wrong things from happening again?" It doesn't necessarily need to be a meeting. The introspection needs to happen, though. No matter what type of process you have - if it's not being constantly reevaluated for efficacy, it's just cargo cult.
Very true, it's not the format but the goal of adapting that matters. If you can discuss and fix your problem in a stand-up, do it. If you need to sit down for half an hour, take time for it. If you need 1/2 day to really understand what is happening and get a shared view to decide what to do, plan it. But make sure that you take action.
And I think that, in turn, might be a symptom of how large organizations often implement scrum. Scrum's meant to be an alternative to - even an inversion of - the traditional way of running software projects. But as it passes through the kaleidoscope of corporate culture, it's all too easy for scrum to just become a layer of makeup on top of the traditional approach.
For example, Scrum has a "scrum master" role that is most certainly NOT that of being a project manager. But usually a project manager gets placed in that role, and is naturally going to interpret the role by finding and then exaggerating analogies between it and the stuff they learned in PMP class. In the more traditional structure that the "project manager" role comes from, the PM owns and dictates a lot of the processes that the team follows, including daily meetings and suchlike.
This is in direct conflict with the idea that the entire scrum team owns and collaboratively determines the processes that they follow. And that idea is fundamental to the inspect/adapt process that the sprint retrospective is supposed to facilitate.
For example, Scrum has a "scrum master" role that is most certainly NOT that of being a project manager. But usually a project manager gets placed in that role, and is naturally going to interpret the role by finding and then exaggerating analogies between it and the stuff they learned in PMP class. In the more traditional structure that the "project manager" role comes from, the PM owns and dictates a lot of the processes that the team follows, including daily meetings and suchlike.
This is in direct conflict with the idea that the entire scrum team owns and collaboratively determines the processes that they follow. And that idea is fundamental to the inspect/adapt process that the sprint retrospective is supposed to facilitate.
Retrospective has, in my experience, been a candidate for biggest 'agile' time-sink and a great example of how agile 'evangelists' and scrum masters are so inward-looking and process-focussed that they get in the way of work.
What happens at these retrospectives?
I've only been at ones that work. I don't see how you could ask these questions and have it be a time sink: https://www.scrumalliance.org/community/articles/2014/april/...
I've only been at ones that work. I don't see how you could ask these questions and have it be a time sink: https://www.scrumalliance.org/community/articles/2014/april/...
The problem is that in many large organizations, the retrospective is a political game where the objective is to find and blame a person (or persons) who caused the team to underdeliver on the sprint. That mindset is an anathema to the sorts of honest constructive discussions that are required to meaningfully improve process. Instead the meeting turns into a toxic political mess that ends up disadvantaging the most talented developers on the team.
You clearly haven't worked with people who like the sound of their own voices quite so much as I have.
>> What went well during the sprint cycle? >> What went wrong during the sprint cycle? >> What could we do differently to improve?
I have had Agile Evangelists, who are supposed to be good at making this stuff streamlined, turn around and say "Everyone needs to come up with five things in each category, then we'll go through and discuss them all, deciding on the most important things to change at the end"
In a team that was already too large (15ish people) I watched that eat an entire afternoon and produce no useful output on more than one occasion. In the team I was on (four, five?) it still seemed to take hours.
I know, I know, they were probably doing it all wrong, this is just my experience of one workplace.
I'm not saying it can't be done right, just that it doesn't seem to be a magic bullet and can devolve into navel-gazing.
>> What went well during the sprint cycle? >> What went wrong during the sprint cycle? >> What could we do differently to improve?
I have had Agile Evangelists, who are supposed to be good at making this stuff streamlined, turn around and say "Everyone needs to come up with five things in each category, then we'll go through and discuss them all, deciding on the most important things to change at the end"
In a team that was already too large (15ish people) I watched that eat an entire afternoon and produce no useful output on more than one occasion. In the team I was on (four, five?) it still seemed to take hours.
I know, I know, they were probably doing it all wrong, this is just my experience of one workplace.
I'm not saying it can't be done right, just that it doesn't seem to be a magic bullet and can devolve into navel-gazing.
From my limited experience, scrum can work (defining 'work' as 'make people more productive'), and even in the classic situations that give rise to the flaccid variety (I work for a blue-chip media corporation which is just in the last couple of years trying to build a modern engineering culture basically from scratch, and it happens to work).
A pretty important point for making scrum work, however, is aggressive timeboxing of everything. If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.
I understand that this is not always an option in malfunctioning corporate environments; but Kanban/XP/programming motherfkerism wouldn't fly either in those situations.
A pretty important point for making scrum work, however, is aggressive timeboxing of everything. If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.
I understand that this is not always an option in malfunctioning corporate environments; but Kanban/XP/programming motherfkerism wouldn't fly either in those situations.
>> If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.
When I rule the world, as they say, every meeting will contain only the people it needs to, "I don't feel this is relevant to my work or that I can contribute" will be the best reason not to attend and time limits will be aspirational in as much as everyone will aspire to beat them by as much as they can.
Unfortunately, as a contractor, I can suggest these things but not mandate them.
When I rule the world, as they say, every meeting will contain only the people it needs to, "I don't feel this is relevant to my work or that I can contribute" will be the best reason not to attend and time limits will be aspirational in as much as everyone will aspire to beat them by as much as they can.
Unfortunately, as a contractor, I can suggest these things but not mandate them.
In that case, part of the retrospective should probably be 'these meetings aren't actually solving anything, are actively getting in the way of getting things done. how can we do this meeting differently?' ;)
After a while we fired the Agile Evangelist and became a whole lot more agile :)
In my experience, either:
- A few people end up discussing some minor point only of interest to them while everyone else stares into space
- Every retrospective ends up being the same as the previous one: it's like someone recorded a meeting 2 years ago and plays it back every 8 weeks
- Things that went well are all internal; things that went badly are all other teams' fault (this can't always be true)
Yes, I realise those aren't really agile issues, just a symptom of having a relatively poorly defined meeting with lots of people.
- A few people end up discussing some minor point only of interest to them while everyone else stares into space
- Every retrospective ends up being the same as the previous one: it's like someone recorded a meeting 2 years ago and plays it back every 8 weeks
- Things that went well are all internal; things that went badly are all other teams' fault (this can't always be true)
Yes, I realise those aren't really agile issues, just a symptom of having a relatively poorly defined meeting with lots of people.
>>A few people end up discussing some minor point only of interest to them while everyone else stares into space
Mostly the manager's minions and pets talk, generally in a softer tone more towards appreciation bordering sycophancy. The remaining fear to give any genuine feedback, fearing retribution. If some one does speak they are taken as non team players who will be handled appropriately the next raise/promotion cycle.
There fore no one talks.
Mostly the manager's minions and pets talk, generally in a softer tone more towards appreciation bordering sycophancy. The remaining fear to give any genuine feedback, fearing retribution. If some one does speak they are taken as non team players who will be handled appropriately the next raise/promotion cycle.
There fore no one talks.
The scrum master or even "team lead" is supposed to catalyze things a little bit in those situations. A lot of times there's a culture of "everyone knows about it, but nobody will say anything about it because they're afraid of the axe," where "it" is the thing that's horribly wrong.
These are clear symptoms of not having retrospectives facilitated in a proper Wat. A good facilitator uses different exercises, has people focused on a fixed scope or time period to catch learning points, supports a team in coming up with actions that they can do immediately and that are small enough to finish on a short notice.
>>Without the retrospective, it's just modified waterfall.
This is true. But retrospectives will never work in any reasonably sized team, the reason is middle managers don't like being told or like being talked about their work in front of everybody, or being told to change something. Ego plays a big role in these things and they don't like being given feedback or advice, especially because these managers tend to think themselves as people in authority as all knowing and in complete control.
This is human psychology, developed over thousands of years. Masters never took feedback from slaves, so why should the modern incarnation of the older masters take advice from the current day slaves?
This is true. But retrospectives will never work in any reasonably sized team, the reason is middle managers don't like being told or like being talked about their work in front of everybody, or being told to change something. Ego plays a big role in these things and they don't like being given feedback or advice, especially because these managers tend to think themselves as people in authority as all knowing and in complete control.
This is human psychology, developed over thousands of years. Masters never took feedback from slaves, so why should the modern incarnation of the older masters take advice from the current day slaves?
The mindset enshrined in this comment will certainly kill any attempt to be Agile. But while common, thankfully it's not universal.
It takes a different mindset to make changes happen (agile or not). If people resists changing their mindset, nothing will happen and we keep struggling. That's a choice I'd rather not do.
It's even worse, since you don't retrospect it's not even modified. It becomes a fixed process, and non adaptable processes simply do not work.
I've never seen an agile article recommend rote meetings taking 50% of the week. Anyone even remotely interested in agility would call that an anti-pattern. I don't think it's a case of organizations blindly cargo-culting, but rather an inability to embrace agile.
Nobody who has any kind of interest in selling or implementing Agile anywhere would. That doesn't mean that the reality of the situation doesn't cause it to happen.
"squashing discussion in standups"
No, that's one of the really good things it's done. Half the time I'm not involved in any way in those discussions, so moving them out of the status meeting means I don't have to stand around listening to stuff that doesn't concern me.
No, that's one of the really good things it's done. Half the time I'm not involved in any way in those discussions, so moving them out of the status meeting means I don't have to stand around listening to stuff that doesn't concern me.
This makes the meetings basically useless to me, especially when there are so many other meetings important things don't get discussed.
It's oppressive.
It's oppressive.
Every time I read one of those posts, it makes me go back to http://programming-motherfucker.com and I enjoy it just a bit more than the previous time.
The article starts with the current note - agile as it was preached was never actually achieved, and most companies and practioners are doing it "wrong" (for varying degrees of wrong).
But then it goes downhill with proposing yet another model that will people will try to adopt verbatim, and again, experience failure to implement.
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
What really killed agile fwiw, where the consultants, going from development team to team, peddling false hope, snake oil, and tedious time zapping process that people learnt to game rather than actually deliver.
Of course, someone will pop up saying agile is awesome, they love the daily scrums, the project is fab, the sky is blue, etc. Question is: can it be better?
But then it goes downhill with proposing yet another model that will people will try to adopt verbatim, and again, experience failure to implement.
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
What really killed agile fwiw, where the consultants, going from development team to team, peddling false hope, snake oil, and tedious time zapping process that people learnt to game rather than actually deliver.
Of course, someone will pop up saying agile is awesome, they love the daily scrums, the project is fab, the sky is blue, etc. Question is: can it be better?
In my experience, the people who say agile is awesome would likely say any process is awesome. Because the true awesomeness they are experiencing comes from being on a good team. After wading through years and years of agile, even working for a major agile tool maker for a while, I've come to the conclusion what process you choose isn't that important. Get a good, passionate, driven team together, and they'll figure out how to kick ass. Without that ingredient, nothing else matters.
> In my experience, the people who say agile is awesome would likely say any process is awesome. In my experience, the people who say agile is awesome would likely say any process is awesome.
Agile is awesome because its not a process, but a set of principles which addresses exactly the problem that context-blind adoption of processes creates that makes good teams mediocre and bad teams worse.
Most of the processes sold in a context-blind manner as "Agile" suck, but they are a recreation of exactly what the Agile Manifesto was a reaction against.
Agile is awesome because its not a process, but a set of principles which addresses exactly the problem that context-blind adoption of processes creates that makes good teams mediocre and bad teams worse.
Most of the processes sold in a context-blind manner as "Agile" suck, but they are a recreation of exactly what the Agile Manifesto was a reaction against.
That's true in theory but rarely in reality. The reality is Agile is a process, often a rigid one. I find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant. I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.
> The reality is Agile is a process, often a rigid one.
No, the reality is that Agile is not a process, though there are a number of different processes sold as "Agile". (The most common now seems to be Scrum as defined in the Scrum guide and a number of variants on it; for a while XP was somewhat prominent as well.)
> find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant.
Teams that do that are Agile: that's exactly and all of what the Agile Manifesto says.
> I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.
The thing is the "Agile movement" consists of two separate and opposed forces: one (and the origin of "Agile") is people promoting exactly the behavior you mention characterizes good teams, the second (and the thing you seem to have a problem with) is people using the name that the first group came up with to promote exactly what the first group is reacting against -- rigid, context-blind adoption of externally-developed process (largely as a reaction against the threat posed by the good ideas of the first to the second groups pre-existing business of selling rigid, context-blind processes.)
No, the reality is that Agile is not a process, though there are a number of different processes sold as "Agile". (The most common now seems to be Scrum as defined in the Scrum guide and a number of variants on it; for a while XP was somewhat prominent as well.)
> find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant.
Teams that do that are Agile: that's exactly and all of what the Agile Manifesto says.
> I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.
The thing is the "Agile movement" consists of two separate and opposed forces: one (and the origin of "Agile") is people promoting exactly the behavior you mention characterizes good teams, the second (and the thing you seem to have a problem with) is people using the name that the first group came up with to promote exactly what the first group is reacting against -- rigid, context-blind adoption of externally-developed process (largely as a reaction against the threat posed by the good ideas of the first to the second groups pre-existing business of selling rigid, context-blind processes.)
But the reality is almost everyone who "does agile" has rigidly adopted scrum, xp, kanban, etc. That is the reality most of us face. Just because a group got together 14 years ago and created a hypothetical scenario that essentially no one follows doesn't seem all that relevant to me.
And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?
The end reality is we have an entire industry built around that stupid manifesto. Sure, it's not what they wanted, but it's what we all got. We would have been better off without it.
And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?
The end reality is we have an entire industry built around that stupid manifesto. Sure, it's not what they wanted, but it's what we all got. We would have been better off without it.
> And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?
Because while there are lots of people who won't understand that with an explanation, and some people who get it intuitively and don't need an explanation even with all the noise from people selling one true way, there's also lots of people in the middle who benefit from people selling there one-size fits all approaches not being the only voice in the marketplace of ideas.
> The end reality is we have an entire industry built around that stupid manifesto
No, we have an industry that existed long before the manifesto built around selling canned, context-blind process and jumping on anything even mildly popular to sell it that, predictably, when the manifesto calling for exactly the opposite of what that industry sold became popular, jumped on that to sell exactly the same thing they'd always been selling.
> We would have been better off without it.
No, I think that there are lots of people who have learned something from the Agile Manifesto, writings actually addressing how to implement its principles that don't amount to context-blind process, and related movements (Lean software development, etc.) and applied the ideas to improve teams and make software in a better way.
Most developers -- before and after the manifesto -- work in places where management is operated with shallow knowledge and poor respect for their staff and buying whatever consultants are selling in terms of process, sure, but that's not the fault of the Agile Manifesto
Because while there are lots of people who won't understand that with an explanation, and some people who get it intuitively and don't need an explanation even with all the noise from people selling one true way, there's also lots of people in the middle who benefit from people selling there one-size fits all approaches not being the only voice in the marketplace of ideas.
> The end reality is we have an entire industry built around that stupid manifesto
No, we have an industry that existed long before the manifesto built around selling canned, context-blind process and jumping on anything even mildly popular to sell it that, predictably, when the manifesto calling for exactly the opposite of what that industry sold became popular, jumped on that to sell exactly the same thing they'd always been selling.
> We would have been better off without it.
No, I think that there are lots of people who have learned something from the Agile Manifesto, writings actually addressing how to implement its principles that don't amount to context-blind process, and related movements (Lean software development, etc.) and applied the ideas to improve teams and make software in a better way.
Most developers -- before and after the manifesto -- work in places where management is operated with shallow knowledge and poor respect for their staff and buying whatever consultants are selling in terms of process, sure, but that's not the fault of the Agile Manifesto
You do make some good points. Perhaps my frustration at the Agile Manifesto is misplaced. I'd still argue that the canned processes that emerged due to the creation of the Agile manifesto are amongst the worst ones available, but for sure I have no real proof for that other than my own personal experience.
"Software is hard, people are hard"
^ this. Agile is only a set of principles set out to help write flexible software. It in no way made the actual writing of software, the gathering of requirements, the effort of design, easier; it simply gave us a process to follow that could potentially help avoid tedious re-writes. At the end of the day it's up to the people to put in the effort to make good software
^ this. Agile is only a set of principles set out to help write flexible software. It in no way made the actual writing of software, the gathering of requirements, the effort of design, easier; it simply gave us a process to follow that could potentially help avoid tedious re-writes. At the end of the day it's up to the people to put in the effort to make good software
Agile does not give us a process, because Agile is not a process (it is a set of principles that can be applied to evaluate processes in the context of a particular team, but its 100% not a process.)
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
People are soft and squishy. Too much rigid process pevents taking advantage of that squishiness. A complete lack of process will result in those squishy humans just producing a gooey puddle.
For every piece of process:
People are soft and squishy. Too much rigid process pevents taking advantage of that squishiness. A complete lack of process will result in those squishy humans just producing a gooey puddle.
For every piece of process:
* what problem does it solve?
* what side-effects does it have?
* are the side-effects good or bad, and how much so?
* are there alternative solutions with better side-effects?> agile as it was preached was never actually achieved, and most companies and practioners are doing it "wrong" (for varying degrees of wrong).
You know Scientology, Amway and most other cult-like phenomena say the same thing: It's never the "system" that's wrong, if it's not working it means you're doing something wrong. You missed something, you didn't try it hard enough, you didn't do it like X, Y, Z.
You know Scientology, Amway and most other cult-like phenomena say the same thing: It's never the "system" that's wrong, if it's not working it means you're doing something wrong. You missed something, you didn't try it hard enough, you didn't do it like X, Y, Z.
Two problems for me:
[1] What bothers me is that people writing the manifesto admit that they are wrong, and they start the whole thing in the same way all over again. All over again!
[2] I have also seen practitioners and consultants that never did a single-frickin-project in their short lifetime, but preaching success. That's how you get wrong - theory and practice are often 2 very different things. And when the shit hits the fan, people say "you are doing the agile wrong". Alright.. teach me master, and admit how wrong you were 14 years ago. p.s. Apologies for the rant.
[2] I have also seen practitioners and consultants that never did a single-frickin-project in their short lifetime, but preaching success. That's how you get wrong - theory and practice are often 2 very different things. And when the shit hits the fan, people say "you are doing the agile wrong". Alright.. teach me master, and admit how wrong you were 14 years ago. p.s. Apologies for the rant.
What really "killed" Agile are two things: the absence of good guidance on how to apply Agile principles as opposed to canned methodologies, and the fact that most people don't have the skill to apply the principles without guidance.
There is some good guidance it there, but you have to get outside of the Agile "brand" for most of it, since much of the work on evaluating methods and other aspects of higher-level metamethodology that fits in with Agile principles is associated with "Lean" rather than "Agile".
There is some good guidance it there, but you have to get outside of the Agile "brand" for most of it, since much of the work on evaluating methods and other aspects of higher-level metamethodology that fits in with Agile principles is associated with "Lean" rather than "Agile".
Agile was created by the consultants. It's a bit disingenuous to claim they also killed it.
http://agilemanifesto.org
http://agilemanifesto.org
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
This depends on the environment. Working for a consulting company, where time spent on the project is billed to a customer and the project has a fixed budget, Process is needed to make sure the project is estimated and executed properly, and the arse-covering helps to guarantee that you get paid when the customer makes changes mid-way through that increase the project costs.
It would be fantastic to work on projects with open-ended budgets and collaboration with customers to figure out what the software should be as it's being developed, but in the real world I don't think that is often possible. It's not just consultant/client relationships; even in big companies where IT is given a budget from upper management you have the same situation. Management won't approve a budget without a detailed description of the deliverable, and IT can't exceed the budget or deliver something other than what was promised.
Waterfall, for all of its drawbacks, handles this situation well. The problem is that no one wants to pay for all of the paperwork and management overhead it requires to function properly.
This depends on the environment. Working for a consulting company, where time spent on the project is billed to a customer and the project has a fixed budget, Process is needed to make sure the project is estimated and executed properly, and the arse-covering helps to guarantee that you get paid when the customer makes changes mid-way through that increase the project costs.
It would be fantastic to work on projects with open-ended budgets and collaboration with customers to figure out what the software should be as it's being developed, but in the real world I don't think that is often possible. It's not just consultant/client relationships; even in big companies where IT is given a budget from upper management you have the same situation. Management won't approve a budget without a detailed description of the deliverable, and IT can't exceed the budget or deliver something other than what was promised.
Waterfall, for all of its drawbacks, handles this situation well. The problem is that no one wants to pay for all of the paperwork and management overhead it requires to function properly.
Someone pointed this out to me long ago, and I've yet to see anything that disagrees with it:
Every time you see someone succeeding at Scrum, it's because they're also doing most of XP.
Maybe we need to go back to our roots. I know that several elements of XP have only recently clicked for me and I feel foolish for having taken so long (but nearly everybody I know is still struggling with those aspects too, so I'm in great company). And I was exposed to XP in '99, which means it took me 15 years.
Every time you see someone succeeding at Scrum, it's because they're also doing most of XP.
Maybe we need to go back to our roots. I know that several elements of XP have only recently clicked for me and I feel foolish for having taken so long (but nearly everybody I know is still struggling with those aspects too, so I'm in great company). And I was exposed to XP in '99, which means it took me 15 years.
> Most of it exists as arse-covering material anyway.
I think bean counter types throughout the business world truly believe there must be some secret fairy dust you can use to transform mid/low competency people into high competency people, and dysfunctional teams into highly functional teams. It's about wages. It's essentially a delusion that you can take cheap, socially lower status people and substitute for more expensive people as long as you have the right fairy dust.
The mentality works to a degree for certain disciplines. It works with McDonalds employees. You can apply management theory and systems to an infantry brigade and get good results from lower grade enlisted men.
The model simply does not map over to the "creative" professions and crafts. But managerial types are often averse to the idea that software engineering is a proper profession on par with their own, not commodity, and must command high pay. They prefer to keep seeking the right fairy dust.
I think bean counter types throughout the business world truly believe there must be some secret fairy dust you can use to transform mid/low competency people into high competency people, and dysfunctional teams into highly functional teams. It's about wages. It's essentially a delusion that you can take cheap, socially lower status people and substitute for more expensive people as long as you have the right fairy dust.
The mentality works to a degree for certain disciplines. It works with McDonalds employees. You can apply management theory and systems to an infantry brigade and get good results from lower grade enlisted men.
The model simply does not map over to the "creative" professions and crafts. But managerial types are often averse to the idea that software engineering is a proper profession on par with their own, not commodity, and must command high pay. They prefer to keep seeking the right fairy dust.
I downvoted you for this bit
>>socially lower status people
>>socially lower status people
I still remain totally unconvinced that 'Agile' is broken, or has failed. I have worked in places that do FakeAgile, and places that do GoodAgile, and there are two conclusions:
1. Bad companies and practices will not be magically fixed by applying 'Agile' or whatever other methodology you want. 2. When companies do agile development well, it is effective at solving some of the worst problems that software development faces.
Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology. I'll tell you what our process is.
- Spend a couple of hours planning a sprint of work. Two weeks, in our case. During that planning meeting, look at the backlog of features and tickets that the product manager has built up. Identify tasks we can reasonably accomplish in that time frame, ensure we have enough information to start, and discuss each one so we have a clear idea of what it involves.
- Make sure that those tasks are customer-visible features wherever possible. It's not always the case that this can be done, but it helps to provide feedback.
- 10-minute daily stand-up to discuss any issues and communicate who's working on what. Also time for the product manager to feed back any information from outside the team.
- Work on some tickets. Review the code. Pass them through QA. Deploy them. Let the product owner receive feedback from customers.
- Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve.
That's the core of Scrum, and I don't see what's wrong with it. The problem arises when it's abused; story points as burndown charts, or productivity monitored in terms of 'number of tickets finished', or whole-company stand-ups, or whatever.
Agile development works well if you're agile. It's not a set of rules that must be followed – it's a set of guidelines that can help to improve the development process. If you are performing useless, time-consuming overhead tasks, then you are not doing Agile – end of story.
1. Bad companies and practices will not be magically fixed by applying 'Agile' or whatever other methodology you want. 2. When companies do agile development well, it is effective at solving some of the worst problems that software development faces.
Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology. I'll tell you what our process is.
- Spend a couple of hours planning a sprint of work. Two weeks, in our case. During that planning meeting, look at the backlog of features and tickets that the product manager has built up. Identify tasks we can reasonably accomplish in that time frame, ensure we have enough information to start, and discuss each one so we have a clear idea of what it involves.
- Make sure that those tasks are customer-visible features wherever possible. It's not always the case that this can be done, but it helps to provide feedback.
- 10-minute daily stand-up to discuss any issues and communicate who's working on what. Also time for the product manager to feed back any information from outside the team.
- Work on some tickets. Review the code. Pass them through QA. Deploy them. Let the product owner receive feedback from customers.
- Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve.
That's the core of Scrum, and I don't see what's wrong with it. The problem arises when it's abused; story points as burndown charts, or productivity monitored in terms of 'number of tickets finished', or whole-company stand-ups, or whatever.
Agile development works well if you're agile. It's not a set of rules that must be followed – it's a set of guidelines that can help to improve the development process. If you are performing useless, time-consuming overhead tasks, then you are not doing Agile – end of story.
> Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology.
Scrum is a useful development methodology with some teams in some contexts, and is often a reasonable process starting point for team seeking to apply Agile principles in software development.
> Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve.
This (without the "sprint" and "when its done" or the specification of the 1-hour timebox) is really the core of Agile: regularly evaluate the results you are getting applying your current methodology with your current team to your current set of challenges, determine what is working well and what isn't, and revise your processes accordingly to make them better.
If anything else is viewed as "core" and non-negotiable, your organization isn't Agile and, in regard to those particular areas, you are elevating process over results.
Scrum is a useful development methodology with some teams in some contexts, and is often a reasonable process starting point for team seeking to apply Agile principles in software development.
> Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve.
This (without the "sprint" and "when its done" or the specification of the 1-hour timebox) is really the core of Agile: regularly evaluate the results you are getting applying your current methodology with your current team to your current set of challenges, determine what is working well and what isn't, and revise your processes accordingly to make them better.
If anything else is viewed as "core" and non-negotiable, your organization isn't Agile and, in regard to those particular areas, you are elevating process over results.
> and revise your processes accordingly
This. So much this.
Your process is one of the things you change. You hack it. You can try a change for one iteration and evaluate at the end of the iteration.
If you have a Defined Process(TM) - of whatever flavor - you're missing a big part of agile, perhaps even the most important part.
Let your process adapt to your people, your environment, your situation, your project, and your goals. Eliminate everything that isn't useful; shorten to the minimum everything that is useful.
Even if you started with Agile(TM) as defined by a Scrum Master(TM), but you're willing to change the process as you find out what doesn't work or is wasteful, you can still converge on something pretty good. You just have to keep tweaking the process, paying attention to what works and what doesn't.
Or to put it in XP terms: Pay attention to pain, not just in your technical areas but also in your processes and procedures.
This. So much this.
Your process is one of the things you change. You hack it. You can try a change for one iteration and evaluate at the end of the iteration.
If you have a Defined Process(TM) - of whatever flavor - you're missing a big part of agile, perhaps even the most important part.
Let your process adapt to your people, your environment, your situation, your project, and your goals. Eliminate everything that isn't useful; shorten to the minimum everything that is useful.
Even if you started with Agile(TM) as defined by a Scrum Master(TM), but you're willing to change the process as you find out what doesn't work or is wasteful, you can still converge on something pretty good. You just have to keep tweaking the process, paying attention to what works and what doesn't.
Or to put it in XP terms: Pay attention to pain, not just in your technical areas but also in your processes and procedures.
"That's the core of Scrum, and I don't see what's wrong with it."
Depends on what you are trying to do. Add some buttons and a new report feature to some 100K code base with 5 programmers? Sure, why not. Get changes in front of the customer quickly, backtrack or iterate, and so on.
Software for a medical device? Not so fast, bucko. Endless regulations (for good reasons), extended test cycles, changes require changes to hardware, long sales cycles, well, scrum is not your friend. Neither is waterfall, or whatever strawman someone wants to erect. I've worked hard projects (military hw/sw) and no well defined process gets you there. It comes back to the real core of agile, which the OP emphasizes - inspect and adapt.
2 week sprints (or any other number) makes no sense if you are held to an external release schedule (work for TV, sports? You are going to be releasing on that schedule, not your 2 week sprints, sorry). Do you have subcontractors? Scrum usually doesn't work there, especially if they are making hardware. Work in a truly 'requirements change' environment (TV, war, etc). Ya, sorry, not going to work to the end of the sprint no matter what, no requirements changes allowed. Conversely, is someone making hardware for you, or are you making hardware? Changing something could change delivery dates and costs by months to years. You can't just treat every 2 weeks as a new day (so to speak), changing things willy nilly. Want to build a search engine or a cloud infrastructure? Lots of planning required - you can't just add features every two weeks.
Scrum is a tool in the toolbox - if the problem you are trying to solve fits its assumptions it'll work fine. But it sticks it head in the sand about things that it considers hard. For the right domain that is brilliant - requirements are hard, let's get ideas in front of the customer sooner, because they don't know what they want anyway. Scrum says 'schedules are hard' and decides not to do schedules. Great if you don't actually need schedules, but if you need to deliver a hw/sw system for a business opening (say), well, you better be scheduling. And soft starts are not an option (as I said before, I used to work for the DoD, now I work for TV - you mostly can't soft start war or the Super Bowl). In military work every meeting is basically risk assessment - what are the risks I am facing, and you manage and mitigate from there. Risk is not in the vocabulary of scrum, and it is hard to think about things when you don't have a vocabulary for it. When I start something or work something I think in terms of 'goals, strategies, and tactics.' Ya, military again. But it works. Goals usually don't change, and you need to choose strategies and tactics to meet those goals. But people get wound around the axle 'we must do X' - well, not if X doesn't meet the goal. 'but X is agile'. I don't care, it's the wrong thing in this case. Scrum, as practiced, doesn't give us the vocabulary for that (the linked article does in the 'think and adapt' paradigm, but that is still a bit too loosey goosey for me). What are we trying to do (goals), how are we going to do it (strategies), and what are we doing today (tactics) is a pretty good, but imperfect way to organize your thoughts.
Scrum can work in places in those things, sometimes. Have a mobile app that is digesting and displaying the data of your system? Maybe/probably that can be scrum (maybe not if medical - regulations, extensive testing, and so on).
Brooks is still right - there is no silver bullet. There is no alternative except think, observe, pull the levers for which you have control, observe the feedback loop, adapt, and continue on. If you need a schedule, make one, and then adapt a risk control methodology to keep costs and other creeps in line.
Scrum is a system. Where else in engineering would we have 8 or 10 rules where we argue that would result in a functioning system? No where. Why expect it to work in running projects. The agile manifesto didn't. They expected thinking and agility, not fixed 2 week sprints, no matter what. People over process. Scrum is a process. Enough said?
Depends on what you are trying to do. Add some buttons and a new report feature to some 100K code base with 5 programmers? Sure, why not. Get changes in front of the customer quickly, backtrack or iterate, and so on.
Software for a medical device? Not so fast, bucko. Endless regulations (for good reasons), extended test cycles, changes require changes to hardware, long sales cycles, well, scrum is not your friend. Neither is waterfall, or whatever strawman someone wants to erect. I've worked hard projects (military hw/sw) and no well defined process gets you there. It comes back to the real core of agile, which the OP emphasizes - inspect and adapt.
2 week sprints (or any other number) makes no sense if you are held to an external release schedule (work for TV, sports? You are going to be releasing on that schedule, not your 2 week sprints, sorry). Do you have subcontractors? Scrum usually doesn't work there, especially if they are making hardware. Work in a truly 'requirements change' environment (TV, war, etc). Ya, sorry, not going to work to the end of the sprint no matter what, no requirements changes allowed. Conversely, is someone making hardware for you, or are you making hardware? Changing something could change delivery dates and costs by months to years. You can't just treat every 2 weeks as a new day (so to speak), changing things willy nilly. Want to build a search engine or a cloud infrastructure? Lots of planning required - you can't just add features every two weeks.
Scrum is a tool in the toolbox - if the problem you are trying to solve fits its assumptions it'll work fine. But it sticks it head in the sand about things that it considers hard. For the right domain that is brilliant - requirements are hard, let's get ideas in front of the customer sooner, because they don't know what they want anyway. Scrum says 'schedules are hard' and decides not to do schedules. Great if you don't actually need schedules, but if you need to deliver a hw/sw system for a business opening (say), well, you better be scheduling. And soft starts are not an option (as I said before, I used to work for the DoD, now I work for TV - you mostly can't soft start war or the Super Bowl). In military work every meeting is basically risk assessment - what are the risks I am facing, and you manage and mitigate from there. Risk is not in the vocabulary of scrum, and it is hard to think about things when you don't have a vocabulary for it. When I start something or work something I think in terms of 'goals, strategies, and tactics.' Ya, military again. But it works. Goals usually don't change, and you need to choose strategies and tactics to meet those goals. But people get wound around the axle 'we must do X' - well, not if X doesn't meet the goal. 'but X is agile'. I don't care, it's the wrong thing in this case. Scrum, as practiced, doesn't give us the vocabulary for that (the linked article does in the 'think and adapt' paradigm, but that is still a bit too loosey goosey for me). What are we trying to do (goals), how are we going to do it (strategies), and what are we doing today (tactics) is a pretty good, but imperfect way to organize your thoughts.
Scrum can work in places in those things, sometimes. Have a mobile app that is digesting and displaying the data of your system? Maybe/probably that can be scrum (maybe not if medical - regulations, extensive testing, and so on).
Brooks is still right - there is no silver bullet. There is no alternative except think, observe, pull the levers for which you have control, observe the feedback loop, adapt, and continue on. If you need a schedule, make one, and then adapt a risk control methodology to keep costs and other creeps in line.
Scrum is a system. Where else in engineering would we have 8 or 10 rules where we argue that would result in a functioning system? No where. Why expect it to work in running projects. The agile manifesto didn't. They expected thinking and agility, not fixed 2 week sprints, no matter what. People over process. Scrum is a process. Enough said?
I completely agree that Scrum isn't suitable for all software development, and that there's no silver bullet. If it doesn't work, then that's totally okay – don't use it. Doesn't mean it's 'broken' or 'dead', as so many claim.
Scrum is a system in the sense that it provides a framework upon which you can build a sensible process. Not every aspect works for every environment, and that's totally fine! It's the key principle of agile development.
I think what's happened is that so many places have completely ballsed-up the implementations of processes like Scrum, and that's given it a bad name. People naturally push back against that. I do find it a little frustrating that the two issues are conflated so often.
As an aside – at it's core, Scrum is just a process that breaks development work down into small, actionable parts. In most cases, that's an internal implementation issue, and is still compatible with meeting fixed external deadlines. Again, it's situation-dependent, but that's why it's advisable to avoid agile-by-numbers and implement the parts that work.
Scrum is a system in the sense that it provides a framework upon which you can build a sensible process. Not every aspect works for every environment, and that's totally fine! It's the key principle of agile development.
I think what's happened is that so many places have completely ballsed-up the implementations of processes like Scrum, and that's given it a bad name. People naturally push back against that. I do find it a little frustrating that the two issues are conflated so often.
As an aside – at it's core, Scrum is just a process that breaks development work down into small, actionable parts. In most cases, that's an internal implementation issue, and is still compatible with meeting fixed external deadlines. Again, it's situation-dependent, but that's why it's advisable to avoid agile-by-numbers and implement the parts that work.
> That's the core of Scrum, and I don't see what's wrong with it.
Where does professional development come in, my true Scotsman?
Where does professional development come in, my true Scotsman?
From what I've seen, professional development in a scrum shop means moving from junior developer to people manager.
If you want to keep coding, you're expected to leave within two years.
If you want to keep coding, you're expected to leave within two years.
Agreed (though maybe not "two years"), and that was what I was getting at. Scrum is not a system for investing in people--and we need to do that. It's a fairly exploitative mode of organization and this industry's largely uncritical adoption of it is something we don't look at particularly often or with much real gusto.
Scrum is not a system for investing in people
You're right – Scrum is a process framework for developing software.
That is totally, absolutely, 100% orthogonal to professional development. I work in a mostly-Scrum environment as I described; that doesn't preclude research, or conference attendance, or any other form of professional development.
Bad culture is bad culture, regardless of development methodology.
You're right – Scrum is a process framework for developing software.
That is totally, absolutely, 100% orthogonal to professional development. I work in a mostly-Scrum environment as I described; that doesn't preclude research, or conference attendance, or any other form of professional development.
Bad culture is bad culture, regardless of development methodology.
What you're essentially telling your engineers is that A) doing their job has nothing to do with getting better at their job, and B) if they want to advance beyond the junior engineer level, they will have to do so on their own time. I've seen this referred to as "terminal juniority."
Having a development process that does not produce senior engineers is a problem, even if you try to make up for it by providing a conference attendance budget and a Safari books membership. At the very least, such a process unfairly penalizes those with large personal time commitments.
Having a development process that does not produce senior engineers is a problem, even if you try to make up for it by providing a conference attendance budget and a Safari books membership. At the very least, such a process unfairly penalizes those with large personal time commitments.
Fantastic post, and I agree. I've always been in a weird place professionally because I came out of school at a somewhat-above-junior level and so I've been in an interesting position to watch companies try to mold developers. There's that "five years of experience"/"one year of experience, five times" thing people sometimes refer to, and Scrum seems tailored to doing the latter.
Terminal juniority is an amazing term for that. Thanks.
Terminal juniority is an amazing term for that. Thanks.
Thanks, though I can't take credit for it. I stole it from an epic anti-agile jeremiad on Quora: http://www.quora.com/Why-do-some-developers-at-strong-compan...
Ha, it sounded familiar. I don't always agree with Michael but he's a great dude.
[deleted]
What do you consider to be professional development? I'm not clear why you think it doesn't fit in there.
Just a quick rant about SCRUM:
I have found that SCRUM is used to allow everyone in the company to believe that the development team is at maximum productivity. It encourages conservative estimation, low-ambition projects, and generally business-friendly, highly measurable pace (with metrics that don't really matter but sound good).
If you have to resort to SCRUM, your company is probably already toxic (or else the last company your VP of Engineering worked at was toxic).
When you don't have good product/market fit, everything the development team builds looks like a miss (because it is) even if the technology works very well. Thus, good product management is crucial.
In the greater scheme of things it matters very little if every single features ships two months late. The most important thing is that the product gets closer and closer to the product/market fit bullseye.
SCRUM insulates developers from managers who would constantly change their mind and thrash the team around willy nilly, but it also insulates developers from the realities of the business.
With good product management, everyone buys into the challenge of product market fit, and everyone wants to apply the right blend of qualitative and quantitative approaches to build the right thing at the right time. SCRUM is fine if everyone is already cynical and there is widespread mistrust, but if you want real team cohesion it's a bad idea.
I have found that SCRUM is used to allow everyone in the company to believe that the development team is at maximum productivity. It encourages conservative estimation, low-ambition projects, and generally business-friendly, highly measurable pace (with metrics that don't really matter but sound good).
If you have to resort to SCRUM, your company is probably already toxic (or else the last company your VP of Engineering worked at was toxic).
When you don't have good product/market fit, everything the development team builds looks like a miss (because it is) even if the technology works very well. Thus, good product management is crucial.
In the greater scheme of things it matters very little if every single features ships two months late. The most important thing is that the product gets closer and closer to the product/market fit bullseye.
SCRUM insulates developers from managers who would constantly change their mind and thrash the team around willy nilly, but it also insulates developers from the realities of the business.
With good product management, everyone buys into the challenge of product market fit, and everyone wants to apply the right blend of qualitative and quantitative approaches to build the right thing at the right time. SCRUM is fine if everyone is already cynical and there is widespread mistrust, but if you want real team cohesion it's a bad idea.
I'd like to at least offer some support to this -- I'm not sure I agree with all of your conclusions but since switching to Scrum mentality I definitely notice that the goals of our team have become much less ambitious... Rather than insulating for development cycles that may not yield much for a few of months but in the end equals proper enterprise architecture, the business/devs have found it much easier to focus on small iterative tasks that are much more superficial in the grand scheme of things.
I think engineering processes benefit when they are insulated from direct scrutiny of timelines. Resorting to tackling smaller, neater issues in Agile seems to be a sign that there is a lack of technical leadership/vision. This is not necessarily the fault of Agile (I don't mind Agile, I think projects can succeed with it if approached properly), I simply agree that increasing process rigor seems to be a symptom of an engineering/mgmt team that is floundering.
In short, if your team's problem is that things are getting "messy" and "hectic" because of too much crappy copy/paste code, I have seen how Agile can just deepen that wound while masking it in a veil of "tangible progress" seen in burndown charts. Then, again, if you don't have the right people you don't have the right people. What else can you say?
I think engineering processes benefit when they are insulated from direct scrutiny of timelines. Resorting to tackling smaller, neater issues in Agile seems to be a sign that there is a lack of technical leadership/vision. This is not necessarily the fault of Agile (I don't mind Agile, I think projects can succeed with it if approached properly), I simply agree that increasing process rigor seems to be a symptom of an engineering/mgmt team that is floundering.
In short, if your team's problem is that things are getting "messy" and "hectic" because of too much crappy copy/paste code, I have seen how Agile can just deepen that wound while masking it in a veil of "tangible progress" seen in burndown charts. Then, again, if you don't have the right people you don't have the right people. What else can you say?
I'm guessing if you're the kind of manager that sees progress in burndown charts you're already on the wrong course as it is.
I'm not sure if your comment will get much attention because of how strongly worded some of it is, but I feel it contains a nice insight about the relation (and potential tension) between Product and Process.
If your hypothesis holds, then perhaps that this is why Scrum appears well-suited to people doing client work!
The client has the responsibility for product/market fit, and "the realities of the business." The software shop they may hire to build something will doubtless think deeply about finding and exposing the value in their concept to users, but at the end of the day the contractor is already insulated from the next-level, "should we be building this or something different?" questions.
One of the best projects I've ever worked on was making an effort to be agile -- but not to adopt any packaged process! 2 fulltime devs, 2 part-time, weekly sprints with working code, story/task level breakdown of effort with estimation/hours assigned to stories, 5-10 minute stand-ups, retrospectives only over email if there's anything we want to talk over ... the people who were on that project still feel like it "just worked" and that it was one of the more pleasant and 'agile' projects they've ever been involved with.
... but, as so many other messages here mention, the reality is that the product itself was the key. There was a good, simple product vision, which the product's (deeply technical, programmer) owner and the lead developer (myself) shared. And, again potentially supporting your hypothesis, it was client work (a tool that salespeople used to do quick mockups for leads on their iPads; it's not a consumer product but it was at least heavily used, and replaced an inefficient manual process).
If your hypothesis holds, then perhaps that this is why Scrum appears well-suited to people doing client work!
The client has the responsibility for product/market fit, and "the realities of the business." The software shop they may hire to build something will doubtless think deeply about finding and exposing the value in their concept to users, but at the end of the day the contractor is already insulated from the next-level, "should we be building this or something different?" questions.
One of the best projects I've ever worked on was making an effort to be agile -- but not to adopt any packaged process! 2 fulltime devs, 2 part-time, weekly sprints with working code, story/task level breakdown of effort with estimation/hours assigned to stories, 5-10 minute stand-ups, retrospectives only over email if there's anything we want to talk over ... the people who were on that project still feel like it "just worked" and that it was one of the more pleasant and 'agile' projects they've ever been involved with.
... but, as so many other messages here mention, the reality is that the product itself was the key. There was a good, simple product vision, which the product's (deeply technical, programmer) owner and the lead developer (myself) shared. And, again potentially supporting your hypothesis, it was client work (a tool that salespeople used to do quick mockups for leads on their iPads; it's not a consumer product but it was at least heavily used, and replaced an inefficient manual process).
This is precisely my concern when servicing clients. Have you (or has anyone else) worked as a client-facing development team and successfully dealt with this tension? Obviously in the case of great clients this becomes a non-issue, but when clients are new to product development, do you simply need to have a very strong hand to make the product successful?
Bingo. Scrum works for products that have already been sold but not yet implemented. That is, client work.
Almost every new idea in software development is having problems when facing "majority adoption" phase. Agile definitely is replacing waterfall now and there are so many people that capitalize on this trend and don't give a shit about agile roots and principles. Every new wave is eventually hiped and monetized. Agile is not an exception. It doesn't mean agile is bad, it just means agile went mainstream with all side effects.
I personally have a strong feeling that this article is just another attempt to monetize agile, by selling "agile failure". Agile is not failed for sure. Some people did.
I personally have a strong feeling that this article is just another attempt to monetize agile, by selling "agile failure". Agile is not failed for sure. Some people did.
Every new idea in management have problems at the "majority adoption" phase. Software is no exception.
Those problems appear because organizations are chaotic, in the mathematical sense, in that the sum of the details completely eclipses the worth of any idea. And that's an inherent problem.
Those problems appear because organizations are chaotic, in the mathematical sense, in that the sum of the details completely eclipses the worth of any idea. And that's an inherent problem.
The problem with agile development has always been Agile Development.
Cargo-cult management practices freely adopted the brand facade without embracing or even understanding the underlying principles that must be present before the branded process elements can be good practice.
I don't care how good your process consultants are. They are not going to convince any manager to reduce his own importance within the organization. Just like it is much more difficult to make software secure by waiting until version 2.0 to add it, it is harder to make an organization agile by patching that in after the startup phase. It is far easier to be born agile than to reorganize into it.
The failure comes when trying to convince a clumsy organization, with plenty of vested interest in remaining that way, to become agile. What you end up with is a racing stripe painted onto their t-shirts and shiny plastic spoilers taped onto their asses, and no real improvement.
So in this context, GROWS will also fail. The only way to stop it from happening is by the developers pushing back hard against any more brand-name processes that are uncritically peddled to any organization flush enough to pay a process consultant. Screw your new snake oil, buddy. My org listens to me barely enough right now, and I don't need anyone messing that up with some new kind of pointless meeting.
Cargo-cult management practices freely adopted the brand facade without embracing or even understanding the underlying principles that must be present before the branded process elements can be good practice.
I don't care how good your process consultants are. They are not going to convince any manager to reduce his own importance within the organization. Just like it is much more difficult to make software secure by waiting until version 2.0 to add it, it is harder to make an organization agile by patching that in after the startup phase. It is far easier to be born agile than to reorganize into it.
The failure comes when trying to convince a clumsy organization, with plenty of vested interest in remaining that way, to become agile. What you end up with is a racing stripe painted onto their t-shirts and shiny plastic spoilers taped onto their asses, and no real improvement.
So in this context, GROWS will also fail. The only way to stop it from happening is by the developers pushing back hard against any more brand-name processes that are uncritically peddled to any organization flush enough to pay a process consultant. Screw your new snake oil, buddy. My org listens to me barely enough right now, and I don't need anyone messing that up with some new kind of pointless meeting.
I was on board with the article until he tried to sell me Agile 2.0. (an unproven and confusing iteration, to make matters worse. Dreyfus skill model? Nursing industry? I'll wait and see and hope someone else has some sort of success with this before considering it myself)
I half-expected this article to be an elaborate troll =/
It started good and I thought it would get even better by creating a imaginary new method (even with the "TM" sign) to make fun of the craziness it was complaining about. At the end I didn't know if it was a joke or not but, sadly, it looks it's no joke (to the authors, at least).
my company is "totally agile" (they wish) and it gives the management layer something to do cuz they are analyzing JIRA all day coming up with horse-shit charts, so of course they keep pushing all of it like its solving high-level organizational issues in ways we will experience tangibly sometime by 2018...
if you got rid of all that process infrastructure and just had a few programmers discussing proper design patterns now & then our company would be lightyears ahead of where it is now. i think everything becomes cargo cult when you refocus technical people onto processes that discourage technicality to make management feel fuzzy about their stats. people aren't more productive now, they are just gaming the agile system
process planning has its place i just feel like its becoming the focal point of discussion rather than a means to it. bureaucracies will continue to grow, what can you do other than look for a job with a more technical group that is focused on code?
i'm a former academic, i was astronomically more productive in that setting and there were no real process restrictions imposed at all. people need to be cultured into code & self-education, not process. optimize process once there is a good technical core in place, not in lieu of one
(i've also noticed that fake agile just promotes a lack of requirements docs from business... in that case i'd be better off doing damn waterfall with a half-decent reqs doc anyway...)
if you got rid of all that process infrastructure and just had a few programmers discussing proper design patterns now & then our company would be lightyears ahead of where it is now. i think everything becomes cargo cult when you refocus technical people onto processes that discourage technicality to make management feel fuzzy about their stats. people aren't more productive now, they are just gaming the agile system
process planning has its place i just feel like its becoming the focal point of discussion rather than a means to it. bureaucracies will continue to grow, what can you do other than look for a job with a more technical group that is focused on code?
i'm a former academic, i was astronomically more productive in that setting and there were no real process restrictions imposed at all. people need to be cultured into code & self-education, not process. optimize process once there is a good technical core in place, not in lieu of one
(i've also noticed that fake agile just promotes a lack of requirements docs from business... in that case i'd be better off doing damn waterfall with a half-decent reqs doc anyway...)
Urgh Jira. Jira symbolizes the entire problem. Issue and task tracking where the actual issue and tasks are 3 layers deep from the main interface, and graphs and burn down charts are front and centre. It's all carefully architected to appeal and sell to the managers who buy it, rather then the dev's who use it.
Contrast to something like GitHub, where code is front and center, and issues are a flat list and which has no other BS cluttering it up. Why? Because GitHub isn't selling a product to managers first - it's selling to to dev's first (via getting them in on open source).
Contrast to something like GitHub, where code is front and center, and issues are a flat list and which has no other BS cluttering it up. Why? Because GitHub isn't selling a product to managers first - it's selling to to dev's first (via getting them in on open source).
Jira has its moments, especially for larger teams. I've seen it used for large projects, and there GitHub Issues would be garbage.
You can ditch a lot of the cruft from Jira by making your own dashboard etc.
You can ditch a lot of the cruft from Jira by making your own dashboard etc.
In many martial arts there is the concept of 3 stages of learning that are roughly[1]:
1) Learn a bunch of rules and follow them by rote
2) Learn when to break the rules
3) Learn to make your own rules
Looking up the Dreyfus model of skill development mentioned in the article, there is a similar concept.
In martial arts, teaching at level #1 is easy; if person A knows a rule that person B doesn't, then person B can teach it to person A. Similarly one person can teach a large class of people a rule all at once. If you ever had a friend as a kid do a year of e.g. Karate and say "Grab my wrist... No, not that way, this way..." you've seen it taught at that level.
In martial arts, at least, learning above level 1 isn't really something that scales, nor is it something that will easily happen without a lot of self-motivation from the learner. There are, however, some traditions that are successful in aiding someone in the transition in a sort of mentorship relationship.
Such traditions aren't peculiar to martial arts though, as most crafts have ways of doing it. It would be interesting to know if modern behavioral sciences have found improvements, as the development of such traditions has always been ad-hoc informal and more of "this is how my mentor did it" rather than "we have good reason to think this way is best"
1: Here's an article on wikipedia about it; the martial-art I learned about this was not Japanese, nor Chinese, so it was somewhat different: http://en.wikipedia.org/wiki/Shuhari
1) Learn a bunch of rules and follow them by rote
2) Learn when to break the rules
3) Learn to make your own rules
Looking up the Dreyfus model of skill development mentioned in the article, there is a similar concept.
In martial arts, teaching at level #1 is easy; if person A knows a rule that person B doesn't, then person B can teach it to person A. Similarly one person can teach a large class of people a rule all at once. If you ever had a friend as a kid do a year of e.g. Karate and say "Grab my wrist... No, not that way, this way..." you've seen it taught at that level.
In martial arts, at least, learning above level 1 isn't really something that scales, nor is it something that will easily happen without a lot of self-motivation from the learner. There are, however, some traditions that are successful in aiding someone in the transition in a sort of mentorship relationship.
Such traditions aren't peculiar to martial arts though, as most crafts have ways of doing it. It would be interesting to know if modern behavioral sciences have found improvements, as the development of such traditions has always been ad-hoc informal and more of "this is how my mentor did it" rather than "we have good reason to think this way is best"
1: Here's an article on wikipedia about it; the martial-art I learned about this was not Japanese, nor Chinese, so it was somewhat different: http://en.wikipedia.org/wiki/Shuhari
The essence of Agile and XP still stand tall
the Agile Maifesto / Scrum tried to downplay process so much it became a by-word for no process, and almost broke the good it was doing as no one could track / report what was going on so every implementation looks like an uncontrolled mess.
(Yes there were sticky notes up on boards, but it's hard to mail that to upper management)
So a little more process, a lot more talking to end users and waaaaay more automated tests and automated releases and we might have something
- sit close to the customer (literally)
- write good automated test coverage
- release early and often and get feedback (see point 1)
the Agile Maifesto / Scrum tried to downplay process so much it became a by-word for no process, and almost broke the good it was doing as no one could track / report what was going on so every implementation looks like an uncontrolled mess.
(Yes there were sticky notes up on boards, but it's hard to mail that to upper management)
So a little more process, a lot more talking to end users and waaaaay more automated tests and automated releases and we might have something
Yes. Feedback!
Feedback from customers by iterating and releasing early and often.
Feedback from the team with proper frequent retrospectives.
Projects that I have been part of that skip or mangle retrospectives have all struggled. Listen to the team. Keep tweaking, improving every week/sprint. But keep the delta low so you can see what actually made an impact. And keep retrospective to mostly the team only so root causes are actually mentioned and not railroaded by external chiefs.
Feedback from customers by iterating and releasing early and often.
Feedback from the team with proper frequent retrospectives.
Projects that I have been part of that skip or mangle retrospectives have all struggled. Listen to the team. Keep tweaking, improving every week/sprint. But keep the delta low so you can see what actually made an impact. And keep retrospective to mostly the team only so root causes are actually mentioned and not railroaded by external chiefs.
If we even look past the 15 years of Agile and into the 50+ years of big-business software development, looking at the differences between the organizations that succeed and the far, far more numerable organizations that fail[1], then I don't think we see any differences that come close to touching the technology or individual work habits of the employees. The differences we see are organizations who trust their employees to be experts, and organizations who try to manage top-down.
Centralized, authoritarian structures, whether for business or government, are where the "lack of agility" come from that the Agile Manifesto spoke against. Creating a new set of rules called "Agile" that such a centralized authority can impose on its underlings doesn't change that.
[1] by some metric, either by time or budget or employee health and retention, which is really just a failure of budget that has been paid for in a way that doesn't show up on the accounting sheets.
Centralized, authoritarian structures, whether for business or government, are where the "lack of agility" come from that the Agile Manifesto spoke against. Creating a new set of rules called "Agile" that such a centralized authority can impose on its underlings doesn't change that.
[1] by some metric, either by time or budget or employee health and retention, which is really just a failure of budget that has been paid for in a way that doesn't show up on the accounting sheets.
Like most people, I've had mixed experiences with agile. I like short regular meetings where I hear what people are doing - but not for process reasons - it's just nice to hear. The places I've worked fit comfortably into one of two categories.
In smaller shops, developers circumvent the process (whatever it is) when it makes sense. Things are messy, but it's not so bad. Hard to say how much process helps there.
In larger shops, the process has won and people just work around it. Developers still try to get around the bad parts, but The Process is stronger than any individual. Work seems to get done less, but everyone understands why the work didn't happen. Generally, I get to go home earlier in these kinds of environments.
All that said, a co-worker recently said they were excited to get more into agile and linked a product that uses this chart to advertise their agile tracking software: http://i.imgur.com/uYZwtFY.png . I cannot for the life of me figure out how we got from "people over process" to that monstrosity.
In smaller shops, developers circumvent the process (whatever it is) when it makes sense. Things are messy, but it's not so bad. Hard to say how much process helps there.
In larger shops, the process has won and people just work around it. Developers still try to get around the bad parts, but The Process is stronger than any individual. Work seems to get done less, but everyone understands why the work didn't happen. Generally, I get to go home earlier in these kinds of environments.
All that said, a co-worker recently said they were excited to get more into agile and linked a product that uses this chart to advertise their agile tracking software: http://i.imgur.com/uYZwtFY.png . I cannot for the life of me figure out how we got from "people over process" to that monstrosity.
Ignoring the article for a moment. I think one of the problems with agile-in-the-wild is that people who try to use it think in binary terms. In the original manifesto, the idea put forth pretty clearly is about rebalancing the way things are done -- not doing one thing instead of the other.
For example, it's not "Working software instead of documentation" it's "Working software over comprehensive documentation".
Agile should be a philosophy about development, not a set of rules.
To make matters worse, Agile-as-a-product (with Seminars, and Books and whatever) seems to only amplify this. I've had scrum masters tell me very directly that "the proper agile procedure for such and such is..." or things very similar.
It doesn't mean you don't have tools or process or contracts or whatever...and it's frustrating that most people don't seem to get that.
For example, it's not "Working software instead of documentation" it's "Working software over comprehensive documentation".
Agile should be a philosophy about development, not a set of rules.
To make matters worse, Agile-as-a-product (with Seminars, and Books and whatever) seems to only amplify this. I've had scrum masters tell me very directly that "the proper agile procedure for such and such is..." or things very similar.
It doesn't mean you don't have tools or process or contracts or whatever...and it's frustrating that most people don't seem to get that.
Agile is a very useful product.. for a certain target market.
The problem is that the target market isn't developers, and the product isn't improved productivity.
The target is middle management, and the product is risk management. Or more accurately, perceived risk management -- it doesn't really matter if it works, the narrative of "being agile" is more important because that narrative can be sold outside the group with all sorts of fancy charts showing just how well managed things are.
That sounds cynical, but in a lot of ways it can be a good thing. Some fictions really do have a utility. For instance, by creating measurables (story points, etc), even if those measurable metrics are largely fictitious, it can give a group credibility that will prevent interference from outside stakeholders, and it can calm upper management that would otherwise be antsy.
The problem is that the target market isn't developers, and the product isn't improved productivity.
The target is middle management, and the product is risk management. Or more accurately, perceived risk management -- it doesn't really matter if it works, the narrative of "being agile" is more important because that narrative can be sold outside the group with all sorts of fancy charts showing just how well managed things are.
That sounds cynical, but in a lot of ways it can be a good thing. Some fictions really do have a utility. For instance, by creating measurables (story points, etc), even if those measurable metrics are largely fictitious, it can give a group credibility that will prevent interference from outside stakeholders, and it can calm upper management that would otherwise be antsy.
There's an interesting discussion on http://www.reddit.com/r/programming/comments/354aze/the_fail...
This has to be a really late April Fools' joke. There is no way in hell they could seriously be trying to pitch a "basically-new-agile-methodology" that is this buzzword laden. I mean, the (TM) on the name?? Come on...
Trademarking the name may be a way to prevent GROWS from being hijacked the way Agile has been. The reference to the Dreyfus model makes me suspect that (aside from rebooting to bypass the way Agile has been coopted) this may be an attempt to put some concrete guidance into the metamethodology of developing process in an Agile (in the Manifesto sense) organization, which was always a fairly big gap in the Agile literature, which tended to be largely principles plus the specific processes used by specific organization, without covering how the agility actually should work (though, if you got outside of the Agile brand into works on Lean, which is pretty much the same set of principles arrived at from a basis that has much stronger process engineering background, and so tends to feature a lot more work on concrete methods of process evaluation, there was quite a bit of that.)
I recently wrote an answer to a question on Quora about Agile.
http://www.quora.com/Why-do-some-developers-at-strong-compan...
To summarize my answers as to why developers have started hating Agile?
1. Most organizations have a wrong understanding/implementation of Agile. 2. People especially at the management/leadership levels think that if a team follows Scrum, they are Agile. 3. There is an entire industry which is trying to over exaggerate/misguide the Agile movement and make money out of it. 4. The troubled understanding that Agile is a One Size Fits All kinda thing. 5. Being in a Fixed Mindset (Anti-Agile). 6. Some teams are already Agile. And for them, Scrum should not be forced. 7. Scrum by definition doesn't give a damn to the seniority of engineers. Because everyone is a Scrum Team Member. 8. Impediments are not removed. Or worse new impediments crop up when implementing Agile in a bad fashion. 9. Scrum by definition doesn't care about flow state of a programmer.
And the essence of the article that I have just read is that there is gonnna be a competitor for Scrum and it is called GROWS.. Wow.. Let's see what happens next.
And as someone rightly pointed out, as long as there is corporatism which tries to implement Agile, there will be lot of failures. So in a nutshell, it is not the failure of Agile, but the failure of people who didn't understand Agile properly.
http://www.quora.com/Why-do-some-developers-at-strong-compan...
To summarize my answers as to why developers have started hating Agile?
1. Most organizations have a wrong understanding/implementation of Agile. 2. People especially at the management/leadership levels think that if a team follows Scrum, they are Agile. 3. There is an entire industry which is trying to over exaggerate/misguide the Agile movement and make money out of it. 4. The troubled understanding that Agile is a One Size Fits All kinda thing. 5. Being in a Fixed Mindset (Anti-Agile). 6. Some teams are already Agile. And for them, Scrum should not be forced. 7. Scrum by definition doesn't give a damn to the seniority of engineers. Because everyone is a Scrum Team Member. 8. Impediments are not removed. Or worse new impediments crop up when implementing Agile in a bad fashion. 9. Scrum by definition doesn't care about flow state of a programmer.
And the essence of the article that I have just read is that there is gonnna be a competitor for Scrum and it is called GROWS.. Wow.. Let's see what happens next.
And as someone rightly pointed out, as long as there is corporatism which tries to implement Agile, there will be lot of failures. So in a nutshell, it is not the failure of Agile, but the failure of people who didn't understand Agile properly.
Agile only seems to be useful if you have prior exposure to the Waterfall model, people who start off with Agile as their first software development methodology tend to parse 'agile' as 'license to freely use bad practices'. I've seen this often enough to a point, at times I think the older waterfall model would work a lot better for a lot of shops.
Back in the day people would do a good deal of paper work as a part of requirements gathering, this would iron out a lot of clarification and specify clear definitions of what people wanted to do. These days 'define as you code', often leads to getting requirements in piece meal, often adhoc with no broader sense of design and what follows is endless refactoring. Delayed projects, and rewrites.
One more damage agile is causing to the Google generation of programmers is destroying skills related to reading and writing documentation. In a urge to do everything in a hurry, we end up doing more damage than good.
And agile never quite really got rid of beaucracratic rituals of the waterfall model, they just got re invented into their new forms.
Back in the day people would do a good deal of paper work as a part of requirements gathering, this would iron out a lot of clarification and specify clear definitions of what people wanted to do. These days 'define as you code', often leads to getting requirements in piece meal, often adhoc with no broader sense of design and what follows is endless refactoring. Delayed projects, and rewrites.
One more damage agile is causing to the Google generation of programmers is destroying skills related to reading and writing documentation. In a urge to do everything in a hurry, we end up doing more damage than good.
And agile never quite really got rid of beaucracratic rituals of the waterfall model, they just got re invented into their new forms.
The Agile Manifesto has a lot of good ideas and was motivated by real world problems and how they were solved. The problem is like many other good ideas is that they evaporate in a cultural vacuum. Agile methods like Scrum and XP are based on the thought that introducing some rules can overcome culture.
What happens in practice is that culture subverts those rules in order to reinforce itself.
Resistance to change is a stronger force than any buzzword methodology or profound observations. This is further confounded by the very nature of software development as something that can't be distilled into a set of rules. Different situations require different approaches.
Is all lost? I don't think so. Agile has contributed to the way people think about software development and gives the right team in the right culture more tools they can use in the right situations. It's not going to "fix" software development in general though.
What happens in practice is that culture subverts those rules in order to reinforce itself.
Resistance to change is a stronger force than any buzzword methodology or profound observations. This is further confounded by the very nature of software development as something that can't be distilled into a set of rules. Different situations require different approaches.
Is all lost? I don't think so. Agile has contributed to the way people think about software development and gives the right team in the right culture more tools they can use in the right situations. It's not going to "fix" software development in general though.
If GROWS became popular, it would also be 'sloganized', branded and ruined. People would go to one-day intensive GROWS courses, get certified and then just do waterfall anyway - exactly what's happened to Scrum and everything else.
I find it slightly ironic that they (correctly) say they are no silver bullets, then suggest a silver bullet.
I find it slightly ironic that they (correctly) say they are no silver bullets, then suggest a silver bullet.
> If GROWS became popular, it would also be 'sloganized', branded and ruined.
Claiming a trademark is a threat of legal action against those hijacking the name to sell things in the same domain using the name without permission, which could be a potent way to prevent people from marketing things that are exactly the opposite from it calls for using its name the way it happened with Agile.
> People would go to one-day intensive GROWS courses, get certified and then just do waterfall anyway
Only if the owners of the trademark license GROWS certifications; if they are serious about preventing hijacking, they'll tightly control how the trademark is used and only use it on material (books, videos, potentially courses) consistent with the the intent of the system, and not for certification of people.
Claiming a trademark is a threat of legal action against those hijacking the name to sell things in the same domain using the name without permission, which could be a potent way to prevent people from marketing things that are exactly the opposite from it calls for using its name the way it happened with Agile.
> People would go to one-day intensive GROWS courses, get certified and then just do waterfall anyway
Only if the owners of the trademark license GROWS certifications; if they are serious about preventing hijacking, they'll tightly control how the trademark is used and only use it on material (books, videos, potentially courses) consistent with the the intent of the system, and not for certification of people.
I don't know anyone who just does waterfall anyway except for simple projects. You just can't get all you architecture and design done up front. There is a lot of iteration between architecture, design and coding. Requirements change and things need to adapt. That is not waterfall.
Lots of places do agile-washed waterfall.
They're mostly places that look for a methodology-in-a-box type solutions.
They're mostly places that look for a methodology-in-a-box type solutions.
I think that I left software development just as these schemes where becoming en vogue.
Being on the outside of the industry and reading about all of these acronyms of "how to succeed with great apes" ... it reminds me of being in middle school band. It smells like how first chair worked to get all of us clarinets to practice more and to try to out do each other performance-wise.
It works.
But eventually it changes from first chair to "first chair". And then it became, iirc, a lighting-rod for interpersonal problems amongst the single-reeds that became disruptive.
I suppose that I think of these schemes as MBA-encoded first chair politics. They work while the meta-game is immature. But as soon as players get to see the carrot for what it is ... it is all about a competition for who gets to hold the stick.
Being on the outside of the industry and reading about all of these acronyms of "how to succeed with great apes" ... it reminds me of being in middle school band. It smells like how first chair worked to get all of us clarinets to practice more and to try to out do each other performance-wise.
It works.
But eventually it changes from first chair to "first chair". And then it became, iirc, a lighting-rod for interpersonal problems amongst the single-reeds that became disruptive.
I suppose that I think of these schemes as MBA-encoded first chair politics. They work while the meta-game is immature. But as soon as players get to see the carrot for what it is ... it is all about a competition for who gets to hold the stick.
It's funny - as a former French Horn player, the second horns get all the good parts...
I've been political, I have been apolitical, I've been places where there were no politics. In the end, it's all the same.
I've been political, I have been apolitical, I've been places where there were no politics. In the end, it's all the same.
Agile is great, for many reasons. Not least but including:
Having loads and loads of meetings. Like teaching people to build a car or town with Lego using an Agile methodology. Instead of letting them do it themselves, it was a game-changer on memories of Lego as a kid, the impact was like coming off a waterfall, no, even being in a waterfall.
Improving meetings by doing them standing up with a whiteboards instead of a meeting room glassboard. Not only freeing up precious meeting room space for those teams doing scrums with remote teams that also do stand-up whiteboard scrums on their own, our white boards cost leading to less wear-and-tear, scrums tend to last for 30-60 minutes, improving everyone's cardiovascular system, and we can do them at any time of the day whenever the team lead decides a scrum should be done, damn everyone's productivity, it is all about the scrum and helping everyone get things done. My team lead says Agile is a better method for managing things.
Overtime is now referred to as a 'sprint' when we realize we're behind deadline, but can enjoy the process of sprinting every 2 weeks. We have replaced the boring, planned methodology of milestones and working overtime to fix what we hadn't planned by sprints, where we do overtime on a systematically planned 2-times-per-month basis, and everyone is happy because of the 'focus time' whenever we're not scrumming, and free taxi home at night. We also work shift 2 days per week because that totally helps sleep patterns. Enjoy the early morning and late evening at least twice per month.
If the sprint doesn't work, we just push things to the next release. It seems to keep everyone happy.
Agile tools are so flexible we have to make our own, as our organization is so paranoid and locked-down regarding information security we cannot use anything that doesn't go through an approval chain so many miles long it literally virtually circles the earth several times over. So we resist this, and dedicate 1/4 of all of our resources to beating these out-of-date systems at their own game. A guy said he could do the whole 300 person project in Excel, but we thought maintaining a staff Name-ID-email-telephone table would not totally not work, and kept the 300 people making this system Agile instead, we're just using a single API, after all. Agile is all about the team.
Even our bathroom staff are Agile. When the GM leaves in the evening, all tissue paper is removed from the bathroom, promptly. It is replaced when he returns in the morning. That is keeping a tight, ship.
*All the above is true, if somewhat hastily typed.
Having loads and loads of meetings. Like teaching people to build a car or town with Lego using an Agile methodology. Instead of letting them do it themselves, it was a game-changer on memories of Lego as a kid, the impact was like coming off a waterfall, no, even being in a waterfall.
Improving meetings by doing them standing up with a whiteboards instead of a meeting room glassboard. Not only freeing up precious meeting room space for those teams doing scrums with remote teams that also do stand-up whiteboard scrums on their own, our white boards cost leading to less wear-and-tear, scrums tend to last for 30-60 minutes, improving everyone's cardiovascular system, and we can do them at any time of the day whenever the team lead decides a scrum should be done, damn everyone's productivity, it is all about the scrum and helping everyone get things done. My team lead says Agile is a better method for managing things.
Overtime is now referred to as a 'sprint' when we realize we're behind deadline, but can enjoy the process of sprinting every 2 weeks. We have replaced the boring, planned methodology of milestones and working overtime to fix what we hadn't planned by sprints, where we do overtime on a systematically planned 2-times-per-month basis, and everyone is happy because of the 'focus time' whenever we're not scrumming, and free taxi home at night. We also work shift 2 days per week because that totally helps sleep patterns. Enjoy the early morning and late evening at least twice per month.
If the sprint doesn't work, we just push things to the next release. It seems to keep everyone happy.
Agile tools are so flexible we have to make our own, as our organization is so paranoid and locked-down regarding information security we cannot use anything that doesn't go through an approval chain so many miles long it literally virtually circles the earth several times over. So we resist this, and dedicate 1/4 of all of our resources to beating these out-of-date systems at their own game. A guy said he could do the whole 300 person project in Excel, but we thought maintaining a staff Name-ID-email-telephone table would not totally not work, and kept the 300 people making this system Agile instead, we're just using a single API, after all. Agile is all about the team.
Even our bathroom staff are Agile. When the GM leaves in the evening, all tissue paper is removed from the bathroom, promptly. It is replaced when he returns in the morning. That is keeping a tight, ship.
*All the above is true, if somewhat hastily typed.
The Agile manifesto was originally written, from what I understand, by people who actually understood software.
I just don't understand what logic brought us to this place where it's not seen as weird that someone wholly non-technical and unfamiliar with software can be a manager of a software team (or run a software company, for that matter).
I'm not arguing that software is somehow 'special' either - I'd make the same argument if say, for example, someone wholly unfamiliar with steel fabrication was acting as a factory foreman. Or if me, as a software guy, decided to just one day declare that I'm qualified to successfully manage a farm.
I feel like this is a big part of the problem. Not the whole problem, but a big ccontributor.
I just don't understand what logic brought us to this place where it's not seen as weird that someone wholly non-technical and unfamiliar with software can be a manager of a software team (or run a software company, for that matter).
I'm not arguing that software is somehow 'special' either - I'd make the same argument if say, for example, someone wholly unfamiliar with steel fabrication was acting as a factory foreman. Or if me, as a software guy, decided to just one day declare that I'm qualified to successfully manage a farm.
I feel like this is a big part of the problem. Not the whole problem, but a big ccontributor.
> I just don't understand what logic brought us to this place where it's not seen as weird that someone wholly non-technical and unfamiliar with software can be a manager of a software team (or run a software company, for that matter).
"Brought us to this place"? We've always been in that place. In the last few decades, we might have started inching away from it a little bit, we certainly haven't recently arrived at it.
The idea that leadership of an technical organization should be skilled technicians (at least up to the point in the organization where there is a distinctly technical organization) is something that has never been the dominant wisdom in business ("management" as a distinct and transferrable skill set has been more dominant.)
Certainly Lean Software Development (and its direct predecessor in Lean Manufacturing and some of the other things that fed into Lean Manufacturing) tend to hold the position that leadership in a technical organization should be technical, but while that Lean has become powerful in some areas of manufacturing, its never been dominant in software development or business generally.
"Brought us to this place"? We've always been in that place. In the last few decades, we might have started inching away from it a little bit, we certainly haven't recently arrived at it.
The idea that leadership of an technical organization should be skilled technicians (at least up to the point in the organization where there is a distinctly technical organization) is something that has never been the dominant wisdom in business ("management" as a distinct and transferrable skill set has been more dominant.)
Certainly Lean Software Development (and its direct predecessor in Lean Manufacturing and some of the other things that fed into Lean Manufacturing) tend to hold the position that leadership in a technical organization should be technical, but while that Lean has become powerful in some areas of manufacturing, its never been dominant in software development or business generally.
Agreed. I was working (for) a company that hired an ex-Coke executive as CEO. We made wireless inventory handheld devices. He was clueless; he presided over the decimation of that company and the destruction of its design team.
I feel like someone should develop and market the "I Ching" and the "Tao te Ching" as a development methodology. It could attain the same cultural position that "The Art of War" enjoys in business.
> Chapter 54
> That which is well established cannot be uprooted
> That which is strongly held cannot be taken
> The descendants will commemorate it forever
Here, the classic teaches us that strong coupling incurs technical debt which limits the future of the application. Just because we've always done it this way, doesn't mean you must rigidly follow bad methodology.
Plus, the inclusion of I Ching divination provides a built in means of making easy decisions and resolving conflicts.
> Chapter 54
> That which is well established cannot be uprooted
> That which is strongly held cannot be taken
> The descendants will commemorate it forever
Here, the classic teaches us that strong coupling incurs technical debt which limits the future of the application. Just because we've always done it this way, doesn't mean you must rigidly follow bad methodology.
Plus, the inclusion of I Ching divination provides a built in means of making easy decisions and resolving conflicts.
agile per se is good -- making it a religious is ususally bad;
I saw many companies using scrum and often I felt like this is a process for slower moving teams, instead of the opposite;
Great software is being written by great individuals that move it forward, pretty indecent of whatever process a company tries to use. To me a process must not get in the way or productivity and creativity.
I saw many companies using scrum and often I felt like this is a process for slower moving teams, instead of the opposite;
Great software is being written by great individuals that move it forward, pretty indecent of whatever process a company tries to use. To me a process must not get in the way or productivity and creativity.
The problem with Agile is that it's political; it gives programmers lots of power because it allows them to control the scope of the project and it gives the more access to the client/customer/business analyst/user. It also lets them argue for improving quality through test-driven development and pair programming.
When you have a manager, a marketing department, you have multiple points of power where the manager(s) come first and try to control everything. Giving up that control is difficult to do. When you have a marketing department, they assume they know what is best for the user and what features the user needs and at what time (all the features done by day X). The developer ends up being a code monkey who's hired to implement exactly what some MBA (or even worse, non-MBA!) wants. It doesn't even matter if users hate; it doesn't matter how slow it is, as long as it meets the whims of the managers in charge.
With Agile, you get rid of the bureaucracy and you make the feedback cycle faster and you have quality built-in. You don't really need marketing or a manager calling the shots because you can go to the customer directly (or through the customer proxy who also is with your agile team every single day). You've effectively removed one or two jobs or at least reduced them to part-time work; that's very dangerous in a hierarchy.
Programmers are low status; when we're high status we can have Agile and we can influence the work we do.
When you have a manager, a marketing department, you have multiple points of power where the manager(s) come first and try to control everything. Giving up that control is difficult to do. When you have a marketing department, they assume they know what is best for the user and what features the user needs and at what time (all the features done by day X). The developer ends up being a code monkey who's hired to implement exactly what some MBA (or even worse, non-MBA!) wants. It doesn't even matter if users hate; it doesn't matter how slow it is, as long as it meets the whims of the managers in charge.
With Agile, you get rid of the bureaucracy and you make the feedback cycle faster and you have quality built-in. You don't really need marketing or a manager calling the shots because you can go to the customer directly (or through the customer proxy who also is with your agile team every single day). You've effectively removed one or two jobs or at least reduced them to part-time work; that's very dangerous in a hierarchy.
Programmers are low status; when we're high status we can have Agile and we can influence the work we do.
Process is valuable, but too often people fall into the trap of trying to trust everything to process. Which will never work. A process is like a little code snippet. The best processes involve heuristics which complement the experience and judgment of human beings in the loop. Otherwise you just get a kafkaesque nightmare.
Agile has some special additional problems, including a misleading sense of detail, a tendency towards short-sightedness, and misplaced credit for success on the process. Having a ton of "artifacts" or stats doesn't mean you have the right data, or even enough data, but if you have a lot of interesting data you tend to fall into the trap of believing you know everything. Agile's short planning windows often means that you don't get proper credit for long, drawn out work and planning very far ahead. This is actually intentional, as Agile/SCRUM have been designed to get productivity out of unproductive and dysfunctional teams, but sometimes you need more than just stumbling along. Also, because Agile has a lot of detail to it people tend to give it credit for successes due to the post hoc fallacy (e.g. "we did Agile, and then we shipped a great product, yay Agile!").
Agile has some special additional problems, including a misleading sense of detail, a tendency towards short-sightedness, and misplaced credit for success on the process. Having a ton of "artifacts" or stats doesn't mean you have the right data, or even enough data, but if you have a lot of interesting data you tend to fall into the trap of believing you know everything. Agile's short planning windows often means that you don't get proper credit for long, drawn out work and planning very far ahead. This is actually intentional, as Agile/SCRUM have been designed to get productivity out of unproductive and dysfunctional teams, but sometimes you need more than just stumbling along. Also, because Agile has a lot of detail to it people tend to give it credit for successes due to the post hoc fallacy (e.g. "we did Agile, and then we shipped a great product, yay Agile!").
I think the conclusion is telling:
> And finally, whatever we attempt here has to work for the whole system, not just the developers, not just the managers, not just the testers, not just the users, not just the sponsors. There is no ”us” versus ”them.” There is only us.
The goal in all these methodologies is to get everybody so perfectly aligned, they'll naturally zero in on The Right Thing.
But the people who are really in charge have no intention of ever letting this happen. It doesn't matter what the methodology is.
People try to apply Agile or whatever in the modern American corporate environment, which is a seething pit of fear and mistrust with no job security. So everyone wants harder guarantees. Brighter lines, that show if they've done their job well or not.
So despite their best intentions, there are strong incentives to maintain all the anti-agility boundaries, in order that blame and credit flow to the appropriate people. If there was a truly Agile product that succeeded, who is to be rewarded? It's hard to say. If it failed, who is to be blamed? Everybody? Nobody?
This isn't short-sightedness -- this is purely rational. This is why you get "Agile"... plus hard requirements docs... hammered out in advance... and a waterfall schedule.
> And finally, whatever we attempt here has to work for the whole system, not just the developers, not just the managers, not just the testers, not just the users, not just the sponsors. There is no ”us” versus ”them.” There is only us.
The goal in all these methodologies is to get everybody so perfectly aligned, they'll naturally zero in on The Right Thing.
But the people who are really in charge have no intention of ever letting this happen. It doesn't matter what the methodology is.
People try to apply Agile or whatever in the modern American corporate environment, which is a seething pit of fear and mistrust with no job security. So everyone wants harder guarantees. Brighter lines, that show if they've done their job well or not.
So despite their best intentions, there are strong incentives to maintain all the anti-agility boundaries, in order that blame and credit flow to the appropriate people. If there was a truly Agile product that succeeded, who is to be rewarded? It's hard to say. If it failed, who is to be blamed? Everybody? Nobody?
This isn't short-sightedness -- this is purely rational. This is why you get "Agile"... plus hard requirements docs... hammered out in advance... and a waterfall schedule.
The problem with agile is that it requires a completely different way to think about productivity and company finances not just in the team but the entire connected reality of a project.
Agile solves a conceptual issue which is it creates a more effective feedback loop that keeps everyone more informed than they used to be with classic waterfall models.
The problem though is that the financial reality isn't following the logic of the agile model and so whether you are trying to use the agile model for customer projects or internally in your organization you are still a child of the the overarching financial reality which dictates how companies are measured and budgets created.
Agile is great for innovation where there is no deadline and no limited budgets. It creates a false sense of effectiveness when it comes to projects with deadlines and budgets.
At the end of the day all it does is allow you to say earlier to those you have to deliver to that they aren't going to get everything they asked for at the same price as what they thought they were getting.
Agile solves a conceptual issue which is it creates a more effective feedback loop that keeps everyone more informed than they used to be with classic waterfall models.
The problem though is that the financial reality isn't following the logic of the agile model and so whether you are trying to use the agile model for customer projects or internally in your organization you are still a child of the the overarching financial reality which dictates how companies are measured and budgets created.
Agile is great for innovation where there is no deadline and no limited budgets. It creates a false sense of effectiveness when it comes to projects with deadlines and budgets.
At the end of the day all it does is allow you to say earlier to those you have to deliver to that they aren't going to get everything they asked for at the same price as what they thought they were getting.
> "Agile is great for innovation where there is no deadline and no limited budgets"
that rings very true with me. I'm nearing the end of a 3 year project where scrum was prescribed and followed, but the truth is we've basically shoehorned agile practices into a waterfall model because of business needs.
My experience with agile projects is probably far removed from how it should be implemented, but it still feels like it's fundamentally flawed to address business needs which rely on fixed scope and accurate estimates from the start of the project succeed (e.g. critical 3rd party tools being end-of-lifed, product mandates beyond company control, renewing client licenses based on feature completion).
I guess until something better comes along, I'm stuck with being told to do some strange type of scrumfall/water-gile.
that rings very true with me. I'm nearing the end of a 3 year project where scrum was prescribed and followed, but the truth is we've basically shoehorned agile practices into a waterfall model because of business needs.
My experience with agile projects is probably far removed from how it should be implemented, but it still feels like it's fundamentally flawed to address business needs which rely on fixed scope and accurate estimates from the start of the project succeed (e.g. critical 3rd party tools being end-of-lifed, product mandates beyond company control, renewing client licenses based on feature completion).
I guess until something better comes along, I'm stuck with being told to do some strange type of scrumfall/water-gile.
Even Dave Thomas (another original signatory) has admitted there are serious problems with the way agile is generally practiced.
http://www.drdobbs.com/architecture-and-design/dave-thomas-i...
http://www.drdobbs.com/architecture-and-design/dave-thomas-i...
Yeah Dave Thomas has written about it here too http://pragdave.me/blog/2014/03/04/time-to-kill-agile/ and also Mike Cohn one of the developers of scrum has criticised blindly following methodologies (which is sort of related) http://www.mountaingoatsoftware.com/blog/dont-blindly-follow
I think the fault was that they focused more on codifying approaches to deal with specific problems rather than discussing the problems they address, and encouraging people to recognize those rather than take a specific approach.
The manifesto was nearly a ten commandments of software development.
The manifesto was nearly a ten commandments of software development.
Agile as practiced by the industry is nothing more than a way for dysfunctional businesses to punish their developers.
Over on http://growsmethod.com/, when you sign up for the mailing list, the page confirming your subscription is loading in mixed content (JS!). I'm suddenly not inspired.
That said, I don't see the point of "methods", agile, waterfall or otherwise. When I worked building SaaS for school districts, we shipped roughly once a month, so I guess that was waterfall, but some ideas we iterated multiple times within that ship period until we liked one. Now I work with a set of e-commerce websites, and nothing front-end isn't AB tested (which slows down shipping anything), and new backend functionality is iterated almost daily. But I've never called these methods anything other than the right approach based on the situation.
That said, I don't see the point of "methods", agile, waterfall or otherwise. When I worked building SaaS for school districts, we shipped roughly once a month, so I guess that was waterfall, but some ideas we iterated multiple times within that ship period until we liked one. Now I work with a set of e-commerce websites, and nothing front-end isn't AB tested (which slows down shipping anything), and new backend functionality is iterated almost daily. But I've never called these methods anything other than the right approach based on the situation.
The proposed solution feels good and all but in my experience it would be almost impossible to adopt for most companies operating in VC-istan.
The most extreme case I can think of was a "startup" I worked at that was VC'd to the gills, had an impressive board, with no traction, no revenue and about 25 engineers on staff. What they did was what I liked to call "product development by whim" where they had 5 product managers which each got to decide which features they wanted and the devs went and built it (we really really really needed a way for our non existent users to invite their friends via email, etc).
So if we needed evidence before development the whole house of cards would come falling down because the evidence would have shown no one wanted what we were selling, period.
The most extreme case I can think of was a "startup" I worked at that was VC'd to the gills, had an impressive board, with no traction, no revenue and about 25 engineers on staff. What they did was what I liked to call "product development by whim" where they had 5 product managers which each got to decide which features they wanted and the devs went and built it (we really really really needed a way for our non existent users to invite their friends via email, etc).
So if we needed evidence before development the whole house of cards would come falling down because the evidence would have shown no one wanted what we were selling, period.
The reason that BigCo never does capital-A Agile is that their release dates are fixed months ahead of time (to coordinate across the organization), and they want to know what they'll actually be shipping in 6 months (again, to coordinate across the org). This makes the biggest two selling points of Agile - continuous release and rapid change - completely worthless.
The only model I've actually seen in a large organization is for the dev team to throw together a barely-working prototype, then spend the next 6 months fixing all its problems while the Marketing, Sales, and Customer Service departments train up on the new software. And they'll find a way to call this "agile", because otherwise the developers will revolt.
The only model I've actually seen in a large organization is for the dev team to throw together a barely-working prototype, then spend the next 6 months fixing all its problems while the Marketing, Sales, and Customer Service departments train up on the new software. And they'll find a way to call this "agile", because otherwise the developers will revolt.
Is it April 1? Andy poo-talks Agile and then drops GROWS (TM) on us? You have got to be kidding me.
It's been mentioned on here a lot that if you have a skilled set of programmers on your team you probably don't need Agile. They are self-managed and tend to do the Right Thing (TM) on their own.
I have seen Agile work and when it does it's pretty fun. Things move along, issues are dealt with, and nobody panics when things get behind a little. Just move it to the next release.
I think the problem is that The Consultants sold Agile to enterprise dev shops and they really ate it up. I don't feel Agile works from the top-down but rather organically from the bottom-up. In fact I believe that is true for most programming methodologies like this.
And Scrum. Don't get me started on Scrum.
It's been mentioned on here a lot that if you have a skilled set of programmers on your team you probably don't need Agile. They are self-managed and tend to do the Right Thing (TM) on their own.
I have seen Agile work and when it does it's pretty fun. Things move along, issues are dealt with, and nobody panics when things get behind a little. Just move it to the next release.
I think the problem is that The Consultants sold Agile to enterprise dev shops and they really ate it up. I don't feel Agile works from the top-down but rather organically from the bottom-up. In fact I believe that is true for most programming methodologies like this.
And Scrum. Don't get me started on Scrum.
> I don't feel Agile works from the top-down but rather organically from the bottom-up.
I believe that is the crux of the issue. Larger organizations, and especially those that view IT as a cost center, do not feel comfortable giving control to programmers.
Every time a consultant proposes a new method with a new name, it seems like it's just a way to create a side industry; a long con that doesn't really attempt to fix the larger issue. I believe the hard problem to solve (which may be impossible, I'm not sure) is getting an organization to see their programmers as business collaborators rather than an inconvenient necessity.
I believe that is the crux of the issue. Larger organizations, and especially those that view IT as a cost center, do not feel comfortable giving control to programmers.
Every time a consultant proposes a new method with a new name, it seems like it's just a way to create a side industry; a long con that doesn't really attempt to fix the larger issue. I believe the hard problem to solve (which may be impossible, I'm not sure) is getting an organization to see their programmers as business collaborators rather than an inconvenient necessity.
> if you have a skilled set of programmers on your team you probably don't need Agile
This. Craft and passion beat any process. These people will organize themselves into the most efficient process eventually.
This. Craft and passion beat any process. These people will organize themselves into the most efficient process eventually.
This. Craft and passion beat any process. These people will organize themselves into the most efficient process eventually.
My direct experience of working with programmers over the years is that this will generally descend rapidly into an inefficient mess. Yes – maybe it works, sometimes. I'd argue that's the exception, rather than the rule.
My direct experience of working with programmers over the years is that this will generally descend rapidly into an inefficient mess. Yes – maybe it works, sometimes. I'd argue that's the exception, rather than the rule.
http://manifesto.softwarecraftsmanship.org/
If you work with people who dont care, youre screwed. Nothing will ever work to force them to actively engage with the process of creating good software.
..but, surprisingly, when you do work with people who do care, they self organize remarkably well. The Valve megacorporation is fundamentally based on this. It works. Thats been my personal experience, over the years.
The problem that has to be addressed is convincing people to care, and self improve.
Forcing a process on the unwilling is going to fail no matter what you do.
If you work with people who dont care, youre screwed. Nothing will ever work to force them to actively engage with the process of creating good software.
..but, surprisingly, when you do work with people who do care, they self organize remarkably well. The Valve megacorporation is fundamentally based on this. It works. Thats been my personal experience, over the years.
The problem that has to be addressed is convincing people to care, and self improve.
Forcing a process on the unwilling is going to fail no matter what you do.
I agree that a group of people who don't care will almost always produce substandard results.
I don't agree that people who do care necessarily self-organise well, or that this self-organisation is compatible with other business goals.
Sometimes it works, and a group of engineers et al. do a good job of forming a coherent team with minimal process. Valve's maybe an example – I don't know. My experience is that this is the exception, rather than the common case.
A good process can provide tools that help good people who care communicate and deliver more effectively. They help us to keep track of how we're performing and analyse pain points, and to make sure that there are methods for dealing with common problems.
For example, if my team felt that daily stand-ups were an inconvenience that weren't helpful, then we wouldn't do them. That's the goal; there's no cast-iron set of rules, just a generally applicable set of principles to follow.
I don't agree that people who do care necessarily self-organise well, or that this self-organisation is compatible with other business goals.
Sometimes it works, and a group of engineers et al. do a good job of forming a coherent team with minimal process. Valve's maybe an example – I don't know. My experience is that this is the exception, rather than the common case.
A good process can provide tools that help good people who care communicate and deliver more effectively. They help us to keep track of how we're performing and analyse pain points, and to make sure that there are methods for dealing with common problems.
For example, if my team felt that daily stand-ups were an inconvenience that weren't helpful, then we wouldn't do them. That's the goal; there's no cast-iron set of rules, just a generally applicable set of principles to follow.
Some kicks in the assets and firing bad apples also go a long way in keeping the team focused.
Some people are self motivated and other needs their slap in the morning (for some, that's a couple of times daily).
Some people are self motivated and other needs their slap in the morning (for some, that's a couple of times daily).
You know, I probably don't know as much as you do, but every time I've ever seen lots of negative reinforcement get applied to teams both in software and outside, it seems to have the opposite effect. Sometimes you have to quietly handle the most toxic people, but on the whole, when you take this sort of approach to managing, I would be very surprised if you only make the situation drastically worse in the long run.
And often they self-organise by taking an established process and bending it into something that works out for them. Which is fine. But that doesn't mean designing a process is useless - if it's a good base it'll be easier for the team to adapt it into something that is good for them.
> The Valve megacorporation is fundamentally based on this. It works.
So where's my Half Life 3, dammit ;-)
So where's my Half Life 3, dammit ;-)
> the Valve megacorporation
Why is Valve a megacorporation vs. just a corporation?
Why is Valve a megacorporation vs. just a corporation?
I'll add that teams should be cross-functional. If every team has product related person, designer, developers and qa — they will do OK.
Some structure needed indeed.
And adjusted to the complexity of the endeavor at hand.
Experience needed (read: got fucked before, now can avoid the treacherous waters and apply effort where and when meaningful).
Ability to deal with herding cats much needed as well.
Add relentless ability to move forward and not hold grudges.
Experience needed (read: got fucked before, now can avoid the treacherous waters and apply effort where and when meaningful).
Ability to deal with herding cats much needed as well.
Add relentless ability to move forward and not hold grudges.
> if you have a skilled set of programmers on your team
Emphasis mine. You probably have more experience than I do, but largely I've seen it to be true that skilled (or, in the absence of skill, passionate) programmers tend to self-organize, as long as they all have the same goal (which hopefully is true for the majority of your team - if not, no methodology is going to help you).
Emphasis mine. You probably have more experience than I do, but largely I've seen it to be true that skilled (or, in the absence of skill, passionate) programmers tend to self-organize, as long as they all have the same goal (which hopefully is true for the majority of your team - if not, no methodology is going to help you).
At several previous jobs I went on and on about how most process was unnecessary and nobody would believe me that you could do with less process. Then I joined a company with better people that has minimal to no process, and we make it work well, and it's the best job I've ever had.
All the companies I was at before this one that hid behind process had the usual problems with quality, scheduling, communication, etc. There's no process that's going to pull excellent work out of average people. It's just band-aids that keep people from taking real responsibility because they believe the Process will take care of things.
All the companies I was at before this one that hid behind process had the usual problems with quality, scheduling, communication, etc. There's no process that's going to pull excellent work out of average people. It's just band-aids that keep people from taking real responsibility because they believe the Process will take care of things.
Absolutely... as others here have said, if you don't have people who want to think, then no amount of process can save you. You only have deal with any official bureaucratic process or government department to see that.
From my POV, a minimum amount of process is useful to keep things on the rails when the pressure goes on, so people don't end up doing things wrong. After all, unit tests, git and CI are 'process'...
From my POV, a minimum amount of process is useful to keep things on the rails when the pressure goes on, so people don't end up doing things wrong. After all, unit tests, git and CI are 'process'...
which is in fact "Individuals and interactions over processes and tools", in the agile manifesto.
Really the manifesto is absolutely sensible.
It is, but tool vendors joined the party and talked to C-level people...
Those people also cost money, and most managers are allergic to spending money on good people (ignoring the difficulties in finding those people in the first place).
> if you have a skilled set of programmers on your team you probably don't need Agile. They are self-managed and tend to do the Right Thing (TM) on their own.
"Any sufficiently complicated company w/o management contains an ad hoc, informally-specified, bug-ridden, slow implementation of management”--wycats
"Any sufficiently complicated company w/o management contains an ad hoc, informally-specified, bug-ridden, slow implementation of management”--wycats
I largely agree, but think it has more to do with passion or interest than strictly skill. Any process that leads people to work with each other to GSD seems best. The best project I've ever been apart of was with myself and a couple others in other time zones in our free time. We communicated by email with our progress, what we planned to do, what we needed from others, etc. And since the team was small, everyone had their place and pitched in, and we created something beautiful at an amazing pace. It is an open source project I work on to this day, though largely just small fixes anymore.
In a corporate environment, you tend to have some burn outs, some 'holier-than-thou', some paycheck collectors, etc. The biggest difference probably is that you can't choose who you work with. It seems Agile as I've seen is implemented around that, which ultimately discourages the behaviors described in the prior paragraph. It becomes one writing quickly to finish things for the manager, rather than writing things for your coworkers.
In a corporate environment, you tend to have some burn outs, some 'holier-than-thou', some paycheck collectors, etc. The biggest difference probably is that you can't choose who you work with. It seems Agile as I've seen is implemented around that, which ultimately discourages the behaviors described in the prior paragraph. It becomes one writing quickly to finish things for the manager, rather than writing things for your coworkers.
^^^ Exactly this. I've seen Agile work extremely well when experienced developers decide "we need to change how we've been doing things". Coming down from management it becomes just another way of lowering the boom on development. Furthermore I think the correct pronunciation for "Scrum" is "Scrummerfall".
I have just bought a "Learning GROWS" book from the Pragmatic Programmer online store, and have hired a consultant to educate (inculcate?) the team on the new methodology.
We even are using one of the new open source libraries that tests and enforces the process, it is called 'poison ivy' - it hurts, like all good software engineering processes do!
Edit: do the downvoters disagree? We don't think there will be books, courses, tools for this new methodology?
We even are using one of the new open source libraries that tests and enforces the process, it is called 'poison ivy' - it hurts, like all good software engineering processes do!
Edit: do the downvoters disagree? We don't think there will be books, courses, tools for this new methodology?
Most people here are humor impaired. Don't try to be funny. It won't work.
We're not humor impaired, there's just a higher bar. Otherwise it becomes like every other internet forum ever: dominated by one-liner meme-based reply-chains that drown out the real conversation.
Then maybe we're irony-impaired. The head of this chain was making a point ironically. It in fact took me a moment to fully appreciate the fact.
It really, apparently, isn't a joke: https://twitter.com/growsmethod/status/596404929679458304
I've found Agile to be a collection of useful tools, but just like "opinionated" framework, it's only perfect for solving the author's problems. In my experience, agile works better for web apps than native mobile apps.
What worries me is toxic dogma. Too many Agile people say:
* "Agile failed? They weren't practicing it correctly!" a.k.a. the "No True Scotsman" fallacy * "You have to choose between Waterfall and Agile" a.k.a. the "Black and White" fallacy.
I realize that not all agile people are like this, but there are enough vocal members of the community that it reminds me of religious fundamentalism.
What worries me is toxic dogma. Too many Agile people say:
* "Agile failed? They weren't practicing it correctly!" a.k.a. the "No True Scotsman" fallacy * "You have to choose between Waterfall and Agile" a.k.a. the "Black and White" fallacy.
I realize that not all agile people are like this, but there are enough vocal members of the community that it reminds me of religious fundamentalism.
I've seen Agile work, except it wasn't called Agile, and it was before Agile existed.
At a small game studio, you may have one guy that knows the hardware really well at a low level, but not the engine or how it's used, but the engine developer does. When you put these two guys in a room together, they will crank out something beautiful in an amazing amount of time, something neither of them could have accomplished alone.
That's agile. Not whatever crap the current mantra is. The manifesto gets this, but it never should have been made into a process.
At a small game studio, you may have one guy that knows the hardware really well at a low level, but not the engine or how it's used, but the engine developer does. When you put these two guys in a room together, they will crank out something beautiful in an amazing amount of time, something neither of them could have accomplished alone.
That's agile. Not whatever crap the current mantra is. The manifesto gets this, but it never should have been made into a process.
A key thing not mentioned in the article or the comments, is that agile only works for certain kinds of software (when the software category is still being custom built).
For others (when the software category has become a commodity), waterfall methods like six sigma are better.
Simon Wardley is great on this:
http://blog.gardeviance.org/2014/07/agile-agile-everywhere.h...
For others (when the software category has become a commodity), waterfall methods like six sigma are better.
Simon Wardley is great on this:
http://blog.gardeviance.org/2014/07/agile-agile-everywhere.h...
Agile fails at most companies because they fail to understand that Agile is a culture not a process. Take the first statement of the manifesto, to allow the individuals to interact you have devolve responsibility down to the level where individuals can make decisions without having to run it up the ladder.
This scares the crap out of alpha executives and so they throw process and tools to ensure that the individuals interact in the "correct" way defeating the whole effort.
This scares the crap out of alpha executives and so they throw process and tools to ensure that the individuals interact in the "correct" way defeating the whole effort.
You're describing this:
http://www.halfarsedagilemanifesto.org/
http://www.halfarsedagilemanifesto.org/
> GROWS in this case is an acronym, for GRowing Real-World Oriented Working Systems
Why emphasize the R in GRowing when the R for GROWS could have been taken from "Real-world"?
Why emphasize the R in GRowing when the R for GROWS could have been taken from "Real-world"?
Uh oh, The Client is figuring out that Agile isn't a silver bullet for building great software... Time to turn the crank..
Get your team GROWS™ certified today!
Get your team GROWS™ certified today!
It looks like all sw development processes try to guarantee budget by taming "unanticipated change". Unfortunately this can't be planned or taken into account early enough, by the definition of "unanticipated". Some processes are better in avoiding collateral damages when trying to restore the budget than others, but at the end of the day, we have a change in our hands.
People can call these things whatever they like: there is a difference between passion and indifference that cannot be overcome by any process.
"Agile methods ask practitioners to think, and frankly, that‘s a hard sell."
Wonderful point, and spot-on. But that's not just for agile newbies, I'd extend that to other groups that are immersed in something. The best example I can think of at the moment are MBAs. For whatever reason, smart people go off to charm school, earn their MBA, and then forget how to think.
Wonderful point, and spot-on. But that's not just for agile newbies, I'd extend that to other groups that are immersed in something. The best example I can think of at the moment are MBAs. For whatever reason, smart people go off to charm school, earn their MBA, and then forget how to think.
I've been at one place where agile/scrum worked. None of us were superstar 10x developers. What made it work was that we had a lot of trust between the developers and management. And that we knew the code-base well enough to be able to give accurate estimates (low turnover is good that way).
It sounds like Andy Hunt has finally discovered ISO 9000. Plan. Implement. Measure. Review. Improve.
The pattern I keep seeing is the IT community's need to re-invent the wheel and give it names like 'agile', 'scrum', etc. Why can't people call a wheel a wheel?
The pattern I keep seeing is the IT community's need to re-invent the wheel and give it names like 'agile', 'scrum', etc. Why can't people call a wheel a wheel?
It appears this is less about agile and more about some new... thing... called GROWS:
http://growsmethod.com/
I can't figure out what it is, though. Then again, I never figured out what agile is either.
http://growsmethod.com/
I can't figure out what it is, though. Then again, I never figured out what agile is either.
Relevant talk by 'Uncle Bob' about how Scrum became what it is now, as opposed to what it was intended to be:
https://www.youtube.com/watch?v=hG4LH6P8Syk
https://www.youtube.com/watch?v=hG4LH6P8Syk
I think methodologies in general don't work as they are basically someone's reflection on some process (ex. Lean Startup by Eric Ries), an attempt to generalize one's experience that isn't widely applicable by construction.
The new agile manifesto:
1. You're doing agile wrong.
2. If you pay me I can make it so you're doing agile right.
1. You're doing agile wrong.
2. If you pay me I can make it so you're doing agile right.
Is a "new Agile" really what will solve this problem? I think really this just isn't a priority for many employers. Maybe we just need something new so us employees can see who's paying attention and flock there?
Agile cannot fail. People fail. People will fail at whatever process or method for various reasons. At least Agile methods embrace failure and demand adaption or change in order to become successful again.
> Agile cannot fail. People fail.
a.k.a self immunization
a.k.a self immunization
while we're in this discussion, is there any good hosted agile/scrum tool? (note: asana doesn't seem to count, it's too flexible, like a glorified todo app).
if there isn't any, i'd take this as an opportunity to develop one (i recently acquired agile.id and scrum.id domain, otherwise i'll just sell the domains).
...or maybe because their mantra "people over process" so the practitioners never feel the need of management software?
if there isn't any, i'd take this as an opportunity to develop one (i recently acquired agile.id and scrum.id domain, otherwise i'll just sell the domains).
...or maybe because their mantra "people over process" so the practitioners never feel the need of management software?
process is often the symptom of tight coupling.
That sounds really strange to me, to the point that I'm not sure if you are being sarcastic.
Sarcastic or not, it's true.
I mean, it's completely tautological; conveys no useful information, and must be fully understood before acting over it in any way.
It's also funny. I'm upvoting :)
I mean, it's completely tautological; conveys no useful information, and must be fully understood before acting over it in any way.
It's also funny. I'm upvoting :)
Good process adds latency to the development cycle while reducing risk.
"Agile process" is an oxymoron. Agile hasn't failed, process has.
[deleted]
GROWS (TM) sounds like another Scrum instead of being another Agile.
If any of you would like to learn more about GROWS™, I have started a GROWS™ consultancy, and I am also offering a GROWS™ certification process. My GROWS™ stands for God-awful Regurgitation Of Weak-ass Snakeoil. These seem like important concepts.
Any discussion about agile invariably yields the predictable flurry of personal hangups and misrepresentations.
Most common of all, though, are the claims that if you just have a great team full of great developers, you don't need a process. Agile and waterfall both be damned.
But most teams aren't great. Most of the teams of people participating on HN statistically aren't great. But those teams still need to develop something -- banks and big cos and countless firms are churning out code by the millions of lines, by millions of completely average developers -- and agile is an honest conclusion that the classic method of software development doesn't work, most critically by biting off work in such enormous chunks that implementation or design issues -- the fit to the problem -- aren't discovered until enormous efforts have been wasted.
So talk about how agile failed, in your estimation, at some shop or another. But the truth is that almost anything would be a "failure" versus the idealized notion of a perfect design built expertly by great developers. Agile is trying to make the best of a normal situation.
Most common of all, though, are the claims that if you just have a great team full of great developers, you don't need a process. Agile and waterfall both be damned.
But most teams aren't great. Most of the teams of people participating on HN statistically aren't great. But those teams still need to develop something -- banks and big cos and countless firms are churning out code by the millions of lines, by millions of completely average developers -- and agile is an honest conclusion that the classic method of software development doesn't work, most critically by biting off work in such enormous chunks that implementation or design issues -- the fit to the problem -- aren't discovered until enormous efforts have been wasted.
So talk about how agile failed, in your estimation, at some shop or another. But the truth is that almost anything would be a "failure" versus the idealized notion of a perfect design built expertly by great developers. Agile is trying to make the best of a normal situation.
"But most teams aren't great"
Most teams work hard enough to become great. Most teams work long enough hours to become great. Most teams are smart enough to become great. Most teams even have the desire to become great.
So what is stopping them?
At the developer level: Lack of autonomy, lack of purpose, and lack of mastery. These issues aren't fixed by Agile.
At the management level: High turnover. Lack of attention/focus on things that aren't easily measurable. Lack of leadership. Constant arbitrary deadlines. A short term focus. Politics. Again, none of it fixed by Agile.
Most teams work hard enough to become great. Most teams work long enough hours to become great. Most teams are smart enough to become great. Most teams even have the desire to become great.
So what is stopping them?
At the developer level: Lack of autonomy, lack of purpose, and lack of mastery. These issues aren't fixed by Agile.
At the management level: High turnover. Lack of attention/focus on things that aren't easily measurable. Lack of leadership. Constant arbitrary deadlines. A short term focus. Politics. Again, none of it fixed by Agile.
This is a great insight, and describes some of the projects I've worked on exactly. I think a fix to these two problems is to hire great developers that you can trust, and give them much bigger tasks. I find that the management breaks things up into too small of tasks so that they can measure it, which creates a bottom up approach, and that's just not how good software works. I prefer the top down approach, which means design the code from a high level (architecture, components, overall structure) then drill down and build the different parts.
I'm not sure what your argument is here. Because the classical model failed agile can't fail too?
I think you're also misunderstanding "great teams". I at least do not mean a team of great developers, but a team that works well together. It's a great team, not a great group of developers. You can have the best developers in the world, it won't work if they can't stand each other.
I think you're also misunderstanding "great teams". I at least do not mean a team of great developers, but a team that works well together. It's a great team, not a great group of developers. You can have the best developers in the world, it won't work if they can't stand each other.
The "argument" is that making software is an ugly, brutish affairs in virtually every case, with virtually every approach. There are extraordinarily few cases throughout history where a team converged, looked at the problem, built a solution, and voila, everyone emerged happy. In the real world there is always a discord between requirements and reality, skillsets and the problem space, change management and the need for rapid change, scope creep, and on and on.
It is the story of every software project everywhere throughout time.
But invariably the comments will fill with tales of woe with agile (usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions. It serves as the canary in the coal mine when noxious gases are afoot), as if troubled projects are some unique reality of agile. They're a reality of every single methodology. Agile merely tries to help reduce a few of the bigger and most deadly issues, which are friction with the business (the ability to adapt to change), and enormous investments of time and money to a project that ends up being a solution to the wrong problem. It doesn't suddenly make everyone cooperative and great.
As to my "misunderstand", so the solution as you see it is just to have developers that work well together. Easy peasie solution.
It is the story of every software project everywhere throughout time.
But invariably the comments will fill with tales of woe with agile (usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions. It serves as the canary in the coal mine when noxious gases are afoot), as if troubled projects are some unique reality of agile. They're a reality of every single methodology. Agile merely tries to help reduce a few of the bigger and most deadly issues, which are friction with the business (the ability to adapt to change), and enormous investments of time and money to a project that ends up being a solution to the wrong problem. It doesn't suddenly make everyone cooperative and great.
As to my "misunderstand", so the solution as you see it is just to have developers that work well together. Easy peasie solution.
You've created a strawman to attack by citing waterfall.
Stop citing waterfall as the reason for agile methodologies. It's like citing the lack of evidence for a christian God as the reason Science exists instead of pointing out how effective science has been in helping us control our environment.
And if you can't describe how effective Agile has been, then have you no reason for your opinion outside of religious views. Which is ok if it works for you, but don't attack a strawman as a way of dismissing other people's experiences.
Stop citing waterfall as the reason for agile methodologies. It's like citing the lack of evidence for a christian God as the reason Science exists instead of pointing out how effective science has been in helping us control our environment.
And if you can't describe how effective Agile has been, then have you no reason for your opinion outside of religious views. Which is ok if it works for you, but don't attack a strawman as a way of dismissing other people's experiences.
Speaking of strawmen, where did I cite waterfall? The entire foundation of your post is a fiction.
Software is tough. It is always, and has always been tough. The same flexibility that is the great benefit of the domain is also its curse. This is true across any methodology, so try not to project your own hangups into that statement.
Agile is something that some shops try to do, imperfectly, against that reality. Every one of these angry anti-agile comments seem to opine that agile is terrible versus some mythical alternative that is shapeless and amorphous, boiled down to "have a great team". That is, quite simply, nonsense. It is the pat solution of the bottom feeder.
Religious views? Again, the entire foundation of the anti-agile screed, which is generally by people with a chip on their shoulder (and they probably had a chip on their shoulder about everything that people with more influence over them got adopted) is that it is deficient compared with an unspoken, unstated alternative.
And I'm the one bringing religion in this? Christ.
Software is tough. It is always, and has always been tough. The same flexibility that is the great benefit of the domain is also its curse. This is true across any methodology, so try not to project your own hangups into that statement.
Agile is something that some shops try to do, imperfectly, against that reality. Every one of these angry anti-agile comments seem to opine that agile is terrible versus some mythical alternative that is shapeless and amorphous, boiled down to "have a great team". That is, quite simply, nonsense. It is the pat solution of the bottom feeder.
Religious views? Again, the entire foundation of the anti-agile screed, which is generally by people with a chip on their shoulder (and they probably had a chip on their shoulder about everything that people with more influence over them got adopted) is that it is deficient compared with an unspoken, unstated alternative.
And I'm the one bringing religion in this? Christ.
I may have responded to the wrong person (or you've edited your post) as the post I meant to respond to was most definitely comparing waterfall to agile.
It's very common for agile proponents to push Waterfall as the necessary alternative to agile, but that's a logical fallacy.
It's very common for agile proponents to push Waterfall as the necessary alternative to agile, but that's a logical fallacy.
> In the real world there is always a discord between requirements and reality, skillsets and the problem space, change management and the need for rapid change, scope creep, and on and on.
We follow Agile. At the beginning of iteration planning, the dev-team, has to task-out the items and score the complexity, and then decide the cut-off point as to what can and cannot be achieved within the 2 week iteration.
It's taken us several years, but this ruthless cycle of feedback, and responsibility has led us to a point, where we scope it right about 75% of the time.
Having also been involved in projects that have overrun deliverable dates by years - I wouldn't have believed it possible for a software-management process to work so well.
Of course it helps, that there is genuine philosophical buy-in, and that our revenue is derived from our software (eg. we're not a cost-centre).
We follow Agile. At the beginning of iteration planning, the dev-team, has to task-out the items and score the complexity, and then decide the cut-off point as to what can and cannot be achieved within the 2 week iteration.
It's taken us several years, but this ruthless cycle of feedback, and responsibility has led us to a point, where we scope it right about 75% of the time.
Having also been involved in projects that have overrun deliverable dates by years - I wouldn't have believed it possible for a software-management process to work so well.
Of course it helps, that there is genuine philosophical buy-in, and that our revenue is derived from our software (eg. we're not a cost-centre).
Once again.
> Because the classical model failed agile can't fail too?
> so the solution as you see it is just to have developers that work well together. Easy peasie solution.
No one said it's easy. No one said you can just have it. No one claims it's the solution to how we build software.
> usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions
Why don't you just tell me you think I completely lack understanding of the subject matter?
> Because the classical model failed agile can't fail too?
> so the solution as you see it is just to have developers that work well together. Easy peasie solution.
No one said it's easy. No one said you can just have it. No one claims it's the solution to how we build software.
> usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions
Why don't you just tell me you think I completely lack understanding of the subject matter?
The beauty of Agile is: if you question or criticize it, you don't understand it; if it didn't work for you, you didn't apply it properly; if you applied it rigorously and it failed, you didn't have a deep understanding of it. Was it Sartre who said "it is what it is not"?
Agile is not an "it", agile is not static. Application of agile principals means guiding and improving development processes. This is not a damned if you do damned if you don't scenario. As the article suggested, you have to "inspect and adapt". If something did not work for you, then capture the results, perform a lesson's learned, and try again.
To say "apply agile methods", is to apply a nimbleness of the mind. This is where not everyone "gets it" right away. If someone suggests a paradigm shift from what you as a developer are accustomed to, you may very well fall flat on your face. But to apply agile methods means to be able to get back up and try a different approach.
To say "apply agile methods", is to apply a nimbleness of the mind. This is where not everyone "gets it" right away. If someone suggests a paradigm shift from what you as a developer are accustomed to, you may very well fall flat on your face. But to apply agile methods means to be able to get back up and try a different approach.
The very definition of agile seems itself to be very "agile" and constantly changing depending on the discussion.
[deleted]
None of the people who complain about agile offer any viable alternatives. I get the impression that these are developers who simply hate being managed period, and would prefer that management never spoke to them at all.
I certainly wouldn't mind if the middle manager that had an hour long meeting today never spoke to me again. The first slide was MLK with "I have a dream" which then continued onwards with 15 minutes talking about how to move post-it stickers on a whiteboard and 15 minutes spent doing a failed analogy between a GPS and continuous reevaluation of when the next release will be done.
At the same time, management has decided to have a release cycle that is 10 months (or in reality after the inevitable delays: 12)..
At the same time, management has decided to have a release cycle that is 10 months (or in reality after the inevitable delays: 12)..
Because there isnt a one size fits all approach that works well. The most effective project I have worked on had ~15 hours of meetings every week.
the thing that often gets lost in these discussions is that a software development process is mainly a method of communicating state to management. management does need to know, despite developer complaints, because company resources need to be allocated and tracked.
if developers can't figure how to let management get the information they need, then management will impose whatever they think is best, even if they have no particular way of figuring that out.
the failure of agile is mainly a breakdown in this communication. the process itself works if it is followed, just as lighter and heavier processes can work. are they optimal? probably not, but communication amongst teams is a fairly difficult problem to optimize and it's likely to not have any one solution.
if developers can't figure how to let management get the information they need, then management will impose whatever they think is best, even if they have no particular way of figuring that out.
the failure of agile is mainly a breakdown in this communication. the process itself works if it is followed, just as lighter and heavier processes can work. are they optimal? probably not, but communication amongst teams is a fairly difficult problem to optimize and it's likely to not have any one solution.
I've worked at over a dozen places claiming to be agile to some degree, shape, or form, and have yet to see a process that's even remotely close, let alone agile. The failure of agile isn't that it takes time to learn and practice correctly or that it's too rigid. Its main failure is an inability to communicate its purpose to its users effectively. Agile is a good process in theory, but it seems the original creators did not anticipate the people that would try to put it into place and their agendas.
Agile goes against the mandates of almost all corporate culture in that it requires one to get out of the estimates as deadline mindset that rules corporate development. Agile tries to be flexible because that's the only rational option when developing software. When faced with irrationality, however, agile just becomes another justification for deadlines, time-wasting meetings (standup and otherwise), and other nonsense that leads to a productivity plunge everywhere I've seen it implemented.
This corporate culture based around deadlines and subservience of engineers is something that cannot simply be defeated with a methodology, especially when that methodology is, at best, only partially adopted. I will go as far to say that there is no methodology that can change this mindset. Regardless of what the author thinks, corporations and their managers will simply not allow something that will disrupt their world views and opinions.
While agile was trying to solve the problem of waterfall design--which is not always a problem and sometimes the best process--many corporate schmucks (both in management and engineering, both at giant companies and startups) saw it as a way to eliminate the design stage altogether. What great software has resulted! While agile was pushing for quicker iteration and release cycles so that code and features doesn't pile up and prevent / delay / disrupt the release, many corporate schmucks (managers only in this case) decided to use it as a justification for working their engineers overtime so they could push the features they "promised" out live by the release date.
There are few things in this industry that have wasted as much time as the doomed implementation of agile. Many have gotten rich off of it, but it has provided little to no value. The idea that processes can be malleable and flexible that the author advances is just pure insanity. It may work with a group of hackers cranking something out, but something like that will especially be discarded or twisted into something dark by management.
This idea, that a perfectly good process can be turned against itself is what the author does not understand and why his new process will likely fail in the same, dangerous way (should it gain acceptance and adoption), wreaking havoc on the engineers and managers it was supposed to help.
Agile goes against the mandates of almost all corporate culture in that it requires one to get out of the estimates as deadline mindset that rules corporate development. Agile tries to be flexible because that's the only rational option when developing software. When faced with irrationality, however, agile just becomes another justification for deadlines, time-wasting meetings (standup and otherwise), and other nonsense that leads to a productivity plunge everywhere I've seen it implemented.
This corporate culture based around deadlines and subservience of engineers is something that cannot simply be defeated with a methodology, especially when that methodology is, at best, only partially adopted. I will go as far to say that there is no methodology that can change this mindset. Regardless of what the author thinks, corporations and their managers will simply not allow something that will disrupt their world views and opinions.
While agile was trying to solve the problem of waterfall design--which is not always a problem and sometimes the best process--many corporate schmucks (both in management and engineering, both at giant companies and startups) saw it as a way to eliminate the design stage altogether. What great software has resulted! While agile was pushing for quicker iteration and release cycles so that code and features doesn't pile up and prevent / delay / disrupt the release, many corporate schmucks (managers only in this case) decided to use it as a justification for working their engineers overtime so they could push the features they "promised" out live by the release date.
There are few things in this industry that have wasted as much time as the doomed implementation of agile. Many have gotten rich off of it, but it has provided little to no value. The idea that processes can be malleable and flexible that the author advances is just pure insanity. It may work with a group of hackers cranking something out, but something like that will especially be discarded or twisted into something dark by management.
This idea, that a perfectly good process can be turned against itself is what the author does not understand and why his new process will likely fail in the same, dangerous way (should it gain acceptance and adoption), wreaking havoc on the engineers and managers it was supposed to help.
Agile glorifies treading water, which will sometimes save your life, but won't get you anywhere. The problem is that it discourages actually swimming, and people forget how.
To explain: where this sort of project management actually works is in a short-term, time-limited crisis that large companies might call a "Code Red" or (in the original meaning of the word) a Scrum. See my Quora post on the topic: http://www.quora.com/Why-do-some-developers-at-strong-compan...
When you're a small web consultancy that has landed a make-or-break project that (say) must be delivered inside of 4 weeks, and when you have absolutely no leverage and must accept any changes in scope as they come, Agile can work. You can reasonably expect people to set aside their long-term goals (career progress, tech debt reduction) and solve the problem at hand. Moreover, when you're a big company fighting a Code Red (meaning, money is being lost right now in large amounts) and have to assemble a cross-cutting do-nothing-else-for-now team with no clear manager, Scrum can actually make sense.
In a true sprint-- a short-term reorganization necessary to solve an immediate problem-- unsustainable effort is OK because, well, no one's going to be expected to sustain it. You're under a short term emergency. You can ignore whether the assigned work helps peoples' careers, because they're not going to be doing it for long. You can mandate that people work on the "official" top priority (of which there's only one) and most people will do so.
The problem is the perma-Scrum that's been sold (dishonestly) by the Agile industry. This stuff works for a few weeks and people don't mind doing it. In fact, even if the work itself is painful and the hours are bad and status updates are (by necessity) frequently demanded, being tapped for the "elite emergency team" is something that people generally like and, over a span of 2 to 6 weeks, it gets results. However, when you have permanent "sprinting" and frequent status meetings or impose these rules over the whole organization, it starts to hurt morale. It starts to feel less like being on an elite emergency team and more like a culture of permanent juniority/micromanagement... which is what Scrum/Agile has become in many organizations.
To explain: where this sort of project management actually works is in a short-term, time-limited crisis that large companies might call a "Code Red" or (in the original meaning of the word) a Scrum. See my Quora post on the topic: http://www.quora.com/Why-do-some-developers-at-strong-compan...
When you're a small web consultancy that has landed a make-or-break project that (say) must be delivered inside of 4 weeks, and when you have absolutely no leverage and must accept any changes in scope as they come, Agile can work. You can reasonably expect people to set aside their long-term goals (career progress, tech debt reduction) and solve the problem at hand. Moreover, when you're a big company fighting a Code Red (meaning, money is being lost right now in large amounts) and have to assemble a cross-cutting do-nothing-else-for-now team with no clear manager, Scrum can actually make sense.
In a true sprint-- a short-term reorganization necessary to solve an immediate problem-- unsustainable effort is OK because, well, no one's going to be expected to sustain it. You're under a short term emergency. You can ignore whether the assigned work helps peoples' careers, because they're not going to be doing it for long. You can mandate that people work on the "official" top priority (of which there's only one) and most people will do so.
The problem is the perma-Scrum that's been sold (dishonestly) by the Agile industry. This stuff works for a few weeks and people don't mind doing it. In fact, even if the work itself is painful and the hours are bad and status updates are (by necessity) frequently demanded, being tapped for the "elite emergency team" is something that people generally like and, over a span of 2 to 6 weeks, it gets results. However, when you have permanent "sprinting" and frequent status meetings or impose these rules over the whole organization, it starts to hurt morale. It starts to feel less like being on an elite emergency team and more like a culture of permanent juniority/micromanagement... which is what Scrum/Agile has become in many organizations.
You're saying that Scrum and Agile promote long hours?
What does "sprinting" mean?
Long hours are just one variety of unsustainable practice. Accumulation of technical debt, and an absence of concern for individuals' career needs and goals, are likewise acceptable in the context of a short-term emergency but not sustainable.
In perma-Scrum terminology, though, the end of one sprint leads straight into the next. This is the core problem with Agile/Scrum as it's sold: it takes behaviors that are known to be unsustainable and encourages people to carry them permanently, and then says they're not doing them right (No True Scrumsmen) if the arrangement deteriorates. It can't be sold truthfully, as a short-term fix that does a lot of damage if it stays in place for too long-- no one would buy it if it were advertised as something that only works for 6 weeks, max, out of a given year-- so the Agilemongers present it as a permanent arrangement.
In perma-Scrum terminology, though, the end of one sprint leads straight into the next. This is the core problem with Agile/Scrum as it's sold: it takes behaviors that are known to be unsustainable and encourages people to carry them permanently, and then says they're not doing them right (No True Scrumsmen) if the arrangement deteriorates. It can't be sold truthfully, as a short-term fix that does a lot of damage if it stays in place for too long-- no one would buy it if it were advertised as something that only works for 6 weeks, max, out of a given year-- so the Agilemongers present it as a permanent arrangement.
I think you are confused. A "sprint" is not "crunch". Its not a period where we work our asses off, late hours, weekends etc. A sprint is just a period of time. For us its two, forty hour weeks. Its sustainable and we've been doing it for 16 months.
It leads to a very confusing situation, where on the one hand the team is lauded for being the most productive team in the company, and on the other, for not working hard enough. o_0
If you can find anything in any Scrum publication that says otherwise then you can make the No True Scotsman claim, but otherwise you are at best misinformed.
It leads to a very confusing situation, where on the one hand the team is lauded for being the most productive team in the company, and on the other, for not working hard enough. o_0
If you can find anything in any Scrum publication that says otherwise then you can make the No True Scotsman claim, but otherwise you are at best misinformed.
The best project manager I ever worked with, in the 16 years I've done this work, was a woman who initially did not have a technical background, but she was willing to dive into the technical end of things. She eventually taught herself SQL and how to write Cucumber tests, so she could better QA test the code she was overseeing. I met when she was in her 4th year, and she had an impressive skill for estimating how long a given task would take, and whether things were going well or badly.
If you have someone really good in charge, and they call their system "Agile", then it might appear that Agile works. If you have someone terrible in charge, and they call their system "Agile", then it might appear that Agile sucks. Likewise, if they call their system "XP" or "Deep Review" or anything else. But the only process that seems to matter is "have someone really good in charge."