Six Weapons of Influence in action

The following is an example I created to convince people that retrospectives are useful. I used the six weapons of influence as a guideline.

Recently, team members have questioned the benefit of certain aspects of the agile, specifically retrospectives. [Acknowledge the problem to gain alignment with the audience]

In regards to retrospectives, certainly each of us wants to improve our on the job performance [setting up consistency]. Retrospectives are specifically intended to improve individual and team performance each and every sprint [pointing out the inconsistency of not holding retrospectives]. Numerous studies and experts agree that retrospectives are a potent tool for performance improvement when executed well [Authority or Directed Deference]. Reflecting on how to become more effective and tuning behavior to maximize effectiveness [consistency] is so important that the originators of agile development list it as one of the twelve principles behind the agile manifesto [Authority or Directed Deference].

As a group, we have committed to following agile development through the scrum process [social proof]. Retrospectives are an important part of the process – one that we all need to improve upon in order to better see the benefits [social proof and consistency].

We realize that retrospectives are not easy and take time. It’s no simple task to ferret out good retrospective items and put them in a form that can be actionable [align with audience].

In order to better support retrospectives, upper management will commit to allow time to work on retrospective items during sprints if the retrospective items are written as actionable stories [Reciprocation]. We also commit to providing, upon your request, retrospective coaching for individuals or groups, and will share examples of good and bad retrospective items. In return we ask for your willingness to continue retrospectives and your support in working with us on improving efficiency/quality/delivery [Reciprocation].

The Inverse Peter Principle?

We all know the developer hero who works for 30 or more hours straight when a crisis comes up and walks away solving the problem. The classic firefighter mentality of software development.  But what kind of manager does this hero make?



Star developers often rise to management because of their ability to program under pressure and, in many cases, their software fire fighting ability, not necessarily the ability to plan, track, motivate, and manage a project.

If the corporate culture rewards a hacker mentality - time savings and emergencies over strategy and planning, developers who rise to management may never be exposed to long term thinking and may not even be told that management is all about planning, managing risks, monitoring, and most importantly reflecting on the future. Do star firefighters have the key ability to plan, see strategy, and organize large groups of people - I would say not always.

So what do we do about this problem? How about promoting people to management for their tendency to over design, over plan, and not necessarily just hack? This is an inverse of the peter principle. Imagine programmers who are mediocre by firefighting standards being promoted to management. We might just be better off in the industry.

Then companies could proudly proclaim “we promote the mediocre” – ah, maybe not.