Quelltext der Seite Some Thoughts on Agile

=Some Thoughts on Agile=

Big risks, if not the biggest risks in a project are:

* Unclear requirements/ shifting scope – because you don’t know what to aim for, or you aim at a moving target
* Large head count – because communication becomes an issue when things don’t fit into a single head
* Absent/ unwilling customers – because the solution will be out of touch with what is needed (not to mention that “customer” often enough is not equal to “user”)

Many projects fail for these reasons. It would be very helpful to not have to work under these conditions. It would be helpful, too, to only have really good people on the team.

Unfortunately, many projects have to operate on this basis. Requirements are sketchy, but management demands a project plan in the first week of the project. Some project are large, because there is a ton of stuff to tackle in limited time. The people who hand you the requirements are often not the people who have requested the system, or the ones who are going to use it. And, especially in big companies, developers are a broad cross-section of the spectrum there is.

Now, if you look at the opposite of these detrimental factors, you get a good portion of what Agile is about:

* User stories that describe what the customer wants. Maybe not in great detail, maybe not completely at the start, but this is what iterations are for.
* Small teams, maybe a dozen people
* A customer who is always present and cooperates, giving feedback all the time (and who has the authority to do so)
* Highly communicative, capable developers who share a common, Agile mindset

Well, this is why I like to work in an Agile environment, too 🙂 I lead successful, agile projects under the prescribed conditions. I suffered like any others in big projects where the sheer amount of required cross-team communication stifles every move.

How to put this nicely… Any project that fits the second list of factors will have a much higher chance of success than a project plagued by the first list, no matter what approach is being used.

I have the impression that, at least to a degree, Agile increases project success by excluding major risk factors (please read on).

If that exclusion is by definition (“let’s only look at projects that fit the definition”), that is a cheap way to success. If a Marathon would be only 5 kilometers long instead of 42km, it would be much easier to run.

If that exclusion is by changing the approach (“let’s do it differently”), that is what Agile is about. The tough part is that places that attempt huge projects in a waterfall fashion are not exactly fertile ground for Agile approaches.

What gives?

* Agile defines a setup which is more likely to succeed, because it tries to get rid of certain major risks
* When a large projects with unclear scope and absent customer gives you a headache, Agile likely is not the solution to use in the situation, you would need to change the situation
* Should you see statistics that Agile projects have a higher success rate than conventional approaches, be aware that this may be owed to the fact that the projects done Agile inherently were less risky from the beginning, and that the big nasty ones were not even attempted in an Agile way.

So, try something new by changing the way you start and execute a project, not by trying to sprinkle a new method on a doomed setup.

[Categorie:ResistEntropy]