Agile Chronicles

Visibility whether you like it or not

When asked about the benefits of agile development, one that I always include is visibility.  And here I mean 'true' visibility - the kind that is unfiltered, honest, and accurate.  Agile development is based on fundamental transparency.  Given this transparency, some people may not like what they see - but the key is they are now seeing it in real-time, just like the team is experiencing it. 

Entrusted with this new information, it may also be necessary to hang up a new kind of construction sign (metaphorically, that is):

Agile Development in Process... Please Act Responsibly

VersionOne named Top 50 Innovator

VersionOne, was just recently selected as one of the Top 50 Technology Innovators of 2005 by IT Week, a leading weekly online magazine.  IT Week selected the 50 companies it deemed to have been the most innovator vendors on the technology front during the last year.  VersionOne's agile planning and management suite set the company apart in the technology industry, and is indicative of the momentum of agile development in general.

Article

Scale out, not up

Some people question agile's scalability... I think the right question is whether software development scales well.  There is plenty of evidence to the contrary. 

If, on the other hand, the question was which approach to scale, I still choose agile as the basis upon which to build the process.  Running software, automated testing, continuous integration, weekly (or at least monthly) milestones, engaged users/customers - these would be the things that would help assure me I was not wasting a great deal of money on my 'large' project.

Agile and outsourcing

Seems like I get asked questions about agile and outsoucing all the time now, and I have a pretty simple answer, or at least assertion.  If I am spending that much money on a project, especially one being performed remotely, I would want running software every so often, maybe very often - wouldn't you?

Agile diner analogy

Internally, we used the metaphor of an 'agile diner' for designing VersionOne's next version of software for managing agile development projects - i.e., hundreds and hundreds of requests (food orders) coming in from all over the place that need to get organized, parsed out to the appropriate team/project (cooks), and then delivered (cooks to waiters to diners).  Software teams, like diners, tend to used strange names for these orders such as stories, backlog, issues, themes, etc. that most outside the teams cannot begin to understand.

Not perfect - i.e., some orders just never make it to the table - but works for us.

Software publishing .EQ. magazine publishing

When you are talking to someone in an entirely different industry, it is oftentimes better to communicate in their language instead of your own.  A few months ago, I was talking with David Rubinstein at BZ Media's SD Times, about agile development.  I asked him to imagine what it would be like if they published a single newspaper/magazine each year vs. every couple of weeks. 

Would their operation be as efficient or optimized?  Would they get more, or less, actually done?  Would the single, super-duper-newspaper published each year be worth the wait?  If they did a better job planning up front, would every single article be perfect?  And maybe just as important, would their customers (in their case advertisers as opposed to readers), value this one newspaper enough to justify and fund the single distribution.

Maybe the software industry isn't so unique.

Innovate: ETC = 100 hours?

In 18 years of software and hundreds of detailed project plans, I realized I have never seen a task called Innovate in any traditional project plan.  We all know that if its not in the project plan, it likely doesn't happen. 

Yet every iteration, I feel like we are given the time and opportunity to, at a minimum, innovate a little based on what we have learned so far in the project.  Deadlines still exist, but not necessarily at the expense of innovation or business value.

Agile methodology soup

I mentioned in a prior post that most of our customers say they use XP, or Scrum, or some other methodology, but have not implemented every practice.  If there are truly reasonable constraints, consider the specific methodologies less absolute doctine and more recipe. 

You absolutely should follow the recipe, and the project will very likely emerge from the oven best if you use all the recommended ingredients, but sometimes you just don't have pair programming preserves in your pantry.  On the other hand, if my only option were to substitute formal code reviews, I might actually have an incentive to go out and find some pair preserves, even if only part of the time.

Doomed to failure

No one put it more eloquently than Tom DeMarco did more than 10 years ago when he said in Why Does Software Cost So Much, "All the attempts to make software into a production activity are doomed to failure".

Agile development gives us the ammunition we've needed for quite some time to do something about it.