Sprint Goals, Backlogs & Star Trek

I’ve recently been working with a number of scrum teams, across a few different organisations, and I’ve started to notice a bit of a trend with regards to agile practices dropping by the wayside. Now, this might be a sweeping generalisation, but I’m noticing something of a correlation between Scrum teams who are struggling, and the “disappearance” of Sprint Goals and Backlog Grooming. Even with ScrumMasters around, these 2 practices seem to be the first to bite the bullet, which makes me wonder if their importance is not as well understood as it could be…

Red Shirts
If Scrum “good practices” were an episode of Star Trek, I imagine Stand-Ups would be Captain James Tiberius Kirk, Retrospectives would be Spock, Sprint Planning would be Scotty, and so on until we’ve covered all of the main characters & characteristics. Now let’s imagine the crew of the enterprise are assembling a landing party, to investigate a strange new world, home to as-yet unknown and possibly hostile alien life forms. The usual suspects are on the holodeck waiting to be beamed down, along with one new lower-ranking character wearing a red shirt – yes, say hello to the Sprint Goal.
If you’re not familiar with the whole “red shirt” thing with Star Trek, it goes a bit like this – in the original Star Trek series, whenever the crew beamed down to a hostile planet, they were seemingly always accompanied by a lower-ranking disposable crewman wearing a red shirt, who would promptly die in some sort of fight with an alien life form. It was always the red shirted guy. If you’re interested and fancy a bit of a giggle, this website actually contains a statistical breakdown of how likely a “redshirt” is to die. Brilliant stuff.

Sprint Goals - The Agile Red Shirts

Sprint Goals – The Agile Red Shirts

Anyway, back to the Sprint Goal – it appears that rather like the redshirt, when the going gets tough, the Sprint Goal appears to be the first one to cop it. This isn’t wholly surprising, because the Sprint Goal doesn’t scream “I’M IMPORTANT AND DELIVER VALUE” in quite the same way as stand ups and retrospectives do. But they are important and they do deliver value. Sprint Goals are rather like acceptance Criteria, in that they ensure that we are doing the right thing. Bear with me on this…

  • Any project or product will have an objective
  • The objectives get transformed into a plan
  • The plan gets split up into milestones and iterations
  • The milestones and iterations are made up of sprints
  • The sprints contain numerous stories

Hopefully this little list will help to demonstrate how detatched a story can be from the original objective. Sprint Goals are a way of making sure our stories are all aligned with our project or product’s objectives, and not just a collection of seemingly misaligned tasks.

If we just start plugging away at stories without having a goal or objective in mind, then we’re not really giving ourselves the right amount of context to make the best decisions.
I sometimes see this issue more clearly on so-called “self-organising” teams, where everyone seems to be sprinting, but not necessarily in the same direction. Deciding on a Sprint Goal before your spint starts is a great way to ensure that everyone is collectively sprinting in the right direction.

We're all sprinting, just not in the same direction...

We’re all sprinting, just not in the same direction…

Sometimes people tell me that it’s really hard to define one single sprint goal for their sprint, and so they don’t bother with one at all. In this instance I would recommend setting more than one sprint goal! Working towards 2 or even 3 complimentary targets is surely better than not working towards one at all.

This feels a lot better...

This feels a lot better…

Backlog grooming is the other practice that I see slipping. I’ve even seen a few teams who just stop doing it altogether. By backlog grooming I mean making sure the backlog is relevant and up-to-date, and that the upcoming stories are of an acceptable standard.
When backlog grooming starts to deteriorate I see scrum teams really struggling. Firstly they struggle to get through planning because the stories are not broken down or thought-through sufficiently. Secondly they struggle to work on the stories because they aren’t of an acceptable standard, thirdly they get interrupted with re-work from the previous sprint (because the stories were unclear and so they built the wrong thing), and fourthly the backlog becomes a big scary mess of out-of-date stories and only the Product Owner knows if they’re still relevant or not.
As you can probably see, failure to properly do backlog grooming can seriously impact a team’s ability to deliver high quality solutions on time. This is why backlog grooming is so important.
So what can you do if you see backlog grooming slipping? It’s easy to say “Just make sure it gets done”, but that just doesn’t work. I’ve also seen senior managers forcing stories into a sprint knowing full well that the stories weren’t of an acceptable standard. The result is the same, stories that are unfit for consumption.
If this situation sounds at all familiar, I recommend adopting a more disciplined approach to accepting stories into a sprint – this is your first layer of protection against poor-quality stories. I encourage the use of the INVEST principle (or rather the NEST principle – I’m not too bothered about the I, and the V).

