Summary
Contrarians reject the majority opinion and often have personal reasons to degrade Agile. These writings often disqualify themselves through bias, thus failing to benefit the community. But non-contrarians - practitioners who tend to support the majority view - may be in the best position to drag the skeletons out of the closet.
Advertisement
The Salt Lake Agile Roundtable is a group of practitioners that meet monthly to discuss items of interest to the group. I had asked the group for pointers to seminal papers on Agile development. Of the many topics I was interested in, two resonated with the group:
Why Agile Fails - Traps and pitfalls that can destroy adoption or cause agile teams to fail.
Why Agile Sucks - Contrarian views; must be better than just bitching about why some schmo couldn't get Agile to work.
I didn't want papers from people with an axe to grind or who didn't understand Agile development; that seemed to be the case with most of the contrarian papers out there. The roundtable thought it would be interesting to brainstorm a list of problem areas ourselves: What do knowledgeable and experienced Agile practitioners say about this?
What follows are a list of traps and pitfalls we identified.
1. Agile teams may be prone to rapid accumulation of technical debt. The accrual of technical debt can occur in a variety of ways. In a rush to completion, Iterative development is left out. Pieces
get built (Incremental development) but rarely reworked. Design gets left out, possibly as a backlash to BDUF. In a rush to get started building software, sometimes preliminary design work is insufficient. Possibly too much hope is placed in refactoring. Refactoring gets left out. Refactoring is another form of rework that often is ignored in the rush to complete. In summary, the team may move too fast for it's own good.
2. Successful Agile development presupposes that team members will all act like adults. That's a euphemism for being competent and professional. Agile teams are expected to to accept a high level of responsibility and accountability. When they don't, things can fall apart really fast.
3. Agile methodologies misunderstood may lead to team burnout due to an irrational culture of ugency. We even use the word sprint, a term that is not connotative of sustainability.
4. Agile requires more team and individual discipline, commitment and openness than a dysfunctional organization may be able to bear. Yet a dysfunctional organization is likely to place excessive hope in Agile as a silver bullet.
5. The high visibility on agile teams causes poor performers to stand out. The benefit is that the organization can take corrective action. In the absence of corrective action, poor performers may try forms of sabotage to avoid detection.
6. Agile teams have a tendency to focus on tactical accomplishments at the expense of strategic goals. Missing the big picture can lead to long-term failure at the expense of sort-term success.
7. Agile can be hard on the product owner who has a lot of responsibility. They are often asked to provide real time requirements support, make feature and business decisions, define acceptance criteria, and be constantly available to answer questions. The product owner is often responsible for understanding and communicating the needs of the customer and the company. This role can become a bottleneck because it is unable to "feed" the development team fast enough.
8. Agile is over-hyped, thus leading to unrealistic expectations. People are led to believe agile development will solve all their problems with minimal effort and experience disillusionment when it doesn't meet their expectations.
9. A variation on The Blame Game can arise. A moderately successful agile development team usually will no longer be the bottleneck. Other departments can no longer blame development and this may give rise to a shift in political games.
10. Too much power can be granted to the product owner when it comes to steering the product. If they have an agenda, they can cause a lot of damage. Agile teams often seem to lack sufficient checks and balances.
11. Agile is too programmer-centric leaving it unclear how to balance work across an organization. There is a need for better documentation and coaching for non-development participants.
That's the list we came up with; no solutions yet. Most of these traps are not specific to Agile but the group felt that Agile development is predisposed to these problems by its nature.
Thanks to all the attendees of the Salt Lake Agile Roundtable for this list. Do any of these traps and pitfalls resonate with you? What traps and pitfalls have you experiences with Agile development? Are you a practitioner? Contrarian? Or both?
I have seen point 1 develop with completely non-agile teams. The greatest pitfall there seems to be - creation of frameworks without clear needs (YAGNI), overuse of language features (inappropriately), and no test-first mentality. The cost pressure not to spend time "fixing" poor or changed design requirements isn't just one that applies to agile projects.
Problems can arise when the developers are agile but the project manager is not. PMs love to put ticks against things and assume that once something appears to work that it is finished. Agile developers then come into conflict with the PM when they want to revisit 'completed' functionality.
An agile project can be in a perpetual state of 'almost finished' which does not look good in a status report to a PM that does not understand the methodology. If the PM is responsible for allocating resources then the chances are that the agile team will never be allowed to go back and rework anything.
It then ceases to be agile but the developers may only get to realize this until later in the project there is considerable technical debt.
To make full use of agile methodologies it takes more than changes in how code is written.
> 2. Successful Agile development presupposes that team > members will all act like adults. That's a euphemism for > being competent and professional.
My eyes bulged out of my head a little when I read this. But I have one nit. Competent and professional are necessary requirements but acting like an adult in the more general sense is also important. I've dealt with some really immature behavior from 'Agile' consultants.
> > 2. Successful Agile development presupposes that team > > members will all act like adults. That's a euphemism > for > > being competent and professional. > > My eyes bulged out of my head a little when I read this. > But I have one nit. Competent and professional are > e necessary requirements but acting like an adult in the > more general sense is also important. I've dealt with > some really immature behavior from 'Agile' consultants.
"Successful Agile development presupposes that" we live in a perfect world.
Regardless of its many merits, I think that this has always been a glaring weakness of the agile world. Any methodology that depends upon a presupposition about how it would like people to behave, rather that works with how people really behave has a built in barrier to success.
2. Successful Agile development presupposes that team members will all act like adults. That's a euphemism for being competent and professional. Agile teams are expected to to accept a high level of responsibility and accountability. When they don't, things can fall apart really fast.
4. Agile requires more team and individual discipline, commitment and openness than a dysfunctional organization may be able to bear. Yet a dysfunctional organization is likely to place excessive hope in Agile as a silver bullet.
The problem I see with these two is this: a functional organization is a prerequisite to success, agile or not. The question I have never really seen addressed (though honestly I haven't gone looking for an answer) is, 'If an organization is already healthy and fully functional, what does agile add?'
If you've already got those in place, you've solved a bunch of problems already: things are probably already working well. Why mess with it? Why agile under those circumstances?
> <p>1. Agile teams may be prone to rapid accumulation of <a > href="http://www.martinfowler.com/bliki/TechnicalDebt.html" > >technical debt</a>. The accrual of technical debt can > occur in a variety of ways. In a rush to completion, <a > href="http://alistair.cockburn.us/Incremental+versus+iterat > ive+development">Iterative development</a> is left out. > Pieces > get built (Incremental development) but rarely reworked. > Design gets left out, possibly as a backlash to <a > href="http://en.wikipedia.org/wiki/Big_Design_Up_Front">BDU > F</a>. In a rush to get started building software, > sometimes preliminary design work is insufficient. > Possibly too much hope is placed in refactoring. > Refactoring gets left out. Refactoring is another form of > rework that often is ignored in the rush to complete. In > summary, the team may move too fast for it's own good.
As a developer I totally agree with this. It feels like there is not enough time to really craft your solution and come up with a clean design. It seems like the whole notion of quality solely evolves around business value, not the code. For me, the developer, the quality of the code is at least as important as the quality of the business value. After all it's what I have to work with every single day.
One thing I <a href="http://dlinsin.blogspot.com/2008/05/agile-code-reviews.html">haven't figured out yet</a>, is how code reviews fit into the agile picture?
Great article. Project Managers that are running Agile Projects need to understand these pitfalls and have a strategy for addressing them. One primary value that PM can bring is the organizational leadership to recognize and address each pitfall as they arise.
For example, the PM needs to have a clear understanding of the amount of technical debt, why trade-offs were made, and be able to challenge the team when it gets "overdrawn" on the technical debt account. They also need to watch for the types of conflict and sabotage that can occur.
As more and more teams move to Agile practices it becomes more important for Project Managers to understand how they can govern these projects add value to these teams, and when they are making the project more difficult to complete.
One thing I discovered when people talk about problems during Agile adoption is that it is amazing how Agile methods uncover dysfunctions in an organization. That is different with Waterfall as you recognize problems only after the crash. That is, you recognize that you have them but the process works in such a way that you cannot tell what the problems are. So if you are in an organization that wants to remain dysfunctional, Waterfall is the way to go. On the contrary, Agile methods uncover the problems on organizational level but do not tell you how to solve them. It is actually out of scope of those methods. Lean methods however can jump in here! Lean provides problem solving strategies on organizational level. For some organizations it might be better to start with Lean to change the organization and adopt Agile methods as a part of the Lean efforts. That way, they learn how to solve those problems mentioned in the post on their own with measures that fit to their individual situation.
I shortened your list a little for context... of course all detail in original article still key.
WRT:
> ... list of traps and pitfalls we identified: > > 1. Agile teams may be prone to rapid accumulation of <a href="http://www.martinfowler.com/bliki/TechnicalDebt.html"technical debt</a>... > 2. Successful Agile development presupposes that team members will all act like adult... > 3. Agile methodologies misunderstood may lead to team burnout due to an irrational culture of urgency... > 4. Agile requires more team and individual discipline, commitment and openness than a dysfunctional organization may be able to bear... > 5. The high visibility on agile teams causes poor performers to stand out... > 6. Agile teams have a tendency to focus on tactical accomplishments at the expense of strategic goals. Missing the big picture... > 7. Agile can be hard on the product owner who has a lot of responsibility... > 8. Agile is over-hyped, thus leading to unrealistic expectations... > 9. A variation on <i>The Blame Game</i> can arise... > 10. Too much power can be granted to the product owner when it comes to steering the product... > 11. Agile is too programmer-centric leaving it unclear how to balance work across an organization. ... need for better documentation and coaching for non-development participants... > > That's the list we came up with; no solutions yet.
This is an AWESOME list and hits the nail on the head almost everywhere - I have seen almost all of these - in agile and SDLC too sometimes. Many times.
I could add war stories to perhaps every single point (as I'm sure most of you could too) - but instead of ragging, I'd rather try to offer something constructive to add to the theme in good ways.
Also, the fact that we can all commiserate with these points is also kind of the main point. Since the problems are not unique - people are people, and development is development - perhaps the solutions are also not unique? (While still acknowledging that indeed, it is not easy perhaps... )
Is there a one size fits all solution? I don't think so - but there are definitely some things can be done to improve the odds, let alone success and lives. Some other ideas:
* No a**holes - Checking egos at the door and treat everyone on the team with respect. Everyone. That does not mean not mean not correcting people, that simply means being respectful, as everyone needs/appreciates. The No A**hole Rule must be applied for overall success (imho). See http://www.amazon.com/Asshole-Rule-Civilized-Workplace-Surviving/dp/0446526568
* Tools and Drivers - Proper and efficient and flexible tools, and competant drivers of the tools. Skimping on tools is not a good way to succeed in efficient and effective agile. Further, the tools do not drive themselves. Never have, never will. And the difference between good/bad drivers can be the difference of success or failure of the project. Just like on the highway.
* Code Reviews - Almost all these problems could be mitigated at some (significant) level with code reviews. Any experienced Sr. Developer understands their value, despite the required discipline.
Here's a few articles on this, with additional links:
You could think that I am just plugging for <a href="http://www.atlassian.com">Atlassian</a>, as a partner of their's - but ironically I became a partner BECAUSE of all the issues cited in this blog article! I knew that they where attempting to solve so many of these issues - so why not align with the right train.
As a reference example, ironically: Atlassian only began in 2002, has over 14K customers in 106 countries, 7 products, offices in 4 countries with only about 200 employees (at last check). Made 38Mil (I think - something like that) in 2008 with very reasonably priced software (for what it does!).
They must be doing SOMETHING right... They are an effective agile dev house example like no other - living and breathing their own tools, and dogfood, to make it better, and everyone else gets to take advantage of their experiences as they package up the solutions to their own iterative failures.
Anyways, I think the sound advice of the linked articles (and many others found on the net) and facts speak for themselves.
I think it's a key point that Agile assumes that people will act in the best interest of the whole. Hmm, communism! I think this is why democracies via balance of powers has proven to be a stable (self-correcting?) form of government. It's central premise is that humans are fallible.
Maybe we need to design a methodology around that principle instead of the other way around?
> I think it's a key point that Agile assumes that people > will act in the best interest of the whole. Hmm, > communism! I think this is why democracies via balance of > powers has proven to be a stable (self-correcting?) form > of government. It's central premise is that humans are > fallible.
Being an employee is not being a member of a democracy. It is reasonable to expect employees to have the best interest of the company in mind. I often get the impression some developers forget who signs their paychecks.
That said, it seems reasonable for the employee to expect to be respected, listened too, integrated into the decision process, etc. That's not a democracy but worth consideration.
If an employee aligns with the interests of the company, and the company succeeds, it does tend to benefit the employees.
How do you feel agile (or any methodology) undermines the proper roles of employee and employer?
> > I think it's a key point that Agile assumes that people > > will act in the best interest of the whole. Hmm, > > communism! I think this is why democracies via balance > of > > powers has proven to be a stable (self-correcting?) > form > > of government. It's central premise is that humans are > > fallible. > > Being an employee is not being a member of a democracy. It > is reasonable to expect employees to have the best > interest of the company in mind. I often get the > impression some developers forget who signs their > paychecks. > > That said, it seems reasonable for the employee to expect > to be respected, listened too, integrated into the > e decision process, etc. That's not a democracy but worth > consideration. > > If an employee aligns with the interests of the company, > and the company succeeds, it does tend to benefit the > employees. > > How do you feel agile (or any methodology) undermines the > proper roles of employee and employer?
That depends entirely on your definition of 'proper'. If a proper role is employer tells employee what to do and employee does it, no questions asked, then Agile destroys this almost entirely. With Agile processes the employee has to figure some things out and push back, solicit feedback, etc. Agile is entirely a two way street where as most traditional employer/employee relationships are one way with those nasty tire popping spikes that you see in parking garages and rental places thrown down on the road.
Flat View: This topic has 38 replies
on 3 pages
[
123
|
»
]
Previous Topic
