Agile IS All About Process

I regularly hear the “Agile is good, process is bad” mantra from various Agile communities. In a recent meeting on development methods one contributor even declared “process doesn’t contribute to the product so we should not put any effort into processes”.

I find this mindset rather entertaining.  It really does not need a genius to realize that the heart of any Agile method IS a rigid process definition. A lean, development  centric process but a process all the same. For example Scrum defines ways of working (backlog, prioritization, even the frequency, duration and form of “stand up” team meetings). Deliverable’s, Roles and Responsibilities are defined too.

My impression is that Agile methodologies work well when the process is followed and less so when it is not (for example when a team fails to identify a Product Owner that has a mandate to make product decisions – and more often than not assigns this role to developer who has little or no understanding of the customer or market).

Aside from the religious fervor that seems to emanate from many proponents of Agile there are many experience reports documenting the good, the bad and the sometimes down right ugly reality of Agile use in small projects (For example Savolainen & Kuuseka in “Transition to Agile Development – Rediscovery of Important Requirements Engineering Practices”), however I have seen very little by way of experience reports of Agile use on large scale developments (i.e. Scrum of Scrum). In fact, despite asking many Scrum users and being told such material is available none have managed to produce a statement of what they did, what worked well and what didn’t. Being somewhat agnostic this is much more valuable than lectures on what one should do.

Do you have experience you can share?

1 thought on “Agile IS All About Process

  1. The inquisitors of agile development are really a nuisance.
    We’re currently setting up a larger project with agile development. We plan to set it up as follows: on the program level, we do road maps, enterprise architecture and the overall release planning. From this program level we will trigger individual development projects. The development projects can choose their process between either RUP or SCRUM. On the program level, because we need some head start to define projects, we plan to tailor it based on the RUP. The architectural milestone (end of elaboration) for the program will be reached, once the first project starts its transition into using it. the people in the program will also be key people in each of the projects, e.g. as product owners, or specialists for enterprise architecture, UX design and requirements.

Comments are closed.