Agile is fragile

Since I started working professionally back in 1994 with software development I got very interested in processes and methodologies. Over the years I’ve worked with quite a few types; Waterfall, Cowboy, eXtreme Programming and lately we’ve been working with applying MSF Agile. Back in 1996 I started doing test-driven development, on games as the matter of fact. We had unit tests for basically everything, some of them needed to be interactive seeing that we couldn’t exactly mock visual stuff that needed the human eye to approve, but nevertheless we were TDD based.

I’ve been working with agile software development for the last 4-5 years, or should I say, trying to work with agile software development. All processes has a certain set of rules that needs to be followed and I remember when I had training in XP they said that you need to obey the 12 pillars of XP. The developers at work, myself included, couldn’t really figure out why that was so important and decided to apply the pillars we found interesting. Mistake number 1.

We applied XP for about a year and a half and found it to be lacking certain elements to it. We felt the process was missing key quality assurance elements and was very exclusive to developers. Mistake number 2 we made was that we hadn’t really applied eXtreme Programming, so who were we to judge. Anyhow, we tagged along and discovered MSF Agile and found it very interesting straight away. It had the roles we felt were missing and process elements that would fill in the missing gaps of what we felt were missing for quality assurance. We jumped aboard the train and never looked back (until today).

Mistake number 3; I found myself believing to my core that we had applied MSF Agile, at the time of introduction I was manager of application development and was working a bit more with processes and planning. I sincerely believed we had applied MSF Agile with all it’s artifacts. Last spring I decided to leave the company for a job that looked very interesting (My personal mistake number X), only to find out that the company I started at was not interested in applying any form of methodology unless it was named adhoc. I decided to leave them after only 2 months and was quickly approached by the company I quit 2 months earlier and got an offer that was acceptable. I went back, this time being only a senior software developer and team manager for a smaller team (4 people, including myself). I decided at that point that I’d had it with all the management stuff, I wanted to primarily write code, but it wouldn’t hurt to have some control over a specific part of the application we are working on. Anywho..  After a couple of months I started to see something very strange. We weren’t working according to any process, or at least any process I knew. I got really pissed off and started ranting openly about why aren’t we working according to MSF Agile (My personal mistake number X+1). The truth was that when I was too busy planning our next big project and going around believing that everyone was working according to the process, people didn’t know the first thing about the process. No one had read the process guidance on our sharepoint site even. I kept ranting and was honestly really fed up that there hadn’t been anyone who took charge and applied the process we had agreed upon.

And now back to the title of this post. Why do I think agile is fragile, in fact I think most processes are fragile in the sense that if you don’t apply the process correctly, the process will collapse under it’s own weight. Agile is fragile is just a cool title, I honestly think the statement applies to all processes. So, why are they so fragile. Take for instance “embrace change” that agile methodologies has in it’s core. The concept of having code that can be changed, refactored, feature change at any given point in time demands that you apply TDD. Without unit tests you would really need to be a cowboy in order to dare to start a major refactoring job. The unit tests serves as a safety net that assures you that the code you are rewriting will still result in a working piece of software. Another example is pair programming. In order to achieve full global ownership to the code, pair programming must be applied. The beauty of pair programming is that you spread the knowledge about the code throughout your team like a wildfire. If you drop this and let developers specialize, global ownership is lost. Pair programming is probably the pillar that is hardest to apply in a team. Many developers will argue not to be part of it at all. Pair programming is not an aspect of MSF Agile. That’s probably why global ownership is not a part of MSF Agile. Yet another example is the fact that the customer should be available all the time. By customer one means an actual customer or a representative for the customer that is located within the team or is available within the organization. Without having the close relationship to the customer, you will not be able to see if the project is on the right track between iterations. An agile project needs to correct itself all the time, this is done through the use of iterations. The length of the iteration can be 1, 2, 3 or 4 weeks. It is not recommended in most cases to have them go for more than 4 weeks. If you don’t have the customer available at these junctions, you will not be aware of any mistakes you might have done. That means you’re back to waterfall were you have a test period at the very end of the project. A very important aspect of all agile methodologies is that all roles work actively for every iteration. That means that you’re planning, writing unit tests, writing code, acceptance testing and so on for every iteration. Loose one of the activities and it all collapses. I could go on and on about other fragile relationships in agile methodologies, my point is that you must be really careful about applying a whole process no matter what process you decide to apply.

The beauty of having time of work (I’m on my paternity-leave or sick-leave, not sure which one yet) and really not think about work, totally disconnected from work (I’m not even reading emails..), is that you get a lot of time to think about stuff like this. I’ve come up with a couple of rules that I believe is important when trying to apply a software development process :

1. Whenever you want to apply a process, one would think that having management with you should be sufficient. Wrong. You need the entire team. Every single member of the team must embrace the new process. They don’t have to like it at first, but they have to agree to be willing to try it out and work according to it.

2. You need to be really strict when applying the process. You can’t afford to not apply the whole process. Most processes will collapse if you do so.

3. Stretch to fit - not shrink to fit. You can adjust the process so it fits to your needs by adding to it, never removing!

4. You need at least 2 persons in the organization that are not only masters of the process, but also really enthusiastic about it. They will act as motivators for the others.

5. Train everyone! If everyone is trained in the process, and if possible, certified in it, you’ll automatically have a process-cop in every single member of the team. Together the team will apply the process and correct any mistakes that is bound to happen.

I’ll probably come up with a couple more rules as the days fly by sitting here doing nothing. Feel free to drop me a comment if you have input to the madness above.. :)