A comment from "AMWOP" states: "Unfortunately while progressive developers may want to work in an Agile fashion the ecosystem around them is frequently fighting against being Agile. Executives, Customers, Testers, Business planners and many other stakeholders insist on detailed, committed plans up front which give them a (false) sense of confidence about viability of long range plans for software delivery. This in fact drives the developers back towards waterfall methodologies. It won't be until these functions change their mindset that Agile processes will make significant inroads in commercial environments."
I wholeheartedly agree. As with most things, adoption takes time. This is a classic example of crossing the chasm. Currently, Agile is in the visionary and early adopter phase. The software development habits that people have now took years to form. It will take many more years before they change.
In addition, the infrastructure for widespread adoption is not yet there. There are lots of books that you can buy, but they are mostly oriented towards the early adopter. On the software development tools side, most are still oriented towards waterfall methodologies. This is changing, but slowly.
This is no surprise. Change takes time. My prediction is that in 5 years time, we will drop the term "Agile Development" and just talk about software development because we'll no longer need to make the distinction between Agile and non-Agile. Instead, people will talk about how often you release because everybody will be doing short iterations. I also predict that Agile will evolve to the point that people stop saying that you might as well just throw up your hands on predictability because they will realize that Agile actually gives you the opportunity to be more predictable. More on that later.
Wednesday, October 25, 2006
Tuesday, October 17, 2006
Agile Development - It's Human Nature
The Agile Manifesto claims that the benefits of Agile Development come in part from "People over Process". That never sat quite right with me, but I could never put my finger on why. An obvious reason of course is that I work for AccuRev, a development tool vendor that specializes in process-centric SCM. So of course I must love lots and lots of complicated process that requires a tool to implement. Actually, I'm a big believer in simplicity and automation.
I believe that attitude, people, and culture have always been important to the success of any project. Therefore, I don’t agree that there is anything special about Agile when it comes to attitude, people, or culture. It may well be that current Agile projects are populated by risk takers and visionaries, but if that was what it required to succeed, then it would never become very popular.
In my opinion, all of the benefits of Agile Development can be directly attributed to the practice of short iterations. That said, simply changing your plans to release more often, say every month, won’t work. While it doesn’t matter how you get to short iterations, you do have to do things differently to get there and many of the practices associated with Agile Development are good candidates for doing it.
Over time, I’ve come to realize that there is in fact something special and people-oriented about Agile. Ironically, it is the process that makes it people-oriented. I believe that short iterations leverage human nature and thus allow us to fall into a more natural rythym in which we make fewer mistakes and we work more productively. While it is true that people can succeed on projects that have very long timeframes and involve a high degree of stress at the end, I believe that people are much more productive and much less prone to error when they work at a constant and sustainable pace. This also means that when there are unforeseen circumstances, people are more likely to be able to respond well.
Consider the following statements. I’ll bet that you’ll agree with most of them.
• When working on software for personal use, people make changes and then use the new version right away.
• One of the things that developers enjoy about software development is the fact that they can make a change and see the result right away.
• When working on a hotfix, people are more likely to cross all of the “t”s and dot all of the “i”s and take extra care to make sure that everything is done just right.
• It isn’t easy to create something that the customer thinks is exactly right the first time.
• People prefer to delay making important decisions as long as possible.
• Towards the end of a release when a new bug is found or a great idea for an enhancement comes in, it is tempting to just put it into the current release rather than the next release because the next release won’t happen for quite a while.
Each of these are a part of human nature. All of the positive parts are reinforced with short iterations, and all of the negative parts are reduced with short iterations. Conversely, long iterations work against the grain of human nature.
I believe that attitude, people, and culture have always been important to the success of any project. Therefore, I don’t agree that there is anything special about Agile when it comes to attitude, people, or culture. It may well be that current Agile projects are populated by risk takers and visionaries, but if that was what it required to succeed, then it would never become very popular.
In my opinion, all of the benefits of Agile Development can be directly attributed to the practice of short iterations. That said, simply changing your plans to release more often, say every month, won’t work. While it doesn’t matter how you get to short iterations, you do have to do things differently to get there and many of the practices associated with Agile Development are good candidates for doing it.
Over time, I’ve come to realize that there is in fact something special and people-oriented about Agile. Ironically, it is the process that makes it people-oriented. I believe that short iterations leverage human nature and thus allow us to fall into a more natural rythym in which we make fewer mistakes and we work more productively. While it is true that people can succeed on projects that have very long timeframes and involve a high degree of stress at the end, I believe that people are much more productive and much less prone to error when they work at a constant and sustainable pace. This also means that when there are unforeseen circumstances, people are more likely to be able to respond well.
Consider the following statements. I’ll bet that you’ll agree with most of them.
• When working on software for personal use, people make changes and then use the new version right away.
• One of the things that developers enjoy about software development is the fact that they can make a change and see the result right away.
• When working on a hotfix, people are more likely to cross all of the “t”s and dot all of the “i”s and take extra care to make sure that everything is done just right.
• It isn’t easy to create something that the customer thinks is exactly right the first time.
• People prefer to delay making important decisions as long as possible.
• Towards the end of a release when a new bug is found or a great idea for an enhancement comes in, it is tempting to just put it into the current release rather than the next release because the next release won’t happen for quite a while.
Each of these are a part of human nature. All of the positive parts are reinforced with short iterations, and all of the negative parts are reduced with short iterations. Conversely, long iterations work against the grain of human nature.
Wednesday, October 04, 2006
A Big Bang AccuRev Release
Some of my more recent thinking on software development, especially in regards to Agile Development, is in an article in the October issue of Queue Magazine, entitled "Breaking the Major Release Habit."
With that in mind I would like to mention that AccuRev 4.5 is now available. While it is called 4.5, it is actually one of our biggest releases ever. Here's a blog that mentions it. So why didn't we call it 5.0? Thankfully, that's not my department. :-) Anyway, my point is that while I believe very strongly in short iterations and more frequent releases, organizational change takes time and is hard to do.
To that end, I am currently working on a new project and piloting a new Agile methodology to develop it called Hyper Agile. The goal of the new project is to take AccuRev, which is already well suited to Agile projects, to the next level of Agile functionality. The aim of Hyper is to take a fresh look at Agile Development and scale it beyond small co-located teams. A preview of the Hyper methodology will appear in an upcoming issue of Dr. Dobb's, stay tuned!
With that in mind I would like to mention that AccuRev 4.5 is now available. While it is called 4.5, it is actually one of our biggest releases ever. Here's a blog that mentions it. So why didn't we call it 5.0? Thankfully, that's not my department. :-) Anyway, my point is that while I believe very strongly in short iterations and more frequent releases, organizational change takes time and is hard to do.
To that end, I am currently working on a new project and piloting a new Agile methodology to develop it called Hyper Agile. The goal of the new project is to take AccuRev, which is already well suited to Agile projects, to the next level of Agile functionality. The aim of Hyper is to take a fresh look at Agile Development and scale it beyond small co-located teams. A preview of the Hyper methodology will appear in an upcoming issue of Dr. Dobb's, stay tuned!
Subscribe to:
Posts (Atom)