agile | DevOpsNet

DevOps Scrum Framework

Posted on December 2, 2016 by jamesbetteley

Imagine this hypothetical conversation I didn’t have with someone last week…

THEM: “Is there a DevOps framework?”
ME: “Noooooo, it doesn’t work like that”
THEM: “Why?”
ME: “Well DevOps is more like a philosophy, or a set of values and principles. The way you apply those principles and values varies from one organisation to the next, so a framework wouldn’t really work, especially if it was quite prescriptive, like Scrum”
THEM: “But I really want one”
ME: “Ok, I’ll tell you what, I’ll hack an existing framework to make it more devopsy, does that work for you?”
THEM: “Take my money”

So, as you can see, in a hypothetical world, there is real demand for a DevOps framework. The trouble with a DevOps framework, as is always the problem with anything to do with DevOps, nobody can actually agree what the hell DevOps means, so any framework is bound to upset a whole bunch of people who simply disagree with my assumption of what DevOps means.

So, with that massive elephant in the room, I’m just going to blindly ignore it and crash on with this experimental little framework I’m calling DevOpScrum.

Look, I know I don’t have a talent for coming up with cool names for frameworks (that’s why I’d never make it in the JavaScript world), but just accept DevOpScrum into your lives for 10 minutes, and try not to worry about how crap the name is.

In my view (which is obviously the correct view) DevOps is a lot more than just automation. It’s not about Infrastructure as Code and Containers and all that stuff. All that stuff is awesome and allows us to do things in better and faster ways than we ever could before, but it’s not the be-all-and-end-all of DevOps. DevOps for me is about the way teams work together to extract greater business value, and produce a better quality solution by collaborating, working as an empowered team, and not blaming others (and also playing with cool tools, obvs). And if DevOps is about “the way teams work together” then why the hell shouldn’t there be a framework?

The best DevOps framework is the one a team builds itself, tailored specifically for that organisation’s demands, and sympathetic to its constraints. Incidentally, that’s one reason why I like Kanban so much, it’s so adaptable that you have the freedom to turn it into whatever you want, whereas scrum is more prescriptive, and if you meddle with it you not only confuse people, you anger the Scrum gods. However, if you don’t have time to come up with your own DevOps framework, and your familiar with Scrum already, then why not just hack the Scrum framework and turn it into a more DevOps-friendly solution?

Which brings us nicely to DevOpScrum, a DevOps Framework with all the home comforts of Scrum, but with a different name so as not to offend Scrum purists.

The idea with DevOpScrum is to basically extend an existing framework and insert some good practices that encourage a more operational perspective, and encourage greater collaboration between Dev and Ops.

How does it work?

Start by taking your common-or-garden Scrum framework, and then add the following:

Infrastructure/Ops personnel

Operability features on the backlog

A definition of Done that includes “deployable, monitored, scalable” and so on (i.e doesn’t just focus on “has the product feature been coded?”)

Continuous Delivery as a mandatory practice!

And there you have it. A scrum-based DevOps Framework.

Let’s look into some of the details…

We’ll start with The Team…

A product owner (who appreciates operability – what we once called “Non-Functional Requirements in the olden days. That term is so not cool anymore. It’s less cool than bumbags).

Bumbags – uncool, but still cooler than the term “non-functional requirements”

Devs, Testers, BAs, DBAs and all the usual suspects.

Infrastructure/Ops people. Some call them DevOps people these days. These are people who know infrastructure, networking, the cloud, systems administration, deployments, scalability, monitoring and alerting – that sort of stuff. You know, the stuff Scrum forgot about.

Roles & Responsibilities

Pretty similar to scrum, to be fair. The Product Owner has ultimate responsibility for deciding priorities and is the person you need to lobby if you think your concerns need to be prioritised higher. For this reason, the Product Owner needs to understand the importance of Operability (i.e the ability to deploy, scale, monitor, maintain and so on), which is why I recommend Product Owners in a DevOps environment get some good DevOps training (by pure coincidence we run a course called “The DevOps Product Owner” which does exactly what I just described! Can you believe that?!).

