Sunday Link Dump!

Sunday Link Dump!

First up, is this most excellent post from Joshua Arnold over at Black Swan Farming. Called “Standing Up Doesn’t Scale” it’s a comment on “false friends and local maxima”, that is having standups and kanban boards, without actually knowing why you’re doing it and what problem you’re trying to solve. Too many organisations are like this and it’s frustrating for everyone involved -especially those hired to help with the transition in the first place.

#noEstimates is a torrid love affair of biblical proportions and, by biblical, I mean magic pregnancies! Anyway, I liked this post from Glen B. Alleman over at Herding Cats because he’s, again, poking a stick at fanatic dogmatism. I don’t agree with everything he says, but it’s a good speech from the prosecution. The Problem With #Noestimates

One for the people people here. Hiring is one of the most important things you have to do in a business – no, seriously, it is. Hiring the wrong people (or, the right people for the wrong role) is hugely damaging to your company. This post talks about what it takes to hire hire an engineering manager. From Calille Fournier at Elided Branches, Hiring Engineering Managers: Screening for Potential

Nothing is immutable

Nothing is immutable

“But they’re the project goals!”
“So what? They’re not appropriate any more.”
“But they’re the project goals, you can’t change them!”
“Watch me.”

Challenge everything and remember, nothing is immutable. If you make your project goals redundant (and you should always try and prove the negative hypothesis), you’ve made a huge discovery.

Nothing is above the laws of science – hypothesise, test, learn.

Dancing to the wrong beat

Dancing to the wrong beat

It’s something we’re not going to get away from: mashing traditional projects and project management with agile. You know it as many names – waterfall, scrumerfall, scrumbut – each as bad as the last. It comes in many guises: time lines, gantt charts, milestones and my favourite, governance.

You can have timelines and milestones, they’re not too far removed from Release Planning, as coined by (and then retired by) Mike Cohn. Gantt charts are OK, if you turn them on the side and use them as a product backlog, but something I cannot really get behind is governance.

Now, there are a truckload of different types of governance, but what I’m talking about is “agile governance”. Brian Wernham talks about it an an APM blog post here and it’s an interesting read. Essentially, it’s a sponsored, empowered set of controls. You could argue that the blog post is over 18 months old and not relevant anymore, but my experience says otherwise.

Sounds crappy, huh?

The idea of governance is that it allows a group of key project people (think stakeholders and team members) to get together regularly in a room and talk about the project. Not altogether too dissimilar to sprint demo, except the governance meeting is future looking and the demo is a view of the last itertion.

The trouble with the governance meeting is that it tries to tie you into a plan, “What are we going to do next?”, “When can we have X thing?”, “What are our biggest risks and how do we avoid them?”

But the biggest and most troublesome problem with the governance meeting is compounded during an “agile transition/adoption”, you can bet your ass that before a company started being agile, they had governance meetings and so, after the adoption, continuing with the governance just helps to reinforce bad habits and out of date ideas on how “projects” should work.

The meetings cause anxiety – instead of going into it (as in a demo) with a list of things to show for your effort, you’re going in with a list of problems that, if you could solve them, you already would have, so they’re unsolvable right now and not worth talking about, they just make you more anxious. You’re going to talk about the future of a project with some of the wrong people and not all of the right people – afterall, it’s a team sport – why leave some of your A players on the bench? Many of the people in that room will not be in your team and not be accountable for the work that get’s done, the planning or the outcome.

Push to get rid of governance and provide everything anyone needs at your demo. It’s the only way we’ll make any real progress on a project. I think that the GDS has got it mostly right. It’s the government, so they’re going to have governance, but they couch it in these terms

GDS has defined 6 principles for governing service delivery. Following them should help you create the right culture within your service. They are:

  1. Don’t slow down delivery
  2. Decisions when they’re needed, at the right level
  3. Do it with the right people
  4. Go see for yourself
  5. Only do it if it adds value
  6. Trust and verify

See what it doesn’t say there? It doesn’t say weekly (or regular) meetings with the same people just to see what the status of a project is and complain when it’s not “on schedule”. Head through to the Governance Principles page, it’s an excellent and enlightening read.

