But then something significant happened. We discovered that work was not just about performing a set of predictable tasks. We started to realise that:

• Work was about adding value rather than destroying value rather than just delivering stuff; and
• We started to see value as something delivered through the interaction of entire teams and not through individual achievement.

Yet you will still find performance agreements in almost any company that are based on individual achievement, sometimes even ranking people against their peers to see who is the best and worst in the team.

Doesn’t it seem a little inconsistent to say that teamwork is the main ingredient for success and then assess people on individual delivery?

But assessing teams instead of individuals is a huge mind-shift and it is a mind-shift that I have not been able to make. Try as I have done to embrace the agile (and modern management) concept that it is the team that delivers value and not the individual, I still think there are people who contribute more than others and I can’t shake the feeling that these are the people I want to attract, retain and reward, even if I have to do so at the expense of others.

Perhaps I am still evolving as a manager and still learning what I know is true::

• Intrinsic motivation is better than extrinsic rewards – ie motivation comes from within;
• It is the diversity of the team and the mix of skills and styles that leads to success – you need different types of people in the team, not clones of some alleged paragon of excellence; and
• Teams are increasingly virtual (temporary) and distributed (spread around the globe) so most managers are now managing people they don’t actually work with directly anymore.

Unfortunately that leaves me with an inherent contradiction – I want the best people and I want to reward and motivate them … but the best people is actually the best MIX of people, and it is the people in the team who will motivate themselves and each other.

One solution is to wimp out (ie avoid the problem). This works well if you are not too passionate about leadership. You can either defer all performance discussions indefinitely or you can use the old fashioned performance agreements and apologise (while adding that it is not your fault – the company inflicts this on everyone). But I don’t find those approaches very motivating.

One surprisingly easy and accurate approach is the “net promoter score” that is used in ITIL and other methodologies to evaluate the performance of an overall team or set of services.

Essentially you just ask you stakeholders one question – Would you recommend us to others? But rather than getting a yes/no answer you ask for a score out of 10. And rather than seeing 5 out of 10 as a pass mark you take anything under 8 as bad and 8 or above as good enough.

So to rate myself as a manager, I could ask my team (if they can be honest) to answer the following question:

If you were talking to your friends, would you recommend to them that they work for me if they get a chance? Please give me a rating out of 10.

In a similar way, if I was managing a group of testers who worked on projects, I could ask the project manager, the developers they were working with and the other testers on the project:

IF a friend of yours was going to work in a project, would you recommend that they have X in their team as a tester? Can you please give me a rating out of 10, where 1 means “no way” and 10 means “Absolutely- every time, even if they had to cancel something else in the project to find the extra budget”.

I think you would probably get a fairly consistent rating from different people in the team and that you will actually get a pretty good assessment of the performance of the tester.

So, with this simple question in hand, could we simply abolish the traditional performance agreement and appraisal process?  Sadly, I don’t think we can.

It would be great if we could allocate a standard score to all our team members and then we could buy and sell them on a “tester commodity exchange”. If I needed adequate testers, I could pay less and get some 5.5er’s. But if I needed some really challenging testing done I could pay more than my competitors and buy in some 9.5’ers.

Giving people a score out of 10 (or ranking them against their peers) should never have been the real purpose of the performance agreement.

The real purpose of performance management discussions is just that – to have a discussion about current performance, possible improvement areas and possible growth for the future.

The real discussion is therefore about where and how the team member is adding (or destroying) value in the organisation. It is about how their work suits them at the moment and where they should head from here – to continue (or start) to find work that is challenging, motivating and valuable to the team member and also valuable to the wider team and organisation. In fact in some cases it might even be a discussion about how someone who is adding great value but has outgrown their role can find a more fulfilling role somewhere else.

So I think we need to improve the performance discussion we have. The problem is – how can we do that?  How can we measure the value of someone who provides intangible value (such as quality that a tester helps build into the system) and how can we talk about growth and development in a world that changes so fast my new mobile phone is old before I finish my first phone call?

It would be great if you could let me know where to find some of the answers that others have come up with. In the meantime I am going to work though my own ideas and publish some of them here. So let me know what you think as I go, and I would really appreciate any suggestions or ideas that you think might help.

