Active Stakeholder Participation: An Agile Best Practice

Agile Modeling

Table of Contents

 

 

 

Strategies for Working Together

AM’s practice of Active Stakeholder Participation is an expansion of eXtreme Programming (XP)'s On-Site Customer that describes the need to have on-site access to people, typically users or their representatives, who have the authority and ability to provide information pertaining to the system being built and to make pertinent and timely decisions regarding the requirements, and prioritization thereof.  While this level of participation is required to make your software development efforts effective it often isn’t sufficient in many organizations, particularly those where politics and not reason are the order of the day.  Project success often requires a greater level of involvement by project stakeholders – senior management needs to publicly and private support your project, operations and support staff must actively work with your project team towards making your production environment ready to accept your system, other system teams must work with yours to support integration efforts, and maintenance developers must work to become adept at the technologies and techniques used by your system. 

It is clear that in order to be successful all project stakeholders must actively work with your team to achieve these goals.  There are several implications of this practice:

  1. Timely decisions.  Stakeholders must to be prepared to share business knowledge with the team and to make both pertinent and timely decisions regarding project scope and requirement priorities. 
  2. Inclusive modeling.  You need to adopt inclusive modeling techniques, which are based on user-centered design (UCD) and participatory design principles, which stakeholders can easily learn and adopt.
  3. Management requires IT skill and knowledge.  For senior managers to effectively support your project they must first understand the technologies and techniques that your team is using, understand why your team is using them, and understand the implications of using them.  With this knowledge their efforts within your organization’s political arena are far more likely to be effective at the right times in the right ways.  Senior managers won’t be able to gain this requisite knowledge simply by reading a weekly project status report or by attending a monthly project steering meeting.  Instead, they need to invest the necessary time to learn about the things that they manage, they need to actively participate in the development of your system. 
  4. Production staff are involved from the start.  Your operations and support organization must invest the resources required to understand both your system and the technologies that it uses.  Your support staff must take the time to learn the nuances of your system, the implication being that they need to work with your system as it is developed and/or your team will need to provide them with training.  Furthermore your operations staff must become proficient with both the installation and operation of your system.  You may choose to include one or two operations engineers on your development team or once again to invest project resources to train operations staff as required.  Regardless of your approach, both your operations and support organizations will need to be actively involved with your project team.
  5. Take an enterprise view.  You need to work with other project teams if your system needs to integrate with other systems.  For example, perhaps your system needs to access a legacy database, interact with an online system, work with a data file produced by an external system, or provide an XML data extract for other systems. Integration often proves difficult if not impossible without the active participation of these developers: imagine how difficult it would be to access the information contained in a large legacy database if the owners of that database refuse to provide any information about that database.  Some initial architecture envisioning will help to drive this.
  6. Don't just hand-off to the maintenance team.  Maintenance developers need to work with you to learn your system.  When the intention is to either partially or completely hand-off the maintenance of your system to other developers, it is common to bring in software professionals skilled in maintaining and enhancing existing systems to free up members of the original development team, then your team must work with these people so they can take over the system from you.  Even when some original team members are still involved an effort must be made to transfer the knowledge to the new members of the team. 

 

Who Are Stakeholders?

My definition of a project stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project. 

From this definition you can see that business people, such as direct users and their managers, aren’t the only stakeholders of a project.  As you know there is a wide range of people potentially affected by a new system, therefore to succeed you must understand and then synthesize their requirements into a cohesive vision.  This is one of the things that makes software development hard – each project stakeholder will have their own requirements, their own vision, and their own priorities – but it also makes software development fun.

In this definition I have chosen to exclude the developers who are working on the project.  This may seem strange at first because developers clearly have an important stake in the projects that they work on.  Yes, developers are definitely project stakeholders.  Why do I continue to distinguish between developers and project stakeholders?  Because I want convenient terms to distinguish them, I really don’t like “developer stakeholder” and “non-developer stakeholder”, and because they have different roles to play on a project.

My definition of project stakeholder and developer may be different than yours, or perhaps you prefer different terms.  For example, XP discusses the concepts of customer and programmer, not project stakeholder and developer, and has slightly different definitions because they use the terms differently than AM does.

 

 

Rights and Responsibilities

I used to talk about the rights and responsibilities of project stakeholders, a concept that I adopted from Karl Wiegers excellent book entitled Software Requirements.  Unfortunately, I recently discovered that these rights and responsibilities as written in Agile Modeling weren’t as clear as I had originally thought and were potentially even divisive.  So, after a fair bit of discussion on the AM mailing list I've decided to reword the rights and responsibilities from the point of view of everyone on the project, not just the stakeholders.

 

The Rights of Everyone

  1. To be treated with respect.

  2. To produce and receive quality work at all times based on agreed to project standards and principles.

  3. To estimate the activities you are actively involved with, and to have those estimates respected by others.

  4. To be provided adequate resources (time, money, …) to do the job that’s been asked of you.

  5. To determine how your resources will be invested.  For people funding the project how the funds will be spent and for people working on the project (e.g. investing time) what tasks they choose to work on.

  6. To be given the opportunity to gain the knowledge pertinent to making the project a success.  Business people will likely need to learn about the underlying technologies/techniques and technical staff to learn about the business.

  7. To have decisions made in a timely manner.

  8. To be provided good-faith information in a timely manner.  Sometimes this is just the “best guess” at the time, and that’s perfectly all right.  This includes but is not limited to business information such as prioritized requirements and detailed domain concepts as well as technical information such as designs and detailed technical concepts.

  9. To own your organization's software processes, following and actively improving these processes when needed.

 

The Responsibilities of Everyone

  1. To produce a system that best meets your needs within the resources that you are willing to invest in it.

  2. To be willing to work with others, particularly those outside your chosen specialties.

  3. To share all information, including “work in progress”.

  4. To actively expand your knowledge and skillset.

 

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here

 

Recommended Resources

 

The Object Primer 3rd Edition: Agile Model Driven Development (AMDD) with UML 2   The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
Agile Modeling   Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
Elements of UML 2.0 Style   The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

 


Canadian Flag

Copyright 2002-2007 Scott W. Ambler

Last updated: March 3, 2007
This site owned by
Ambysoft Inc.

|| 
Agile Data (AD)  |  Agile Unified Process (AUP)  |  Enterprise Unified Process (EUP)  |  My Writings  ||