Agile in large organization

After reading Scott Ambler on Disciplined Agile Delivery (DAD) I have started to think more deeply on how to integrate/include agile in a running organization.

Scrum is a nice process framework, but adopting it may be not so simple and effective in large organization where more “formalized” processes and artifacts are required.

So let’s see how Scott Ambler propose a larger view of a “Scrumy” process:

to a wider one:

Of course there are potential benefits in adopting it, but - as always - we’ll encounter some trade-offs to deal with. Let’s see some of them.

Requirements are ever-evolving That is true, especially if you see change requests and problem reports as change on requirements (and to be clear: you must manage it). But it’s also true that in the inception phase of the project all (key) stakeholders should agree on a vision, a common backgronud for the features the system will provide. Fixed thata background it’s normal that requirement may change.

Self organizing teams in constrained environments It’s a fact: intellectual workers express the best from themselves when they have an active participation in the work they are doing. Agile promotes such aspects, but in large organizations often teams are dealing with more projects/operations at once and people and people may be burned and demotivated more easily. Be careful on that.

Lack of process Adoption Agile doesn’t mean there isn’t a process at all. Always we have to deal with customers, subcontractor, and so on… with a clear set of rules on “how to do” all that. Someone (proxy Product Owner? Scrum Master?) should deal with such things.

Finally I’d like to quote Scott Amber on definition of DAD process:

DAD is both iterative in the small but serial in the large.

That is particularly important: iterative in the small when you can appreciate rapid feedback loop and serial in the large when more wide-range artifact lives (think for a moment about a large program…).