And they are all related to the managers in the team not having enough time to talk about succession planning.

Managers spend a lot of time talking about the people in their team – who is good, who is not so good, who is happy and even how people are getting on with each other. But people are not talking about

• What to do when people move on from the roles they are doing;
• Wether people are still growing in their role and if the role is growing with them;
• Whether people need more support to learn how to do their existing role better; and
• Whether we need to start developing people now to be ready to fill the roles we will have in the future (2 years from now, 6 months from now or even in a month’s time when the big project goes live).

These are the topics that are meant to be covered under the heading of succession planning, and without them the following problems seem almost inevitable:

• People get stuck in a role that no longer really challenges them because they do it so well and it is so important to us (eg they are the only one who can look after the backend production database. This is robbing the good people we have from the potential growth they could be getting in a different or extended role;
• Companies are going outside to hire managers above a certain level because they lack the talent within the company to fill the most important and most rewarding roles in the organisation; and
• Teams are becoming increasingly single point sensitive (the can’t afford to lose one particular person) and then go into crisis mode if that person moves on or even tries to go on holidays.

So, is there a sophisticated and powerful way to address all of this?

No, but there is a simple conversation that the management team can have on a regular basis. And if the management team have this conversation then it can support the performance and development discussions they are having with their team members – so those team members are aware of potential opportunities within the company in the future and have the chance to develop the skills (and experience) to fill those roles.

The management discussion

I think the succession planning discussion deserves to have its own meeting, otherwise it always gets left to the side while we address “urgent issues”. And I think it needs to involve the whole management team.

The meeting should start as all other meetings do:

• People turn up and talk about the weather. Then the manager arrives 5 minutes late and apologises. he or she asks what has already been covered and the team reveal that they didn’t do anything because he or she was not there yet. (OK this part of the meeting can be improved).
• We remind ourselves why we are here – The purpose of this meeting is to discuss the critical roles that we have in the team and the people either in them now or potentially in them in the future.

Cool – but how do we discuss all this? Well, here is a form to use:

As  a word document: Succession planning table

As a PDF: Succession planning table

And here is a possible agenda:

1. What roles are critical in our team?  Of those, which ones are the most critical?
2. Which roles have only one person in the team capable of doing them? How much would it hurt if that person won the lottery and retired?
3. Now the hard part – for each critical role:
   • What is the name of the role?
   • Who is doing it at the moment?
   • How experienced are they in the role (draw a scale from [new – still learning – comfortable – mastering the role – ready for something new]?
   • How might the role be different 2 years from now?  How might it be different in 6 months?
   • Is there a development plan in place to keep the current incumbent (person in the role) growing?
4. For each role
   • Who is ready to take over the role in an emergency? Or if the current incumbent is on holidays?
   • Who is ready to take over the role right now?
   • Who might be ready in 6 months?
   • Who might be ready in 18 months?
   • What outside options exist for filling the role, temporarily or permanently? For example are their consultants who could help in the short term, are their people in other parts of the organisation we could bring across, are there people we know of in other companies who might be able to fill the role?
5. In addition to the roles we have today, are their any emerging roles that we might want to have in the future?
6. For the people in the team who might be able to fill our critical roles in the future?
   • What development plans should we have in place to ensure they are ready for the role?
   • Do they actually have any interest in doing the role?

All that discussion will take some time and might take quite a bit of thinking to do properly. But if you have a go at it a few times I think it should all come together.  Of course you can also get your managers to do some preparation before the meeting … or you could cut the meeting back to only talk about agenda item 3 and 4 in the meeting and let each manager do the rest on their own.

Hopefully, even knowing that the management team think about this stuff will help motivation a little. And if you actually implement improved performance and development discussions as a result of this meeting then you should definitely see an improvement in the performance of your team.

• What they have done since last time
• What they will do today
• What obstacle or issue is in their way

It works really well in my slides but now I am trapped in the real world temporarilly working on a real project. Do I really want a daily meeting?

I actually do really benefit from the daily meeting, especially when I compare what we say we are doing to a physical story wall.

Lately though, I have been on multiple projects, all of which have a standup.  I have also asked my own team to do a stand up.  So now one of my obstacles is “I am in too many meetings about my obstacles”.

The simple solution we have implemented is that nobody can be in more than two standups a day. It seemed impossible because we are doing so much. But then we realised we were actually commiting to so much, not necessarilly doing it all.

Nobody believes me in my training courses, but if you are on 10 projects you really do have to stop being spread so thinly. People often thing there is no choice but to remain too thinly spread. But even if you get thrown off the projects for complaining and people tell you off, this is better than being left on 10 projects and then having people complain that you are not delivering.

So I was happy again.  But I had no idea that outside of agile projects some guy published a book on “Mastering the Rockerfeller Habits“. Based on this the team I am working with have:

• A daily meeting to keep up on things.  The agenda should be short and sweet and should cover
• What 3 things you will do today
• The “rock” or obstacle in your way
• Your daily measure or “Key Performance Indicator (KPI)
• A weekly meeting to confirm progress, communicate across the team and commit to the next week.

It all sounded very agile even though I assume Rockerfeller never used the term “agile”. 

I particularly like the limit of three things you will do today, because it forces you to prioritise and to be brief in your update. But then I stopped to think about it – why would I provide a KPI every day?  And what happened to the “This is what I actually got done yesterday”.

So we now have a story wall for one team (we are colocated) and make sure we put our daily commitments up on the wall – so we see if they have been done.  For the other team we have to remind each other what we missed or achieved.

But good grief – who wants a daily KPI?  It turns out that it sucks quite badly for multiple reasons. 

• Rather than just reporting tasks completed or stories delivered, we have to measure the quality of our work every day. It turns out it is a lot easier to talk about stuff you did than about the value you added or the quality of what you did.
• You need to find out what the core focus of your role is and quantify it.  Then you need to explain your focus to the rest of the team.
• You need to constantly come back and focus on your measure.
• Even simple measures lead to challenging questions when they are inconsistent (or too consistent) or unexpected.

Of course these are also good reasons for doing it.

My initial measures were a bit lame, but now I think I will change one of mine to the following

• Percentage of time spent adding new value to the business (new stories for developers, something hard for managers)
• Percentage of time spent “consolidating or protecting existing value”.  This would include fixing defects (because you are repairing the system to what it should be doing already), maybe monitoring the system and maybe refactoring to simplify what the system is already doing
• Percentage of time spent doing other stuff (writing on my blog, going to meetings which have no defined value nor good muffins, writing reports for people, etc).

Since we don’t have time sheets here (yay) I will have to guess what the percentages are every day. But then I would probably have to be able to justify the rating I give and that seems really hard.

Maybe I should tell them that agile projects don’t measure KPIs. We measure activity rather than quality. 

In fact many projects measure activity instead of progress (story points complete but not problem solved or new capability delivered).

Then again – maybe my agile projects should be providing some kind of measure of daily contribution to the business rather than daily activity.

What would happen if our agile projects were expected to do that in the same way the team I am working with have been asked to?

Generally I think of them as “project managers for creative people and artists” but I did once ask a producer what they really do and they succinctly described all the roles of business analyst, Scrum Master/iteration manager, project manager and product owner.

Maybe a shorter description is that they make sure everything comes together on a brief before time, creativity and money run out.

Producers are often used to running running relatively small projects where they can deliver through hard work, luck, finesse and sheer determination; but they often struggle when they end up on larger and larger projects where their role becomes ever more critical while simultaneously becoming ever more vague and confused until they need to resort to PDD as the only way to bring the project home (PDD – Panic Driven Development).

Agile approaches often provide a structure and a discipline that allow the producer to manage the complexity and creativity on larger initiatives, but unfortunately most agile literature and training is aimed at IT development teams, rather than producers.

So how do a producer learn to become agile?  I got asked this question recently and referred it onto Rebecca Yik – Executive Producer and accidental agile coach. She came back with the following advice:

Things I’ve learnt and can recommend as a Producer developing my Agile expertise

Blogs, Resources, Guides

• James King http://kingsinsight.com  (goes without saying right?)
• Agile @ Atlassian http://www.atlassian.com/agile/
• Version One http://www.versionone.com/Resources/
• Mike Cohn http://blog.mountaingoatsoftware.com/
• Rally Software http://www.rallydev.com/

Books

• Agile Estimating and Planning by Mike Cohn

Tools – At the moment I’m reviewing/trialling online tools we should use

• Version One
• JIRA with Green-hopper

Groups you should join in Sydney Australia

• Agile Sydney http://www.meetup.com/Agile-Sydney/

Training

• Software Education (snuck in by James) http://softed.com/Courses/Agile.aspx
• Agile Academy http://www.agileacademy.com.au/agile/
• On the job!

To that list I (James again) would add one course that looks like it will be a really good one for producers: Passionate Product Ownership with Jeff Patton.

Of course both Rebecca and I are also available to help your journey – either with advice over coffee or fully-fledged coaching and consulting work.

We  discussed several approaches that are sometimes successful and sometimes detrimental.

So here is a collection of some of the approaches we discussed.

Tell the team they are the most elite team ever

People often perform better if they believe that they have been hand-picked as the experts in their field. So some project managers (and consulting companies) find great success in motivating people by telling them that they are awesome.

Feeling they are awesome not only makes people feel good, but also often makes them work harder so that they continue to live up to their reputation and continue to receive such positive feedback.

But it often backfires when people:

• Start to ignore the input of “the less awesome” people outside the team, resulting in solutions that fall far short of what they could have achieved with the input of others; or
• Start to over-estimate their own importance and either skimp on the detailed boring work that the less awesome must do, or even become corrupt (thinking “the rules don’t apply to us because we are awesome” is the beginning of a slippery slope towards slef interest and eventually corruption for many elite teams); and

Most importantly, there will often come a time when someone has to support the existing project or go and do some of the critical but boring work. This would not be a problem, except that other members of the team are being offered more awesome work and being told they are still awesome. This can lead to resentment among the “recently awesome” and to friction within the team.

Tell the team failure is not an option

Some projects are so important they simply can not be allowed to fail. When people realise this they often go the extra mile in both effort and ingenuity.

Unfortunately there is a risk that the team will start to believe that the project will come together because “its just so crazy it has to work”.  This is unfortunate because usually (outside the movies) crazy ideas fail the first time they are attempted.

What often happens is that the team redefine success near the end of the project so they can deliver something they can call successful. What happens next is that people get angry with them and the team start to feel badly treated because nobody appreciates the heroic efforts and innovative thinking the team employed to deliver what they did get done.

So if the project is too important to fail (or you want to motivate people by claiming it is) then the best thing to do is to really really focus in on what really needs to happen. Then if you can deliver the bare minimum before the end date and build upwards from there if time permits then you will be a hero instead of a cautionary tale for others.

Truly understanding the root cause of the problem or opportunity often also leads to the truly innovative, achievable and maintainable solutions.

Unlike the movies of course, the “too important to fail” speech can’t really be delivered every adventure or people become cynical and start ignoring the call to action.

Tell the team that this is the CEO’s most important project

I once worked with an organisation where every single project seemed to be described as “Someone-important’s top priority”.

This seemed to have a similar effect to turning on a light when there are moths around. Stakeholders and potential team members all rushed forth at as soon as you turned the lights on. And people often seemed more than accommodating.

But then when things got a bit tougher, or the senior manager went away to look at something else, then a lot of the people seemed to wander off, just like moths do when you turn the light out.

So while having senior managers engaged on a project is a real key to success, claiming that senior managers are interested often gains only temporary or apparent motivation.

But even when the project is the senior manager’s most important initiative, people are sometimes more motivated to give the manager good news or highlight their own prowess than they are to engage in intense debate or challenging thinking.

In other words, gaining executive buy-in helps and having a key stakeholder passionately explaining the importance of the project are both very good for motivating the team. But you still need to shift the discussion quickly to WHY the project is the executive’s most important initiative.

Tell the team that the project will  drive career growth

Some projects are real career builders. This can be because of the new skills and experience that people gain; it can be because of the visibility that the project gives people and it can simply be because of the relationships that people form while on the project.

But once again there is a potential dark-side.

• Just because the project has the potential to create career growth does not mean that it will do so; and failing to deliver on promised rewards will de-motivate people as quickly as the prospect of career growth motivated them in the first place; and
• There is a risk that people will focus on the opportunity to impress or fight over the juiciest pieces of work on the project.

So if you are using the carrot of career growth, you really need to work on the implementation of the promises you are making, while also making sure that people understand that they will need to commit to hard work and real commitment to the outcome if they are to share in the spoils.

Conclusion

All of the approaches I have listed above work, at least in the short term. But all come with issues and risks. So I am left back where I started in concluding that to motivate people on projects what you really need to do is:

• Show them how can make a contribution;
• Show them how their contribution will make a difference; and
• Show them how their contribution will be rewarded, preferably through intrinsic rewards like satisfaction in a job well done or learning something new.

I also spend a lot of time coaching project managers in how to run more effective projects, but I find that a lot of my time is spent on helping them to deal with internal politics, resistance to their projects and communication issues – which do not form part of most project management courses.

As a result I believe there is a need for good training in the area of managing change.

So I have written a two day course to equip managers and project leaders with pragmatic approaches and concrete techniques for anticipating and managing the impact of change in their organisations.

I know there are other change management courses around but I believe that many of them focus on the theory of change rather than the practical implementation of change in the real world.

My new change management course consists of four modules. Each module can be delivered as a stand-alone course over half a day and are designed to flow together as a single 2 day course. 

1. The first module introduces the concepts of change management and then focuses on:
   • Conducting the initial engagement interview and creating a working understanding of what communication is needed on a project;
   • Performing a basic stakeholder analysis; and
   • Building a communication plan for an existing project.
2. The second module focuses on performing a change readiness assessment:
   • Using a systems view to analyse the value proposition, services, skills and processes of new or existing teams;
   • Assessing teams from a socio-political perspective, to understand the connection between culture, politics, power, rewards and recognition, social interaction and tradition in a team; and
   • Identifying the key factors that will encourage or constrain the adoption of a particular change in a team or organisation.
3. The third module focuses on creating a clear and persuasive message:
   • Preparing the team to communicate;
   • Aligning the message with the appropriate channel and format;
   • Clarifying what to communicated and how to best frame the communication;
   • Creating two way communication to listen to stakeholder feedback and respond effectively; and
   • Measuring the impact and progress of change and communication.
4. The fourth module brings the previous concepts together to create an implementation plan:
   • Applying adaptive planning approaches to implementing change; and
   • Handing over the knowledge and support needed to sustain the change once the project ends.

Each module introduces some of the theories relevant to the subject area and then provides room for discussion about how those theories apply in the real world. But the main focus is on practical techniques that can be applied to projects and initiatives in the real world.

Simple techniques are introduced for smaller initiatives and then more complex techniques are introduced through the application of a case study that grows in complexity with each module. Or, for in house courses, I can replace the case study with a real project and coach the team in using the techniques in their own, live, environment.

I have not booked any public courses at this stage but will do so if there is sufficient demand. So please let me know if you are interested in:

• Attending a public course;
• Learning more about how the course can be run in-house for your team; or
• Coaching a small number of in-house experts to apply the techniques and run a customised version of the course in-house as part of a large change initiative.

In addition to running the course I also provide coaching to individuals and teams in many of the concepts that I have included in the course.

Two trends I have been noticing that are both scary and exciting to me are

• People are making knowledge and ideas available for free.  This blog includes some of my trade secrets in the hope that they will be useful to others.  But that is nothing compared to MIT publishing entire course curricula online or the sheer volume of free information you can get in wikipedia, youtube and other places;
• People are increasingly interacting, doing business and learning online. I did my entire masters degree online and yet even that experience was pretty mundane compared to the emerging opportunities that are emerging – youtube based videos, ebooks, Secondlife (yes – I still think we can do a lot of training in 3d worlds) and even mentoring by Skype and twitter.

So I am planning to spend some time over the Christmas break, just browsing and checking in with what the rest of the world is up to.

But before I have even started, COFA tweated this intriguing link to me (and the rest of the world):

http://online.cofa.unsw.edu.au/learning-to-teach-online/ltto-episodes

It appears to be free training and information sharing for teachers in the area of online learning.  I guess it makes sense that you should learn to tech online by going online.

So, I here-by designate myself an eager student of online communication and learning.  Now I just need to find the time to log in and start learning.

Do you know any other elearning or e-living links I should be exploring?

But quite often the role profile, position description and annual performance agreement become more of a burden than a source of job satisfaction.

In fact in most of the really successful project teams I have been in, we threw away our job titles and did whatever it took to make the project successful. So my experience with performance agreements and job descriptions seems to go against management theory.

As the team matured though, we started to learn more about each other’s strengths, weaknesses and even the type of work we liked/didn’t like doing. And it is at this point that I agree with the management theory – I was happiest when I knew what value I added to the team.

But it can take a while to carve out your niche on a project if it is large and complex. So this is the approach I like to take to get to this when starting on a project:

1. Define your job in really simple terms in relative ignorance (ie based on what you think you know before starting):
   • My role is blah: where “blah” is less that seven words or a title such as DBA
   • If my grandmother asked what that means I would say …..
2. List your most important 3-5 responsibilities as you see them 
   • For example a BA might list “produce the scope document” and “Mentor other BAs”.
   • Define a measurement.  This is not a smart goal or a stretch target – just state “I would know I was on track if …” and “I would know this isn’t happening if …”
3. State the key decisions on the project you think you should be involved in:
   • I will be the one who decides …
   • Always check with/involve me in these decisions before they are made …
   • Let me know just before you …. even if you didn’t get my input
   • Tell me after the event if you ….
   • I am happy to be involved in other discussions but feel free to leave me out.
4. At least meet with the project manager and argue about all the points above.  At best have a speed dating session where everyone in the team presents the above info to each other and argues what it should be for each person’s role:
   • (By “argue”, of course  I mean talk … actually I mean feel free to argue too).  Argue about both the explanation and the ranking of your responsibilities.
   • You will be suprised how often you thought the most important aspect of your role was different to what others on the project thought it was. Talking about it removes that ambiguity and forms a common understanding.
5. After about 3-4 weeks, repeat the process and see what has changed.
6. To go the next step, you can have a separate session on understanding each other’s strengths, weaknesses and communication styles. I can help you with this but there are also many books and workshop techniques you can use yourself. In fact if you are in Sydney, you can go to the Australian Institute of Management bookshop and they will show you several cheap and breazy workshops you can run out of the box.

If you review this description periodically and even better discuss it during project retrospectives then life will go easier and you will both get more kudos and feel like you are adding more value. 

The reason is that you will be discussing (and evolving) your understanding of why you are there and the understanding others have of why you are there.  And it means you will be focussing your energy on the key things that others also think they need from you, rather than working really hard on what you thought was important but that others didn’t think was.

Apparently it is more effective to ask yourself “Will I succeed” than to say to yourself “I will succeed”.

Will I apply that lesson next time I want to achieve something important?

It seemed to go down really well, so I have decided to make the game available publicly if anyone is interested in using it.

In the game, participants are a group of scientists and engineers who are stuck on Mars after a “less than successful” landing.  They are on a mission to make scientific discoveries but must now rebuild a basic infrastructure for survival before returning to their original mission.

Participants then create a strategy based on rebuilding their ship, building a base and/or returning to their basic goal of research.  In doing so they must make trade-offs between quality and velocity.

The game introduces concepts such as release planning, iteration planning, velocity, release planning trade-offs, building by feature and adaptive planning.

The game is designed to be led by a facilitator, but can be run without one.  The release planning game takes around half an hour to play and can be replayed multiple times to explore different concepts in more detail or to improve the outcome based on lessons learned in the first attempt.

Different options allow the game to be played as a very simple introduction to the concepts of release planning or a more complex game involving more realistic trade-offs and decision making under conditions of uncertainty and pressure.

In addition, there is an extension included in the game that focuses on planning within the iteration (or sprint) rather than across the wider release.

Let me know if you are interested in learning more, or even trying the game for yourself.