It’s not often anyone can say “let’s be more like the government”.

Link dump! Agile is the new waterfall, from chaos to managed chaos, best practice and more!

Link dump! Agile is the new waterfall, from chaos to managed chaos, best practice and more!

Agile Is The New Waterfall
“Agile promised us engineer driven development.” is the first of many fallacious claims that the CTO of joinjune.com makes in this rant that woefully misunderstands what agile is. He makes the odd good point, but then messes up the punch line (I especially like the bit about estimating). I suggest you read it with an open mind, otherwise you risk a hernia.

From chaos to managed chaos
Vasco Duarte tweeted this during the Coding Serbia conference. It’s one teams journey from estimates to #noEstimates. An interesting read.

Four Ways to Kill Best Practice
I’ve blogged about best practice before, but Megan Louw from ThoughtWorks offers some practical advice on getting rid of the idea from your business entirely.

Hashtagagile
Some cheeky self-promotion on the new agile slack channel I recently created. We’ve got a massive 23 people online now – come and join the conversation

How Google Thinks About Hiring, Management And Culture
I really enjoyed Work Rules! By Laslo Bock, who used to be Googles SVP of operations – there are some excellent ideas and stories in there and plenty of SCIENCE! This has an interview with the man and some key points from what he was saying – worth a listen.

#agile slack channel – http://hashtagagile.com

#agile slack channel – http://hashtagagile.com

I’ve started a new Slack channel called #agile. You can find out more and signup at http://hashtagagile.com.

A while ago I started a #people Slack channel, for discussion around HR, management and people ops. At the moment there are ~260 people on that channel. It’s not always busy, but there’s usually someone to ask about things, or just have a conversation with. I looked for a similar channel for agile discussion, but came up short – so, I thought I’d make my own.

There is no shortage of forums and websites, communities and clubs with which to talk about agile, ask questions and get answers. What there isn’t, though, is somewhere to get live chat, instant replies and all the other good stuff that you get from something like Slack. #agile is a chat community for talking about all things agile: from software engineering to scrum mastering, methodologies, culture, process and anything else.

So, if you’re interested in chatting with other folk about all things agile, then head to http://hashtagagile.com, sign up and join in the conversation. It’s a bit quiet at the moment, as it’s only just started, but all it needs is your voice as one of the founders to make it useful.

The secret of #noEstimates

The secret of #noEstimates

I’ve not really understood the no estimates movement. I’ve read a bunch of blog posts and followed the twitter hashtag and discussed with friends and peers, but it just seems like a different kind of estimating, albeit using empirical evidence (not that story points don’t).

Anyway, the secret is this: INVEST.

If your stories adhere to this acronym, then you’ll be able to do #noEstimates and, by “adhere” I really mean, be “Independent”. I believe this is the one most important things about the movement – being able to make decisions about what to build and deploy, how to prioritise and project comes down to the quality and size of your stories.

The trouble is, that is really, really difficult.

How to have better remote team meetings

How to have better remote team meetings

Where I work now, half the team is based in Romania. Yes, they’re an offshore team, but you wouldn’t think it the way they integrate so well with our teams, tools and general day-to-day. One of the things I was way of when I started, was how they would get involved with team meetings, like planning, stand-ups, retrospectives, etc.

I’ve experienced people joining team meetings remotely before: there’s a room with most of the team in, sitting around a table and then one giant talking head on the screen (it’s even bigger on a projector screen). It takes real discipline and frequent repetitions to make sure the remote worker is included in the conversation and gets the value they need and the common understanding the team needs.

However, at my current job, we do it slightly differently. Instead of booking a room and having one or two talking heads, everyones does the hangout from their desk instead. The key thing to experience here is that everyone is “remote’ in that they’re dialling in.

It levels the playing field for the whole team.

Yes, it levels it lower than in-person meetings and you have work hard to make sure it works, but I’ve been surprised and impressed at how well these meetings have worked. Especially complex meetings that involve more interaction like a retrospective.

It’s not perfect – it’ll be a long time before remote team meetings are on par with IRL ones – but it certainly helps keep remote members feeling included.

