DevOps Certification – Part 2

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.

Advertisements

SAFe – Command and Control Agile?

SAFe (the Scaled Agile Framework, with a random “e” at the end) seems to be the talk of the agile world at the moment, and as you’d expect, opinions are both strong and divided. On the one side you’ve got the likes of Ken Schwaber and David Anderson (the guys who brought us Scrum and Kanban respectively), while on the other side you’ve got, well, pretty much anyone who stands to make any money out of SAFe.

scrum_v_safe

I’m working at a company in London who might be about to go down the SAFe route, so obviously I’ve had to do a bit of research into this new framework, as it could soon be directly impacting me in my capacity as an agile coach and devops ninja.

My initial questions were:

  1. What the hell is this and how come I’ve never heard of it?
  2. Why is there no mention of devops?
  3. Is it really as prescriptive as it sounds?
  4. Isn’t it a bit “anti-agile”? (recall “individuals and interactions over processes and tools”, part of the agile manifesto)

So I started looking into SAFe. There’s quite a bit of information on the SAFe website, and the “Big Picture” on the homepage is crammed with information, jargon and stuff. At first glance it seemed fairly sensible on the higher levels, but overly prescriptive on the team level. Then you start clicking on icons, and that’s when it gets interesting…

Story Sizing, Velocity and Estimating: They tell us that all teams should have the same velocity and the same sizing (i.e. 1 point in team A should be exactly the same as 1 point in team B). They also say that 1 point should equal 1 day. I find this quite interesting, as this time-based evaluation is flawed for a number of reasons. Velocity (in normal scrum) should be obtained by measurement, not by simply saying “right, there’s 5 people in the team, 5×8=40, therefore our velocity will be 40!” This pains me, because I firmly believe that each team should be allowed to work out their own sustainable velocity, based on observation and results (and applying the Deming cycle of making a change and seeing if it improves output). If we are all given a goal of x points to achieve in a sprint, all we will do as a team is fiddle our estimations so that we hit that target. That’s exactly why we don’t use velocity as a target. What am I missing here?

ScrumXP: SAFe seems to suggest that you MUST do 2 week sprints. You have no option in this. Doesn’t seem to matter if you want to have a kanban system based around a weekly release schedule. SAFe seems largely ignorant of this. Is SAFe suggesting that Kanban doesn’t work? Has anyone told David Anderson?

SAFe prescribes Hardening Sprints: These are sprints set aside at the end of every release (one every 5th Sprint), to allow you to do such things as User Acceptance Testing and Performance Testing. In Continuous Delivery we work towards making these activities happen as early as possible in the release pipeline, in order to shorten the feedback loop. We really don’t want to be finding out that our product isn’t performant a day before we expect to release it! I certainly wouldn’t encourage the use of hardening sprints in the SAFe way, instead I would encourage people to build these activities into their pipelines as early as possible. I think of hardening Sprints as a bad smell, isn’t it just a way of confessing that you don’t expect to catch certain things until the end? So rather than try to fix that situation and reduce that feedback loop, you’re kind of just saying “hey, s**t happens, we’ll catch it in the hardening sprint”.

Innovation Sprints: These happen at the same time as the hardening sprint. SAFe is suggesting that during a normal sprint we don’t have time for innovation. And that is quite often the case – but wouldn’t it be better if we actually did have sufficient time for continuous innovation, rather than actually have a dedicated half-sprint for innovation? The book “Slack” by Tom DeMarco talks about the myth of total efficiency, and suggests that by slowing down and building in some slack time, we get greater returns. This is better achieved as part of everyday practice rather than working at some mythical “total efficiency” level and then having an “innovation sprint”. The SAFe approach seems to be an easy option. Rather than taking the time to determine a team’s sustainable velocity which includes sufficient time for innovation, it suggests just saving it up for a sprint at the end of every release. Don’t forget that at the same point, the team will apparently be doing “hardening” activities, gearing up for a release, and planning the next one. For some reason I feel uncomfortable with the idea that innovation is something that should be scheduled once every 10 weeks, rather than something that should be encouraged and nurtured as part of normal practice.

The Scrum Master: SAFe has this to say about the Scrum Master:

In SAFe, we assume that the Scrum Master is also a developer, tester, project manager or other skilled individual (though not the team’s manager) who fulfills his Scrum Master role on a part time basis.

