Kent Beck and Alistair Cockburn are two of the original Agile Manifesto signatories. Since publishing the Manifesto in 2001, agile development has become a popular practice. Used by thousands of development teams, agile development can be very beneficial to a project's success, but there is a real danger that a project adopt agile in name, but not in spirit, says a recent CIO.com article, When Agile Projects Go Bad.
Based in part on interviews with Back and Cockburn, the article points out that dogmatic application of the agile practices are at the hear of the danger of misusing the agile label:
A typical developer pain point is when Agile techniques are applied dogmatically, without thinking through whether a specific practice makes sense for a given task. They confuse checklists with real Agile adoption...
When companies apply Agile practices without self-examination, Beck says, peril lies ahead. When companies try to "do" Agile mechanically, he says, "We ask, 'Well, aren't you talking about it? About what's working and not working in the quality of your communications and your community?'" Because the initial community was self-motivated, those issues didn't need to be addressed early on. "These are the things we didn't think to say back in 2001, and now we're seeing people applying it very mechanically, we're seeing what's missing."
While customer communication is at the heart of agile practices, Alistair Cockburn points out that some teams use the agile development label to avoid having to completely take in customer's view of a project:
They start going around in circles, and the customers or users try to tell them what they want, and the developers say 'No, no, no! That's too much information. Just give me the first sentence out of what you said and I'll go build it.' And then the users say 'But no, it's more complicated than that, let me tell you more.' The developers say 'That's all I need, we're doing increments, let me just build that.'" The result, of course, is that "They go around in circles, and they get lost, and they're over-budget.
At the same time, Cockburn also notes that developers have to have a clear scope of the project in mind from the outset:
The user stories multiply like rabbits... If you were to do a burn-up chart, where the line goes toward the ceiling, instead of down toward zero, you'd find that the ceiling is going up faster than the progress being made...
I'm not sure where this has come out of the manifesto... But what happens is that [developers] say 'We don't need to know how big the problem is, because we'll give you great stuff as we go along.' So they never figure out the shape of what it is they're building, which means they don't have a clue how much it's going to cost.
The latter point directly relates to the need for developers to make, and keep, commitments, even in the face of some uncertainty:
It's good for teams to call their shots, but Beck says it's important to make commitments. That isn't easy when you don't know a lot about the user's needs, and it can be hard to know what to say with any certainty. Still, Beck says, you can explain to management and users, "At the end of the week, we're going to know something we didn't know before," even if you can't say that at the end of the week you'll have a specific feature.
Finally, some agile converts try to apply the agile principles dogmatically, without adapting it to the needs of specific projects, says Cockburn in the interview:
I'm one of the authors of the manifesto, so if I say something 'weird,' they can't tell me I don't understand Agile. But if someone else—and it doesn't matter how many years of experience they have—says something funny, they get told they don't understand Agile...
I get called in by a CIO, CTO, any CXO, and they're suffering because their programmers are telling them 'You don't know anything about Agile. Agile means we don't have to give you a plan, Agile means we don't need an architecture'—a whole bunch of rubbish that isn't in the Agile manifesto.
What do you think are some of the biggest Agile mistakes teams make?
I think the biggest mistake possible is to apply the process and not to adapt the company culture towards continuous improvement. The problem is that the latter one is harder by orders of magnitude. So if you keep applying the broomstick* mentality of following rules blindly, you will end up in a nightmare, no matter what process you are following. That said, there is one true advantage of Agile: If you fail, you fail faster.
no, the biggest problem (as said) is using the word "Agile" as an excuse to avoid planning and design, or to use it as an excuse to dogmatically stamp out any opinion that's different from your own. In extreme cases it's used as a blanket term to just get rid of people you don't like. As there's no clearcut definition of "Agile", yet many companies tout their commitment to it, accusing someone of "not being Agile" is a surefire way to get rid of them. Next performance review, they go down and can be fired for "not following standards" or some such.
Isn't that problem a part of "adapting Agile beyond the process"? Would you have dogmatists in a company that practices continuous improvement? Isn't that a contradiction?
> Isn't that problem a part of "adapting Agile beyond the > process"? Would you have dogmatists in a company that > practices continuous improvement? Isn't that a > contradiction?
There is always some danger in hiding ideology in humanist or libertarian phrases like "agile is about people not processes" and I think that's what Jeroen refers to. It's always nice to dissolve contradictions within an utopian horizon e.g. "the totally agile company" where everything and everyone is reconciled but this prevents us from acknowledging some very simple facts of life. For example rules, bureaucracy and some rigidity ( the opposite of "agile" apparently ) are always annoying and lead to more abstract/alienated work but they also shield programmers from arbitrariness of management decisions. What if all those documents produced and signed in pre-agile processes are some tax and insurance that aid in clarifying responsibilities on both sides?
> What do you think are some of the biggest Agile mistakes teams make?
Maybe even "best practices" can become cargo cultish and meaningless. But that's not about agile specifically. The worst thing about "agile" is that it has been turned into an idealism and an utopian idea.
What if one restates the whole methodological discussion under a more defensive viewpoint with a less sexy but more honest agenda? There are incredibly many bad programmers and bad managers who all overrate themselves, who give up on thinking about the whole and are full of ideosyncratic ideas and behaviors [1]. A process is just a means to standardize behavior, define contracts, tasks, interfaces, workflow, documents and responsibilities. It doesn't create a mesmeric flow that turns our work into collective poetry and a team of programmers from alienated workers into an archaic hunter/gatherer tribe. This might happen occasionally but it's not the primary goal of corporate development that is just finished when the paying customer finds a cheaper or more feature rich product.
[1] I wouldn't take this too literally as well because it leads to blame games and mystifications of "great people who are 10 times better than the rest" and similar macho bullshit. It is rather a methodological assumption. Just as if you create tests and suspect that every method can fail or create a security system under the assumption that everyone is a potential cracker.
Correction: What I wanted to write is "adopting Agile beyond the process" not "adapting". For me it is strange to think of ideology in combination with Agile. Agile methods such as Scrum did not pop up out of an utopists mind. They were created out of pragmatism. There has been a long learning phase that started in the mid 1990s* and it is not over yet. Of course there is no-one out there that succeeds with Agile or whatever without discipline. Moreover, rules and bureaucracy are necessary to some degree but they are no silver bullets either. If they where, why are so many waterfall projects so miserably failing although they had piles of documentation and signed off forms around**?
> Correction: What I wanted to write is "adopting Agile > beyond the process" not "adapting". > For me it is strange to think of ideology in combination > with Agile. Agile methods such as Scrum did not pop up out > of an utopists mind.
I think what the article is getting at is that Agile has become the new dogma. The problem isn't with Agile per se, it's that people throw the term around and use it as a bludgeon in political struggles.
> I think what the article is getting at is that Agile has become the new dogma. The problem isn't with Agile per se, it's that people throw the term around and use it as a bludgeon in political struggles.
You are perfectly right but it takes too here: one that argues that way and another that accepts that ;-). It seems to be extremely important that management gets to know what Agile is about in their language. Would that have happened in the companies mentioned, chances are good that that stupidity never had happened in the first place. Jeff Sutherland even suggests to train top level management in Scrum first to avoid those misunderstandings from the beginning.
Maybe it is better to call that perverted outgrowth of the term Agile "Weasel Agile". That's what Scott Adams would probably do. There is just one rule for Weasel Agile: If someone wants something from you or tells you what to do, just reply: "we can't do that. That's not Agile!". ;-)
"Business people and developers must work together daily throughout the project."
IMO, this is where agile projects go bad. There's no detailed spec, but also no "business person" (or. I'd prefer "customer / customer rep" to flesh out the spec. Said customer must be available 100% to the development team.
> Said customer must be available 100% to the development > t team.
I've never yet come across the situation where the customer doesn't already have a job to do and therefore cannot provide 100% (or anywhere near it) availability. Developing software for a sales team is a classic example.
"Agile" development is incredibly fragile in the "real world" when it encounters people who aren't experts and aren't converts. Office poster phrases like "people over process" (preferably with a cuddly kitten on) are both meaningless and unhelpful in dealing with such situations. In such cases, being told something more useful than "You're not doing Agile properly because you didn't do X; so the mess is your fault not ours." would be nice and yet it seems to be a recurring hallmark (sic) of the whole Agile industry.
This bit of the manifest is potentially troublesome:
"Welcome changing requirements, even late in development."
Sometimes an apparently small change in requirements can require an arbitrarily large change in the code that addresses it. So in mathematics changing "min" to "max" can mean starting again from the beginning (or even giving up --- no realistic algorithm exists). Requirements of this kind need to be established early and later changes may not be realistic.
"I'm one of the authors of the manifesto, so if I say something 'weird,' they can't tell me I don't understand Agile."
This seems like a claim to privileged knowledge, similar to a prophet claiming direct revelation...what we wrote is authoritative with exception to whatever we think at the moment, because we are the authors.
Flat View: This topic has 20 replies
on 2 pages
[
12
|
»
]
Previous Topic
