Principles of Stakeholder Management, Agile, and Lean

Agile Software Development, Lean Thinking, Lean Software Development, and the Toyota Production System (TPS) all have a set of founding principles. These are understood and are receiving increasing attention in software development. Deming’s management principles have had enormous influence on the evolution of TPS and Lean. Stakeholder Management is an area of strategic management that so far has received less attention in software development, but equally has a set of founding principles that we can learn from and that compliment the other sets of principles.

Overview

Principles provide guidance, in the form of non-prescriptive rules, for making decisions in contexts that the authors of those principles can’t imagine. Systems such as Agile Software Development and Lean Thinking are bolstered by a set of guiding principles. The same is true for Lean Software Development and the Toyota Production System (TPS). All over the world, teams and organizations are benefitting from applying these principles to become more agile, more lean. The power of principles lie in the fact that these teams and organizations can successfully apply these same principles using different sets of practices that meet their particular needs.

Although often used almost interchangeably, there is a fundamental difference between Lean Thinking, Lean Software Development, and the Toyota Production System (TPS). Each has its own set of principles, and I present them separately below.

Stakeholder Management also has a set of guiding principles. Taken together, the principles of Stakeholder Management, Agile, Lean Thinking, TPS and Lean Software Development provide a powerful system for guiding organizations engaged in development of products and systems. For me, the principles of Stakeholder Management provide balance to the others and help to create a more complete picture of what an organization needs to consider.

As shown in the diagram, Stakeholder Management Principles form part of a ‘system of principles’ for organization design. This article provides a summary of the principles, not a deep analysis. As part of my research work I am working on a paper that provides that deeper level of analysis.

 

Organization Design Principles

Organization Design Principles

Stakeholder Management Principles

There are ten principles of Stakeholder Management. These are from R. E. Freeman’s ‘Managing for Stakeholders‘.

  1. Stakeholder interests need to go together over time.
  2. We need a philosophy of volunteerism – to engage stakeholders and manage relationships ourselves rather than leave it to government.
  3. We need to find solutions to issues that satisfy multiple stakeholders simultaneously.
  4. Everything that we do serves stakeholders. We never trade off the interests of one versus the other continuously over time.
  5. We act with purpose that fulfills our commitment to stakeholders. We act with aspiration towards fulfilling our dreams and theirs.
  6. We need intensive communication and dialogue with stakeholders – not just those who are friendly.
  7. Stakeholders consist of real people with names and faces and children. They are complex.
  8. We need to generalize the marketing approach.
  9. We engage with both primary and secondary stakeholders.
  10. We constantly monitor and redesign processes to make them better serve our stakeholders.

The application of Stakeholder Management to Agile and Lean product development organizations is the subject of my ongoing research work.

Agile Principles

There are twelve principles behind the Agile Manifesto:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Toyota Production System (TPS) Principles

There are fourteen principles behind the Toyota Production System. These are a summary of the TPS principles in Jeffrey Liker’s ‘The Toyota Way‘. Liker groups the fourteen principles into four sections.

Section I: Long-Term Philosophy
1. Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.
Section II: The Right Process Will Produce the Right Results
2. Create a continuous process flow to bring problems to the surface.
3. Use “pull” systems to avoid overproduction.
4. Level out the workload (heijunka). (Work like the tortoise, not the hare.)
5. Build a culture of stopping to fix problems, to get quality right the first time.
6. Standardized tasks and processes are the foundation for continuous improvement and employee empowerment.
7. Use visual control so no problems are hidden.
8. Use only reliable, thoroughly tested technology that serves your people and processes.
Section III: Add Value to the Organization by Developing Your People
9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.
10. Develop exceptional people and teams who follow your company’s philosophy.
11. Respect your extended network of partners and suppliers by challenging them and helping them improve.

Section IV: Continuously Solving Root Problems Drives Organizational Learning
12. Go and see for yourself to thoroughly understand the situation (genchigenbutsu).
13. Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly (nemawashi).
14. Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen).

Principles of Lean Thinking

In ‘Lean Thinking: Banish Waste and Create Wealth in Your Corporation‘, James P. Womack and Daniel T. Jones describe five principles of Lean Thinking:

  1. Value (as defined by the consumer, and created by the producer).
  2. The Value Stream (the set of all specific actions required to bring a product from concept through producer to consumer)
  3. Flow (specifically, the flow of value creating activities, or how the work flows through our organizations)
  4. Pull (people in the value stream pull work when ready, rather than have it pushed on them)
  5. Perfection (the ongoing, continuous pursuit of improvement and of the elimination of waste)

Lean Software Principles

