Archive for the ‘Teams’ Category
I read a lot of blog posts, articles, papers and what-not on creating, maintaining and coaching teams. It’s the one thing that, for me, has no set formula. Each team is different, as they’re made from different individuals, each with their own set of morals, ethics and experiences that drive their behaviours. There is no ‘one-size-fits-all’ team guide, unfortunately.
So, what we’re left with is a miasma of different works, all decrying or promoting some way or other of how to form and maintain a team, how to help them become high-performing, how to retrospect, plan, work, play, love, eat, argue and play football together. None of them are right and, equally, none of them are really wrong. But the one thing I see frequently is suggestions, and often demands, that “if they don’t fit, you’re hiring wrong/replace them” and this is alarming.
The common theme I see is that, yes, there IS a formula for creating the winningest team and, if one of the members of the team you’re trying to engineer to stardom doesn’t fit your mould, then he’s out on his ear … hit the road jack, your awesome-coding-but-complete-lack-of-personal-skills ass is outta here!
Not everyone can be a rockstar, you need some roadies too.
Or maybe there’s the guy who just REALLY enjoys honking about with MySQL queries, doesn’t really give a rats ass about what the business does, but cares deeply about the quality of his code and making his queries elegant and fast.
Some of you may know the guy who get’s a real kick out of cutting HTML all day, taking the photoshop files from your rockstar, sweater-vest wearing, macciato drinking, fixie-bike riding designer and making a cross browser compliant, responsive and even working in IE.
These guys may not be the fastest, or the bloggiest, or the githubbiest, they may not even really get on that well with agile estimation, sprinting or ‘stakeholders’, but they’re rock solid and dependable.
Everyone has a place, even if they’re wearing a christmas sweater in June, they’re part of your team. Find a place for them, or, better yet, let them find their own place and do what they do best, even if it doesn’t align with your idea, or the internets’ idea, of what a perfect team is.
They tune the guitars and your rockstars play ‘em. That’s what a real team is.
Some of us inherit teams. We don’t have the luxury of hand picking the people we want to have. Maybe there just isn’t enough in the budget to fill your team with rockstars. Software gets written outside of Silicon Valley too!
This, for me, is the real notion of building a team. Not chucking money at a bunch of rockstars, but taking what you have, or building on a small budget and creating a live band – you need rockstars AND roadies if you want to wow your audience.
Today, my department begins a trial of a new culture. It’s a new way of thinking about work. Alright, it’s not *new* but it is rare. Especially in the UK. The culture can be summed up with one sentence: ‘Employees are free to do what they want, when they want as long as they get the work done.‘
There will be a whole bunch of blog posts on this subject, so consider this one a bit of a summary of all the main points.
I’m talking about a Results-Only Work Environment, or ROWE for short. It started with Best Buy in the states. Two employees were tasked with making things better and they began with flexible working programs which quickly morphed into a Results-Oriented Work Environment, then settled on a Results-Only. They detail their journey in their book ‘Why work sucks and how to fix it‘. I devoured the book in one sitting and made copious notes and realised that this was what we needed.
The way business works now is outdated; why do we need to work between 9 and 5:30? Why do we need to go to one particular place to do it? It doesn’t matter if you’re a knowledge worker, or in sales, it’s the same thing: the focus should be on results, not when or where you are.
It’s not been easy getting this trial started. There are lots of questions around holiday allocation and remaining on the correct side of UK employment law and legislation. Essentially, we need to still allocate people the appropriate amount of holiday and then ensure that they remember to take it. This mostly covers the company, so if someone leaves on a bad note, they can’t claim to have not taken holiday, because, in ROWE, you take holiday whenever you need it, there’s no allocation really. Because employees get to choose when, where and how they work, the rules governing the Working Time Directive don’t count either. There’s no 48 hour waiver or whatever.
We’re starting with *almost* the exact ROWE for a three month trial, I say almost because we’ve made two concessions, which I detail in the guideposts below. After three months, if it’s still working, we’ll extend the trial. The idea is to see if vanilla ROWE as detailed in the book works in the UK. UK and US cultures are different and employment law and employee rights are also different, so we need to make sure it fits properly for us and our business. I’m 100% confident that this will work.
Freedom and culture
Ultimately, working in a ROWE is purely focussed on the results. But it gives employees absolute freedom to manage their lives they way they need to. We all have to work, there’s no way around that (unless you’re a millionaire playboy or whatever), so we should be free to fit that work into our lives as we see fit. You don’t need to take a half day holiday to visit the doctors, you don’t need to phone in sick unless you’re going to be letting someone down with a meeting or conversation and you don’t need to worry about where anyone is, you and your colleagues are available 24/7 by phone, voicemail, email, SMS, skype, irc, Google Hangout – lot’s of options!
ROWE isn’t an activity or an action, it’s a culture and a new one too. It’s about changing the attitudes people have towards work and challenging the long held beliefs that time plays an important role in measuring someones value (time is still relevant for deadlines and in some lines of work, but not in the web industry).
I’m expecting to see productivity improvements too – I have no idea what they’ll be or in what format, but I’m sure they’ll be there. For one, I find I can get a lot of work done in the wee small hours, because I’m not being distracted and there’s nothing to procrastinate about when the kids and wife are in bed – so I can’t play PS3 or watch a movie, so I work and I can get more done in less time because I’m so focussed on what I’m doing.
Our teams use Scrum to build our software, so we have a built in results measure. We’ll be looking at velocity for each team and the department as a whole, as well as defects, engagement and acceptance rate of stories (the percentage of story points accepted at the end of the sprint). On top of that, all the people in my team have individual goals and objectives; a mix of skills acquisition and platform or performance goals, so I can measure individuals as well as teams.
ROWE is based on a set of principles called ‘Guideposts’ which enable the change of culture to happen with a purpose, the most contentious of which are ‘Unlimited Paid Holidays’ and ‘Every Meeting is Optional’. The holiday one is easy to cover in principle – it’s irrelevant how much holiday you take, or when/where you take it, as long as the work gets done. That said, we still need to make sure that we’re adhering UK legislation and in order to do that, we still need to allocate and record holiday taken. It’s a small price to pay for that much freedom though!
‘Every Meeting is Optional’ is also difficult for people new to the culture to get their heads round, it doesn’t mean ‘flip a coin to decide whether or not to go to a meeting’, it does mean, find out if you can get, or give value to the meeting, find out, or define (if it’s your meeting) the outcomes and then decide whether you need to be there in person, whether you can dial or Skype in, or whether you’re just required to give information which you can email to the organiser. As long as the work get’s done and you’re meeting the goals, objectives and targets set, it’s up to you whether you attend meetings and how you attend them.
The one concession we made to this guidepost was that, ALL meetings are optional, but pay particular attention to external client meetings or group-wide meetings. We’re only one department in one company doing a ROWE trial, we can’t expect others to change they way THEY work … just yet. It’s a small concession and, to be fair, will barely affect our department.
Metrics and the win condition
How do we know the trial is successful? If nothing changes. Like I said, we’re currently tracking:
- Velocity: The average rolling department velocity over the last 4 sprints (and long term velocity, but this is less volatile and less useful)
- Defect rates: how many defects are opened per two-week period and how long those defects stay open (as an aggregate and also by priority)
- Acceptance rate: What percentage of story points is ‘accepted’ by the product owner at the end of the sprint.
- Engagement: we’re using Murmur to track employee engagement with the company on many levels.
We’re also looking to measure the perception of the department from across the business.
The win condition will be if nothing changes. If none of the metrics change over the next three months, then the trial will be considered successful, the net benefits of ROWE will be over and above just the impact on those metrics. So, as long as nothing get’s worse, we’ve proved ROWE as a culture in the organisation.
On top of the team metrics, we’re also setting goals and objectives on an individual level – skills acquisition or just ‘stuff that needs doing’ for the platform, our tools or whatever. So, we can watch everything that’s happening and see if it’s making a difference.
Next I sit back and wait for a sprint or two and see what’s happening, I need to keep my eye on the metrics and the individual objectives, but really, it’s business as usual … or not, depends on how you look at it!
I’ll be blogging more as the trial progresses in the hope that others in the UK who are already in a ROWE, or those thinking about going ROWE can share their progress, problems, failures and successes.
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?
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).
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.
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.
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!
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.
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.
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.
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:
> total story points / velocity (from step1) = number of sprints based on velocity (don’t use this though, it’s a very rough guide)
> number of sprints based on velocity x (estimated hours for sprint (from step 2)) = total hours for project.
> (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:
> 400 / 20 = 20
> 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.
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.
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?
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
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.
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
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?
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.