Many organizations have adopted Agile practices into their development methodologies which have proved to be successful for the organization as a whole. There are also many organizations that have pockets of people that wish to be Agile, but can’t get traction within their organizations to make it a widely accepted practice throughout the enterprise.
I recently had an opportunity to participate in an Open Space session where we explored how organizations that are mainly guided by Waterfall methodologies, unwittingly also employed Agile practices.
I observed that most projects that were considered “top priority” projects for an organization typically had the luxury of being situated into a team room. As much as the team initially resisted this set up, they quickly found that the ability to collaborate and bounce ideas off of each other was far beneficial to their success, then being bound to the walls of their cubicles on different areas of the floor. The team was able to brainstorm ideas and quickly rule them in or out by doing mini proof of concepts that allowed them to understand the solution in more detail and determine if it was a logical path to follow. I also learned that the communication with neighboring groups improved therefore strengthening their cross functional relationships.
I noticed that these same teams also had some home grown concept of a daily standup meeting. Once again, there was initial resistance however, as the project progressed, these daily “meetings” seemed necessary to set the direction for the day. They also helped bring resolution to issues a lot faster then the traditional methods. In fact one project manager was told that when they weren’t present to run the standup, the team found themselves floundering on their targets or goals.
One last observation that I made was that most of the work that was produced by these teams was immediately being tested by the team itself or by dedicated testers. So the solution was continuously being improved and proven out.
I know that the items listed above don’t fully satisfy a complete Agile development shop however, I think that these are all tenants or rather the foundation for an organization that is willing to be Agile in some shape or form. This is the beginning of an organization that is willing to accept change to make the entire organization successful.
I’m interested in hearing more about your observations especially from those of you who are currently in organizations that think that “Agile is Fragile” and is challenged with slowly introducing Agile concepts into your resisting organization. Please post your thoughts or ideas so that I can make this post a collaborative effort into defining if Agile is truly visible through the Waterfall?
Tuesday, February 24, 2009
Subscribe to:
Post Comments (Atom)
.jpg)
Posts
The challenge is not so much agile methods as in how to integrate management controls with them. Project/program management, sourcing, financial reporting, project tollgates... in most cases, corporations aren't agile in any of these - and these quickly become a bottleneck.
ReplyDeleteharappa brings up a good point, but many of these items can simply be items in the sprint queue that need to be addressed as a part of the sprint. Assigned to the scrum master for example.
ReplyDeleteSelling the agile method to sponsors and IT management has always been a challenge. When they are so invested in getting a firm estimate upfront, it becomes hard to go agile. Here are a couple of situations where we have been able to sell agile:
ReplyDelete1) When requirements change a lot, often IT says "no more changes" and business becomes unhappy. I have been able to say, let the requirements and estimates evolve (thru agile) and we can better meet your changes.
2) When there are a number of small fixes to deliver and business is unhappy with the throughput, I have been able to say, give up on the design and estimate phase and we can improve throughput.
These are small scale, bottom-up approaches to cultural change, but good productive steps to getitng there over time.
Agile is really the best way to protect software projects from failure. Think about it, if a majority of project management revolves around managing change, why not adopt a methodology that accounts for change?
ReplyDeleteAs for the need to have a firm timeline/budget up front, how many projects actually are delivered on time and within budget? Maybe 50%?
Ken Schwaber gave a presentation on Scrum at Google a few years ago (it's on my blog in a post titled "Like a Gun to Your Head") He mentions that using Srcum/Agile
helps you know up front what kinds of projects you can realistically take on and which ones are doomed to failure.
The problem is that constantly changing requirements, dynamic business processes, staff turnover, and new technologies make managing projects incredibly difficult. Say your team spends a few weeks writing specific module, and then a product comes to market that does this for you relatively inexpensively. Why not integrate that product into your app and continue? Imagine this happening over and over again. So by the time you're done with a massive multi-year project, the technology has changed so much, your application could be considered obsolete. A methodology that expects and embraces rapid change is really the best thing for you.
One last thing, Andy Singleton from Assembla has a good post saying how agile doesn't require everyone to be in the same room at the same time. With collaboration and messaging tools like Skype, you can probably be just as productive.
Raza Imam
http://www.SoftwareSweatshop.com
"Agile" is a descriptive term and an an outright cool name. But here are a few things I keep in mind when trying to apply Agile techniques in a non-Agile world.
ReplyDelete* Agile is a buzzword and buzzwords turn a lot of people off -- and for good reason. All new technologies, process improvements and tools are over sold. You know, the "silver bullet" phenomenon. The problem is, there are no silver bullets, and savvy IT people know that. However, that doesn't mean there isn't great value to be derived from the collection of techniques referred to as "Agile".
* The Agile name has a pitfall. It implies -- either intentionally or unintentionally -- that other processes are not agile/flexible. The interpretation by many is that the Agile community is saying that all non-Agile process are wrong. The world is not that black and white to me. The process world is more of a continuum. What we should be striving for is constant, gradual process improvement -- not silver bullets. As other posters have described above, there are many approaches to apply Agile -- some are bigger steps, others are smaller. The right size step depends on the organization.