Mary and Tom Poppendieck have been working on applying Lean production to software development. Their first book in 2003, ‘Lean Software Development: An Agile Toolkit‘ describe seven principles of Lean Software Development. In their second book, ‘Implementing Lean Software Development‘, the Poppendiecks revise their seven principles of Lean Software Development. They also provide a roadmap in the form of a 21-step program for implementing the seven principles, using 3 steps per principle.
1. Optimize the whole
  • Implement lean across an entire value stream and the complete product
  • Restructure the measurements
  • Reduce the Cost of Crossing Boundaries
2. Respect people
  • Train team leaders / supervisors
  • Move responsibility and decision-making to the lowest possible level
  • Foster pride in workmanship
3. Deliver fast
  • Work in small batches at a steady cadence
  • Limit work to capacity
  • Focus on cycle time, not utilization
4. Defer Commitment
  • Abolish the notion that it is a good practice to start development with a complete specification
  • Break Dependencies
  • Maintain Options
5. Create knowledge
  • Create design-build teams
  • Maintain a culture of constant improvement
  • Teach problem solving methods
6. Build quality in
  • Synchronize
  • Automate
  • Refactor
7. Eliminate Waste
  • Provide market and technical leadership
  • Create nothing but value
  • Write less code

Deming’s 14 Points

If you want to understand the history of Lean development, then you need to read Deming. W.Edwards Deming define his principles as 14 points. For a deeper understanding and explanation of Deming’s points, see Deming’s own ‘Out of the Crisis’ or Mary Walton’s ‘The Deming Management Method’.

  1. Create constancy of purpose for improvement of product and service. Deming suggests a radical redefinition of a company’s role. Rather than focus just on making money, the role of the company is to stay in business and provide jobs through innovation, research, constant improvement, and maintenance.
  2. Adapt the new philosophy. Our organizations should not accept the production of poor quality products and services.
  3. Cease dependence on mass inspection. Deming argues that quality comes not from inspection of the product at the end of the cycle, but rather from improvement of the process.
  4. End the practice of awarding business on price tag alone. Build long-term relationships with suppliers.
  5. Improve constantly and forever the system of production and service. Improvement needs to be accepted as a continuous, with everyone seeking ways to reduce waste and improve quality.
  6. Institute training and retraining (in skills).
  7. Institute leadership. Leaders help people do a better job, and know how to focus on the individual needs to everyone they are responsible for.
  8. Drive out fear.
  9. Break down barriers between staff areas. Apart from the functional silos that pose a problem, different groups can have different, competing goals.
  10. Eliminate slogans, exhortations, and targets for the workforce.
  11. Eliminate numerical quotas. If you ask someone to meet a quota, they will meet it at any cost. They encourage local optimizations. The problem with quotas is they only consider numbers, not quality or methods, and usually lead to high costs and inefficiency.
  12. Remove barriers to pride of workmanship. People want to do a good job. Sometimes the system prevents them from doing so.
  13. Institute a vigorous program of education and retraining (in the process). Everyone in the organization (and even beyond) is a stakeholder in the process, and needs to be trained, and retrained as the process evolves and improves.
  14. Take action to accomplish the transformation. This point calls for an effective change management program, with a critical mass of people from all levels in the organization.

Conclusions

It’s interesting to examine the principles from these different value systems and to see how they compare. What’s interesting for me is how they work so well together. There are areas where they have a lot in common, and there are areas where they address different concerns yet compliment each other well. As the software industry embraces agile and lean methods it is important to build an understanding of founding principles so we understand where these methods have come from, and what it takes to be successful with them. Blindly copying a set of practices will have limited, if any, positive results for a team or an organization. Developing a deep understanding of the underlying principles, and then working out how to apply these principles to the benefit of your organization and stakeholders, will have a far more lasting and positive impact.

I am continuing to explore these principles, as well as related areas, to see how they work together in practice, and how we can evolve them.

I would love to hear your experiences, thoughts and opinions.

Refactoring the Organization Design – LESS2010

I was fortunate to be invited to speak at the First International Conference on Lean Enterprise Software and Systems, 2010, in Helsinki last week. I presented on the topic of organization change, as part of the Scaling Agile to Lead track. More specifically, on the type of change that is implied when an organization decides to adopt agile and/or lean.

The main theme of my talk was in support of applying concepts from Stakeholder Management to support agile and lean adoption. I used the concept of refactoring to talk about some of the changes that can be made to organizations, and showed some examples of how Martin Fowler’s classic Refactorings can be re-purposed to talk about organization design rather than software design.