Friday Link Dump

Fridays, so close to the weekend you can almost taste the lay-in and the breakfast burrito. So, to hurry it along, here are some of my favourite links this week:

 

The Unmyths of Estimating

The war between estimates vs #noEstimates still rages on and this is an interesting piece that evokes the dark, magelike forces of statistics and probability.

The Science Of When You Need In-Person Communication

It’s a little bit one-sided in it’s presentation, but this article does bring together some good evidence on in-person meetings. In a world where remote workers, Google Hangouts and Skyping are more and more frequent, we shouldn’t underestimate the power of touching someone (not like that, weirdo). Still, it does raise the question whether the details (like touch) of in-person meetings have an opposite or equal behaviour in remote meetings?

Going To A Conference? Don’t Waste Your Time

Careful with this title, it’s not “Don’t waste time by going to conferences” (which I thought it was – damn linkbait) instead, it’s “Going to a conference? Use your time wisely there.”. Interesting take on how to view conferences as a source for asking more questions.

Doctor Who Spin Off: Class

Doctor Who (and its spinoffs) are one of my favourite ways to pass the time, so, news of a new spin off, called “Class” by young adult author Patrick Ness is pretty exciting. No news on what it’s about yet, other than the school, but I’m looking forward to it anyway.

Meeting etiquette (or, how to be mindful when it comes to meetings)

Meeting etiquette (or, how to be mindful when it comes to meetings)

There’s nothing worse than a badly run meeting, except a badly booked meeting, or a badly behaved meeting attendee. Read this page, internalise its meanderings and never again be responsible for a bad meeting.

Introduction

There are few things that annoy like a badly run meeting. They’re to blame for many of the world’s ills, not least of all, being the sole reason why many people feel like they never get anything done. Because they’re always stuck in meetings, or feel like meetings aren’t a valuable use of their time. This document will help. You’ll look at meetings in a different way and, hopefully, encourage others to as well. We’ll look at how to book meetings first, as this is the most important step. After that, we’ll look at your responsibilities as an attendee. Finally, we’ll close with some tips and tricks on how to get the most out of meetings.

Booking a meeting

It seems like this would be an easy thing to do, right? But take a look at your calendar now, go on, I’ll wait. I bet there are at least two or three meetings with obscure, ambiguous titles, that you’ve agreed to attend. Perhaps one or two that you’ve agreed to, but aren’t quite sure what they’re about right? There are also probably a couple that are back-to-back (one ends and another starts immediately).

Maybe you’ve booked meetings that look like these too? It’s OK, without proper training, you’ll just book meetings the same way your boss or peers do, but let’s change this now. Let’s look at how to book a proper meeting.

The key thing to remember when booking a meeting, is that it is your meeting. It is your responsibility for all attendees to get the most out of the allotted time to reduce the need to follow it up with another meeting about the first meeting later.

Purpose

What are you booking the meeting for? There are a few reasons that you might want to take time out of your colleagues day to go sit in a room with them, some of them are worth it, some, not so much. If, for example, this is just a status meeting, then do you really need to meet at all? Is there a better way of transferring this information to you? Perhaps you can do it in an email? Perhaps you could bookend another meeting with this kind of stuff? There are plenty of online tools that allow you to gather status information from your team without having to sit together. Is it a discussion? A brainstorm? A workshop? The type of meeting will dictate just how you book it and who should be there.

A proper title

First things first, what do we call the meeting? Give it a decent description, something that gives the invitees a good understanding of what the meeting is about. “Meeting about stuff” is no good, “Quick catchup” is no better. You want to get the purpose of the meeting across succinctly. Try “Quick catchup about marketing goals” or “Meeting about the service agreement”. Instantly, the recipients of your request will understand what it is the meeting is about.

You don’t have to be overly verbose – there’s a description field for more information, but you want the attendees to be able to glance at their calendar and mentally prepare for what’s next.

Outcome, agenda, requirements and follow-up

Most of the failure of good meeting booking comes from not paying any attention to the agenda or outcome.

Outcome