There’s no scrum master in this framework, because it isn’t scrum. There’s a DevOpScrum coach instead, who basically does the scrum master coach and is responsible for evangelising and improving the application of the DevOps values and principles.

DevOps Engineers – One key difference in this framework is that the team must contain the relevant infrastructure and Ops skills to get stuff done without relying on an external team (such as the Ops team or Infrastructure team). This role will have the skills to provide Continuous Delivery solutions, including deployment automation, environment provisioning and cloud expertise.

Sprints

Yep, there’s sprints. 2 weeks is the recommended length. Anything longer than that and it’s hardly a sprint, it’s a jog. Whenever I’ve worked in 3 week sprints in the past, I’ve usually seen people take it really easy in the first couple of weeks, because the end of the sprint seemed so far away, and then work their asses off in the final week to hit their commitments. It’s neither efficient nor sustainable.

Backlogs

Another big difference with scrum is that the Product Backlog MUST contain operability features. The backlog is no longer just about product functionality, it’s about every aspect of building, delivering, hosting, maintaining and monitoring your product. So the backlog will contain stories about the infrastructure that the application(s) run on, their availability rates, disaster recovery objectives, deployability and security requirements (to name just a few). These things are no longer assumed, or lie outside of the team – they are considered “first class citizens” so to speak.

I recommend twice-weekly backlog grooming sessions of about an hour, to make sure the backlog is up-to-date and that the stories are in good shape prior to Sprint Planning.

Sprint Planning

Because the backlog is different, sprint planning will be subtly different as well. Obviously we’ve got a broader scope of stories to cover now that we’ve got operational stories in the backlog, but it’s important that everyone understands these “features”, because without them, you won’t be able to deliver your product in the best way possible.

I encourage the whole team to be involved, as per scrum, and treat each story on merit. Ask questions and understand the story before sizing it.

Stories

I recommend INVEST as a guiding principle for stories. Don’t be tempted to put too much detail in a story if it’s not necessary. If you can get the information through conversation with people, and they’re always available, then don’t bother writing that stuff up in detail, it’s just wasting time and effort.

The difference between Scrum and DevOpScrum in respect to stories is that in DevOpScrum we expect to see a large number of stories not written from an end-user’s perspective. Instead, we expect to see stories written from an operation engineers perspective, or an auditor’s perspective, or a security and compliance perspective. This is why I often depart from the As a… I want… So that… template for non “user” stories, and go with a “What:… Why:…” approach, but it doesn’t matter all that much.

Stand-ups

Same as Scrum but if I catch anyone doing that tired old “what I did yesterday, what I’m doing today, blockers…” nonsense I’ll personally come and find you and make a really, really annoying noise.

Please come up with something better, like “here’s what I commit to doing today and if I don’t achieve it I’ll eat this whole family pack of Jelly Babies” or something. Maybe something more sensible than that. Maybe.

Retrospectives

At the end of your sprint, get together and work out what you’ve learned about the way you work, the technology and tools you’ve used, the product you’re working on and the general agile health of your team. Also take a look at how the overall delivery of your product is looking. Most importantly, ask yourself if you’re collaborating effectively, in a way that’s helping to produce a well-rounded product, that’s not only feature-rich but operationally polished as well.

Learn whatever you can and keep a record of what you’ve learnt. If any of these lessons can be turned into stories and put on the backlog as improvements, then go for it. Just make sure you don’t park all of your lessons somewhere and never visit them again!

Deliver Working Software

As with Scrum, in DevOpScrum we aim to deliver something every 2 weeks. But it doesn’t have to just be a shiny front-end to demo to your customers, you could instead deliver your roll-back, patching or Disaster Recovery process and demo that instead. Believe it or not, customers are concerned with that stuff too these days.

Continuous Delivery