If you’re not already familiar, here’s what INVEST stands for:

  • I is for Independent, meaning each story should not have to rely heavily on any others. I ignore this one simply for a happier life
  • N is for Negotiable, but I like to think it just stands for Now Go And Talk To Someone, because I like to use it to remind people that a story is the starting point for a conversation, not a massive requirements document!
  • V is for Valuable. This one’s straightforward, but for me a bit superfluous. If a story isn’t valuable then what’s it doing on the backlog on the first place?
  • E is for Estimable. If the story is impossible to estimate to any degree of confidence then it’s too risky and needs breaking down or time-boxing.
  • S means Small. Sort of related to Estimable. But if a story is too large then that should set off alarm bells. Smaller is better when it comes to stories.
  • T stands for Testable. Yup, I’m afraid we’re going to have to think about how we’re going to test the story!!

You could try to make sure that your backlog is split up into 2 pots of stories, those that have been INVESTed (or NESTed, if you’re more like me) and those that haven’t. Be clear that you can only accept stories from the NESTed pot. If you find yourself in this situation and you’ve adopted the NESTed approach, then let me know how it goes!

Advertisements

On DevOps in Distributed Teams…

Working remotely is so common these days, that I’d say the vast majority of organisations I work with today accommodate some degree of remote working. I think it’s great that organisations are prepared to do this for the sake of their employees –  it shows an awareness of that so-called “work-life balance” that so many of us have managed to get wrong in the past.

It’s perhaps not surprising then, that when I speak to people about the importance of culture and collaboration as essential ingredients in any devops or agile transformation, people become concerned about how compatible this is with their working-from-home policy and globally distributed teams.

Unfortunately I’d say there’s no straight answer. As with most things in DevOps, it depends on many factors. We all love a good list, so here’s my list of things that can impact your DevOps journey if you’re working with distributed teams and remote workers:

  • Team maturity (is there strong trust within the team?)
  • Decision making (how effective are you at decision making?)
  • Location (do your working days overlap much?)
  • Language (do you all speak and understand the same language effectively?)
  • Collaboration (It’s not the same as communication)
  • Management techniques (are you a command and control freak?)
  • Tooling (are you on mute?)

Bearing these factors in mind, let’s take a look at what makes an effective distributed team (in my humble opinion, of course).

High Trust

High trust between individuals in the team means people are comfortable allowing others to work autonomously, safe in the knowledge that they will deliver what they committed to. High trust also means you’ll feel comfortable asking for help when you need it. In high-trust teams, a daily stand-up is usually sufficiant for a Team Lead (Scrum Master, PM, PO, or whoever) to feel comfortable and confident that the individuals can be left to get their work done. This is not to say that they will work alone, far from it, to do DevOps successfully you absolutely MUST collaborate and work together effectively throughout the day, but crucially they don’t need a Team Lead to continually check in on them to make sure they’re doing the right things.

Devolved Decision Making

Responsibility, accountability, empowerment – all of these are high-scoring bullshit bingo words, but they’re also important factors in effective decision making. Give team members the power to make decisions without having to summon a committee meeting and things will run much more smoothly. If this idea scares you, then mitigate the perceived risk by ensuring all decisions are retrospectively reviewed – doing this allows people to go ahead and get on with their work but it also allows you to catch any bad decisions before it’s too late. When it comes to decision making within the team, my policy is to seek forgiveness, not permission. Of course, there’s a boundary within which we all need to work when it comes to decision making, and decisions around features etc should always be made by the Product Owner, but we all knew that, right? Obviously I’m not suggesting that individuals should unilaterally decide to change the language the product is coded in, or introduce a new feature – common sense still has a large role to play!

Location

Most of the successful distributed teams I’ve been involved with have had a significant amount of overlap in terms of the hours worked by the individuals. The least successful teams have had very little overlap in working hours. If you work in the UK and you have significant parts of your team in places such as the US West Coast, Australia, China or Japan then you’ve probably already felt the frustration of having to wait an entire working day for an answer or response from a colleague, only to find that it wasn’t what you needed. In the fast-paced IT world of today, many of us can ill afford that sort of delay, so teams have worked out new ways of dealing with the challenge, such as working different shifts, dialling in to meetings at unsociable hours and so on. It’s often not an ideal solution but if it helps the team work more effectively while allowing you to continue to enjoy a comfortable and convenient working lifestyle then it’s probably worth the effort.