The main topics of my talk were:

  • Using Dan Pink’s Motivation 3.0 Type-I toolkit for intrinsic motivation as a guide for what we should be refactoring towards
  • Refactoring applied to Organization Design
  • Agile transition journeys
  • Designing a process: core framework versus toolbox
  • Refactoring toolshed
  • Stakeholder Management
  • Stakeholder Mapping applied to Scrum teams
  • Stakeholder Management and the challenges of Product Ownership for large organizations
  • Stakeholder Management and the role of manager
  • Stakeholder engagement
  • The power of metaphors for organizational learning
  • Jazz improvisation as a metaphor for organizational learning and stakeholder engagement
  • Artful Making as a metaphor for software development and stakeholder engagement
  • Organization Patterns

Paper Abstract

The following is from the abstract of my paper that was published in the conference proceedings:

Every organization has a design. As an organization grows, that design evolves. A decision to embrace agile and lean methods can expose weaknesses in the design. The concept of refactoring as applied to software design helps to improve the overall structure of the product or system. Principles of refactoring can also be applied to organization design. As with software design, the design of our organization can benefit from deliberate improvement efforts, but those efforts must have a purpose, and must serve the broad community of stakeholders that affect, or are affected by, the organization. Refactoring to agile and lean organizations demands that we have a shared vision of what the refactoring needs to achieve, and that we optimize the organization around the people doing the work.

The full conference proceedings are available form Springer.

Presentation slides

My presentation slides are here:

Stakeholder Management

We often use the term stakeholder in software development, however the use is often limited to financiers, executive management, customers, or others who have a direct financial stake in the products or services we provide. I have always thought this to be a limited (and limiting) perspective. There are many more people and groups that have a stake in what we do.

Stakeholder Management is an area of strategic management that provides models for identifying and mapping stakeholders. Probably the primary author and thinker in the area is R. Edward Freeman. Freeman’s work encourages a broader use of the term ‘stakeholder’. Freeman identifies seven techniques for creating value for stakeholders, including stakeholder assessment, stakeholder behavior analysis, understanding stakeholders in more depth, assessing stakeholder strategies, developing specific strategies for stakeholders, creating new models of interaction for stakeholders, developing integrative value creation strategies (See the books Strategic Management: A Stakeholder Approach and Managing for Stakeholders).

I have published several papers that describe Stakeholder Theory, Stakeholder Management, and how these can be applied to software product development organizations. The application of Stakeholder Management to agile and Lean product development organizations is the topic of my ongoing research.

Managing for Stakeholders

Managing for Stakeholders

 

Freeman et al take a broad view of who are the stakeholders in an organization. In this book they present ten principles of stakeholder management, and seven techniques for stakeholder engagement.

Authors: R. Edward Freeman, Jeffrey S. Harrison, Andrew C. Wicks

Publisher: Yale University Press (October 30, 2007)

ISBN-10: 0300125283

ISBN-13: 978-0300125283

Buy on Amazon

 

Strategic Management: A Stakeholder Approach

Strategic Management: A Stakeholder Approach - Book by R.E. Freeman

Classic text on Stakeholder Management from R.E. Freeman. First published in 1984, it has been hard to find in recent years, but there is a recent reprint issued by Cambridge in 2010. This book provides a history of the term ‘stakeholder’ and the theory behind Stakeholder Management. The book explores the roots of Stakeholder Management in Corporate Planning, Systems Theory, Corporate Social Responsibility, and Organization Theory.

Author: R.E. Freeman

Publisher: Cambridge University Press (March 11, 2010)

ISBN-10: 0521151740

ISBN-13: 978-0521151740

Buy on Amazon

PhD in Stakeholder Management applied to Agile and Lean Organizations

I have always been interested in research – exploration, discovery, figuring things out, solving problems. I’m curious by nature and enjoy a good problem to solve. One of the things that appeals to me about working in R&D organizations is the emphasis in attention on both research and development. I’ve had the opportunity to work in different industries and different problem domains over the years, and on a wide variety of different products and systems.

I’ve been working with agile development methods (initially XP, later Scrum, Crystal and others) since around 1999, and in more recent years with Lean and Kanban. Throughout that time I have developed a deep interest in understanding what makes effective organizations work. One thing I have become acutely aware of over the years is that everything in software development comes down to people – the people themselves, yes, but also the organizations that people choose to put in place, and the organizations that are put in place around them.

For a few years I had been thinking about doing a PhD. In 2009 I registered as a PhD student with National University of Ireland, Galway (NUIG), while still continuing to work full time. I’m hoping to be complete in around 2012. I’m also fortunate enough that I can apply research ideas in the context of my day job. We’ll see how it goes.

My area of research is the application of Stakeholder Management principles and stakeholder theory to agile and lean product development organizations. I already have a strong background in agile methods. This gives me the opportunity to dive deep into Stakeholder Management, and understand how Stakeholder Management can benefit agile and lean organizations.