I personally believe this should be the guiding practice behind DevOpScrum. If you’re not familiar with Continuous Delivery (CD) then Dave Farley and Jez Humble’s book (entitled Continuous Delivery, for reasons that become very obvious when you read it) is still just about the best material on the subject (apart from my blog, of course).

As with Continuous Integration, CD is more than just a tool, it’s a set of practices and behaviours that encourage good working practices. For example, CD requires high degrees of automation around testing, deployment, and more recently around server provisioning and configuration.

Summary

So there it is in some of its glory, the DevOpScrum framework (ok, it’s just a blog about a framework, there’s enough material here to write an entire book if any reasonable level of detail was required). It’s nothing more than Scrum with a few adjustments to make it more DevOps aligned.

As with Scrum, this framework has the usual challenges – it doesn’t cater for interruptions (such as production incidents) unless you add in a triage function to manage them.

There’s also a whole bunch of stuff I’ve not covered, such as release planning, burn-ups, burn-downs and Minimum Viable Products. I’ve decided to leave these alone as they’re simply the same as you’d find in scrum.

Does this framework actually work? Yes. The truth is that I’ve actually been working in this way for several years, and I know other teams are also adapting their scrum framework in very similar ways, so there’s plenty of evidence to suggest it’s a winner. Is it perfect? No, and I’m hoping that by blogging about it, other people will give it a try, make some adjustments and help it evolve and improve.

The last thing I ever wanted to do was create a DevOps framework, but so many people are asking for a set of guidelines or a suggestion for how they should do DevOps, that I thought I’d actually write down how I’ve been using Scrum and DevOps for some time, in a way that has worked for me. However, I totally appreciate that this worked specifically for me and my teams. I don’t expect it to work perfectly for everyone.

As a DevOps consultant, I spend much of my time explaining how DevOps is a set of principles rather than a set of practices, and the way in which you apply those principles depends very much upon who you are, the ways in which you like to work, your culture and your technologies. A prescriptive framework simply cannot transcend all of these things and still be effective. This is why I always start any DevOps implementation with a blank canvas. However, if you need a kick-start, and want to try DevOpScrum then please go about it with an open mind and be prepared to make adjustments wherever necessary.

DevOps Certification – Part 2

Posted on March 10, 2016 by jamesbetteley

In part 1 of this exciting 2-part blog series, I argued, quite elegantly I think, that DevOps certification is perhaps not the single greatest breakthrough in the advancement of software delivery since the invention of computing. In this part, I’ll attempt to go into even further detail in support of my hypothesis…
At an agile conference last year I did a quick survey to see what people valued the most about Agile Cerification. The results were conclusive, not one single person said they valued the certification itself. Most people said they thought the training was the most valuable thing, and I can understand that 100%. Quite rightly, people valued the knowledge they had gained and the content they’d been taught over a certificate they walked away with.

devops_cert
But certification is still very popular, and that’s hardly surprising when you see how many people advertise roles for “certified” scrum masters. But the abundance of certified scrum masters doesn’t seem to have done much, in my view, to help progress the agile movement as a whole. In fact, I’m more inclined to believe that some “agile” certification has done more to confuse and derail the agile movement than to actually help it.
Here’s why:
Organisations think they’re agile because they’ve hired some certified scrum masters (or sent some people to get scrum master certification). I’m sorry, but hiring a certified scrum master makes you no more agile than hiring a violinist makes you an orchestra.
I’m not going to try to make excuses for misunderstanding the very meaning of “agile”, but it’s pretty easy to see how some people might think “well I’ve now got these Scrum Masters for christs sakes, MASTERS – not just any old scrum practitioners, and they’re certified! So if that doesn’t make us agile then why did I spend so much money on sending them on that certification course!?!!” (Answer: because you stoopid). Scrum certification is “reassuringly expensive” (genuine quote right there), and is VERY useful for teaching people about how to run scrum, but it doesn’t make you agile. Don’t be fooled by the price tag and the highly egotistic “Master” title.

