How to do appraisals: asking the team
Feedback comes from these - image by mpeterke
Part of my new role is to review and appraise the team. Given that there are a lot of them and I can’t spend enough time with each of them (and nor would I want to) to be able to do a good review, I figured that I’d have them do 360 reviews. There are multiple ways to do this, which I outline below, but I didn’t pick one for my team, I let them vote (I also let them post any new review methods they knew of in order they could vote for those too) – can you guess which they voted for?
Traditional
The traditional approach is an anonymous review: I pick several people to review the employee, they craft and submit reviews and then I deliver this feedback to the reviewee.
This sucks on multiple levels:
- Suppose the reviewee disagrees with some of the feedback, how can they offer a rebuttal? To me? How does that help?
- What happens if they don’t understand the context of the feedback?
- What happens if, in the name of keeping the feedback anonymous, I remix the feedback and lose the actual message (but I don’t know I’ve done that)?
- We work in tight scrum teams, this means that the BEST people to offer feedback, are the other people on the team (also the product owner and potentially stakeholders, but we’ll come to that), this means that, after the review, the employee goes back to their desk, possibly seething or feeling dejected, put upon or just miserable because of the above but they KNOW that someone in their team gave them shitty feedback.
- Sucks, right?
- The shy, or sociopathic might feel they can be more honest if they don’t have to do it face to face.
- The feedback won’t be bland.
- There is no fear of retribution (unless they find out who it was).
Not anonymous
So, another option is to have the reviewee choose the people they want to review them. No. This also sucks:
- They might pick people who don’t really have much to do with the and would offer a good, although bland, feedback.
- Again, they have no chance of rebuttal or dialogue there and then to discuss context of the feedback unless …
- …they go back to their desk knowing that one of their team gave them shitty feedback and now aren’t sure how to broach the subject.
This doesn’t suck because:
- Same as the above.
Team 360
The whole team goes to the pub (or cafe, whatever) and they take it turns to offer feedback on each other. Starting with me as a warmup so they don’t feel shy when it’s there turn (this is great for me, I’ll get LOADS of feedback). You go round the table one at a time and everyone on the team feeds back to me – positive and negative – and write it all down. Then someone else volunteers and so on until everyone has had a go.
Developers drinking...
You need trust in the team for this and a good bond. This isn’t going to work with a new (or a ‘forming’) team and I’d advise something different (not the above, maybe just one-to-one coaching until the team are up to cruising altitude). But for established teams, or those stuck in a retrospective rut, I think this is a great idea.
I’ve run one trial of this method before putting it out to vote and the team had some positive feedback on the process (and each other!). It’s tough to do, but giving and receiving feedback is always tough, and the idea of doing it face-to-face with people you work with every day is challenging, but you should do it. Nut up and prove to your peers that you’re a grown up and can and need to learn something about yourself that you didn’t know before. This is about improving yourself in ways you didn’t know you could improve and making sure you’re not annoying your team. 
This idea isn’t new, although I wish I’d thought of it, I originally read it in Management 3.0 by Jurgen Appello (the book is good, as are his talks, but his slides suck – well, he does draw them with MS Paint…)
What about … ?
Well, I mentioned product owners and stakeholders above. I’m undecided yet (but, I’ll probably let the team decide) on whether to include product owners in a team 360. They do spend a lot of time with the time and can probably offer some good feedback – it does depend on the relationship with the PO. Even though we don’t foster the feeling (and, Affiliate Window isn’t alone in this I’m sure) there’s a little ‘them’ and ‘us’ between the developers and the product team – but maybe this is a good start in breaking down that status quo.
Also, for stakeholders, having those in the team 360 would be pointless – they don’t have day-to-day dealings with the team, mostly it’s just input and output with the odd nudge in between, but we need their input. This is what the release retrospective is for but I’ll cover that in another post!
A change of direction
This is not my cake - image by notanyron
My loyal readers. I’m very, very sorry. I’ve totally neglected you of late (it’s been a month since my last post). A lot has happened in this time. Not including Christmas and New Year, some things have changed which have taken up large chunks of my time: I’m no longer an agile coach, I’ve been promoted to a Head of Development.
This is a great move for me, I’m doing much the same role, but I have bigger teeth and can affect greater positive change for the people in my teams. I already have good relationships with the people in my department and I spent my days coaching and teaching and nudging the guys into improving one way or another. Now, however, I have the ability to do it officially and sanction their individual and team growth in ways I couldn’t before (mostly because I don’t have to ask before I spend money… )
I want them to tell me how this department should function and I’ll make it happen. Already we’re pushing each other to create and achieve short-term goals for improvement and, while the rest of the company is having an appraisal and Personal Development Plan rolled upon them, I’m letting my team decide how they would like to be appraised themselves.
It’s an exciting time and I’m hoping that, with the department in charge of it’s own destiny, we can create some exceptional software, improve and grow quickly as both teams and individuals and, above all, delight our clients.
What does this mean for the blog? Nothing much, I still intend to blog about agile and frameworks, but you’ll probably see more management stuff, training, goals that kind of thing as it becomes more a part of my role. We’re also looking for a scrum master to head up a couple of the teams, so, if you’re looking for a permanent position as a new scrum master, then let me know. I’m looking for someone with a little experience, but who needs more and wants to learn.
10 Reasons why using a whiteboard is better than a digital tool
I’m a big fan of whiteboards. I’ve got a bit of a reputation at work as someone with an unhealthy desire for many whiteboards. As I sit here, I can see seven. There are three more in the office I can’t see and another four waiting delivery.
"Buy whiteboard: done" by Mark.Pilgrim
Ron Jefferies speaks at length about how big visible charts are a “good thing” (he echos Alistair Cockburns sentiments on having Information Radiators) and so, in the name of throw-away blogging, and because I don’t have any link baiting “10 reasons why… ” posts, I thought I’d add one.
- The elephant in the room.
Whiteboards are there in the room with you. You can’t do anything without having it there, reminding you it’s there and what is on it. With a digital tool, you need to go and find it, on the web, on the intranet, on demand. - The ice breaker.
They start conversations. People will gather around a whiteboard (especially if it is a sprint backlog) and discuss its content. - The flexibility.
Things can be changed, moved around, re-ordered, annotated, etc etc without fuss or hassle. - The process.
The manifesto says “Individuals and interactions over processes and tools”. Use the flexibility of a whiteboard to help hone your process, before committing to a tool which defines a process for you. The structure can be changed REALLY easily. Need a new column? Different chart? Another colour? Silly picture? Stick it up there, instantly with a pen. You’ll probably need to program, request or configure these changes with a digital tool, which takes a LOT longer. - The culture.
They help a team define their culture. Each sprint backlog whiteboard where I work is a little artefact which reflects the culture of the team and it’s members. One is clean accurate and ordered neatly, another is messy and colourful with pictures of Transformers. You can tell a lot about a team from the sprint backlog whiteboard. - The collaboration.
Product owners, stakeholders and interested parties can see what a team are up to and, importantly, collaborate with the team as they’re standing next to them when looking at their board. - The disposable information.
You only need to measure something for as long as it is useful. Need to chart the performance of your tests over a release period? Perhaps you want to chart users of a particular feature temporarily? The whiteboard allows you to track this information, with no overhead and comparatively little investment compared to a digital tool. - The doodle.
If you’re trying to explain something to more than one person, a doodle, or sketch may help (especially in development, when you might be describing a class structure, or some architecture). You’ve already got a whiteboard in your team area for your sprint backlog, use the other side? - The wheels.
I advocate whiteboards on wheels, these can be dragged back and forth between the team area and meeting rooms if needed. You don’t have to worry about logging in to a meeting room PC, getting the digital tool up, logging in to that, then increasing the resolution, or zooming with the browser so everyone can see, then clicking to the right section then … you see what I mean? Take your whiteboard and your pen. - The end.
Often it’s nice, when you reach the end of a release window or the end of your tether, to just wipe the board clean and start again. Get some solvent, give it a good clean, redraw your columns and start from fresh. It’s cathartic and cleansing.
How do I estimate how long an agile project will take, before we start?
Elephant Black and White
I was asked this a while ago and I’ve seen it mentioned a few times on blogs and forums and what not. I’ve answered it on a few occasions, so I thought I’d put it all into a coherent blog post.
Estimating a project before you start, with a brand new team is a tricky situation and one lots of people encounter.
There is a way you can work it out though, but your product manager should understand that it’s an estimate and it will change. If you need some backup, read this article on the ‘Cone of Uncertainty’ by Jeff Atwood and remember, you know the LEAST about a project right at the beginning!
How can I estimate?
There’s two ways you can do this; based on points or based on hours. I’d suggest using the hours method as it will give you a range. You can get a range with points as well, but only when you’ve done a few sprints. Some people are against estimating in hours and, usually, I am too. But for this “beginning of a project with a new team” exercise, it’s invaluable. The below all assumes that you have a product backlog ordered by priority.
I’ll start with the points method (and, step 1!):
- Estimate, in story points, your entire backlog. This is easier than you think and is often called the white elephant method, we use it with great success.
- Draw up somewhere a grid with 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ? as labels.
- Print out all your stories, or, if you’re already using index cards, just put them in a pile (but remember to put their priority order on them, so you don’t forget!) and put them in a stack somewhere.
- Now, each member of the team gets up, picks a story from the pile and sticks it to the board where they think it goes. If they have NO idea, then they put it in the ? box.
- Get everyone in the team to take turns in doing this. They must all do it in silence. Each turn they can pick up a story and place it on a board, they can also move a story that is already on the board, but they have to pick it up, face the team and say ‘I am moving this story because… ‘, then they can re-place it on the board.
- This goes on until all the stories are gone from the pile and no one is moving stories anymore.
- If you get two people moving a story back and forth because of a personal belief on it’s size, just have them put it in the larger number.
- Now, pick the story at the top of the backlog and say “Can we do this in two weeks?” If the team says yes, put it on the board, this board represents your sprint. Pick the next story and say “Can we also fit this story into two weeks?” if yes, put it on the board. Continue until your sprint is full.
Now, assuming you’ve story pointed all your backlog and the total is 260 points, you’ve worked out you can do 20 points per sprint, that means it’ll take you 13 sprints based on story points (so, 26 weeks). This will be quite wrong, but will give you a rough idea. If your product manager is bit simple, he might start telling everyone it’ll be done in 26 weeks. So, do the next step too:
- Ask each member of the team to estimate a max and min number of hours a day that they can work (taking into account meetings, phonecalls, emails etc etc that take time out of your productive, development hours); so Steve might say 4 – 5, Tina 5 – 6 and Hardeep 6 – 7. Work this out as hours per sprint. (So, Steve can do 40-60 hours per sprint in a two week sprint), with the above figures you’ll have a range of 150-180 hours a week;
- Remove all the cards from the board and put them back on the backlog;
- Pick the top story again, say “Can we fit this into a sprint?” If the team says yes, put it on the board again;
- Next, break this story down into tasks and estimate those tasks in hours;
- Do steps 3 and 4 until the team says they can’t fit anymore in the sprint based on the total number of hours (by adding up all the tasks) and their estimated man hours per sprint (ie: 150-180 hours per week as above), as a guideline, you should probably stop at around the 165 hour mark or, if the team cannot agree whether a story would fit or not, assume it won’t;
- Add up the number of hours they estimated, now you have how many hours they can fit into a sprint;
- Add up the story points for the sprint, this gives you your velocity.
So, you now do:
> velocity (from step 1) x (estimated hours for sprint (from step 2)) = total hours for project.
and then:
> (total hours for project) / (lower weekly hours estimate) = minimum number of sprints
> (total hours for project) / (upper weekly hours estimate) = maximum number or sprints
As an example:
> 20 x 165 = 3300
> 3300 / 150 = 22 sprints
> 3300/ 180 = 18 sprints
So, now you can say to your product manager, the project will take between 44 and 36 weeks (assuming two week sprints). Again, this is still only an estimate, but it gives you a better idea. Especially as you know the least right at the start. The best thing to do is provide continual updates to the PM. Once you’ve done a couple of sprints, you’ll have a better idea of your velocity and you should groom your backlog frequently (including re-estimating occasionally) to keep your estimated delivery fresh, based on the most up-to-date knowledge.
The annual performance review sucks; try an agile appraisal!
Recently, at work, I was asked if I knew anything about Agile Appraisals. I had to admit that I didn’t, so I went and did some research. The first thing I found was a Wall Street Journal article called ‘Get rid of the performance review!’ from Samuel A Culbert, who is a professor at the UCLA School of Management. It’s an interesting read and sparked some ideas about what an agile review process should be.
I’ve taken some queues from the article as he talked a lot of sense, and wrapped an agile spanner around it.
Agile Appraisals
As anyone who has seen Indian Jones and the Last Crusade knows, this is NOT the Holy Grail - Picture by Eddie Van W
The key is in the name, ‘agile’. We should turn to the holy grail; the 12 principles and four core values of the agile manifesto when thinking about how to appraise people people in our department. The four main points to take from the manifesto when thinking about appraisals, I think, are (paraphrased for context):
- People and interactions over processes and tools
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behaviour accordingly.
- Continuous attention to excellence enhances agility
- Simplicity is essential
So, with this in mind, we can see what an agile appraisals needs to:
- Dispense with forms and formality and concentrate on the conversations;
- Look at how the team can work better together.
Individual agile appraisals
In individual appraisals, the ‘team’ are the boss and his/her subordinate. The boss’ focus of an appraisal should switch from the traditional “How are you performing for me?” to, “How can we work better together?”. The idea is that, the appraisal is about doing things that make the relationship between the boss and subordinate better and allowing the subordinate to appraise themselves. What do they need to do to make their input more valuable and what do they need from their boss?
Learning happens here - Pix by shuichiro
This could be in terms of more training, guiding, coaching, tutoring or it could also be in terms of their relationship “I need you involved more in what I’m doing.” or “Help coach me on unit testing”. The subordinate should talk about how they’re going to make the relationship better and the boss should reply with “How are you going to do these things and, more specifically, how can I help you do that?”. This also has the benefit of reinforcing the Stop, Start, Continue idea of appraising your boss.
The whole idea here is to inspect and adapt, to spend some time reflecting how things are going and suggest and then try some ideas for the next period which reinforce the idea of a ‘team’ relationship between boss and subordinate and to ensure that the subordinate improves on issues that are important to them as well as being beneficial to the greater good of making quality software.
Bare this in mind during any appraisal: “Given who I am and what I am learning about this other individual, what is the best way for us to complement each other in getting work accomplished with excellence?”
The appraisals should be regular, at least once a quarter and last no longer than one hour. An appraisal can also be arranged at a convenient time for both boss and subordinate if either feels that their working as a team is suffering for any reason or that something that was agreed isn’t working or needs a tweak. The notion of ‘annual appraisals’ is absurd in this context.
Team agile appraisals
The team gather to reflect - tiarescott
Team appraisals can be run in the same way. These shouldn’t be confused with the sprint retrospective. The team appraisal is where the whole team gathers in one place for a time (not sure if a time box is relevant here, I think it should be no longer than half a day perhaps, but no less than two hours) and in turn, each person works on the mantra above (“Given who I am and what I am learning about this other individual, what is the best way for us to complement each other in getting work accomplished with excellence?”), says how they feel they could improve to benefit the team and then the team provides feedback on what the team member said and perhaps offer any help, or suggest ways in which the team member might meet that improvement.
This is not an opportunity to bitch and moan. This is an opportunity to inspect and adapt and reflect on how the employee works within the bounds of their team. This is like a retrospective in many ways, instead of being about the process, however, it is about themselves.
They have the option of having their manager present, but it isn’t essential and if they don’t want them, they should not be forced to have them. The team appraisal should happen BEFORE the individual appraisal, this will give the team time to reflect honestly on how they feel they need to improve without fear of reprise, and then take this to their individual appraisal, hopefully without modifying their feelings too much before they sit with their boss.
Pay Reviews
Wait, what? - Toban Black
It should be made explicit that annual appraisals are nothing to do with pay reviews. Appraisals are NOT for showing off how wonderful the subordinate is, no one writes things down they’ve done all year, they just get on with their job and do the best they can. If the appraisal was about that, the boss and subordinate would be working at cross purposes: the boss wants to talk about how the subordinate can improve and the subordinate wants to talk about all the great things they’ve done. The pay review meeting (if there even IS one) should be entirely separate.
The appraisals are about improving working relationships, not about money. I can’t stress how important this is. Without this explicitly stated, it will undermine the usefulness of the appraisal.
Another issue to think about when using money as a motivator is that it will only work in a narrowly defined way. People will do EXACTLY what is asked of them in order to get the bonus, or the payrise. They will do nothing more and nothing less, just what is required to pass the test and win the prize. Mary Poppendieck had this to say:
Using money as a motivator is like playing with dynamite because money is a VERY effective motivator. Monetary rewards motivate people to do EXACTLY what is being rewarded – not necessarily what the organization intended to reward, but EXACTLY what is being measured to generate the reward. Therefore monetary motivators have a long track record of generating unintended consequences. If there is any apparent competition for the money, money motivates people to get as much as they can for themselves. Thus monetary motivators have a track record of suppressing collaboration. Finally, bonuses for performance rapidly come to be an expected part of the landscape, replacing passion and dedication as motivators . These are things you probably cannot change about using money as a motivator.
- Mary Poppendieck
Traditional Appraisals
Annual appraisals or performance reviews are supposed to be an objective evaluation of the employee that helps with determining payrises derived from performance and to let the employee know where they can improve. In reality, this is not a majority of peoples view; most folks see appraisals as a waste of time: they are dispiriting and foster resentment, cynicism and inherently dishonest, instead of promoting honesty and candour. Reviews are political and subjective and create a chasm in boss-employee relationships. The link between pay and performance is tenuous at best and they are in no way objective. Would two bosses give you the same review?
Nurturing team culture
No, I don’t understand it either. One of the guys in my team made them. Perhaps I have two sides, one good and one evil. What is he trying to say? That I can kiss my own butt? Answers on a postcard please.
One of my favourite things about coaching multiple teams is you’re in the enviable position of watching multiple team cultures grow and change with the passage of time. These changes occur with outside influence, changes of team size and, at least here anway, with new memes that pop up on the internet.
One of the teams I coach has a team ritual. Their bot in IRC can be provoked into asking one of them to make tea, which the team member will do by filling their team-teapot with hot water, returning from the kitchen and performing the ‘Which tea shall we have gents?’ dance. This is accompanied by rounds of oohs and aaahs and finally the selection of a Fortnum and Mason loose leaf team will be dumped into the teapot.
It’s fascinating and humbling to watch these guys gel as a team. It’s often said that developers are insular, quiet, reclusive, like herding cats, blah blah blah and, while in some instances this may be true, I don’t believe it’s the norm. They form firm bonds around their passion for the code, which then spread out into their passion for other things (like tea, whiskey, or carpet putting).
Team culture is important, as I’m sure many other books and blogs will tell you, what is equally important, is allowing that culture to come into being and then nurturing it into something that, eventually, helps define that team. Make sure you do that, no matter whether you’re a coach, manager or team member, make sure you’re not impeding your teams ability to become a micro-culture within your organisations existing culture. This is doubly true for teams of developers.
I don’t know what role I might have played in helping the teams here define their own culture, if I’ve even helped at all, but I’ll certainly never try to stop them and will always encourage them along a theme and, importantly, take part in that culture – this is crucial to gaining trust. When in Rome, do as the Romans do. The great thing is, I love each of the way the teams here operate, so it’s not hard for me to get involved. Your mileage may vary, especially if their culture dictates they all play football and you hate it for example.
There’s probably a blogpost in creating a team and making them a cohesive fighting unit. But for now, it’s safe to say I’m proud of the way the teams I coach are actually teams of guys and not just individuals sitting next to each other writing code.
leave a comment