If you’ve heard many people talk about agile development, you’ll quickly find that there are as many versions of what agile is as there are people to talk about it. Some espouse varying versions of Extreme Programming or Scrum. Others simply perform certain practices of agile methodologies and assume that it’s agile. If you start looking for where agile came from, you should quickly find the Agile Manifesto.

The primary way formal agile methodologies miss the point is in the first part of the Manifesto. The rest of the “Agile” community is made up of teams that attempt to adopt certain “agile practices” but don’t meet up with the core of agile.

First, I’ll discuss why formal agile methodologies violate the first principle in the Agile Manifesto. Then I’ll go into why the other “agile” practitioners miss the point everywhere else.

Individuals and interactions over processes and tools

If you don’t believe agile methodologies miss the point here, try implementing Extreme Programming (XP) without help. XP is extremely process heavy and implements many tools that may or may not help your team.

I need to point out that I don’t have a problem with XP. If it works for your team, then I fully encourage you to continue following its practices. However, it doesn’t work for everyone. I’ve met several people who have not had XP work for them. To be honest, the response they usually get is that they didn’t follow the practices completely.

This leads to two problems. Teams implement agile methodologies, see an increase in quality and development speed, and then follow the agile methodology to the letter without regard for what may be a beneficial adaptation for their team. Or, they attempt to implement the methodologies only to find that because they are not practiced at them, they see a loss in speed or quality and thereby drop the practice altogether.

Neither option is ideal.

What we need is for people to understand that agile methodologies are made for them. It’s not important that they rigidly follow XP, scrum, kanban, or some other set of practices. Rather, these are excellent starting places for people to enter the agile community and learn to build software that allows them to adapt to the real world.

The barrier to entry also needs to be lowered. If you’re trying to implement one of these methodologies, adopt a few practices, figure out how to make then work for you, and then add others into the mix. This is especially effective if your company’s tolerance for slowdowns as you figure this stuff out is very low.

Working software over comprehensive documentation

The concept of working software versus documentation is a mixed bag when it comes to agile development. Most methodologies do focus on working software in their iteration and code delivery practices. However, the “agile” practitioners who adopt pet practices frequently miss this point.

They may adopt ‘iterations’ or ‘continuous integration,’ meaning that they have a machine that makes sure all of their tests pass and their code builds, which doesn’t insure that the program works. They may have ’sprints’ which basically boils down to a shortened waterfall approach over and over because they don’t deliver working code regularly.

These approaches lead to the need for documenting what’s done and what isn’t as well as building workarounds rather than architecting solutions.

The other major area where this breaks down is when you only adopt some of the agile practices without others, you still wind up with a huge amount of paperwork to support each sprint, set of sprints, or functionality set. Rather than creating massive requirements documents that are going to change in one week because someone actually used your software, why not get the smallest thing that could work out there and then iteratively make things better from there?

Customer collaboration over contract negotiation

Some approaches to agile development do really well with this. I read a book about XP that described building a team out of the developers and several other stakeholders who represent the customer.

This is exceptionally important. As a former Director of Tech Support who fought to get issues fixed in a non-agile environment I can tell you there is huge value here. You manage to lower the barrier to entry on your own product and you’ll attract more people.

Most partially adopted agile teams miss this completely. They focus on the practices that involve the developers and ignore the frequent deliveries and customer collaboration built into the approach given by the other more rigid methodologies.

What they wind up with is software that may work well, but doesn’t meet all of the customers’ needs. Good luck selling that!

Responding to change over following a plan

This is the core of what I think agile is trying to accomplish. It’s part of the “Crap Happens” mentality. This, more than any of the other tenets of the Agile Manifesto depends on the others. If you don’t allow your people to excel, don’t get something working to prompt feedback, don’t collaborate with the front lines in your business, then you can’t possibly know where change needs to be made or will be hampered in making it!

The word agile implies that you can adapt to change. The place where agile practitioners get this wrong is that this change can come at any point. You cannot force or expect these changes to occur when you start a new sprint.

I’m not stating that you shouldn’t set goals for what you want to accomplish in your sprint, but be aware that being diverted in building something you don’t need, or in a way that won’t meet your customers needs is a good thing. It saved you time, your employer money, and your customer frustration.

If you can’t adapt mid-sprint or mid-iteration, then what you’re practicing is weekly waterfall with pair programming and a meeting at the end. Don’t get caught up in the dumb little things that don’t matter. So, you had to rewrite a little code. You got it done that much sooner than if you had finished and then gone back to implement the changes on the next sprint.

You are the developer, not the company, so the better you can communicate and collaborate the better off you and your projects will be.

Conclusion

In the end, being Agile is about doing what works for you to provide the best service and software to your end users and to represent your company well. If you’re focused on anything other than providing great software, you’re missing the point. Period.

So, learn, adapt, try new things. If you’re just getting started, pick up an agile methodology and run with it, then find your own style. It may look crazy to everyone else, but when you look at the results it yields in your software and job satisfaction, you’ll realize that what they think doesn’t matter… So long as you still get a paycheck.