scrum master
As part of my role as a consultant, I sometimes get asked to assess organisations agility. More often than not I get told “Oh we’re agile, we do scrum”, or “Oh we’re agile, we do sprints and have stand ups” and that sort of thing. These things, sadly, don’t necessarily make you agile. They’re just things. But one big problem in the software delivery world right now is that many people DO think that those things “make you agile”, and that’s all there is to it.
The silver lining for me of course, is that I get quite a bit of work out of it! I get to help some of these organisations realise that thier ability to do scrum, and their overall agility are two quite separate things.

And this brings me round to DevOps.
The DevOps world has an identity crisis every bit as bad as the agile world. Where agile suffers from people confusing the link between “agile” and scrum, in DevOps we suffer from people believing DevOps means Automation.
To be clear, DevOps doesn’t mean Automation. There’s already a word for Automation, and that word is Automation.

For me, DevOps is about the way in which teams work in order to create high quality products from Operational and Development perspectives.

Sure, automation can play a part in that, but it’s only a part.
Part of my role is to help teach people about how to unlock the power of DevOps, and to do that I usually have to start by explaining what DevOps is and what it isn’t. We call this the “Education” piece, because that’s exactly what it is – it’s not simply a case of defining something and drawing up a glossary, we’re literally opening people’s eyes and minds to what DevOps actually is, and what it can do for organisations who do it properly.
At one point we even thought about formalising this DevOps Education and even providing some sort of certification or professional credits system, but we quickly realised that this was utter bollocks.
The thing is, you can’t certify something that doesn’t have a commonly agreed definition, and you can’t certify a philosophy. You can certify actions and behaviours, and how well people understand particular frameworks (like scrum for instance), but you CAN’T CERTIFY A PHILOSOPHY. And anyway, who are these self-proclaimed guardians of the DevOps philosophy? These people who are so sure that they not only understand DevOps better than the rest of us, but also believe they’ve stumbled upon the perfect training program for passing this most precious wisdom on to people who attend their course? It must be a veritable who’s who of the DevOps movement, the Adrian Cockrofts, Jez Humbles, Patrick Dubois and John Allspaws of this world… Hint: it isn’t.
It’s almost as if the whole thing is just a scheme to make money! Imagine that!

So to conclude, I fear that DevOps certification isn’t worth the paper it’s written on, and bandying around a DevOps certification is only going to perpetuate the problem that we already see within agile, where organisations will believe that they’re “doing DevOps” simply because they’ve hired people with some bullshit certification.

Sprint Goals, Backlogs & Star Trek

Posted on February 23, 2016 by jamesbetteley

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

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…

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…

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!

Keep CALMS and do DevOps!

Posted on June 25, 2015 by jamesbetteley

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.

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.

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?

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.

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.

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

Upcoming DevOps & Agile Events

Posted on May 21, 2015 by jamesbetteley

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?

Posted on May 7, 2015 by jamesbetteley

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”

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)

Posted on April 30, 2015 by jamesbetteley

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):

Workshops
Attending meetups
Pairing
Retrospectives
Mobbing
Hackdays
Devdays
20% Time
Tech Talks
Book clubs
Coding Dojos
Team Swaps
Rotation
Tech Academy
Blogs
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

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.

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

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.

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!

Stop Comparing Software Delivery With Manufacturing!

Posted on July 10, 2014 by jamesbetteley

A couple of weeks ago I was at an Experience Devops event in London and I was talking about how software delivery, which is quite often compared to a manufacturing process, is actually more comparable to a professional sports team. I didn’t really get time to expand on this topic, so I thought I’d write something up about it here. It all started when I ran a cheap-and-nasty version of Deming’s Red Bead Experiment, using some coloured balls and an improvised scoop…

The Red Bead Experiment

I was first introduced to Deming’s Red Bead Experiment by a guy called Ben Mitchell (you can find his blog here). It’s good fun and helps to highlight how workers are basically constrained by the systems the work in. I’ll try to explain how the experiment works:

