Agile

Projects are a tricky thing. No matter how much you plan, or how adaptable and agile you are, something will always go wrong. Any project manager who states that they have never had a failed project is young, confused or going for a job interview.

Consider for a moment, your management style. Dr W. Edwards Deming, put forward two types of mistakes that you, as a manager can make when dealing with "variation" in process and outcomes. Interfering or tampering when everything is normal or within tolerance (common causes), indicative of micromanagement, and a failure to intervene when a process in out of control (special causes), indicative of absenteeism. As an Agile Manager, you need to find the middle ground between these two extremes.

I had a great time attending and speaking at AgileDC (http://agiledc.org/) earlier this week. I found the presentations to be interesting and educational and the people very friendly. This is just a quick write-up of some of those presentations that I attended.

Adaptive Leadership: Accelerating Enterprise Agility - Jim Highsmith (http://agiledc.org/presentation/keynote-adaptive-leadership-accelerating...)

I feel that there is a capability gap in the suite of methods making up the formal Agile methodologies. Specifically a programme management method to govern large organisational change programmes and the related projects that support them. Let's call this concept Agile Programme Management or APM (I never said I was good with names).

While there are many popular processes for personal productivity, GTD & Inbox Zero (http://inboxzero.com/) immediately spring to mind, neither of these scales well to manage team or project productivity. Part of the Agile toolbox, Kanban is a workflow & workload management method to improve the productivity of individuals (sometimes called personal Kanban), teams and projects. At its core, Kanban provides Just In Time (JIT) visualisation, scheduling & control mechanisms to track tasks through their lifecycle.

Becoming an agile organisation is an incremental process. There is no point you say to yourself, "yesterday we weren't agile, but today we are. Success!". However, there are points you can say, "today we are more agile than yesterday!". The journey be become an agile organisation can be formal, through a transformation program, or informal, through ad-hoc changes addressing problem areas. Regardless of the mechanism, your agile journey begins with a set of clear organisational goals. What is your organisation trying to achieve by becoming agile?

The 3rd domain of Agile Governance develops an organisational structure that promotes the increased communication, trust and empowerment of your teams. The ideal Agile Governance structure has minimal layers of management between the CEO, or equivalent, and junior team members. By empowering individuals and teams with personal authority & responsibility to deliver the Customers requirements, combined with self-organising teams, a single mid-level manager should be capable of supporting between 5 and 10 teams.

“How much is this going to cost?” - “As much as you're willing to spend.”
“How long is this going to take?” - “As long as it necessary.”
“What am I going to get?” - “Whatever you tell us you want.”

These are the common questions that get asked at the beginning of any project. “Pure” agile has minimal constraints beyond the customers imagination. The high-level scope that is defined at the beginning of a project can be changed out of all recognition as the customer evolves the product backlog between iterations.

In preparation for a book, this blog post is the first of many on Agile Governance; a topic that I have been researching and developing for a few years. Unlike many of my other blog posts (which are extensions of standard processes), this concept is cutting edge, and I am really looking for as much feedback and comment as possible.

So without further ado;