The most liberating day of my career was when I realised that, despite being responsible for the project I was running at the time, I actually controlled very little of what happened. That was the day I freed myself from the “fallacy of control”.
I can’t really control who does what. I can’t really control whether an individual does the work to an acceptable quality. I can’t control whether or not the product owner is going to change their mind about priorities. I can’t control whether the proposed technical solution turns out to be much harder than anticipated or just a dead end.
All I can really do is influence what happens in my programme/project. Spot issues quickly and react appropriately. Lean-Agile gives me the tools to do that.
Search the Lean-Agile literature and you’ll struggle to find much mention of vision. Agile is all about short planning horizons, releasing stuff early and often, and learning. And a vision doesn’t necessarily help with that.
My direction? Anywhere. Because one is always nearer by not keeping still
The quote is from Engleby by Sebastian Faulks (cited Good Reads) and pretty much sums up the Agile attitude. Movement is the key rather than the direction of movement. Most Agile initiatives (i.e. projects and product development) are simply about building high priority stuff now, so it is no wonder that the Lean-Agile methods are relatively silent about the future.
In contrast a programme is about organisation change and the vision helps define the future state and attract buy-in – it is a “Postcard from the future”. A clear vision is an essential mechanism for staying aligned with business strategy. Alignment is, of course, one of my three threads within Agile Programme Management. The vision should be stable; not static but broadly resistant to change. Despite Agilists desire to “Embrace Change” a radically changing vision suggests the programme is no longer aligned with strategy and hence raises the question of whether the programme should be shut down.
In his brilliant post Don’t know what I want, but I know how to get it Jeff Patton used a sketch of Mona Lisa to illustrate the difference between Iterative and Incremental development.
Jeff points out that many Agile people use the word “Incremental” when they mean “Iterative”. I believe this is because, in reality, most Agile project combine both approaches and become Iterative Incremental. In fact I can’t imagine delivering software in any other way.
To illustrate what Iterative Incremental means I’ve taken Jeff’s Mona Lisa illustrations and added a third showing a combined Iterative Incremental approach.
Lean-Agile offers two productivity measures: Velocity and Throughput. It is possible to improve both over time but there is little point in management demanding that a development team improve either because both metrics are very simple to fudge.
There is also little point in using either of these productivity measures in product development. The focus is discovery not churning stuff out.
Where a productivity measure is useful is in a project or programme. Where somebody is wanting to know when the team will be finished. Or, conversely, how much functionality will be delivered before the time and/or money has run out.
The way I see it Agile Programme Management weaves together three threads: Transformation, Alignment and Adaptation. These threads are present in traditional approaches to programme management however an Agile approach subtlety changes each and increases the focus on Adaptation.
In this, the first post in a new series on Agile Programme Management, I’ll explain the three threads within Agile Programme Management.
For the last couple of years I’ve been running a lean startup within the BBC. No really, I mean it. It is indeed possible to have a successful lean startup inside a large publicly funded corporate. It is all about your outlook.
Personally I think good governance is essential for successful delivery, either within a programme or project, or part of on-going product development.
The recent publication of Governance for Agile delivery: Examples from the private sector July 2012 by the British National Audit Office suggests the UK government is also very interested in Agile and how it can be used to deliver value. But within the constraints of good governance.
However the term “governance” is rarely used along side “Agile”. As a agile programme manager I thought I’d try to answer the question “What is Agile Governance?”
Jim Highsmith proposed two simple strategies for successful software development: Build Less, Start Sooner.
Jim’s observation is genius, but I would add “Innovate Constantly”.
So your boss comes to you mid-sprint and demands a new oscillating-email-ingest-engine. Right now. Nothing else is higher priority.
Scrum says “Say no”. I think the discussion is more nuanced.
Last year I wrote a series of blog posts for the Project Research Institute of Athabascau University in Canada. As I mentioned before the PMI’s aim was to introduce their relatively mainstream audience to an Agile perspective. My aim was to show how the principles and practices of Lean-Agile Software Development offer creative solutions to general project challenges.
The PMI has now published all of my posts, including:
- Why Lean-Agile is relevant to all Project Managers
- A Lean-Agile Perspective on Project Governance
- Managing Complexity with Agility
- Empirical Project Management: Agile estimation and being “Done”
- Agile Experiments in Self-Organization