You have a box full of coloured beads
Some of the beads are red
You have a paddle with special indentations, which the beads collect in (or you could just use a scoop, like I did).
You devise a system whereby your “players” must try to collect exactly, let’s say, 10 red beads in each scoop.
You record the results

Now, given the number of red beads available, it’s unlikely the players will be able to collect exactly 10 beads in each scoop. In my especially tailored system I told the players to keep their eyes closed while they scooped up the balls. I also had about half as many red beads as any other colour (I was actually using balls rather than beads but that doesn’t matter!). The results from the first round showed that the players were unable to hit their targets. So here’s what I did:

Explain the rules again, very clearly. Write them down if necessary. Being as patronising as possible at this point!
Encourage the players individually
Encourage them as a team
Offer incentives if they can get the right number of red beads (free lunch, etc)
Record the results

Again, the results will be pretty much the same. So…

Threaten the individuals with sanctions if they perform badly
Pick out the “weakest performing” individual
Ask them to leave the game
Tell the others that the same will happen to them if they don’t start hitting the numbers.

In the end, we’ll hopefully realise that incentivising and threatening the players has absolutely zero impact on the results, and that the numbers we’re getting are entirely a result of the flawed system I had devised. Quite often, it’s the relationship between workers and management that gets the attention in this experiment (the encouragement, the threats, the singling out of individuals), but I prefer to focus on the effect of the constraining system. Basically, how the results are all down to the system, not the individual.

Thanks Kanban!

I think one of the reasons why the software industry is quite obsessed with traditional manufacturing systems is because of the Toyota effect. I’m a huge fan of the Toyota Production System (TPS), Just-in-time production (JIT) Lean manufacturing and Kanban – they’re all great ideas and their success in the manufacturing world is well documented. Another thing they all have in common is that various versions of these principles have been adopted into the software development world. I also happen to think that their application in the software development world has been a really good thing. However, the side-effect of all this cross-over has been that people have subconsciously started to equate software delivery processes with manufacturing processes. Just look at some of the terminology we use everyday:

Software engineering
Software factories
Kanban
Lean
Quality Control (a term taken directly from assembly lines)

It’s easy to see how, with all these manufacturing terms around us, the lines can become blurred in people’s minds. Now, the problem I have with this is that software delivery is NOT the same as manufacturing, and applying a manufacturing mindset can be counter-productive when it comes to the ideal culture for software development. The crucial difference is the people and their skillsets. Professionals involved in software delivery are what’s termed as “knowledge workers”. This means that their knowledge is their key resource, it’s what sets them apart from the rest. You could say it’s their key skill. Manufacturing processes are designed around people with a very different skillset, often ones that involve doing largely repetitive tasks, or following a particular routine. These systems tend not to encourage innovation or “thinking outside of the box” – this sort of thing is usually assigned to management, or other people who tend not to be on the production line itself. Software delivery professionals, whether it be a UX person, a developer, QA, infrastructure engineer or whatever, are all directly involved in the so-called “production line”, but crucially, they are also expected to think outside of the box and innovate as part of their jobs. This is where the disconnect lies, in my opinion. The manufacturing/production line model does NOT work for people who are employed to think differently and to innovate.

If Not Manufacturing Then…

Ok, so if software delivery isn’t like manufacturing, then what is it like? There must be some analogous model we can endlessly compare against and draw parallels with, right? Well, maybe…

home sweet home

I’m from a very rural area of west Wales and when anyone local asks me what I do, I can’t start diving into the complexities of Agile or devops, because frankly it’s so very foreign to your average dairy farmer in Ceredigion. Instead, I try to compare it with something I know they’ll be familiar with, and if there’s one thing that all people in west Wales are familiar with, it’s ~~sheep~~ rugby.

It’s not as daft as it sounds, and I’ve started to believe there’s actually a very strong connection between professional team sports and Agile software development. Here’s why:

