Digital Detox

I read Documentally’s news blog post with a twinge of jealousy today: Rebalancing my relationship with technology. I’d read about the Punkt phone in his newsletter (which you should subscribe to, it’s very good) and my mouse pointer hovered over the buy button the Punkt website…

I would love to do this, but some things stop me. £230 is a lot for a ‘dumb’ phone, when the OnePlus 3 (which I own) is £329 and the OnePlus 2 is £239, sure I could use an old Nokia like Christian suggests, but where’s the fun in that? New tech drives me to try new things. But this is new tech driving me to do … nothing. Well, it’s not really “nothing” it’s just something else. Look at trees, skies, plants, be engaged in the moment. Be engaged in the people around me. Be engaged.

Mostly all of my communications during the day are text based. The only people I actually speak to on my phone are my mum and, occasionally, my wife (I don’t mean I only occasionally speak to my wife, just that we WhatsApp mostly and the odd call for clarity or high bandwidth). Most communication is fairly brief “Check this out: [youtubeurl]”, “See you later”, “Can you forward me the thing we spoke about?”.

Some of it is international – I work with a team in India, there’s a lot of text-based comms (email, slack) but also a daily chat.

So, without buying a Punkt (or resorting to an old Nokia) can I digital detox? Can I commit to only using the data functions of my phone when on the wifi?

Would it really hurt to call people more? Maybe I’ll enjoy it.

 

#offBoarding (or #alighting)

#offBoarding (or #alighting)

There’s lots of talk about Onboarding. Wikipedia sez:

Onboarding, also known as organizational socialization, refers to the mechanism through which new employees acquire the necessary knowledge, skills, and behaviors to become effective organizational members and insiders.

I love this idea that carefully curating and designing a process for new starters to get up-to-speed and be better integrated into your company can bring nothing but sunshine and unicorns, create better bonds, lower attrition and more engaged staff.

But what about when someone leaves? It’s usually a short process: leave is negotiated in private (either a jump or a push), it’s communicated to the wider team, some handover, perhaps there’s an exit interview, “clean out your desk”, eat a bit of cake, say goodbye down the pub and Mondays aren’t the same every again.

For everyone else in the company.

The leaver will be enjoying the delights of the next company and their onboarding process, but the people at the old company? Mourning the loss of an ally, a compatriot a peer.

And this is where I wonder whether we shouldn’t be paying more attention to the people around the leaver as they work out their notice period. There are thought processes:

The leaver was happy, weren’t they? Why would they choose to leave? Maybe I should leave? Is it better elsewhere

Or maybe

Why were they sacked? Could I be sacked? Maybe I should look for another job?

Or even

Who is going to do their job? Am I doing it now? How will I know I like the new person? Will we get on? Will they be able to do everything the leaver can do?

These thoughts all lead to a risk that those around the leaver, the peers (and perhaps the reports) will be feeling adrift, unsure, unsteady, things have changed and it’s resulted in someone I like/respect/admire/fear not being a such a big part of my life anymore.

I feel like we need to account for this somehow. To have a process of offboarding for the people around the team member – make sure they understand why the leaver is leaving, what that means for the future of the team, how they might use this upheaval, this change as an opportunity for improvement, or promotion or simply to realign themselves with their team, their company and their career. Use somebody leaving as a positive thing to promote … something good. My thoughts here aren’t clear and I believe that whatever the process is, it’s probably going to be specific to your company anyway.

(Hat Tip to @nefarioustim for the #alighting alternative)

Interviews

Interviews

I prefer interviews that are a conversation as opposed to me asking questions and listening to answers. I want the candidate to engage with me like they would a colleague – it shows they’re taking the process seriously and are interviewing me just as much as I am interviewing them. I love it when I leave an interview thinking “I really want them to work here, I hope we impressed them enough!”.

What I want to know about a candidate is what experiences have they had before and how they dealt with them. I want to hear about real world examples. Questions will usually take the form of “Tell me about a time that X, what did you do?”

“X” could be:

  • you had a difficult team member.
  • you had a ridiculous deadline.
  • you had some tough politics.
  • you worked with remote stakeholders.
  • things really went bad.
  • thing went really well for you and the team.
  • Etc…

Usually these will be a conversation rather than a question/answer session, but still based on the candidates actual experience as opposed to “What would you do if?”. However, it’s OK to say “Actually, I’ve never had to deal with that, but if I did, I would …”

I also want to know about actual projects themselves as I’ll be trying to get a feel for team/project size, the position of influence the candidate felt they had within the team. The language people use is important – are they talking about they/them or we/us?

I’m looking for PM style – are they command and control, or servant leader? Or somewhere in between? The language they use is as important here as the actions they took. Do they use people’s names from previous projects, or just “the developer” this is telling, although not conclusive.

Finally, I’m looking for evidence of autonomy and mastery. I want the successful candidate to be someone I can point at a problem and they’ll get on and deal with with little interaction from me.

Should you have a set number of acceptance criteria?

Should you have a set number of acceptance criteria?

A conversation came up today in which a statement was made about having a set number (three, in this case) of acceptance criteria per user story. My gut reaction was that I didn’t agree, how can you define that? But then I got to thinking that maybe it wasn’t such a bad idea.

I turned to the internet and asked twitter, the replies were heartening.

I agree with these replies, however, I’m not convinced on having a fixed arbitrary limit. I think it’s a case of being vigilant and for someone to say “Hey, that’s a lot of A/C, maybe we should split this?”

It’s also relatively simple to avoid the limit by loopholes. For example, your A/C could be described as Given, When, Then. In this, you could add “and then … and then… and then…”. It’s still one A/C, but has multiple steps.

As with everything in the world of building software, it’s about balance and discipline.

A great retrospective!

A great retrospective!

I’ve blogged before about remote teams where I am now and how well we manage to make it work, even with people in another timezone. Because we’ve got people remote, our retrospectives are, naturally, done over video chat (hangouts in our case) and we use webwhiteboard (by none other than Henrik Kniberg!) to make it as interactive as possible.

Today, we had just such a meeting and I really wanted to show you the output. Nothing much to learn from this post (except how we retro), but I thought the webwhiteboard worth sharing – just for fun.

Selection_003

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.