In a DevOps environment you’ll want to make sure that there’s as much overlap as possible between your developers and infrastructure engineers – these are the roles that need to collaborate most closely, so an environment where ALL your devs are in one location and ALL of your infrastructure team are the other side of the world is going to be a real challenge.

Language

Ok, I’ll be blunt – you all need to speak the same language, and you need to do it well. We all know it’s hard work trying to communicate with people who don’t fluently speak the same language as you, and in the end you just end up making excuses for not communicating with them (and that’s a bad thing). It’s high-time we all agreed to speak 1 global business language, and that language should be Welsh (because it’s by far the most awesome language in the world).

Collaboration

For me collaboration is about people working together in an effort to build something mutually beneficial. It’s not the same as communication. Collaboration means you need to be able to listen to other people, make appropriate changes, help others, coach people and share ideas. Tools like GitHub (along with the Git workflows) are great for allowing us to collaborate when working on code. Teams with good collaboration techniques and processes (code reviews, retrospectives, workshops etc) tend to become higher trust teams as well. I haven’t stopped to think why this happens, but it’s an observation. These teams handle distributed working easily because they have such a high degree of interaction anyway, that location becomes insignificant. In a successful DevOps environment both developers and infrastructure engineers will collaborate and use techniques such as pairing and code reviews to learn from each other and improve.

Management Techniques

Again we’re looking at high-trust teams. Teams where management are happy to give the individuals the space and time to work are more effective than teams with managers who feel the need to constantly check in on them. In my experience the best style of management to work with a distributed team is one of high-trust and devolved responsibility – one where management provide guidance and support rather than instructions. If you see yourself as a command-and-control style manager or obsessed with micro-managing individuals then you’re probably going to struggle working with a distributed team.

Tooling

There’s loads of tooling out there to help people work remotely. Most people are already using things like Slack, HipChat and Skype because they are such effective communication tools – but communication is only part of the picture. As I mentioned earlier, GitHub is a great collaboration tool for anyone involved in coding (so devs and ops alike), but we also often need to share large binaries (such as PDFs, Presentations, diagrams, pictures  and so on) which don’t usually belong in source control alongside your code. For these types of artifacts tooling like Google Drive and Dropbox are great (as long as your corporate security policy will allow you to use them). I like the latest Atlassian tools for managing requirements and handling wikis because the real-time updates work really well with people working remotely, but in terms of sheer simplicity and ease of use, you can’t look any further than Trello for task management! I’ve seen IdeaBoardz being used very effectively for brainstorming and sharing ideas across a distributed team – like Trello it’s a really easy-to-use and fun collaboration tool.

So, in summary, doing DevOps in a distributed team can be an absolute doddle or it can leave you dead in the water – it all depends on how mature your team is, what sort of management you have, the tooling available to you, the communication skills of the individuals, and your team culture.

Keep CALMS and do DevOps!

In order for any sort of process, framework or methodology to succeed in the IT world, it absolutely must involve a large number of acronyms. And devops is no different. In the devops world we like to say that there are five underlying principles of devops, and they’re represented by the acronym CALMS. As with any good IT acronym, you start with the acronym itself and then work backwards from there. The main reason why the CALMS word was chosen for the devops world was because of the unlimited marketing oportunities it offers. For instance, you could use the “Keep CALMS and carry on” slogan and plaster it all over anything that you can actually print onto, like T-Shirts, mugs, foreheads, powerpoint presentations etc and so forth.

img_20150624_131537_720 keep-calms-and-do-devops img_20150623_154452_360

CLAMS?
The next trick was to work out what the CALMS should stand for. This was the hard part, and required the input of some of the smartest minds in the devops world to come together and use their collective brainpower to think of some devops words that would conveniently fit the CALMS acronym. So, in May 2013 or something (lets say), some people with names like Gene, John, Jeremy, David, John and Adrian all got together at the top of a mountain in North Wales and meditated on the CALMS acronym. That didn’t work, so they all got really drunk and that’s when they came up with what we now know as the five pillars of devops:

C and S stand for Cats on Skateboards
As everyone knows, the vast majority of the internet is made up of billions of pictures or videos of skateboarding cats. That’s why the internet is so big (and that’s also where the term “BigData” comes from). Devops is all about deploying pictures of skateboarding cats to the internet, in order to satisfy the world’s seeemingly endless desire for more and more pictures of kittens doing cute things. The better you arer at deploying skateboarding cats, the better you are at devops. Simple as that.

