Mike MacDonagh's Blog

Somewhere in the overlap between software development, process improvement and psychology

Scaled Agility: The Project Forum

This blog is an extract from the Project Forum practice: Holistic Software EngineeringThe Project Forum

When it might be appropriate

  • In situations where multiple competing stakeholder groups with different agendas are required to work together
  • In situations where multiple product groups need to collaborate on a bigger outcome
  • Where there is a conflict in direction, resource management/ownership or scope between collaborating groups
  • System of systems development

What is it?

The Project Forum is an application of agile philosophy to large project structures. Rather than impose a hierarchy of decision making from the Project Manager downwards the Project Forum is a virtual team in the middle of all stakeholders.

The Project Forum is a self-organising democratic group that balances competing voices and concerns, owns high level scope and architecture, runs the high level release train and performs integration activities for the product.

Use of the Project Forum practice does not prevent any communication directly between contributing groups it only provides a vehicle for that conversation when it’s relevant for the wider project.

From Traditional to Agile at ScaleThe Project Forum practice is an example of Agile at Scale combining social business practices, technical software practices and ways of working to make a simple way of doing big complicated bits of work.

The problems this practice is solving

Specific large scale problems that this practice fixes are:

  • Conflict between resource ownership in a “command and control” Big Project vs. a toothless project management function trying to get resources from organisational units
  • Scope alignment and change management (not prevention or control) between diverse groups with potentially different agendas
  • Linking up enterprise architecture with component architecture between diverse groups with potentially different agendas
  • Removal of “middle management” layers reducing cost, translational problems (since the customers are now closer to the delivery teams)  and bureaucracy
  • Lack of individuals understanding the big picture
  • Prevention of overloading at lower levels but exposing scope vs. resources vs. quality at an aggregate level.

Functions

Structure

Membership of the Project Forum includes Customer and User Representation, contributing groups technical and people management, enterprise analysts and architects. To be most effective it needs to have the least possible number of people actively contributing (a forum of 40 competing voices is going to have a lot of difficulties) however there are certain positions that must be filled. A good rule of thumb is that for a large project the forum should be around 7 to 15 people, if 30 want to turn up then half of them should be on an observational gallery unable to interject in the proceedings. The people who should come can be thought of in the following ways:

  • Facilitator (like the speaker in a political context best if it’s someone independent from the project like an agile coach)
  • Customer Representatives (2 or 3)
  • Resource Management and Technical leadership from each contributing group (2 each)

People can be elected by their groups to the forum, membership could be rotated, the organisation could appoint membership or the least busy from each group could attend. The last two are bad ideas.

Forum Competency BoardA way to limit the composition of the Project Forum is to use scaled competencies defining what the required skills are. These can be shown as slots on a competency board and then individuals can declare their own competencies. Once the required competencies are “filled up” the forum is full.

One of the advantageous side effects of this approach is that the team begin to understand each other’s skills, strengths and weaknesses rather than assuming knowledge of each individual’s position.

A lot of conflict in professional settings comes from unmet expectations caused by a misunderstanding of the skill level or decision making practices between individuals or groups. These practices and strong facilitation help to reduce those misunderstandings.

Measures

Organisations need to know that teams are delivering quality products at the right pace to fit the business need. To achieve this goal teams need to be able to demonstrate that their product is of sufficient quality and that they can commit to delivering the required scope within the business time scales. If the project goal may not be achieved then the business or the team need to change something (such as scope, resources or time scales). This feedback mechanism and the open transparent communication of this knowledge is key to the success of agile delivery.

The goal of delivering quality products at the right pace can be measured in many complex ways however the Project Forum practice includes just 3 simple high level measures:

For more detail on this measurement set see: Simple software project measures

Implementation

The Project Forum may well need to meet either physically or virtually on a regular basis depending on its decision making processes. Ideally the members of the Project Forum should be co-located at the beginning of a release cycle, at the middle and towards the end to cover things like requirements churn, scope issues, quality checks, acceptance testing and transition activities.
Some members of the Project Forum involved in continuous integration and testing may benefit from more frequent co-location. Having a common space for this group to do its work, supported by tooling such as social business software will be necessary for the group to function effectively, especially if distributed.

I recommend using an agile coach with deep agile experience, project and programme experience and very strong facilitation skills to be the servant-leader of the Project Forum. The Forum tends to contain strong opinionated characters and can be the focus of internal political difficulties and personal conflicts. Managing these is a delicate business involving a lot of soft practices to nurture the Project Forum into the exemplar of effective agile productivity.

Outcomes

Increased resource requirement for cross-team communication, scope and architectural management, change management, high level integration and test. All good things you should be spending time on anyway!

Improved Quality – Quality Confidence is tracked regularly, the open and honest balance between quality, scope and resources is actively managed by the Project Forum to improve quality

Increased Delivery Frequency –  Combining an understanding of throughput and quality the Project
Forum is able to understand it’s minimum valuable release cycle

I co-developed the Project Forum practice with Steve Handy drawing on many sources of inspiration and contributed it to Holistic Software Engineering.

Advertisements

2 responses to “Scaled Agility: The Project Forum

  1. Brad Appleton September 13, 2012 at 4:26 pm

    Seems to bear a strong resemblance to Holocracy. Was that one of your sources of inspiration?

    Also, are you using the term “Release Train” in the same way as Dean Leffingwell does in his ScalingSoftwareAgility blog? (scalingsoftwareagilityblog.com)

    If so, is your ProjectForum an instance of what Leffingwell calls a “System Team” there (and at scaledagileframework.com)?

  2. mikemacd September 13, 2012 at 6:55 pm

    Hi Brad, thanks for commenting 🙂

    I actually came across holocracy (and holacracy – although that seems to be a trademark) after writing this stuff so it wasn’t an inspiration but has become one since. However, I don’t think that autocratic=bad, instead I believe that working out how a project/programme/organisation/group/team culture will be formed is something that deserves attention. In some cases an autocratic decision making process may be appropriate, in others a democratic or indeed holocratic process may be more appropriate. For me the important thing is that these options are considered and communicated clearly. As Socrates said, the unexamined life is not worth living! I posted a bit more in depth on that in the decision making posts.

    Where I refer to “Release Train” I am in was referring to Leffingwell’s work. However in Holistic Software Engineering I’ve not amended this concept to Integration Streams.

    The Project Forum overlaps with the “system team” construct (I think) but is a bit different in composition and dynamics – The Project Forum to be a more social construct focussing on cultural and communication issues, not just infrastructure, integration and testing – there is a resemblance though.

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: