Skip To Content

A Lean-Agile Perspective on Project Governance | Project Research Institute

A Lean-Agile Perspective on Project Governance

Ole Jonny Klakegg posed the question, "what are the most important means of governance that might help us keep our projects aligned with strategic objectives" even as the objectives change? Because the Lean-Agile methods arose from a need to "embrace change" (Beck, 2000) some aspects of Lean-Agile can help answer that question. This is not to suggest that all Lean-Agile programmes/projects have sufficient governance, but if a Lean-Agile approach is applied with care then some "means of governance" are already present. A glimpse into the Lean-Agile approach will, I hope, offer insights for wider project management community.

Firstly, what is governance? For simplicity I follow OJK's observation that that governance is the "alignment of projects with the organization’s goals. Above all, governance is about creating value". (Some, like Stretton (2010), layer additional meaning onto the term which I do not find helpful; for example, I disagree with Stretton's assumption that that governance work is separate from management work and that the governance body is a program/project board.)

I will look at five aspects of typical Lean-Agile that aid governance in some way. A word of warning - these activities, even in combination, do not necessarily provide sufficient project governance of themselves. For more customised versions of Lean-Agile with stronger governance have a look at Allan Kelly, Aterny, Keith Richards, and/or Scott Ambler.

1. Assign somebody to steer

Companies attempting Lean-Agile try to delegate to the lowest level possible (Jim Highsmith). The most common example of this is have somebody on the team responsible for dealing with change as it impacts the project. Following Scrum I call this role the "Product Owner" (Schwaber & Beddle, 2002) but it is also called the On-site Customer (Beck, 2000), and in DSDM Atern is the Business Visionary/Ambassador. Whatever it is called, the product owner is part of the delivery team and actively participates in the process. This person's main responsibility is to shape the product throughout the project. The product owner identifies and explains the requirements, prioritises requirements, provides feedback on the emerging product, and accepts the resulting product on behalf of the company. They can also, within limits, change the scope (see below).

2. Deliver early and often

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" (Principles behind the Agile Manifesto). In a project the finished deliverables are what enable value creation; delivering early and often enables value to be accrued throughout the project. The main benefit is that stakeholders get to see visible progress as the work proceeds. Commonly Agile projects are organised into timeboxes of one to six weeks (Agile Lifecycle) however increasingly companies are trying to shrink software delivery lead-time further, from weeks to hours, adopting continuous delivery of new features (Humble & Farley, 2010). Perhaps software has an advantage over other domains because the work can be packaged in small batches and it is this which enables the move to shorter lead-time (Poppendiecks, 2007).

3. Do high value work first

Lean-Agile teams prioritize high value items early in the project. This ensures early return-on-investment but also, in combination with frequent delivery, makes the project more resilient to change. Part way through a project the undelivered scope is, by definition, lower value compared to the work done earlier. So when new, high value, items are identified they can safely swapped for low value items, assuming the effort is similar.

4. Plan to learn To deliver early

Agile Project Initiation has to be compressed in comparison to more traditional approaches. The main deliverables of the upfront phase are a initial high level requirements and initial high level plan. Both are expected to change so, from the agile perspective, there is little point in investing more time in these interim deliverables. The same is true throughout the project because the team expect to continually learn about the product. Agile Project Monitoring and Control includes several practices that enable regular, and formal, feedback. Daily team meetings - also called Daily Stand Ups (Beck, 2000) or Scrums (Schwaber & Beddle, 2002) - the product demonstrations at the end of each timebox, and regular delivery of working software are all opportunities for feedback and learning. The feedback is from team to management and the customers, and in the reverse direction as well. Ultimately the key question is, do customers appreciate the new features and/or the product as a whole or should the team do a pivot (Ries, 2011)? A pivot being a major change in business direction.

5. Make change easy

Lean-Agile teams make change easy. Traditional projects are protected from scope changes by formal change management processes. Often involving escalation to a change board outside the team the formal processes are slow. In contrast Lean-Agile teams "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage" (Principles behind the Agile Manifesto). As change is expected Agile Change Management is light weight. At the simplest this is the product owner deciding what to prioritise for development and, by implication, what gets dropped to stay within time and budgetary constraints.

The aspects of Lean-Agile described above help create value and/or stay aligned with changing strategic objectives. Although taken from a software development context I believe they can offer project managers in other domains insight into how governance can operate in a changing context.

References and Further Reading

Agile Manifesto

Ambler, S. W. (2007). Best practices for lean development governance. IBM.

Ambler, S. W. (2009). Discipline Agile Delivery. IBM.

Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.

Highsmith, J. (2007). No more self-organising teams. Cutter Consortium. Humble, J. & Farley, D. (2010). Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. Addison-Wesley.

Kelly, A. (2009). A new governance model for Agile work. Technology Management.

Klakegg, O-J. (2011). Governance as alignment with strategy. PRI.

Klakegg, O-J. (2011). Clarity in the governance of projects: is it possible?. PRI.

Poppendieck, M. & Poppendieck, T. (2007). Implementing Lean Software Development: From Concept to Cash. Addison-Wesley.

Richards, K. (2010). Agile Project Management: Integrating DSDM Atern into an existing PRINCE2 environment. OGC.

Ries, E. (2011). The Lean Startup: How constant innovation creates radically successful businesses. Penguin.

Stretton, A. (2010). Notes on Program/Project Governance. PM World Today, XII(I).

Schwaber, K., & Beddle, M. (2002). Agile software development with Scrum.. NJ: Prentice Hall.

Thomas, S. (2008). Agile Change Management. It's a Delivery Thing.

Thomas, S. (2008). Agile Lifecycle. It's a Delivery Thing.

Thomas, S. (2008). Agile Project Monitoring and Control. It's a Delivery Thing.

Thomas, S. (2008). Agile Project Planning. It's a Delivery Thing.

Thomas, S. (2008). Agile Roles and Responsibilities. It's A Delivery Thing.

The Institute

The newly created Project Management Research institute provides a focus on collaborative research excellence in project management. Read more..