When booking a meeting, think to yourself “What do I want to have, or know, by the end of this meeting?” is it a decision? A document? An agreement? Put this in the meeting description so that the attendees know exactly why the meeting is necessary, eg:

Outcome: A decision on where we spend this month’s advertising budget.
Outcome: A rough draft of a document, detailing the next steps for building the service.
Outcome: Rough designs for the new mobile app.
Outcome: A plan for this week’s work for each team member.
Outcome: Agreement on: a) What to do with Bobs cat, b) When to apply for the licence and c) What to have for lunch on Friday.
With a clear outcome, attendees will understand the purpose of the meeting that much better.

Agenda

Put down, in writing, how you expect the meeting to go. It doesn’t matter so much if your agenda isn’t adhered to, the most important thing is you achieve the outcome you set out to achieve. If the agenda goes awry, that’s fine. That said, it’s useful to HAVE an agenda, so attendees know what to expect. It’s also useful if your meeting will cover several different topics. You don’t necessarily need to put timings for each part of the agenda, but if it helps to keep you on track, then do so. eg:

0 – 2mins: Introduction
2 – 10mins: Outline of current marketing spend
10 – 30: Brainstorm potential avenues for exploration
30 – 50: Voting and discussion on top three
50 – 55: Wrap up and actions.

Requirements

Depending on the type of meeting you’re having, you may have some requirements of the attendees. Perhaps they’ll need to read a report, or view a video or even just spend some time jotting down a few notes about what the meeting is about. Give people advance warning of what they may need to prepare for. If there are some documents required, then attach them to the meeting request (you can even do this with Google Calendar, you just need to enable a labs setting). Make sure attendees know:

Folks, before you come to the meeting, it’ll be a good idea to review the current state of the marketing budget/system architecture/world. I’ve attached a document that you should review before coming and make some notes on how you think we might proceed.

Follow-up

Finally, let people know what you will do after the meeting. Whatever the outcome, the very least you should do is email all the attendees, thanking them for the time and outlining the key points of the meetings and any actions that were decided (you were taking notes, right?). That way, there is no ambiguity on who said they’d do what or by when and it gives people a chance to sanity-check their understanding with yours.

After the meeting, I’ll forward the document we wrote and outline the next steps. Any actions for attendees will also be detailed in the email.

Attendees will appreciate you making notes for them.

Meeting Length

How long should a meeting be? Use your agenda and the number of attendees as a rough guide. The more agenda points and the more attendees you have, the longer your meeting will be. Use the timing to your advantage. If you want to get a decision quickly, then book a shorter meeting. If you feel like the topic would benefit from some longer discussion, then book a longer meeting. Pay attention to the people you are inviting to your meeting? Are they pretty busy? Look at their calendar and see what their day is like, they’ll probably appreciate a shorter meeting if they’ve got a busy day.

Shorter meetings are also useful for quelling useless chit-chat and clowning (unless you’re in engineering, there’s always clowning). All attendees, no matter how busy, will appreciate spending less time in a meeting room.

One thing to note, is that Google Calendar allows you to book meetings that end earlier than 60/30 etc minutes. This gives attendees a few minutes to get to their next meeting, which is very useful if they’ve got a meeting following yours.

Remember, when the outcome of the meeting has been achieved. End it. Let people disperse, if you want to carry on talking, you can, but make it clear that the purpose of the meeting has been achieved and people are free to go.

Attendees

Who should you invite? Only you will know that, but if you’re not sure, make people optional and let them know, add a note to the bottom of the description:

(Bob, I’ve made you optional, you might have an opinion on this, but your attendance isn’t required. I’ll send around meeting notes and the achieved outcome afterwards either way).

Think about your attendee list and ensure you’re mindful of the fact that people are busy.

Attending a meeting

Hey, look at that! You’ve been invited to a meeting! Aren’t you the popular one! Your responsibility for being a good meeting attendee starts well before the meeting, in fact, it starts the moment you get the meeting request.

Responding to a meeting

So, you’ve been invited to a meeting. What should you do? Well, I’ll tell you what you shouldn’t do first, you shouldn’t hit “accept”, not yet anyway. How do you know you’ll get any value out of the meeting? How do you know you’ve not been the victim of a meeting muppet and just been invited willy nilly because they like the smell of your aftershave, or the way you wear your hat? You don’t, so, pay a little attention to the invite.

