Comment:     by leena chittineni 2/6/2008 We have been using Agile scrum for past 1.5 yr its a very effective process so far excellent scrum master , product owners. yes I agree , if the agile ways r not followed they fail
	Comment:     by Judith Hofeditz 9/11/2007 Response to Jay Rogers' comment of 8/23/07: We in Premera Blue Cross' eBusiness area embed our usability and user-centered design tasks into our entire Agile development process, using Scrum. We are currently transitioning from waterfall to Scrum, and we consider the usability/UI discipline to be an integral part of our development process. It appears to work much more effectively in an Agile than waterfall mode. Author's Response: 9/11/2007     Ray and Judith, I have discussed usability and user-centered design with a variety of teams adopting agile and we absolutely (to Judith's point) do NOT throw it out upon going agile! We insist upon usability (and its incumbent design) being a part of the completeness of functionality for any demonstrable item at the end of the timebox. Sometimes, that means some "pre-work" done by the usability gurus in the prior iteration/Sprint. These teams discuss the pros and cons of how this works for them and then make agreements about their work. What do we do then? We run a retrospective on whatever usability timebox approach had been agreed upon and then determine what changes may help the process along. For further guidance, a wonderful resource is Jeff Patton. Also, I have seen some nice work on this by Gerald Mazaros based on work he did with the Canadian Railroad.
	Comment:     by Jonas Ekstrom 9/5/2007 Developers have a reason for beeing agile. Projects and business need to react on changes in the world around us. Business change prefered vendors, out sourcing partners, products, ect. Projects will have to change their implementation based on new requirements or underlying technologies. No method in the world can help a business to be agile while in the same time locking in processes, functions, services and data into stove pipes (read applications). The reason why businesses listen to the word SOA is because it promises agility (and resuse for those who cannot understand the value of agility). The SOA message will be to break...Read On
	Comment:     by Dean Schulze 8/23/2007 Your article is titled "11 Ways Agile Adoptions Fail". At the risk of splitting hairs, do you mean that the team does not become agile or that the project itself failed? The team could fail to become agile while still managing to complete the project, or the team could become agile while the project failed (remember the C3 project). I've worked on several non-agile teams that were very successful, and it would be a mistake to try to convert most of those teams to agile. They just wouldn't be open to it since they are successful with no real process at all. I could see one of those teams fail to become agile while getting the...Read On
	Comment:     by Jay Rogers 8/23/2007 Hi Jean, I came across the link to your excellent article on the agileusability list at yahoo. I joined that list because I'm a user interface designer and usability guy who's just spent two years slogging uphill trying to get user-centered design into our waterfall process, to see that effort being washed away with a wholesale switch to agile. You're obviously speaking from experience: do you have any stories about usability successes with Agile/SCRUM? There's some great ideas coming out of Alias in Canada, but otherwise its hard to find well-considered writing on the topic. Author's Response: 9/11/2007     Ray and Judith, I have discussed usability and user-centered design with a variety of teams adopting agile and we absolutely (to Judith's point) do NOT throw it out upon going agile! We insist upon usability (and its incumbent design) being a part of the completeness of functionality for any demonstrable item at the end of the timebox. Sometimes, that means some "pre-work" done by the usability gurus in the prior iteration/Sprint. These teams discuss the pros and cons of how this works for them and then make agreements about their work. What do we do then? We run a retrospective on whatever usability timebox approach had been agreed upon and then determine what changes may help the process along. For further guidance, a wonderful resource is Jeff Patton. Also, I have seen some nice work on this by Gerald Mazaros based on work he did with the Canadian Railroad.
	Comment:     by Jean Tabaka 6/19/2007 Robert, of the 7 Lean Principles, "Seeing the whole" speaks to your point. I'll take a leap here and say that you can associate any of my agile adoption failure modes with a failure to pay attention some lean fundamentals. In additions, from Womack and Jones, paying the greatest attention to VALUE in everything the organization does is crucial. I have not called that out specifically in my little list. The word "Focus" and "Value" continue to gain greater traction in my lexicon however. Your comments reinforce that. Thank you for your comment. Jean
	Comment:     by Robert Ahearn 6/16/2007 While trying to adopt elements of Lean, Agile, 6-Sigma and SOA into the business life. It is important to have the greatest impact on the customers and the company's bottom line in the most effective manner. There does not appear to be a single answer for every instance. Which opens another sticky point, that being that companies, despite, having enterprise systems are not agile enough for the site-specific business unit. I enjoyed the insights the article provided and hope to find the opportunity to inject the applicable tips into the company's life. Regards, Robert Ahearn Teva Pharmaceuticals, USA
	Comment:     by Kirthivasan Subramanian 6/9/2007 Hi, After going through , i personally feel agile methodology could be good in a shorter span of time but not for a longer period, as there is not much learning and from project management perspective it is not a healthy trend.
	Comment:     by Kirthivasan Subramanian 6/9/2007 Hi, After going through , i personally feel agile methodology could be good in a shorter span of time but not for a longer period, as there is not much learning and from project management perspective it is not a healthy trend.
	Comment:     by Jay Packlick 6/6/2007 I know one thing that definitely helps the adoption of agile - and in it's absence makes adopting agile more difficult: An organizational commitment to delivering quality products and services that starts at the top. I'm talking about the kind of commitment that translates to a willingness to achieve longer term goals at the expense of short term impacts or what Deming called “constancy of purpose”. Change is difficult: there are learning curves and old habits to extinguish. Teams often go slower before they go faster when adopting new methods. Operational pressures do not magically go away. Successful teams naturally resist change. ...Read On Author's Response: 6/19/2007     Arrgh! You are so right Jay, and I realize now that I meant to, but failed to point out your concerns about quality as an adoption failure mode. Pulling testing forward, being prepared to stop the line at the sign of any defect, making test coverage an imperative: all of these quality practices must be present in an adoption approach in order to agile to succeed. In the variety of organizations where I have worked and consulted, I've seen the impact of this lack of quality commitment and that impact is not pretty. Additionally, to your point, I believe it is associated with an organization's unwillingness to slow down in order to speed up. I greatly appreciate your adding these quality comments to the article and in particular your reference to Deming. Jean
	Comment:     by Wayne Mack 6/6/2007 Ms. Tabaka provides many excellent points, but I would like to comment in particular in regards to "brutal honesty." This is often an area that both the development team and upper management have difficulty with. Unfortunately, in many organizations, development teams have learned how to play the "spin" game. They have learned that reproting even remotely bad news has consequences and have learned to create illusions of progress. It is better to have a lot of empty shells developed rather than any one thing completed. Errors can be hidden through well turned phrases and tightly scripted demos; the development team then works...Read On Author's Response: 6/6/2007     Thanks Wayne. I do a lot of work with teams about how to provide feedback, both positive and "negative" (I don't use that term though) either about the state of the work, the delivery on the commitment, or on individual work within an agile team. Indeed, a mind shift has to occur organizationally that invites useful data about the iteration commitment and what was actually completed, product progress, feature completion, release readiness, etc. Successful organizations take and feedback as a gift for "What can we do to help? How can we fix that impediment? Who is available to assist?" When I work with groups that do this, they really "get Agile". It is a wonderful sight! However, I've also sadly seen that some organizations have denial sewn deep into the fabric of their patterns of work. Or, in some cases, the organization is learning to embrace reality, but some individuals are unable to alter their patterns of denial. In these cases, Agile adoption will ultimately fail, AND, the word on the street will be that Agile is no good, that Agile failed. Ughhh.
	Comment:     by MG Hariharan 6/5/2007 This is a very excellent article covering all aspects of institutionalization of any system I faced all these problems during CMM implementations. Various aspects of these problems to different intensity are prevalent in all organizations. I would like the author to offer solutions for each one. Exchange the different solutions for these problems will add value to systems. If they can be converted to processes and sub process then best practices can be defined add to learning. Thanks 'Jean' Keep it up. Author's Response: 6/6/2007     Thanks MG. I'd love to write a BOOK about this! I've collected these patterns of adoption failure based on a lot of different companies in different industries and different cultures. And yes, I do firmly still believe in Agile and I do believe that through mentoring and ongoing inspection of the Agile adoption, teams really can overcome these failure patterns. They really can!
	Comment:     by Mark Striebeck 6/4/2007 Please let's not use dysfunction here. I see this tendency to blame all failures on "dysfunction" - that sounds too easy to me. I think in this list (which I really like!) there are a couple of items which have nothing to do with dysfunction but with using agile practices (some of which are actually counterintuitive): 1. Retrospective Most of my teams have a very hard time to see the value of a retrospective. It's one practice that gets dropped quickly because "we get it". Also, outside of an adaptive approach, retrospectives are just a complaining place because the team can't change anything anyway. 2.Read On Author's Response: 6/6/2007     Thanks Mark. Here are a couple of thoughts that come to mind: if your meetings are considered too big as a result of "Everyone attends the planning meetings" the team needs to re-evaluate who has what roles. "Everyone" means everyone who is going to take on tasks and commit to estimates. If everyone else is attending because they represent some stance or advocacy position about a product backlog item that they want to defend, they are probably in the wrong meeting. That could be a smell that the owner of the product backlog has not done sufficient preparatory work of backlog items with the variety of stakeholders who impact the backlog: is there sufficient detail for the items; do all stakeholders have agreement on the risks and rankings; is the product owner capable of representing the items usefully in the planning meetings? Product owners need to have their own rhythm of meetings with their own set of attendees that then make the iteration planning meetings highly focused, highly results-driven. As for the "complaining" nature of retrospectives, read "Agile Retrospectives" by Diana Larsen and Esther Derby about some wonderful ways to focus retrospectives on inspection and change and healing and moving forward. My book "Collaboration Explained" has some advice on that too :- ) Thanks again for your comments.
	Comment:     by Robert Merrill 6/4/2007 In one word, DYSFUNCTION. It's probably an oversimplification, but organizational dysfunction, rather than lack of agile know-how, seems to be behind most of these problems. Things like lack of user involvement, micro-management, drive-by management, and inability to face reality and learn from one's own past are oft-cited causes of failure for projects run in other ways, too. Is there some kind of "ruggedized Agile" which doesn't break down in a dysfunctional environment? Can the agile principles, if introduced well and in the right order, actually help reduce organizational dysfunction? Author's Response: 6/4/2007     Robert, indeed organizational dysfunctions are organizational dysfunctions regardless of software development approach. However, those dysfunctions can't hide when adopting Agile. (My experience is that dysfunctions get to lie around as a "hidden killer" in bureaucratic or hierarchical organizations still relying on waterfall and command-and-control management styles. In those non-agile environments, learning is not amplified nor is team empowerment.) In Agile, however, the practices explicitly call forth the pain these dysfunctions cause the productivity and morale of the team. Moreover, command-and-control and very plan-driven organizations may not consider themselves dysfunctional. Agile does. Agile can't abide these behaviors. Learning MUST be amplified; teams MUST be empowered. Organizations MUST see the whole. I am hopeful that my 11 adoption failure modes emphasize that message. Thanks so much for your comment.

Back to Top