Understanding who our stakeholders really are, and how their stake changes over time

When we use the term stakeholder in software development, we often take too narrow a view of who our stakeholders really are. Classic stakeholder management defines a firm’s stakeholders as those people and groups that influence, or are influenced by, the activities of the firm.

To successfully ship a product or deliver a service, it helps to understand who has a stake in our product, our services, and our organizations. It also helps to understand that the nature of that stake or claim changes over time. Applying principles of stakeholder management helps our agile and lean organizations to be successful.

Motivation

If we understand who our stakeholders are, and when their claim takes on a higher degree of salience, then we can, among other things:

  • Better plan for how and when to engage with the diverse community of stakeholders that influence, or are influenced by, our products and services
  • Avoid surprises as we innovate, design and ship products
  • Reduce risk, or at least identify risks that we might otherwise miss
  • Take a more holistic view of the people involved in our product development, or service delivery
  • Avoid the need to revisit issues because the right people were not involved in the decision-making process
  • Create whole teams that create and deliver the right products

We can use 3 attributes (Power, Legitimacy, and Urgency) to create a simple model that helps us to understand our stakeholders’ salience. We can apply this model from multiple perspectives, e.g.,

  • from the perspective of the managers of the firm
  • from the perspective of the product team
  • from the perspective of the product itself
  • from the perspective of users of the product

Open Jam at Agile 2010

At this Open Jam session at Agile 2010 we will

  • Explore who the wide variety of stakeholders are in a product development effort.
  • Attempt to understand these stakeholders in terms of Power, Legitimacy, and Urgency, and how that helps us know which stakeholders we need to pay attention to
  • Attempt to understand how the salience of stakeholders changes over time, by looking at different stages in the life of a product, and therefore understand that we need to pay differing levels of attention to different stakeholders at different times.
  • Anything you want to talk about…

Format

We will use a simple map that correlates stakeholder engagement with time, highlighting various phases of a product’s or feature’s life cycle.

Using a whiteboard, flip chart paper, markers and stickies, we will work together to understand which stakeholders have a stake at different times in a product’s life cycle, and how that stake changes (or has the potential to change) over time.

Where and when

Open Jam session at Agile 2010 on Thursday August 12th at 5:15 PM in the Genie Open Jam area.

Refactoring the Design of the Organization

Every organization has a design. As the organization evolves, the design may or may not evolve to support the needs of the organization’s stakeholders (including the agile teams, managers, executives, customers, etc.). Sometimes we may wish we had the opportunity to start again with our organization design, and may even have some solid ideas about what we would do differently. However, few of us have the luxury of actually starting again, unless perhaps we build a new company.

Motivation

Organizations that decide to ‘go agile’ or adopt ‘lean development’ are often not prepared for the sort of organizational issues that are implied by such a decision. Even those organizations that, with the greatest of intentions, tell their teams to “go, be agile”, do not set their teams up for success unless they provide the right organization support structures that create the right environment for their teams to be successful. Sometimes, fundamental is required.

For established companies with an established design, if we want to change something, then we need to refactor the design of the organization.

Managers, executives and other leaders have a crucial role to play as designers of the organization.

Open Jam at Agile2010

I’ll be speaking in greater detail on this topic later this year at LESS2010.

This Open Jam session at Agile 2010 will explore a number of questions, e.g.:

  • What refactorings would you apply?
  • What are we refactoring towards?
  • What is our measure of success?
  • How do we make sure we don’t break the organization while refactoring?
  • Should we be refactoring towards yet another fixed structure, or should the new structure accomodate, expect, and support ongoing change?
  • What structures do we need so that we build teams that are truly whole, cross-functional, and empowered to build the right thing?
  • What tests can we apply to ensure the refactorings are successful?
  • How do principles of coupling and cohesion apply to organization design?
  • Who are the key stakeholders in the organization design?
  • How does the current organization design serve it’s stakeholders, and how will the new organization design change that?
  • Do we really need to change anything? Can’t we just patch the current organization design?
  • What about skill specializations? Can communities of practice within our organizations replace functional silos?
  • What about HR issues? Reward structures? Compensation?
  • How can we build more autonomy into the organization?
  • What’s the relationship between organization vision and organization structure?
  • What are the implications for decision making?
  • How can we apply the Type I Toolkit for Organizations, so that we create an environment where intrinsic motivation can thrive?
  • Anything you want to talk about…

Format

Using whiteboard, flip chart paper, markers and stickies, we will work together to understand how we might go about refactoring an organization.

We can take an example of a typical, large matrix organization with functional silos and discuss what refactorings we would like to apply.

Where and when

Open Jam session at Agile 2010 on Thursday August 12th at 12:30 in the Genie Open Jam area.