Software delivery is a team effort but also contains subject matter experts who need to be given the freedom to put their skills and knowledge to good use – they need to be able to improvise and innovate. Exactly the same can be said of a professional rugby or soccer (yes, I’m going to call it soccer) teams. Rugby and soccer are both team sports but both contain very specific roles within that team, and for the teams to be successful, they need to give their players the freedom and space to use their skills (or “showing off” as some people like to call it).

2008 World Player of the Year Shane Williams

Now, within a rugby team you might have some exceptionally talented players – perhaps a winger like former World player of the year Shane Williams. But if you operate a system which restricts the amount of involvement he gets in a game, he’ll be rendered useless, and the team may very well fail. Even with my dislike of soccer, I still think I know enough about how restrictive formations and systems can be. The long ball game, for instance, might not benefit a Lionel Messi style player who thrives on a possession & passing game.

The same can be said of software delivery. If we try to impose a system that restricts our individual’s creativity and innovation, then we’re really not going to get the best out of those individuals or the team.

So Where Does Agile Fit Into All of This?

Agile is definitely the antidote to traditional software development models like Waterfall, but it’s not immune from the same side-effects as we witness when we do the red bead experiment. It seems to be that the more prescriptive a system is, the greater the risk is of that system being restrictive. Agile itself isn’t prescriptive, but Kanban, XP, Scrum etc, to varying degrees are (Scrum more prescriptive than Kanban for instance). The problem arises when teams adopt a system without understanding why the rules of that system are in place.

prescriptive = restrictive

For starters, if we don’t understand why some of the rules of Scrum (for instance) exist, then we have no business trying to impose them on the team. We must examine each rule on merit, understand why it exists, and adapt it as necessary to enable our team and individuals to thrive. This is why a top-down approach to adopting agile is quite often doomed to fail.

So What Should We Do?

My advice is to make sure everyone understands the “why” behind all of the rules that exist within your chosen system. Experiment with adapting those rules slightly, and see what impact that change has on your team and on your results. Hmmm, that sounds familiar…

The Deming Cycle: Plan, Do, Check, Act

On collective ownership and responsibilities

Posted on July 3, 2014 by jamesbetteley

Recently I’ve been butting heads with some people on the subject of Ownership, Responsibility and Accountability. There seems to be a very unhealthy obsession with these things sometimes, and I think this is indicative of a less-than-ideal culture. I don’t want to say that they’re “anti-agile” because that just sounds a bit weak, and because I also think they’re not just bad for agile, they’re bad for pretty much any system. I’m not sure how familiar most people are with the “RACI matrix” concept, but in my eyes it’s downright evil in the wrong hands, and I’ve been hearing “RACI Matrix” a lot recently (it’s now on my Bullshit Bingo card).

I’ll start off by clarifying what I mean. I’ve got nothing against people owning actions or being accountable for certain particular (usually small) things, but I do take offence when pretty much everything has to be given an owner, someone accountable and someone to “take responsibility”. It’s divisive and results in lots of finger pointing, in my experience.

I much prefer the concept of shared ownership, and collective accountability. As a software delivery team, we should all feel responsible for the quality of the product, as well as the performance and the feature richness. These things shouldn’t be assigned for ownership to individuals, as it’ll create an attitude of “well it’s not my problem” among the other team members.

Here’s an example: I’ve worked in a team where one person was made the “owner” of the build system. They busied themselves making sure all the builds passed and that the system was regularly ticking over. Of course, the builds often failed and nobody cared except this one person, who then had to try to get people to fix their broken builds. It almost seemed as if people didn’t care about the fact that their software wasn’t capable of being compiled, or that the tests were failing, and in truth they didn’t. They cared about writing code and checking it in, because they didn’t “own” the build system.

One message that I always try to drive home with software delivery teams is that our objective is to make software that works for our users, not just write code. I know how easy it is for developers to just focus on checking in code, or perhaps just make sure it passes the tests in the CI system, but beyond that, their focus drops off. I know because I was once one of those developers 🙂 These days I try to encourage everyone to care about things such as:

