4squareviews

In his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference,” John Stenbeck has created an “Agile PM Process Grid” which contains 87 processes used in agile project management divided up into 5 process areas and 7 knowledge areas.

I’m now covering all the processes in the first process group called Initiate, and have covered all the processes in that group under the first 5 knowledge areas.   Now I’m moving on to the two processes in the sixth knowledge area of Communications, 6.1 Colocated/Distributed Teams and 6.2 Participatory Decision Making.   This post will cover the second of these processes.

Agile Project Management is successful because it provides creative and non-linear solutions to significant, complex problems.   It does this by empowering the knowledge worker to make decisions that they are in the best position to make.   Vigorous discussion and active participation by every team member is used to interrogate the problem until the best solution emerges.

Leadership in an agile project consists of facilitating the discussion between team members.   If a single solution emerges, that’s great.    If two solutions emerge and the group is split between which of these two solutions to follow, then the leader may have to come in and break the impasse.

The iteration is set up to be conductive to this decision-making process.   For example, there is a two-step iteration planning meeting where the agile team and the Product Owner discuss and then refine their mutual understanding of what will be delivered at the end of the iteration.   This process is a participatory decision-making process where:

• The Product Owner describes user stories that should be included in the iteration,
• The Team asks questions in order to clarify the exact meaning of each user story,
• The Team develops specific metrics and/or acceptance criteria for each user story.

Although I have made it seem like this is a step-by-step process, like a chess game, the more apt metaphor would be a tennis match.    However, in this tennis game, the goal is not to beat the opponent, but to keep the ball in the air as long as it takes for each step to be complete to the satisfaction of all parties present.    The amount of time the ball will stay in the air is roughly proportionate to the size of the user story, meaning, the relative priority it has in the product backlog or global list of features requested by the customer.

This exact process listed above is described in more detail in the Plan process group; the reason why this tool is listed here in the Initiate process group is that everyone on the team needs to be aware of the ground rules for such interactions, so that no team member’s voice is left unheard.

That may mean that you ask the introverted or the younger team members their opinion first, because they are the voices most likely to be drowned out if they have to compete with extroverted or more experienced team members.   But however the participation is encouraged, you also need to set ground rules on how to give feedback to other team members regarding their suggestions.    Get the tone right, and you have an open mode of communication; get it wrong, and you have a battle of egos, and all of the energy that could have been spent tackling the problem is spent parrying negative comments.

The process contained in the Initiate process group in the last knowledge area, that of Continuous Improvement, is process 7.1 Identify Agile Ceremonies, and it will be discussed in the next post.

Filed under: Uncategorized |