The Tragedy of Agile

I've recently become aware of some recent complaints about the agile methodology and as I've thought about these complaints it seems to me that the reason for these complaints is because people are too locked into doing what someone has ordered them to do to. What I mean by that is too often we're not able to ask why we're doing something other than the boss (or someone else like an expensive consultant) said so.

All too often agile, or any process decision, is directed from the top-down.  An executive/manager/lead gets wind of a way to make all their buggy, late, and expensive software problems go away.  All you have to do is follow a few simple rules.  Now the tragedy is the people who have to carry out these rules are never asked how they feel about these rules before they're told to do them.  What we're seeing is a bureaucratic, closed, and stale culture trying to implement a set of rules that are based on an open, transparent, and continuously improving culture.  The rules for the software development process just don't seem to fit, but luckily nothing is set in stone.

This is your process...not Scrum's

During my grad studies I took a class about lean manufacturing which is the basis for the Toyota Production System (TPS).  Basically, TPS is a culture, set of rules, guidelines, and processes that enable Toyota to eliminate waste in their business.   Eventually Toyota realized that it needed to help their suppliers eliminate waste so that they could work together better.  Our class took a tour of one of these suppliers called Autoliv.  Autoliv builds parts for Toyota's airbags and with Toyota's help they've been able to create a more efficient production system.  Now, do they call it the Toyota Production System?  No way.  Why?  Because they're not Toyota, they're Autoliv.  It's the Autoliv Production System.  It was modeled after TPS but modified for their specific needs.

Don't say we use the Scrum or OpenAgile or Waterfall or whatever methodology you're basing your process off, because the truth of the matter is you aren't.  You're taking whatever you understand these methodologies to be and you're applying it to your circumstances.  When you say you're using Scrum it's too easy to blame your problems on Scrum.  Take ownership of your development process because if there is a problem, you'll need to fix it.  And by you I mean everyone on your team.  

Empower the team.  They will come.

I've come to discover that self-organizing teams are incredibly productive and for the most part a lot happier than your traditional team (I wish I had empirical proof, but I don't).  Part of the self-organizing team is shared responsibility.  You fail together and you succeed together.  Most people I've come across(sure there's a few dicks out there) are going to want the team to succeed and will share ideas on how to improve. Whether code or development process, the team needs to be able to adjust to better increase their chances of success.  In order to do that they need to be able to experiment with their ideas without going through miles of red tape.  Does experimentation lead to some failures?  Absolutely, but it is the only way to improve.  

Another important aspect of the team is having clear roles.  Generally, you'll have your product owner and your customers and your project manager (some people might call this scrum master for some weird reason), and your developers.  Your process might have more and maybe less (do you see a problem with having less?), but the fact of the matter is if you know who has what role, and what specific duties are included in that role, there won't be as many conflicts of people trying to do the same thing.  For example, if you have a clear product owner who is driving the direction of the project you won't be receiving conflicting feature requests.  Again, it's important to understand why you have each role on the team.  If you don't know why, you probably don't need it and you can move that person to QA since they're probably overloaded anyways.

Tool not rules

As I've come to better understand agile, lean, theory of constraints, and other ideas of improving processes the better I've come to understand that all the ideas and strategies are simply tools.  Tools that I can choose to use in a certain situation where necessary or, if it wouldn't be effective, to leave in the toolbox.  You wouldn't use a sledge hammer to hang a picture would you?

In carpentry it's generally pretty easy to decide on which tool for a job, but it may not be so easy for software development.  For this reason it's important that you're measuring the right things to see if a tool really is beneficial.  I agree that this is way easier said than done, but at the very least you should know how long, on average, a feature takes to go from inception to release.  That way you can monitor any changes that come about from your experimentation(remember the scientific method?).

Some other useful metrics might be ROI, velocity and there are a slew of others.  And once again, understand why you're measuring something, because truth be told, measuring can be a pain.

So...

If I were to have you remember anything from this article, understand why you're doing what you're doing. I sincerely hope that you're in an organization where that's okay.  If not you might have a hard time trying to convince people to change, but I've found that most people are willing to change If they understand why it would be better.

And if you were to remember some other things it would be good to also remember that it's YOUR software development process, for better or for worse.  The sooner you realize that the better for you and your team. And lastly, use tools that are good for the job.  

So, by following these few simple rules (maybe I'll name it the Be Awesome To Each Other Methodology), you too can enjoy your job in software development.  

Seriously though,  I am interested in your stories, ideas, anecdotes, etc.