<br /><br /><img src="http://itshouldbeeasy.files.wordpress.com/2010/10/20101022-233524.jpg" alt="Agile Scrum software development manager" title="Agile Scrum" width="640" height="480" /><br /> Waterfall doesn't work or at least it is definitely good at failing. We deliver the majority of our projects using the Waterfall methodology, but there is usually a reduction of scope or a slippage on dates and certainly a huge dollop of risk. We constantly bemoan the fact that the requirements aren't clear and change as time goes on; but all attempts at remediation yield nothing. Enter Agile; the saviour of development teams the world over. This week I accompanied a number of previously cynical managers on an Agile Awareness course. Not so much a training course, as the instructor was keen to point out, more an outline of the overarching mentality, some of the principles and an attempt to highlight why it should be adopted. But what do you mean by Agile some might cry. After all, Agile is not one single process or methodology, more the heading for a whole raft of them. It was clear that the software development centric audience were keen to vociferously articulate the bug bear of incomplete and changing requirements. This is currently viewed as the biggest software development bogeyman. It leads to poor estimating, poor quality and inconsistent delivery; or at least that is what the squeaky clean software developers want to believe. Can Agile help? Clearly any system that simplifies the description of requirements and then iterates the development around them in tighter loops has to help. There is also merit in closer engagement between the business domain experts and the systems domain experts; all in a scrum I hear you shout. I think it is fair to say that the merits of Agile were there for all to see. By the end of the day it was clear to many that there could be some significant benefits to be had. It was also very clear that without significant commitment from the business we would not be able to secure any benefits. None of this is really news. Agile grew up because Waterfall consistently failed. But how much do you need to implement to make any development gain the Agile benefits. We don't have much Greenfield development and minimal use of technologies that support TDD. Very little take up of continuous build and or integration. So most of what we do in development is unlikely to be easily switched. My view is that the minimum we should aim for is breaking the requirements development issues. Why not create cross functional teams to get to to a clear specification of the delivery. Do the planning in the style of a sprint and get workable development task or user stories as a result. Still I remain unconvinced. I think I would conclude what I have always concluded. Yes some principles are worth adopting, but if you really want to go Agile then commit to a lot and not a little.

Waterfall doesn't work or at least it is definitely good at failing. We deliver the majority of our projects using the Waterfall methodology, but there is usually a reduction of scope or a slippage on dates and certainly a huge dollop of risk. We constantly bemoan the fact that the requirements aren't clear and change as time goes on; but all attempts at remediation yield nothing.

Enter Agile; the saviour of development teams the world over. This week I accompanied a number of previously cynical managers on an Agile Awareness course. Not so much a training course, as the instructor was keen to point out, more an outline of the overarching mentality, some of the principles and an attempt to highlight why it should be adopted. But what do you mean by Agile some might cry. After all, Agile is not one single process or methodology, more the heading for a whole raft of them. It was clear that the software development centric audience were keen to vociferously articulate the bug bear of incomplete and changing requirements. This is currently viewed as the biggest software development bogeyman. It leads to poor estimating, poor quality and inconsistent delivery; or at least that is what the squeaky clean software developers want to believe.

Can Agile help? Clearly any system that simplifies the description of requirements and then iterates the development around them in tighter loops has to help. There is also merit in closer engagement between the business domain experts and the systems domain experts; all in a scrum I hear you shout. I think it is fair to say that the merits of Agile were there for all to see. By the end of the day it was clear to many that there could be some significant benefits to be had. It was also very clear that without significant commitment from the business we would not be able to secure any benefits.

None of this is really news. Agile grew up because Waterfall consistently failed. But how much do you need to implement to make any development gain the Agile benefits. We don't have much Greenfield development and minimal use of technologies that support TDD. Very little take up of continuous build and or integration. So most of what we do in development is unlikely to be easily switched. My view is that the minimum we should aim for is breaking the requirements development issues. Why not create cross functional teams to get to to a clear specification of the delivery. Do the planning in the style of a sprint and get workable development task or user stories as a result. Still I remain unconvinced.

I think I would conclude what I have always concluded. Yes some principles are worth adopting, but if you really want to go Agile then commit to a lot and not a little.