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!
Estimating stories quickly and efficiently with ‘The Rules’
ticktickticktickBING - An Old Timer by hiro008 on Flickr
Estimating a backlog should be easy, especially if your Product Owner has looked after it, knows how to write good stories that mean something to the developers and the business and is able to prioritize based on business value (or, customer delight!). However, estimation meetings, poker planning, planning two or whatever you call it, can often be painful events that descend into chaos, anarchy and heated debate. While these things are all fun, estimation should be fast and simple, afterall applying arbitrary numbers, whose only measure is relatively sized, to amorphous items of work can’t be rocket science, so why would you want to spend much time on it?
Trouble is, developers and engineers are paid to solve problems, that’s what they love to do, so they begin the moment the problem is presented! This is to be applauded, but doesn’t really nail what should be fast conversations about stories!
We’ve recently been coarse estimating the next releases’ worth of stories for each if our products, the backlogs for these products contain between eight and 38 stories, depending on the goal. When we started estimating these, it was clear that it was going to be painful, so I created ‘The Rules’ (to be clear, they’re guidelines, remember the Shu Ha Ri!):
- Reset the countdown timer to five minutes.
- Product Owner reads story and acceptance criteria.
- Team ask questions to clarify their understanding of the feature. No technical discussion.
- When no more questions, the team estimates.
- If estimates converge or there is consensus, GOTO 1 and start a new story.
- If no consensus, start more discussion. Technical discussion is OK here.
- When the conversation dries up, or the time ends, whichever is first, the team estimates again.
- If estimates converge or there is consensus, GOTO 1 and start a new story.
- If a consensus isn’t reached, reset the time for another five minutes.
- When the conversation dries up, or the time ends, whichever is first, the team estimates again.
- If a consensus still hasn’t been reached after 10 minutes, put a question mark next to the story and GOTO 1 and start a new story.
- Optionally: create a spike story to discover more information in order to estimate the difficult story.
Should I start with scrum, or kanban?
or, Should I transition from scrum to kanban?
Adventure lies EVERYWHERE! Image by Daniel Voyager
We’ve been doing scrum at Affiliate Window for a couple of years now. We go through the inspect and adapt cycle regularly and we’ve made few, if any, changes to our process, only our engineering practices. Recently, however, we’ve been working on a couple of projects which have required some groundwork and lots of backend work. This kind of work doesn’t really lend itself to the ideal of having something to show the stakeholders at the end of every iteration. We still have the review, describe what we’ve done and then take a look at the backlog with the stakeholders to decide what the priorities are for the next iteration.
This has raised a question from one of the teams about moving over to kanban and it got me thinking about what organisations can do to start on an agile journey, should they start with scrum, or kanban? What about established teams? Can they transition from scrum to kanban, or vice versa? Why should they? Should they even do it?
Now, there’s no reason why you can’t continue doing scrum (which is what we’ve decided to do), even with backend heavy work. Afterall, it’s simply a framework designed to offer constraints in order to create fast feedback (amongst other benefits), but kanban is attractive in that it allows you to decide when you demo/review and so gives you the benefit of time in order to actually have something tangible to show the stakeholders. Kanban is also attractive for those coming to agile afresh. It allows you to start integrating some agile practices and get a view of your issues (in order to solve them) without changing your heirarchy or existing process.
For Kanban to really work, you need to make sure you’re setting up a pull system that describes your entire process, from inception to delivery – not just a column based todo board (which, unfortunately, you see a lot described as ‘kanban’). To be able to do kanban well and retain the holistic view of your work required by the product team to make educated guesses on delivery and suchlike, the team needs to be mature enough to do kanban well. This means; mapping out the different states in your system, working out WIP limits and, importantly, deriving cycle time (how long it takes an item on the board to get from left to right) in order to estimate delivery/scope/cost etc. Herein lies the rub (I’ve always wanted to put that in a blogpost!).
If you’re not able to use scrum to help you deliver backend-heavy, large work items, then it’s unlikely that kanban can help either. The constraints of scrum help you stay on target and be accountable for what you have or haven’t done and make tweaks and adjustments to perform better in the coming iterations. Once you’ve nailed scrum and you have a product backlog with well defined stories, which are easily estimatable, then you’re ready to mature to a really valuable, efficient and data-driven kanban implementation. Eventually, when you’re able to size your stories all the same, you can do away with estimating as your cycle time will remain constant. Allowing you to set regular reviews and inspect/adapt cycles. You’re one step closer to programmer anarchy!
So, should you start with scrum, or kanban? Kanban allows you to start your agile journey without upsetting the status quo; you don’t change any names, or add/remove roles. You simply illustrate your process on a big visible board and become accountable, as a team and a company for the work you do. You can implement any agile practise you like (standups, backlogs, user stories, etc) and see how they work for you without rocking the boat. Scrum, on the other hand, requires a reboot and an installation of a new process, one with constraints *built in*, but the benefits are numerous and valuable right off the bat.
Should you start with scrum, or kanban? The answer, I think, is ‘it depends’. If your organisation, including those at the top are comfortable with scrapping your current process and starting something new, even with it’s inevitable lead time, then go for it. Use scrum and the constraints will help you become agile. If your organisation is reticent to start, or you have buy-in from teams, but not the business, then start with kanban. It’s lightweight and non-intrusive and will still allow you to raise your impediments and issues (but solving them often requires bold and honest action, beware!).
Should teams transation from scrum to kanban? Probably, but make sure it is for the right reasons and that your team is mature enough to make the most of it, if you’re not sure, then try transitioning via scrum-ban, it’ll help you see the benefits and enable you to get better at the things which make kaban most useful, without changing more than you are comfortable with.
I’d be interested to know how others started their agile journey, or whether many transition from scrum to kanban (or the other way). Drop me a mail, tweet or leave a note in the comments!
Scrummaster? We don’t need no steenking Scrummaster!
A Sad Face by Emmaline
I discovered something strange today. I recently left one development team to go work for another (that’s for a seperate blog post all together) and I was chatting to some old team members today who had just had their Scrum Sprint Review/Retrospective and they mentioned one of the things that had come out of the Retrospective was that they aren’t going to have a Scrum Master for this sprint, or, it seems, any sprint.
“Huzzah!” I hear you cheer! “They must be self-managing!”
No, no they are not. It’s far, far worse than that. They’ve decided they don’t need a scrum master as, in their experience, the scrum master is useless. With no power to help the team make decisions and one team member describing the Scrum Master as “a puppet of the business”, then it’s quite clear that scrum, at this company, is broken.
It’s a sad day for me as ever since I heard about scrum about two and a half years ago from a colleague (@garethholt), I realised it’s potential. I’ve tried hard, arguing the point with colleagues, management and everyone who’ll listen. We’ve tried different length sprints, staggered sprints, digital backlogs, analogue backlogs, all sorts. Inspected and adapted and now it’s all for nowt. At every turn, the business said “No, I’m not confident enough to try scrum properly.” or, more accurately, “I don’t want to surface the organisational dysfunction.”. The team realises that the business cannot let go of the reigns.
It’s all about trust.
They all seem like the wind has been taken from their sails and it’s sad and dissapointing. Especially as they have an ‘Agile Manager’ and a ‘Product Owner’ who is also a director. Even the people employed to support scrum don’t seem to have confidence in it. Now THAT is a problem.
I might go home and cry.
Resourcing, it's just an estimate OK?
Reign of the Supermen by fengschwing
Too often, businesses seem to think that the resourcing we do during sprint planning to work out how many ideal hours we have, allowing us to decide what we can fit into a sprint, is an accurate reflection of how much work the team can/will do.
It’s not, OK, chill out. At BEST it’s a worse case scenario.
The average work day is 7.5 hours. That does not mean that I can dedicate 7.5 hours of work to tasks from the board. When we used to do resourcing, the business would estimate our resourcing for us:
There are seven people on the team doing a two week sprint, therefore, you have 490 man hours in this sprint, fit stories and tasks in that equate to those hours, you can have 15% of that figure for bugs.
-Somebody from the business
We quickly realised (well, as a team, we realised this was wrong immediately, but the business will always wait for empirical evidence first) that this wasn’t going to work. There is no way each team member can dedicate seven hours a day to the sprint. There are numerous things that vie for your time; getting a coffee, taking a piss, talking to colleagues, talking to the business, researching your industry, emailing your wife, checking your bank balance, rebooting your Windoze computer on a AD network which takes about 15 minutes, getting a coffee, etc, etc.
So, sprint after sprint failed (let me be clear, the sprints didn’t “fail” as the business always decided we “drop” something low priority from a sprint before the end but, as a team, that feels like a failure) and this could be down to bad estimating of ideal hours for tasks, true, but this is compounded by bad resourcing.
If you resource incorrectly, your entire sprint is undermined as it’s the basis for deciding what you commit to, you have an inflated idea of how many ideal hours you can deliver and so you over commit. Your gut feeling is always “this is too much work, we’re overcommitting!” but the math is right? So, it should fit in, right? RIGHT?
No, wrong. It won’t. Neither will pretending it will fit in and then dropping stories at a later stage work either. This will undermine the teams ability to deliver quality working software as there is always this grey cloud of unachievable stories hanging on like a bad smell at the end of your sprint backlog. The team will inevitably rush through what they’re doing to try and deliver what they’ve (been forced to) commit to. This is bad on many quite obvious levels, so I won’t spell them all out…
… OK, I will. This will result in less than polished code, rushed, hurried unit tests. Bothered and harrassed QA roles (if you have them) a stressed release manager as he’ll be backward and forward with UAT, an annoyed stakeholder as the stories get rushed, other annoyed stakeholders as their stories get dropped and, finally, a shoddy release of badly written, implemented, tested and released code.
Exaggeration? Maybe. But it makes my point.
If you ask each team member “How many hours a day can you commit to, ideally?” when you’re resourcing. You’ll get a worst case scenario on the amount of ideal hours you have. If you then estimate and plan based on that, you’ll ALWAYS deliver what you commit to (unless you get the planning REALLY wrong) and, usually, have time at the end to pick up an extra story, fix an extra bug, research a new technology or whatever. Everyone wins; the team are happy that they’ve delivered what they’ve said they would (and, maybe more) and the business is happy as they’ve managed external expectations and delivered the commitments and perhaps even more happy if another story was squeezed in, or an extra bug or two squashed.
I understand that you need to know where inefficiencies are, I really do, I want to know also. If the team are kicking around spending three hours a day reading XKCD and reading LOLCats, then I want to know as well and why. But they aren’t they’re spending the time doing actual work. So, let them do it and don’t force them into it.
If you want to measure time spent on things other than the sprint, then use something other than the sprint to measure that time. Resourcing and estimating/planning won’t help you here as they are, after all, just estimates.
An Open Letter To Those Modifying Scrum To "Fit"
Sir,
Scrum is not about keeping the faith, I am completely committed to scrum, as, I think, are you. It’s about hearts and minds. American military generals bang on about it all the time and for good reason. For months and months we’ve been calling it a “stand up” or a “scrum” and, on the very eve of launching our latest product, which was designed, written, managed and launched using scrum, we switch to calling it a “huddle”. What this says, unconsciously perhaps, is that we stopped doing a standup and when we switched to a “huddle” the product got launched; not a good advert for doing scrum.
Might sound like a bunch of crap, but it’s all psychologically sound.
We are a scrum team, regardless of whether we’re actually in a sprint, if we all stand up at the beginning of a day, then we’re doing a stand up. We can do a huddle if there’s less people and it’s at a different time of the day, maybe. There are ceremonies and artefacts of Scrum and the last time I looked, a huddle wasn’t one of them. The rules are few, simple and really easy to follow. Breaking them, for whatever reason, should not be done. If you’re breaking the rules of Scrum, you’re NOT doing scrum! Simple as that. If you break the rules of chess, while you’re playing chess, you’re not playing chess and you’ll probably get a punch on the nose from your opponent for cheating to boot.
One of my responsibilities as a scrum master and dedicated member of the team is to improve the scrum process, this can only be done with more and more business buy in – if we start diluting it now, then we take two steps back. The product got delivered BECAUSE OF scrum, not in spite of it. Without scrum it would have been a different story (probably wouldn’t have failed, but it wouldn’t have been launched yet). I can only do my job with the help of the team and, although I don’t think you called it a huddle because you want to rename the standup to huddle, I need your support in pushing through scrum, which includes not diluting it.
Do you understand my point? It’s about cohesion and making sure we’re always an advert for ourselves and the way we do things and the reason for doing things and that we get things done BECAUSE of the CHOICES WE MAKE as a TEAM on how we do the things we do.
Kind regards,
Mike Pearce
Does the daily standup provide value?
Our team sits in a horse-shoe shape where I work. Some people on the inside and some on the outside. There are no partitions, no borders and people only really put their headphones on when they REALLY want to get in the zone. Communication is key to having an effective scrum team and in this shape, totally co-located (even the DB team are in the horse-shoe and they’re not even part of the scrum team!) means communications is but a chair twhirl or a lean over the desk away.
So, with this much communication going on, is the daily stand up still worth it? Does it provide enough value for the team over and above that value currently being sucked from rich communication throughout the day anyway? It seems to be that the only people who might benefit from the standup, then, are the chickens, who really don’t listen to what we’re saying as they don’t understand it and are just there to wait until the end when they get a chance to say their piece.
Usually, not particularly interesting or worthy.
None-the-less, the stand up does provide a moment of the day at which you can see everyone’s trousers and shoes and feel like a “team”, a group of people all striving for the same goal and not a disparate set of developers hunkered behind a screen waiting for the end of the day.So, then, is the standup merely an ideal? Something that is important only for what it IS and not what it does or provides in the way of value? Perhaps, but I don’t mind either way, either options provides some benefit and some is better than none. Also, I like to look at shoes.
Should you bother with a product backlog?
I recently started a conversation on the agile development group over at Yahoo Groups. My initial question was, should I ditch the product backlog? We tend to do a lot of just-in-time development, the requirements come in, sometimes mere hours before our sprint planning and as such, these stories are only on the product backlog for a very short period of time, if at all. Often they’ll just come in via email from the Technical Director and they get added to the sprint. The backlog, then, becomes ever growing and it seems that some of the stories on there will never be looked at again, let alone completed. It’s the fable of the ever-growing backlog.
So, do we even need it? Jack Milunksy of Agile Buddy fame said, if you’re not using it, then in pure lean fashion, ditch it and stick with the just in time. Others have said, if you’re not using a product backlog, how will you define a release strategy or be able to roadmap the product? Which is a good point. The answer then is that it depends. Why is this always the answer with anything scrum?
If you’re using the product backlog as a place to store and prioritise stories, use as a release manager or roadmapper, then you should keep at it. If you’re using the product backlog as somewhere to store half-formed ideas of possible features of additions to your product, then maybe you should use a backlog. If you get your priorities minutes before the sprint starts, hastily written on the back of a beer mat, then maybe not. Or, maybe just use it to store high priority stories that are definitely going to be worked on but not yet.Above and beyond all this though, is grooming. If you don’t groom your product backlog, then you’re in a whole world of pain. Epics, which are at the bottom will suddenly become top priority and, without grooming, will still be Epics. Your team may even throw things at you, I wouldn’t be surprised. So groom the backlog regularly, get the team involved and make sure you’re breaking stuff down!
Update: Jack Milunksy over at the Agile Buddy blog even blogged about this: http://blog.agilebuddy.com/2009/11/do-you-even-need-a-product-backlog.html
CSM Certificate
Some people are like Yay! others are Boo! Me? I’m more meh…
I can understand both sides and, frankly, can’t get behind either. Some say that the CSM course isn’t about learning how to do scrum, but learning how to take scrum to your business. That’s fine. These people, they say “Why do you need a certificate for something that you can prove you know by doing?” Well, you need to find somewhere to do it first, surely? Being a CSM makes it much easier to get a job as a scrum master, and, once you’ve got that foot in the door, you can then start to prove yourself as a CSM by actually doing. Fair enough right?
Others, they say; “OK, so what’s the point in the certificate in the first place?” and I say, well, I concede that point also. Going on the CSM course is enough, as long as you can say you were on the CSM course – how do you do that? With your automatic entry to the Scrum Alliance, you can looked up on the register.
Well, I say meh… If it helps you get a job, then great! If it helps you get a foot in the door, then great. If it helps you pay attention more in the training, then that’s awesome too. Just don’t worry to much about it. At the end of the day, it’s what you DO in the day to day of running your sprints that counts.
Besides, the industry is full of certificates and exams that mean exactly squat. It’s just like university – you prove you can learn and retain enough knowledge to pass a test; although it’s a hell of a lot cheaper!
Guessing a velocity
You’re at sprint zero. You’ve got a new team. You’re new to scrum. You’ve never quite managed to stick to the Scrum framework. All reasons why you might not have a velocity. I’m sure there are more, but these are the most common. What do you do? How do you know how much you’re going to be able to fit into a sprint?
You guess.
Yes, I’m serious. If you’ve groomed your product backlog for the first sprint, estimated your stories and refined those estimates and broken down larger stories, then the only thing left to do is guess. Gather your team around and ask them “What do you think you can fit into this sprint?”. Once the team has picked from the highest priority stories and agreed that they think they can fit the work in, ask for their commitment. It’s at this point that you’ll need to help the team decide whether or not they’ve over committed. Most teams almost always start out thinking they can deliver more than they really have the capacity for. It’s not because they’re showing off, or because of any kind of arrogance, they actually do think they can deliver what they’ve said they will. Remind them that, while the stories are well written and the acceptance criteria well defined, they are just the start of a conversation with the business and things could change.
Your team will probably decide to knock of one or two stories and right now, that’s fine as they can always go back into the sprint if you find yourself running out of stories half way through. Once there’s a commitment, add up the story points. That’s your predicted velocity. It may not be accurate and it’s quite probably wrong, but right now, right this very minute it’s the most accurate idea you have of how much you can deliver in your sprint.
Why is this useful? Well, it will give your team a target, they’ll want to actually hit that velocity prediction as they’ve said they would. It’ll also come in useful for release planning and having some kind of vague idea of when your product might be delivered. You know least about how long or how complex a task is right before you start it, but now you’ve got some benchmark. You can add up the rest of the story points on your backlog, divide by the predicted velocity and have a figure which is roughly how many sprints you’ll need before you have delivered your product.
That is something that the product owner will shit himself with excitement about. Assuming he hasn’t asked you to translate that into a gantt chart.
leave a comment