In a project or product development context you can determine the level of agility by the way you structure, sequence and finally validate the completed parts. And what you do with what you learn.
What you should worry about
- is setting up a structure and finding an approach, where everyone is able to contribute and has the freedom to perform, very much like Game Changing Beliefs
- find a way to break down what you have to do in ‘minimal viable somethings’ and in this way stamp out ‘winnable missions’ for your teams, very much like what Tom Gilb taught us with EVO to drive fast and frequent feedback based on quantitatively defined objectives and very much to keep flow flowing like expressed by Don Reinertsen
- actually being able to validate and give objective feedback, very much like in validated learning from Lean Startup
- constantly pivoting or persevering at all levels to overcome impediments, drive learning and exploit new opportunity, instigating Agile Engines in the areas required
I believe these would be the ingredients in operating agile at scale in projects and product development
If you believe in self organization, the least you should worry about is how your teams work
To do agile at scale – structure, sequence, validate what you do – let your teams figure out how
Creating the right structure drives the right behavior.
Driving lead time by sequencing work in ‘minimal winnable missions’
Early validation drives fast and frequent feedback,
… which drives learning and innovation
We often overlook that agility in the organization goes beyond the operational practices at the team level. If you get it right, you should see tangible benefits at the organization level in terms of better immediate results, short term predictability, fewer binding future commitments and reduced risk from work in progress. These are the tangible benefit of doing agile at scale.
(v0.03, 04-Jul-2015)
===
Mike Cottmeyer express very similar ideas: http://www.leadingagile.com/2015/08/the-leadingagile-transformation-manifesto