I personally think that both the articles have some good parts and some bad parts. He correctly points out that agilists can sometimes be loud and dogmatic. This is true and I've written about it before: Agile is not XP.
Having said that, I really do think that agile principles from the Agile Manifesto have a lot of value. Most of the problems associated with agile come from the 5 pitfalls list. Just to summarize, here is the list in short:
- Unfamiliarity
- Top-down thinking
- Culture change
- Incomplete implementation
- Silver bullet syndrome
When something starts to get popular, there are any number of managers who want to implement it to get immediate results. "This book says that if we write requirements on index cards instead of an excel sheet, we will be more successful." Obviously that is nonsense, but for a number of people, that is the take away message from agile. "Do X and you will be more successful," where X can be test first, pair programming, daily standups or what have you. You then have the manager forcing the team to have standups everyday, its 45 minutes long (Standups are supposed to be short, not more than 15 mins), and naturally everyone just hates it. The result? The engineers hate it, and the manager is disillusioned.
Don't obsess over techniques. If pair programming doesn't work for you, that's perfectly fine. Don't do it. Do what works. Maybe you are having a lot of success with daily standups. Continue to do it. A confession: I don't do pair programming either.
Techniques do not exist in isolation. There are a number of factors that contribute to the success of a technique: the people, the environment, the culture, the management. A technique might work great for Google, but be terrible in your environment. A technique that is terrible for Google might work great for NASA.
So if you are not going to focus on techniques, what do you focus on? I prefer to focus on principles. Being agile is not about writing requirements on index cards or doing test first development. To me, being agile is about valuing people, working collaboratively, improving continuously and delivering consistently.
Now, that is a lot easier said than done. A comment on Steve's post goes like this (the company mentioned is Google):
If the engineers didn't find it useful, the practices should have been changed. Continuous improvement of the process by the team is a cornerstone of agile. This is a perfect example of following the techniques and ignoring the principles.I worked on a team (at the same company as you) where we were essentially "forced" to use Scrum. I don't think a single engineer on our team found it useful, and I personally found it annoying, but we didn't really have a recourse for evaluation: I gave feedback that I didn't like it, but I'm not sure that everyone else was comfortable doing the same, and there weren't any of these wonderful double blind weekly evals. I also think its results were mis-used. The data that was derived from it (how much our team could accomplish in a week) was tainted and it shouldn't have been turned around and used to make decisions.
Agile is not a set of techniques. It is the principles that matter more than the techniques. Focus on the principles, and do the techniques that work in your environment.
This post is a part of the selected archive.
4 comments:
Great post. Couldn't have said it better myself. Too many people think Agile is about the specific techniques, when in reality the techniques are only a side effect. pliantalliance.org is all about questioning those who would have us believe that techniques X, Y, Z will lead to software development heaven. Like you said, we believe strongly that the principles are the important part, that we should be aware of our environment and use the techniques that work in our context (and don't use the techniques that don't work!)
Hi Tim, that sounds interesting. Sounds similar to Appropriate Process: http://www.aptprocess.com/index.htm
If Agile is nothing more than "adopt practices that work best for the team" then why do we need a manifesto, countless books, high-priced consultants, week-long training and endless blogging on the topic?
Every time an agile "best practice" falls under real scrutiny, the Agile dweebs run away from critical discussion with the statement, "if it doesn't work for you, don't use it." If I'm not getting a set of best practices out of Agile, I am not getting anything out of Agile.
Hi Dave,
No matter what methodology you choose, you want to do what works best for the team. This is as true of waterfall, iterative or anything as it is of agile. Why would you want to do something that does not work in your environment?
You bring up a good question, if it's just "do what works", something that is pretty obvious, then what is so great about agile?
The most important is that apart from so called 'best practices' - I prefer to call them techniques to emphasise that they are good in context - agile brings forward a number of principles. The agile manifesto is all about the principles. I find these principles valuable. To quote my article, "So if you are not going to focus on techniques, what do you focus on? I prefer to focus on principles....To me, being agile is about valuing people, working collaboratively, improving continuously and delivering consistently."
The second reason is that the techniques from the methodologies are a good starting point. Everyone needs a starting point from which you can adapt, and the agile methodologies provide these, packaged together in a form where they have worked for some other people. They also provide a varied set of techniques from which to select ideas for trying out.
Some related links: Shu-Ha-Ri and James Bach: No best practices
Post a Comment