Ideally, the person booking the meeting has followed the details above, if they have, it will be fairly simple to decide whether or not to go, ask yourself the following questions:

Do I need to be there, or can I just send in some information by email.
Do I need to attend in person, or can I dial in remotely?
Is there someone else going who would be able to represent me?
If you’re not sure on anything, or the person booking the meeting hasn’t given an agenda or outcome, then you can reply to the meeting request and ask for more information before deciding on whether or not to go. If you think you should go, but require more information, then again, email – ask for clarification or further documentation! Don’t just go because you’ve been invited! It’s not rude to ask for more information.

The rule of thumb is, if you feel like you can provide no value, or if you will get no value from the meeting, then feel free to decline it. The onus is on the person booking the meeting to give you a compelling reason to come.

Finally, respond AS SOON AS YOU CAN. Declining a meeting five minutes before it’s due to start is, frankly, badly behaved.

Being a meeting attendee

You’ve decide to go. You’ve turned up on time, prepared, with a pen and everything, what now?

Stick to the agenda, pay attention, be present.

Remember, it’s not your meeting, you are there to help the person who booked the meeting achieve the outcome they need. If you feel like the agenda isn’t useful as you proceed through the meeting, then suggest you change it – but don’t hijack the meeting and don’t switch off. You are partly responsible for the successful outcome.

Other than that, being an attendee just requires you pay attention and get involved. If you’re in the meeting, you’ve already decided it has some value in you being there, so behave like that. There are a few guidelines that, while they shouldn’t need to be said, I’ll say anyone. Meeting etiquette is just about not being a dick:

  • Mobile phones: No, just … no. Leave it in your pocket on silent.
  • Laptops: maybe. If they’re needed for the meeting, or you’re taking notes, but ask the room “Does anyone mind if I take notes on my laptop?” This will both ensure everyone knows you’re not managing your fantasy football team in the meeting, but you’re taking notes and also means your notes could be shared with others.
  • Turn up on time. You said “yes” to the meeting. Be punctual, it shows respect. If you want to get a coffee, then get it in good time. Leaving your desk at 10:59 to get a coffee for an 11am meeting is a muppet move. If you’re going to be late, let them attendees know and an ETA of your arrival time, it allows others to potentially delay the meeting by a few minutes so you can fully take part.

After the meeting

If you don’t receive an email from the organiser, send one to all attendees, thanking them for their time and outlining the actions as you know them. People will appreciate the reminder.

Conclusion

Meeting etiquette is not rocket science. Be polite, thoughtful, courteous and respectful. These people are your peers, often your friends and always your colleagues. Treat them the way you would expect to be treated and you won’t go far wrong.

Got any other tips for meetings? Leave them in the comments below!

I’ve forgotten how to play guitar … again.

I’ve forgotten how to play guitar … again.

I’ve had a guitar since I was in my early teens (before that, a cello, which my mother had to walk to and from school with, because it was too big for me to carry). During my late teens and early 20s, I was pretty good at it – not band good, but I could make it do what I want and I enjoyed playing it. The trouble is, I’d stop playing for weeks, sometimes months and then forget my chords, notes and the songs I’d learned and have to re-learn everything.

This happened again recently – my son has started guitar lessons and this piqued my interest as I twanged away on his 3/4 size classical, so I got mine out, replaced the strings and … blanked. I’d forgotten most of the stuff (again). I can remember Knockin’ on Heavens door, but that’s about it.

I’ve had to relearn everything again and this got me thinking. It’s like a analogous  to most other things in my life, if I don’t do them regularly, I forgot how. Like playing board games, setting up symfony2 or running a retrospective. I have the idea that I can do it, as I have done it in the past, but the doing it eludes me until I’ve spent some time with it.

So, remember to practise things, even if it’s not daily – keep your hand in the game and work out your muscle memory. It’s a pain having to relearn everything (even if it does take less time), especially we you can be learning new stuff, instead of relearning old stuff.