Wow, that’s some assumption. They seem to suggest that you can just take any developer, tester etc and send them on a scrum course, and hey presto, you have a scrum master. And yes, you could do this, but what sort of scrum master are you getting? They also say:

responsibilities can generally be accomplished in about 25% of the time for that team member

which I again find surprising. A Scrum Master is just one quarter of a person’s time?? Seriously? Mentoring a team, coaching individuals, removing impediments, applying the principles of Scrum, helping the team work towards a goal, leading a team towards continuous improvement – all of these things are expected of the Scrum Master in SAFe, and yet they can all be achieved in “about 25%” of a person’s time, apparently. And where does an agile coach come into this? Well, they don’t exist in SAFe. In SAFe you have SAFe consultants instead.

The Product Manager and The product Owner: These are 2 very separate, very different roles in SAFe. A Product Owner works with the Scrum Team, but doesn’t have contact with the customer. The Product Manager has contact with the customer but deals with the scrum team through the Product Owner. Also the product owner doesn’t own the product vision – that responsibility belongs to the product manager – this seems strange to me, I would have naturally thought that the product “owner” would own the product vision. So essentially we’re adding yet another link in the chain between the customer and the team.  I’m struggling to see this as a good thing, when in my experience a close relationship between the business and the team has always been of great benefit.

There is no Business Analyst role in SAFe, which I find quite interesting. This role seems to have been split out into the Product Owner and Product manager roles. For instance, the PO is meant to do the Just-In-Time analysis on the backlog stories.

in SAFe, the UX Designer is NOT part of the agile team. Rather, they work “at the Program Level” (whatever the hell that means, possibly on a different floor, maybe) yet they still do the following:

  • Provide Agile Teams with the next increment of UI design, UX guidelines, and design elements in a just-in-time fashion
  • Attend sprint planning, backlog grooming, iteration demos
  • Work in an extremely incremental way
  • Rely on fast and frequent feedback via rapid code implementation
  • Are highly collaborative, and…
  • The UI criteria are included in the “Definition of Done” and User Story acceptance criteria

But I must remind you that according to SAFe they are NOT part of the agile team 🙂 Is it just me or does this come across as a bit, I don’t know, pedantic?

Pretty much the same rule applies to devops (which was included in a later version of SAFe) – devops people aren’t in the team BUT, you can simply achieve “devops” in part by:

 integrating personnel from the operations team with the Agile teams

Er, ok. So they’re not part of the team but they’re integrated with the team. Riiiiight. On a plus note – it does mention “designing for deployability”, which can never be overstated in my opinion.

These are just my initial observations and I’m sure I’ll have a lot more to say on the subject as we embark on our SAFe journey. I’m hoping it’s not as prescriptive as it sounds, as I honestly don’t believe there’s a one-size-fits-all solution to adopting Agile. I very much believe that every organisation needs to go on their own journey with agile, and find out what works best for them. It’s my opinion that the lessons you learn on this journey are more important than the end result. In my experience, most organisations will have invariably witnessed a fantastic cultural shift during their gradual transition to agile, and I find it very difficult to see how a prescribed framework such as SAFe can facilitate this cultural shift.

The Agile Silver Bullet

agile_silver_bulletSo is SAFe really an agile silver bullet? I doubt it, but time will tell. I certainly don’t disagree with the majority of the contents of the “Big Picture” but where I do disagree, I feel very concerned, as I seem to disagree on a very fundamental level.

I would be much happier if SAFe was a lot less prescriptive-sounding. I can see SAFe being popular with larger-scale organisations with a penchant for job-titles and an unhealthy affinity for bureaucracy, I mean, it’s a framework, and they lap that stuff up! I can also see it being quite effective in those situations, after all, pretty much anything’s better than Waterfall!

I can see SAFe appealing to people who aren’t prepared to go on the agile journey, because they fear it. They fear they will fail, and they fear a lack of clarity. This framework puts nice titles everywhere, tickboxes to be ticked and nice clear processes to blindly follow. I can imagine it would be hard not to look like you’re making progress! I don’t yet trust the framework, but that could still change, but for the time being I’ve got the impression that it’s command-and-control agile, more of a tick-box exercise than a vessel for personal and organisational development.