cat-on-skateboard

A stands for Agile
Devops was invented because sysadmins felt they were missing out on the whole agile party. So devops is just agile plus sysadmins. AMIRITE?

2848324491_b1d8eff41f

L stands for Letters
Acronyms are nothing without letters. Letters are very much the key ingredient of a good acronym. The trouble with acronyms though is that the letters don’t always lend themselves to a word that’s relevant to your topic. One way around this is to think of a world beginning with that troublesome letter, let’s take the letter L for example, and let’s randomly pick the word “Lean”, and then simply write a book which demonstrates how “Lean” is actually quite relevant and applicable to the topic of devops. It’s a clever one this, because you can then use it to help flog copies of your book.

potd-cat-black_2798668k

M stands for Money
Doing devops will make you rich beyond your wildest dreams. A recent survey has discovered that firms with high performing IT functions are less likely to suck ass than one’s with crappy IT teams. It only takes a medium sized leap of faith to believe that this has anything to do with devops. So it’s crystal clear then – doing devops means your organisation will outperform your competitors and we’ll all be sipping cocktails on a beach somewhere by this time next week.

3552926886_47c2e4d1b3

So what are you waiting for? Go deploy those skateboarding cats and I’ll see you on the beach!

Upcoming DevOps & Agile Events

London Puppet User Group Meetup
London, Thursday May 21st, 2015
6:00pm
http://goo.gl/C2zuKb

DevOps Exchange London – DevOps & DevOps
London, Tuesday May 26th, 2015
6:30pm
http://goo.gl/Xmdqxl

London Agile Discussion Group – Should DevOps be a person or a team-wide skill?
London, Tuesday May 26th, 2015
6:30pm
http://goo.gl/xksVOH

AWS User Group UK – meetup #15
London, Wed May 27th, 2015
6:30pm
http://goo.gl/uBsiUj

Chef Users London – Microsoft Azure / Chef Taster Day
London, Friday May 29, 2015
9:00am to 5:00pm
http://goo.gl/VOvkC3

DevOps Cardiff – Herding ELKs with consul.io
Cardiff, Wednesday, June 3, 2015
6:30pm
http://goo.gl/WwOvkQ

Agile Testing – Visual Creativity: Using Sketchnotes & Mindmaps to aid testing @ #ltgworkshops
London, Thursday June 4th, 2015
8:30am
http://goo.gl/34iIXM

ABC (Agile Book Club) London – Review Jeff Patton’s User Story Mapping
London, Thursday June 4th, 2015
6:30pm
http://goo.gl/X0qPwb

Agile Testing – Hooking Docker Into Selenium @ #ltgworkshops
London, Thursday June 4th, 2015
8:30am
http://goo.gl/ONH8dQ

UK Azure User Group – Cloud Gaming Hackathon
London, Saturday June 6th, 2015
9:30am
http://goo.gl/ONH8dQ

London DevOps – London DevOps Meetup #10
London, Thursday June 11th, 2015
7:00pm
http://goo.gl/uolxJk

Kanban Coaching Exchange – Continuous learning through communities of practice – Emily Webber
London, Thursday June 11th, 2015
6:30pm
http://goo.gl/9aFD8x

Lean Agile Manchester
Manchester, Wednesday June 17th, 2015
6:30pm
http://goo.gl/Z15ac3

London Lean Coffee – Holborn
London, Thursday, June 18th, 2015
9-10am
http://goo.gl/QkIBhj

UK Azure User Group – Chris Risner
London, Thursday June 18th, 2015
7:00pm
http://goo.gl/EfbNnn

Jenkins User Conference – Europe (London)
London, Tuesday June 23rd – 24th, 2015
2 days
http://goo.gl/achJJX

BDD London June Meetup
London, Thursday June 25th, 2015
6:30pm
http://goo.gl/C2zuKb

Automated Database Deployment (Workshop – £300)
Belfast, Northern Ireland, Friday June 26th, 2015
1 day course
http://goo.gl/fXlJr7

Database Continuous Integration (Workshop – £300)
London, July 8th, 2015
1 day course
http://goo.gl/lW4TjA

Database Source Control (Workshop – £100)
London, July 8th, 2015
1 day course
http://goo.gl/C2zuKb

