John Hines' Software Process Blog

A blog on Agile software development and Scrum

  Home  |   Contact  |   Syndication    |   Login
  37 Posts | 6 Stories | 42 Comments | 0 Trackbacks

News

The information in this weblog is provided “AS IS” with no warranties, and confers no rights.

This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.

To err is human, to forgive is divine.

Tag Cloud


Archives

agile

Monday, September 20, 2010 #

Returning from paternity leave I found my co-workers had redecorated my cubicle in a relaxing, bamboo forest theme (complete with pandas).  It's hard to see the loads of chocolate, the trickling water fountain, or the inspirational sayings on the walls.  Very nice.

Having so much time off helped me to contemplate the year-long debates I've been having about Agile.  Mostly I struggle with the militant "Do Agile everywhere full-time" perspective I learned from the very first Agile books with the feeling that even a few Agile methods could help in most cases.

The most important thing I realized was:  Focus on your projects.  Gil Broza often suggests test-driving Agile/Scrum with a well defined project.  Even experienced Waterfall teams aren't seasoned enough to skip this step and jump headlong into Agile on multiple projects simultaneously.

The other thing I realized that the most pursuasive argument for Agile is to show it produce results.  Apply some Agile practices to long-running projects and you may find that, even if the velocity hasn't risen, more people will be aware of what's going on.

Let others run their projects using waterfall or any other methodolgy (including none).  Use a phased approach on your team where you make sure all of your personal projects use Agile, but don't worry about the rest.  Then do an unemotional comparison - time to market, customer satisfaction, quality of product.  I think you'll find that Test-Driven Design and Scrum project management will be the winners in at least two of those three areas.

Lastly, it's fine to doubt Agile.  I intended this blog to be a place where I trumpet how Agile solved all of my problems, only to be hit in the face with a year of not being able to implement it.  Agile helps software developers better react to their customers' changing requirements and predict accurate deliverables.  If you don't have issues with your customers (or you don't have customers), Agile is irrelevant.  You probably have bigger problems to worry about.

The difference is that I'm now surrounded by ferns and the sounds of a bubbling brook to keep me Zen.

Technorati tags: Scrum