How your code builds
How the tests execute
How good the tests are
How good the code is
How easy it is to deploy
How easy it is to maintain
How easy it is to monitor

Because it takes all of these things to produce good software that users can enjoy, which means we get paid.

Here’s another example of how “ownership” has hurt a product: A large system I once worked on was deployed into production using a complicated system of bash and perl scripts, which were cobbled together by a sysadmin who did the deployments. He became the de facto “owner” of the deployment system. There were untold issues with the running of the application because of permissions, paths etc and so forth. The deployment process was creaky and relatively untested. Since the “ownership” of this system was assigned to the sysadmin, rather than devolved or collectively shared throughout the delivery team, the “deployability” was seen as a second class citizen within the delivery team, because everybody felt like it was “owned” by one person who just happened to be on the periphery of the team at best.

So here’s what I think: The ability to monitor, maintain, deploy, test, build and create software should all be treated as first class citizens and should be the collective responsibility of everyone in the team. They should all own it, and they should all be accountable.

I would extend this out further, to include supporting systems such as environments, build systems, testing frameworks and so-on. Sure, each team might have an SME or two who focuses more on one of these things than any other, but that doesn’t make that one person accountable, responsible or the owner any more than any particular developer is the “owner” of any particular class, method or function. If I write some code that depends on a method that someone else has written, and that method is failing, I don’t just down tools, shrug my shoulders and say “well I’m not accountable for that”. That would be hugely unhelpful and I’d make no friends either. In the same way, we shouldn’t treat our supporting functions and systems as someone else’s responsibility. If we need it in order to make our software work for the end user, then it’s our collective responsibility, no matter what “it” is.

Are “Ready For” Columns on Kanban Boards The Enemy of God?

Posted on April 17, 2014 by jamesbetteley

This is going to be a quick ~~rant~~ post, hopefully. Today I saw another Kanban board which had a “Read for test” column on it, here’s the screenshot:

Not 1 but 2 “Ready for” columns!

I Think “Ready For” Columns Are Baaaaad

With most Kanban boards you mark a card as done when it’s ready to be pulled into another column. If that means it has to be deployed before a card is ready for test then so be it. The last thing we want is cards just sitting around waiting – this is baaaaaad. “Ready for Test” usually means it’s either deployed (and yet to be tested) or waiting to be deployed. Either way, not much is happening to the work sitting in this column. Basically it’s waste (or “muda” as the Lean Kanban aficionados might call it), and remember, waste is baaaaad.

Seriously, I Think They’re Baaaaad

A result of using these “Ready For x” columns is that they tend to slightly move us away from the “stop the line” practice that good Lean/Kanban systems employ. Basically whenever there’s a problem, or a bottleneck is appearing, we want to stop the production line and address the issue. So, if we keep all these “Ready for QA” cards in our In Dev or Code Review Column (basically whatever column comes before your Ready for QA column) then we’ll very quickly reach our WIP (Work In Progress) limit and the line will be stopped. That’s a good thing! We want to catch that bottleneck as soon as we can, we don’t want to hide it by pushing our cards into another “buffer” column.

Did I Mention That I Think “Ready For” Columns in Kanban Are Baaaaaad?

Yet another problem with “Ready for x” columns is that they quite often tend to be push rather than pull columns. You can’t really pull into a Ready for QA column as it isn’t an actual “workflow” state, it’s a “wasteflow” state (see what I did there?). I mean, who’s going to pull stuff into that column anyway? I’ve yet to meet a “ready for test” team who just sit around pulling cards into their column before marking them as “ready” (presumably once they’ve verified that they are indeed ready for test). Ok, you might have a deployment team who are responsible for deploying stuff to your test environments and so forth. In this case, your workflow state still isn’t “Ready for test” it’s “In Deployment”.

Conclusion

“Ready for x” columns make baby Jesus cry.