London Lean Coffee – Holborn
London, Thursday, July 16, 2015
9-10am
http://goo.gl/mtJ3k4

Agile Taster – a free introductory Agile training course
Cardiff, Saturday 18 July 2015
10am – 3pm
http://goo.gl/qFYS6b

AWS User Group UK – meetup #16
London, Wed July 22nd, 2015
6:30pm
http://goo.gl/Tc3hlD

What does devops have to do with agile?

One of the questions I commonly get asked at the workshops we run is “What’s the connection between Agile and Devops?” or vice-versa. My usual tactic is to let the workshop attendees argue that one out amongst themselves. Firstly, because it’s quite an emotive question, so it gets people chatting, and secondly because I’m always keen to hear what other people’s opinions and experiences are.

Here are a few of the things I’ve heard from the workshop groups:

  • “Devops is an evolution of Agile”
  • “Devops is the missing link between agile development and operations”
  • “Devops is a subset of Agile”
  • “Agile is a subset of Devops”
  • “What time are we having lunch?”

I’ve heard strong arguments in support of each one, and I’ve also heard people say there is no link between agile and devops (again, with a strong argument to support this opinion).

For me though, I like to think of devops and agile as complimentary. I also think devops is a key enabler for enterprise agility, and this is where things get a little murky. I don’t want to get into any great yak shaving exercise, but before we can describe the relationship between agile and devops, we really need to define what we mean by “agile”.

Agile development vs Organisational Agility

Agile development comes with many different frameworks, some more prescriptive than others, but they all share a certain number of core “agile“ features in common – namely that they embrace change, and are able to comfortably respond to it (ok there are plenty of other features in common, such as focus on customer value and working software etc, but I’m going to concentrate on the responsiveness to change for now).

The agile manifesto "values"

The agile manifesto “values”

 

Scrum, on the other hand, is a framework for helping you do agile software development, it has clearly defined team roles and a few rules you need to follow. But let’s be clear – Scrum is NOT agile. Don’t confuse the two!

Scrum is a framework for helping you do agile software development, doing agile software development helps you become agile

Now let’s take a deeper look in to what being “agile” is all about. It’s about being able to respond to changing conditions, changing market forces, changing requirements, and not only survive, but to succeed. “Change” is the arena in which agility thrives. So, to be agile you need to be able to react and respond to changes quickly. This is where the agile world and devops come together. Devops encourages closer and more meaningful collaboration between the business, development and operations, to help organisations deliver higher quality applications that can be deployed quicker, be maintained and monitored more easily, and provide fast and accurate feedback to the business. Without these key enablers, you’d be hard pressed to respond or react quickly to anything, let alone changing requirements, changing markets and changing technologies.

So in a nutshell, agility is all about the ability to embrace change, and succeed in a changing environment. Devops is one of the key ingredients to helping you achieve this.

Can you do agile software development without doing devops? Yes, of course you can, you could do Scrum, for example. But doing agile software development and being agile are two very different things.

So, now for the harder question: Can you “be agile” without doing devops?

Some might argue that this must be possible, because organisations have been agile for longer than devops has been around – to which I would respond by saying that the term “devops” may be relatively new, but the ethos behind it has been around for as long as agile has.

I imagine that under certain circumstances it may be possible to be highly agile and yet have an anti-devops culture, where there’s very little collaboration between the business, development and operations, but I’ve not actually come across it, if it does exist. In my experience, highly agile organisations from start-ups through to large enterprises, are embracing the principles behind devops whether they know it or not.

In summary, agile is NOT about sprints, it’s NOT bout stand-ups, it’s NOT about retrospectives or any of the following:

  • Velocity
  • Points
  • Planning
  • Stories
  • TDD
  • BDD
  • Automation
  • Demos

You can’t do agile, you can be agile, but you can’t DO it. You can “do” scrum, XP, Devops, TDD, BDD etc – these are explicit activities, unlike agile, which is more of a set of values and principles. You can perform all of the individual activities listed above, independently of any other. Sure, they certainly complement each other, but they can be done separately. The same can be said of agile software development and devops.

The relationship between devops and organisational agility is that one is an enabler for the other. The relationship between devops and Scrum, for example, is simply that they are both enablers for organisational agility, but they can also exist independently of each other.

Continuous Improvement – 10 Ways to Help Your Team Learn (plus 6 more)

