Posts Tagged With: communications

How are you resolving your agile transformation blockers?

Teams leading agile transformations can encounter multiple challenges along their journey including changing the mindsets of senior and mid-level managers, transitioning from a focus on specialists to developing generalizing specialists, educating and effectively engaging delivery or control partners and reducing the time and effort required to deploy deliverables once they’ve been deemed production ready. Worse yet, it can sometimes feel like a game of Whac-a-Mole – as soon as your team resolves one hurdle then another two surface.

How about being agile with your transformation!

Treat each of these blockers as a work item in a backlog. Collaborate with stakeholders to identify appropriate acceptance criteria to help you know when you’ve successfully resolved the issue. Size the work items with your team. As with all preliminary estimates in agile don’t aim for precision but rather for consistency. T-shirt size them or if you feel creative use an alternative fun sizing taxonomy (Decepticon-sizing?).

Prioritization will be a challenge. Just like managing a backlog of product requirements, it’s rarely as simple as letting business value be the sole determinant of priority. Many of these hurdles will be interdependent. You might also want to incorporate relative uncertainty into the ranking process by tackling higher risk and impact hurdles first.

Once you’ve prioritized these blockers at a high-level your team should decide whether it is worth disaggregating them into smaller hurdles. Techniques such as story mapping could then be utilized to help you create a release plan for resolving the issues.

Now comes the tricky part – socializing the plan with your senior stakeholders. Assuming they accept the list of blockers and their relative priority you will want to share it with delivery teams and control partners across the organization. This will increase their confidence in the transformation as well as helping to manage their expectations regarding the resolution timeframes for specific blockers.

A critical step is to adapt and evolve the plan as your transformation progresses but don’t obsess over creating the ideal plan. As new blockers get identified by delivery teams, size them, prioritize them and add them to the backlog. Use information radiators to share status. For example, you could post a list of which hurdles are being actively worked on, which ones are “on deck”, and a burn-up chart with an up-to-date forecasts of when the backlog will be cleared. Your team should also decide whether a sprint-based or lean lifecycle makes sense given their capacity and maturity.

Resolving a backlog of organization blockers can seem an insurmountable task but take the opportunity to increase buy-in and provide a showcase for the benefits of being agile.

 

 

 

 

Advertisements
Categories: Agile, Facilitating Organization Change | Tags: , | 2 Comments

Avoiding groupthink on long-lived teams

Long-lived teams are often presented as being superior to their temporary counterparts. The benefits of longevity include the avoidance of wasteful forming-storming-norming cycles, higher levels of trust and psychological safety within the team and a more accurate understanding of what someone means when they communicate with us.

But there is a potential downside to persistent teams which can erode many of these benefits: groupthink.

Groupthink usually refers to a situation where team members prioritize consensus over the quality of a given decision or outcome. We might all disagree with Bob’s recommendation on how to address a project issue, but we value the harmony of the group over the mediocrity of his approach and hence we don’t challenge it. According to Irving Janis, the social psychologist who is credited with introducing the term, groupthink tends to occur most often where there are high degrees of cohesiveness, external threats, difficult decisions or isolation of the team from others. These factors are often found on long-lived teams.

So how can we avoid groupthink on long-lived teams?

One countermeasure might be to use Delphi or a similar method of anonymously or simultaneously gathering input from the team. This will reduce the likelihood of any one team member winning a “first to speak” advantage and will provide a structured approach to surface and discuss differing viewpoints.

Another option is to have the group nominate one team member to act as a devil’s advocate. This selection should be made on a per decision basis. Since everyone knows that this team member is responsible for finding weaknesses within a decision it eliminates their fear of being perceived as disruptive. Care needs to be taken in selecting the right team member to play this role. Someone who is likely to have significant interest in the outcomes of a decision might not be the best candidate as they might consciously or unconsciously disqualify the group’s approach to further their own path of action.

Have the foresight to bring someone in from the outside who has no stake in the outcome. This approach can replace the previous suggestion if team members feel that none of them can impartially play the role of devil’s advocate. This method has its own challenges as it might take some effort for the outsider to gain sufficient context to be an effective contributor to the decision.

Finally, breaking the team into two independent groups and having each group develop a recommendation is a very explicit method of eliminating groupthink. Of course, this requires a team which is large enough that such a sub-division is possible. If this approach is used more than once, it is a good idea to have different people in each group for each distinct decision.

When all think alike, the no one is thinking – Walter Lippman

 

 

Categories: Agile, Project Management | Tags: , , , | 2 Comments

It’s time for RAID logs to evolve!

When documents are used to track project information, a common approach is to create a consolidated workbook in MS Excel for tracking risks, actions, issues and decisions. This is usually referred to as a RAID log.

The benefit of this approach beyond having the information in a convenient, centralized location is that there are logical relationships between these disparate elements which can be easily reflected if they are consolidated. For example, negative risks which have not been successfully avoided could be realized as issues. In turn, issue resolution might be done via actions. And finally, actions may require formal decisions to be taken.

But is there an opportunity to consolidate additional list-based project data elements for greater benefit, and if so, what are some good candidates?

We frequently hear about the need to capture assumptions made by stakeholders when planning our projects so that they can be validated over time. A benefit of having the assumptions consolidated in the same workbook is that part of a regular risk register refresh could include a quick walkthrough of those assumptions which have not been validated yet to see whether any new risks can be identified or whether information regarding existing risks should be updated.

It’s rarely ideal to wait till the very end of a project to harvest knowledge. But if you choose to identify lessons regularly over the life of your project, they’ll have to be captured somewhere. As issues are often a good input into lessons identification, having the ability to link issues to a lesson will simplify the process of understanding the context behind the lesson. Another benefit of this approach is that since it’s common practice to review issues and actions in regular team meetings, having lessons also available in the same document might encourage team members to review them and identify new ones.

Finally, let’s consider stakeholders. We know that it’s a good practice to identify stakeholders early in your project, analyze them according to their impact, interest and influence, and use that information to form your engagement and change strategies. Stakeholders will be closely associated with all of the other data elements we’ve looked at so it’s likely worth including your stakeholder register too.

So if your organization doesn’t have a central project management information system, why not use a RADIALS log in place of a traditional RAID log!

Categories: Project Management | Tags: , , , | 1 Comment

Blog at WordPress.com.

%d bloggers like this: