The Agile Manifesto - Principle 2
Principle #2 - Welcoming changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
This is a core tenet of Agile development: to expect and even welcome change. Conceptually I understand the reasoning behind it and can see the value, but in the real world I think it can break down. If change happens late in the development cycle, does that also mean the release date changes? Does that mean quarterly revenue estimates need to be remade? Does that mean the sales force needs to be reined in? Every change has an impact and change for change’s sake can not be made blindly as even the smallest change may have unforeseen ripple effects.
March 6, 2008 at 9:25 am
I found your site on technorati and read a few of your other posts. Keep up the good work. I just added your RSS feed to my Google News Reader. Looking forward to reading more from you.
Jason Rakowski
March 6, 2008 at 9:54 am
You bring up a very important point. If a team of software developers in corporation x adopts the principles of agile development, essentially the rest of corporation x must adopt the same principles. This doesn’t meant that your HR department suddenly becomes “agile” (although I wonder what Agile HR would look like), but it does mean that, as you indicate, the change will ripple across corporation x.
March 6, 2008 at 9:57 am
Yes, and this is a thing we are struggling with. We’re working on a large enterprise level application that is impacted by more than just my team. Even with my team running in an agile fashion, other teams are not going to (and actually can’t by their very nature).
How do you handle agile when you have something that’s going to take 3-6 months to do, like overhauling a complete data warehouse?
March 6, 2008 at 10:56 am
As far as I can tell, a “pure” agile environment is only possible for small, flexible projects in small, flexible situations. A “pure” waterfall environment doesn’t exist anymore, except in cases where developers are not held accountable for meeting customer expectations.
Where most of us end up is somewhere in a spectrum that lies between the two.
Regarding the first two principles - overhauling a DW doesn’t lend itself to “continuous” delivery, so we move away from continuity, but we strive nevertheless to deliver something of value. As far as changing requirements, this is a perfect example of the importance of “managing expectations”. We welcome changes in requirements, even late in development, but we need to be clear about the risk and impact of welcoming such changes.