Not long ago I went to one of the Agile Coaching Exchange’s meetups in the lovely asos offices in London. Speaker for the night was none other than Rachel Davies who I worked with about a decade ago when she was a freelance agile coach. My god that decade has gone quickly. Anyway, her talk was about the techniques that they use at unruly to encourage learning in the workplace, and as you’d expect, it was really interesting stuff. So, I decided to take some notes and even give some of her ideas a go. Here’s what happened:

Learning Techniques

At one point Rachel asked us, the unsuspecting audience, to come up with a list of different learning techniques we’ve used in the workplace. It was a trap. No matter how many I thought we’d covered off, we were nowhere near the list that Rachel came up with. Basically we’re just not as cool as those kids over at Unruly, that’s what I learned. Anyway, keen to learn more about learning (woah, Learning Inception!) I decided to list the learning techniques I liked the sound of, and I’ve added a bunch of others that hopefully you’ll like the sound of as well (because, you know, lists are way cool):

  1. Workshops
  2. Attending meetups
  3. Pairing
  4. Retrospectives
  5. Mobbing
  6. Hackdays
  7. Devdays
  8. 20% Time
  9. Tech Talks
  10. Book clubs
  11. Coding Dojos
  12. Team Swaps
  13. Rotation
  14. Tech Academy
  15. Blogs
  16. Conferences

Workshops – I use these a lot in my work. I mostly try to keep them hands-on, encouraging the attendees to physically get involved. If I was any good at marketing I would probably describe them as “Interactive”. If necessary, I’ll use hand-outs, but I’ll never just stand there talking through a bunch of slides – that’s seriously uncool and you’ll never get into the Secret Inner Sanctum of the Workshop Magic Circle if you do that. The objective is for the attendees to be actively involved in the workshop, rather than to simply be an observer. I run workshops on Agile Product Ownership, Kanban, Flow (Theory of Constraints), and Sprint Planning & Estimating. Remember, using the term “Workshop” isn’t just a way of making a 4 hour meeting sound more interesting 🙂

Attending Meetups is not only a great way of learning from whatever the speakers are talking about, but also from chatting with the other people at the meetup. I regularly attend the London Continuous Delivery Meetup group (where you get the chance to pick the brains of people such as Matthew Skelton, Steve Smith and Chris O’Dell), the London Devops Exchange, the London Devops Meetup (where you can casually run your devops problems by Marc Cluet and Matt Saunders and then listen while they give you a solution) and the Cardiff DevOps Meetup (hosted by the DevOpsGuys, so you can be guaranteed some top-notch speakers as well as the best beer in the business – I kid you not, at devopsguys we have our own beer!)

Yep, it's called DevHops

Yep, it’s called DevHops

Pairing – Like other programmers of my particular skill level (pisspoor), I get very self-conscious whenever I’m pairing. Not only when I’m the one driving, but also when I’m observing, because I ask stooooopid questions. Below is a picture of me pair programming with my son, who, despite being unable to speak yet, is clearly getting annoyed at my stupid questions (I think I just asked him what nested ternary operators are). However, there’s no denying it’s a fantastic way of learning. The technique we’re trying below involves me writing some ruby function, and then my son will refactor it and embarrass me.

IMG_20150329_114207[1]

 

Retrospectives are a way of reflecting on your latest sprint or release, and talking about what you did well, as well as what you didn’t do so well. The trouble is though, that you have to actually take these lessons on-board, and start implementing changes if necessary. It’s all very well reflecting on your performance, but it won’t improve unless you actually do something about it. This could be a whole blog post of its own, bust basically I’m seeing a lot of people in this situation where they rigorously do retrospectives, but nobody every implements the lessons learnt. Quite often it’s because there’s no agile coach involved with the team (and without the agile coach, nobody else has the time to implement the relevant changes themselves, let alone feels responsible for doing so).

Mobbing – Another picture coming up. This time another member of my family is joining in a mobbing session, which is basically a bunch of people all working on the same problem simultaneously (usually around the same screen). Like pairing, it’s a great learning technique. In fact I think it’s superior to pairing, because there are more people and therefore more minds on the job. But of course it can be costly to tie up multiple people on the same task.

Mobbing with my son and Tygwydd

Mobbing with my son and Tygwydd

