My Take on Agile

Today’s editorial is from Pawel Brodzinski, hailing from Krakow, Poland. His experience in software development covers positions in both rank and file and management roles.  He’s been working in quality assurance, software development, design, support, and implementation teams.  He’s been managing different teams from small group of testers up to an ERP system development department.  Being a part of a software development process is both great learning and great fun for him, yet sometimes it’s quite challenging.  Pawel also enjoys writing about his experiences with managing software projects at http://blog.brodzinski.com.

Most of the opinions you can hear about agile are either strongly for or strongly against agile methodologies.  Since balanced opinions are rather underrepresented and I’m usually far to treat anything as a panacea, my take on agile is neither black nor white. It’s gray.

From the very beginning, I’m providing a small disclaimer for those who aren’t familiar with my approach: I don’t advocate any specific methodology.  I know there are projects where agile methods can bring a lot of additional value.  I also know there are projects where other methods give better results than agile.

OK, let’s start with something very basic. Let’s look at the “Agile Manifesto” which says (among other things):

• Individuals and interactions are prioritized over processes and tools
• Customer collaboration is prioritized over contract negotiations

Interactions.  Customer collaboration.  Nice.  Some wise people who developed agile methodologies brought us some scenarios which cover those points. Short iterations should be done with customer’s verification, to give one example.

Now, if you have a customer who understands agile and is eager to help – great. You should be able to build something the customer will be happy with and your relationship with them should improve. You’ll build something different than what you and the customer thought of at the very beginning, but that’s natural.

No one denies that functional specifications brought up front don’t represent exactly what a customer wants to get. People who can clearly define what they want from a single product are rare. People who can clearly define how complex software product should work are close to extinction.

I’ll take scrum as an example. Scrum looks like a great answer to ever-changing requirements, since it uses short iterations. After each of them the customer reviews current state of the product and gives feedback. Comments are then used as input to the next iteration which brings the product closer to meeting real customer expectations. Everyone’s happy, the atmosphere becomes idyllic, and everyone shares skyrockets.

Except that doesn’t happen in every single project.

The most crucial part of the process is interaction with the customer. The whole thing works great if the customer puts an effort to review the software every fortnight. This works If the customer gives you feedback about your work. This works if the customer understands that they won’t get every single feature you were talking about at the beginning and a bunch of other features added as a bonus. Also, this works If the customer doesn’t force you to bring detailed functional specifications up front and strictly requires development of the full list. If, if, if…

Each of these cases undercuts values brought about by agile approach. How the product will be closer to the customer’s expectations if they won’t even take a look at the application before acceptance tests? How will you plan to explain lack of specific features from the initial scope if the customer rejects to accept the otherwise reasonable explanation that you were doing other features instead? How will you answer the customer who needs more predictability than flexibility?

If the communication with the customer in those areas “sucks”, then old-school ways of running projects usually would work better. The same situation is when the customer values contract negotiation over vendor collaboration or breaks any of the other agile paradigms. Sure, no one may deny you to exploit agile methods in that kind of environment but profits you gain would be questionable.

From my perspective you can decide each time whether agile would bring additional value based mainly on your judgment of customer collaboration. Think about it as a whole. Ask yourself whether you can expect customer involvement in the process of creating software. Think about how many of your customers may not help you in that area. Then decide if it’s worth to jump on the agile bandwagon.

Each project management methodology sets goals for both the vendor and the customer. These goals depend on the methodology – sometimes focus is set on paperwork, sometimes on collaboration. Besides, if one side doesn’t perform well, even if this is the other side, the project won’t be a stunning success. No matter how hard you try.

And one more thought as I close: no methodology can substitute for common sense.

Do you agree with Pawel’s viewpoints on Agile methodologies?  Leave us a comment and let us know!

Get the pm411.org Project Management Podcast delivered by email for free! – Your email address and personal information are confidential and will never be sold or rented.