Agile methodologies seemed like a good idea to this software development team. But when the company doesn't sincerely accept the change in work style, the result is just a buzzword for the usual project hell, as Charlie Martin's story about an agile project gone wrong describes:
Sometimes, your friends tell you hard things. If you think you're doing Agile, you must step back every so often and ask: Can I respond to changing requirements easily? Do I have confidence that I could run the current build and see part of the system work? Am I seeing my family on a regular basis? Or did we plan to work overtime over Christmas to make our commitments? If you aren't seeing easy response to change, regular working deliveries and a regular schedule with a normal workweek, you have a cargo cult...
Cargo cults developed in Melanesia, starting in the 19th century, but really grew during World War II. To the locals, the war meant cargo planes and cargo ships arriving, carrying everything from canned pineapple to Quonset huts. And it was good... Then the war ended, and the cargo stopped. The locals responded by building their own runways, with airplanes made of bamboo and palm fronds, in hopes of attracting it back.
Martin's experience relates to a project that wanted to follow agile principles, but also had to fit into existing corporate standards and processes. Some agile principles were compromised, and although the project did deliver, it was late, cost more than anticipated, and was not much different in the end from a traditional waterfall project.
In your experience, to what extent is it possible to run an agile project within a corporate environment where not every layer of management has bought into the agile principles?
Interesting but it's odd that we see articles about Agile going wrong but I've not seen any about this:
"All of us team members were survivors of another much larger project. That project had been done with outsourcing to a CMM Level 5 organization, with great care in the methodology at our end and with careful detailed project management overall. The project consumed tens of millions of dollars and years of overtime. It failed utterly."
Maybe I'm not paying attention but I'd be interested in an in-depth description on that. I've been involved in I similar disaster but I was gone before the whole debacle played out. I can only hear about how badly it is going second person. Where is the article about this kind of thing?
Really? I've seen a lot. I don't have any refs but two that come to mind are that IBM air traffic control project and the FBI national identity system.
If you think of slicing a company horizontally then you talk about exec buy in to - in this case - agile. If you slice a company vertically, then you talk about silo buy in.
In the former case, I wonder if it is even wise to embark on a change to agile.
In the later case, one can have success in a step-wise fashion by bringing increased value to the point where adjacent organizations ask "What is it you're doing that makes you so effective?"
Case in point, our IT development 'customers' are our internal business units. At some level they don't care if we use agile or voodoo, as long as we deliver. We can hit most of the agile sweet spots w/o them but eventually, we need more of their support when it comes to how requirements are created, how we run our iterations, and how we perform scheduling and estimation.
As we have adopted agile methods - in a one-at-a-time fashion - our capacity to meet our customers' needs has grown. It has created increased trust and a willingness to change how our customers interact with us. When we say, "If we do requirements this way, it will make us even more efficient." Or, "If you participate in our iteration planning you will have more control over the project," the business customers are interested and willing to give it a try.
our department is trying to "agilize" right now, from a base of NO project management at all, but with a new IT director used to waterfalls... not sure if this is a similar enough situation to help you much, but here goes:
so we're starting with use cases ("stories") for new projects, and trying to schedule our customer meetings "scrumm style". "dependency injection" and "unit testing" are the next big things we think we can start implementing, but I don't know how specifically "agile" those last two are.
we're using the new director's project templates, which means we're still trying to gather all requirements and set milestones before the project begins. this is a bit conflicting with the nature of scrumms, but we have the authority to pad our estimates to reflect an entirely new learning curve, mostly on the part of our customers who aren't used to dealing with terms like "scope" or "user acceptance testing". and also dealing with the contradiction between "you can change your requirements at any time" and "well that's going to require rebuilding X and Y from scratch as we didn't know to take that into account".
So our working theory now is that we can set start/end dates for a project based on initial requirements + padding, but when a customer asks for changes, we go through a round of re-estimating/prioritizing/negotiating/documenting to decide whether it gets in before the end date or what other features it can move aside until the next "version" (a new round of Requirements/Start & End Dates). It's a very weird hybrid that is definitely slowing us down, but not more (IMHO) than the alternative where we waterfall for months and then have to rebuild for months instead of doing it in weekly or bi-weekly sprints.
honestly, i'd call us more "spiral" than "agile" at this point, but we're working on it. ;)
Previous Topic