Hackdays are like a geek-off for devs. I once spent the first 4.5 hours of a hackday trying to install LAMP before basically throwing my PC out of a window. Hackdays are where you get a bunch of devs together and give them all a problem to solve, or some objective to reach (you can be a specific or as vague as you like – often the more vague you are, the more creative your devs will be). 24hrs and a lot of pizza later, you’ll have a bunch of interesting creations – some more complete than others, but all of them creative, geeky, and in their own way very cool. I guarantee you’ll never see a passionate software developer work harder than during a hackday. What do you learn from a hackday? As a dev, you learn how to concentrate after 8 cans of Red Bull, and if you’re in a team then you learn how to work as a team under a high-pressure environment.

Devdays are something I really like to encourage within my teams. The idea is that for at least one day a sprint, 1 or 2 of your delivery team can work on something outside of the sprint commitments. I would aim to make sure everyone gets to take a devday at least once every 3 sprints. Of course, it needs to be relevant work, and it needs to be scheduled ahead of time (get into the habit of asking if anyone’s planning on taking a devday during sprint planning). If your team aren’t doing devdays, it’s a sure sign that you’re either too busy (and will end up experiencing burn-out) or your devs are disinterested. Devdays are a great opportunity to learn a new tool or to start spiking a new idea, perhaps using a new language.

20% Time is fairly similar to the devdays concept, in that people are encouraged to spend up to 1 day a week working on something that’s not on the backlog. I think the idea came from Google, but I’m not sure if they still practice it. Basically devdays, gold-card days or 20% time, call it what you will, are all designed to encourage learning and innovation and keep people feeling fresh and engaged. During her talk, Rachel spoke a little about Gold Cards, which I’d love to tell you more about, but I had to go and take a call just as she was talking about them, so you’ll just have to go and read more about them here.

Tech Talks are like little mini meetups, usually within an organisation, but companies like Facebook also do public tech-talks as well. Great for learning and eating free pizza and doughnuts. As a general rule, if there are no free nibbles, don’t go. Facebook had exceptionally good nibbles at their tech-talk. Just like at meetups, they’re a great place for tapping into the brain power of your fellow attendees as well as the speaker/presenter.

Book Clubs are one of the most underrated and under-used tools for learning, in my opinion. I ran a book club last year in an organisation that was trying to transition to Agile. The book I chose was called The Agile Samurai by Jonathan Rasmusson, which was a big hit with everyone who joined in. The format I use is for the group to read a couple of chapters of a book over the course of a week, and then have a review session where we all discuss what we’ve learnt. It’s a great way to share what we’ve learnt (which helps to make sure we’re all on the same page) and it also ensures that everyone is progressing at a reasonable pace.

sam

Coding Dojos – These are coding-centric programming clubs, basically. They involve a bunch of eager coders getting together and working (usually on their own laptops or in pairs) on a particular challenge, with the purpose of learning more about a particular language (Ruby, Go, Erlang etc) or technique (BDD, TDD etc). Suffice to say you usually need to have a reasonable amount of programming experience to be able to get the most value out of these, but don’t let that put you off. There are plenty of coding dojo metups available to cater for most levels, or you could of course run one yourself within your own organisation.

Team Swaps are where one team swaps with another for an entire day, or possibly longer. The idea behind this is that if you’re going to hand your codebase over to an entirely different team (and not be around to help), then it teaches you to write clean, self-documenting, simple code. On top of that, it also helps you learn more about other team’s coding styles and techniques.

Rotation – If I had to pick one concept and make it a mandatory part of software development, I would pick rotation. Here’s how it works: you take Danny the developer and put him in QA for a couple of sprints. Meanwhile, you take Tammy the Tester and put her in Dev for a couple of sprints. At a later date, Danny the dev will have to do a stint in the helpdesk, while Tammy does a couple of sprints working with the BA or Product Owner. Until eventually, everyone in your sprint team will have done stints in each of the following teams: Dev, Test, Helpdesk, Infrastructure/ops, Architecture, Product (Product Management, BA or whatever you have in your org), and possibly even Sales. It can take up to a year to complete the full set, but the amount you learn is invaluable. It’s not just skills that you pick up, but most of all it’s the different perspectives you get to see. Eventually, this experience will make you a better software delivery professional.

Tech Academies are becoming quite popular, and we’re seeing an increasing demand for help in setting these up within organisations. The idea is to create a number of internal training courses, tailor-made for the challenges that are unique to your organisation. These could be anything from Agile Coaching courses to Database Administration courses (and everything in between). It’s even quite common to see organisation-specific “certification” as well. People can enrol in one of these academies by choice, or you can make them mandatory, it’s up to you – but the key thing is to make them specific to your organisation’s needs. I think these are exceedingly valuable, and they have the added advantage over external training courses of always being 100% relevant, plus you can also ensure that everyone is getting the same standard of training!

Blogs are a great source of information, and a great way to keep up to date with fellow professionals in your technical area. But don’t just read them, write one for yourself! Keeping a team journal or a company blog is a great way of promoting the cool stuff you’re doing, and is also a great way to encourage and develop people’s technical writing skills (not to mention their written communication skills).

Conferences are a great source of free T-shirts, pens, hats, stress-balls, stickers, key-rings, laser-pointers and other things that you quickly get bored of and leave on your desk at the office. But did you know that you can actually learn stuff at conferences as well? It’s true! Some conferences have really, really clever people speaking at them, (other conferences have me), and you’ll usually find the speakers are more than happy to have a chat with you over a drink after their talk. In all seriousness, the Pipeline conference this year was brilliant – a great crowd of very smart professionals from all walks of life, an inspiring keynote from Linda Rising, and a chilled atmosphere. So, get along to a conference (even if you have to take a devday to get away with it), write down what you learn, make a blog out of it, do a tech-talk to your team about it, expand that into a workshop, maybe include some pairing and/or mobbing, and then head on out to a meetup to chat to more like-minded professionals. 🙂 Learning Level: Einstein!

Upcoming DevOps & Agile Meetups and Events

Here are some UK-based meetups and events in the devops/agile space that are happening in the next month or so…

Internet Performance Management & Monitoring
Cardiff, Wednesday, April 1, 2015
6:30 PM to 9:00 PM
http://goo.gl/FFKvSX

London DevOps Meetup #8: Hackathon
London, Tuesday, April 7, 2015
7:00 PM
http://goo.gl/zowRqC

Continuous Delivery for Databases
Bristol, Wednesday, April 15, 2015
6:30 PM
http://goo.gl/P494lm

Agile Planning & Tracking
Manchester, Wednesday, April 15, 2015
6:30 PM
http://goo.gl/kGKwjG

HDInsight on Azure/Real-time data analysis on Azure
Birmingham, Thursday, April 16, 2015
6:30 PM to 9:00 PM
http://goo.gl/jThZfL

Kanban metrics at Sky – Grow your system from good to awesome!
London, Thursday, April 16, 2015
6:30 PM
http://goo.gl/FAM1QQ

London Continuous Delivery, Nic Ferrier + David Genn
London, Tuesday, April 21, 2015
6:30 PM
http://goo.gl/4WwNaj

London PaaS User Group (LOPUG) Meetup
London, Thursday, April 23, 2015
6:30 PM
http://goo.gl/wncy2I

Ansible Oxford Kickoff
Oxford, Thursday, April 23, 2015
7:00 PM
http://goo.gl/BygpRs

Global Azure Bootcamp
TBC, Saturday, April 25, 2015
9:00 AM
http://goo.gl/8lVPyz

Hacking Azure Security in a SCRUM cloud
London, Monday, April 27, 2015
7:00 PM
http://goo.gl/2i1sP1

DevOps Thames Valley. Kick Off Meetup – shaping the event
Reading, Wednesday, April 29, 2015
7:00 PM to 9:00 PM
http://goo.gl/e0iKTB

Agile Coaching Exchange (Lego + Agile + Nigel)*Scaling = AWESOMENESS
Wednesday, April 29, 2015
6:30 PM
http://goo.gl/Tu1D3b

DevOps & NoSQL
London, Thursday, April 30, 2015
6:30 PM
http://goo.gl/gWP5XJ

DevOps – The reluctant change agent’s guide – John Clapham
Cardiff, Wednesday, May 6, 2015
6:30 PM to 9:00 PM
http://goo.gl/6JEoSh

London Continuous Delivery, Chris Young and Alex Yates
London, Tuesday, May 19, 2015
6:30 PM
http://goo.gl/Gyjl5h

London New Relic User Group – APM Training Session + Meetup
London, Wednesday, May 20, 2015
6:00 PM to 8:30 PM
http://goo.gl/WjqdnM

DevOps Manchester @ IPExpo
Manchester, Wednesday, May 20, 2015
5:00 PM
http://goo.gl/z08UOM

Agile Coaching Exchange – Visual Artistry with Stuart Young
London, Wednesday, May 20, 2015
6:30 PM
http://goo.gl/D2HKA3