By William Knight

When I was in my twenties, I met an undertaker called Mrs D’ath. Then a few months later, a policeman known as PC Sergeant. Sometimes it seems that people follow careers based on their names and develop a great talent later. Did the name or the talent come first, Usain Bolt? 

You could believe in synchronicity, or you could believe that the name was an important aspect of how people see themselves. Ask a marketer how important the name is, and they’ll tell you how the Rolls Royce Silver Mist never sold in Germany because mist in German means something unsavoury that you normally flush down the toilet.

After all, “Your brand is not what you say it is, it’s what THEY say it is,” says Marty Newmeier, of The Brand Gap, and the discerning Germans couldn’t see past the name to the quality of the car.

So it is with DevOps. The name is so screamingly technical and bland that any head-screwed-on non-tech person will fail to register it as a thing at all. As far as creativity goes, the childish concatenation of two technical terms strikes me as the first thing that somebody thought of while they were absent mindedly picking fluff from their belly button.

Yet apart from the sheer obviousness, there are three reasons the name DevOps is terrible if you are using it to drive change in your organisation.

•    The name may neutralize or even negate the good work great engineers do because, “It’s just about nerds!”
•    The name fails to generate any natural interest and forces you to spend more time and effort educating your audience. “I’ve not got time to talk about that propeller stuff, can we do it later?”
•    You’ll face all the same challenges every time you try to introduce a new department or leader to the concept. You’ll run out of energy before any changes have happened. “What did you say again?” 

Yet it can’t be denied that finding a great brand name for DevOps is a tough challenge. Google have their own version known as Site Reliability Engineering (Yawn!) and a straw poll of my work colleagues generated not a single serious contender, (though one cynical suggestion was, “Fat Raise for the CIO”).

But I suggest that a committed investment is made by the DevOps community to come up with a better name. Think about it. You want product managers, business executives, stakeholders, financial gurus and strategists to endorse a fundamental change to how they engage with technology, but you’re telling them it’s totally boring and they shouldn’t bother listening.

Better to promise excitement and status and at least have a chance of achieving magic, even if your promises are overblown. Put a grey tarnish on an old brass lamp and most business people won’t pick it off the floor to find the genii.

By William Knight

​Over a chilled glass of Sauvignon at the agile blog-in the other night, a well-respected colleague of mine pronounced that he didn’t like the term “User Story”; he found it misleading when so many requirements of a complex system are not based on a user’s or even a customer’s interaction, and he feared that important features would be missed if one took the term “user” too literally. He suggested that it was good enough to say simply, “story” and dispense with the misunderstood user.

Many organisations have tried and been successful with agile in small pilot projects, but when they have attempted to apply that success to  the organisation as a whole they’ve make poor compromises to fit agility with their particular situation, and ended up with agile in name only.

For example a business might run a small team that’s able to realise agility by releasing finished, valuable software every two weeks. But then fail to reproduce the same small, cross-skilled teams when they scale because of an unwillingness to change reporting lines, refusal to dismantle departments and inability to tackle historic but wasteful processes.

An early warning that things may not be working out as intended may be found by inspecting how User Stories are written and split.

For example, you might find integration or testing stories. Neither deliver independent value to the user by themselves, but creating stories like this does allow integration or testing teams to pretend they are working in an agile way. Crucially, the “user” part of User Story is an inconvenience if your goal is to create work for these specialist teams.

Removing the word “user” means requirements can be unlinked from creating end-to-end value and therefore allow siloed teams to operate with less need to collaborate with other teams and without understanding the value their part of the build will deliver to the overall solution.

To combat such a situation, a back to basics approach is required. Here are some pointers to remind us what user stories are all about and why we must always strive to keep the user part upmost in our minds.

1. Write business stories that illustrate the business outcomes and value that will be created for the user (or customer) of the system you are building.
2. Avoid technology related language (as far as is sensible) in your user stories (by all means add notes with tech stuff), but the user or customer should be able to understand the intentions and, vitally, value it will add when complete.
3. User stories must deliver value so expect them to be a complete piece of work that delivers or retrieves real data to and/or from a user (or makes an improvement to such a scenario).
4. Strive to make user stories that can be delivered into production independently and in the order the business decides.
5. Resist splitting stories by technology or expertise – e.g. not testing, or integration stories. (these are not business requirements and doing so puts us at risk of dependence between stories) If you need to decompose stories to understand them better or for more accurate sizing, split user stories by business outcome and/or user groups so that each still delivers an increment of value instead of one part of a whole.
6. If you are running Scrum, the development team may suggest bringing lower priority stories into the sprint to help balance work for the skills available in the team and keep everybody working, but do not create stories by technology or skill to enable this. (e.g. don’t allow stories to be split into coding and testing stories so the coders that are available can start a sprint or two early)
7. To help the development team balance the available skills with the work being done, it is useful to have the backlog peppered with some small valuable fixes/changes that can be brought in when there is capacity for extra fillers but not enough capacity to “finish” something large. (These changes may or may not be user stories) It is not necessary that the backlog is exclusively made up of user stories – you can have fixes, updates and improvements, but do avoid using the word “story” as a generic term for all requirements; it’s confusing.

A User Story is a light-weight requirement from the user or customer’s perspective about their needs and the value they will get from it. A user story prompts a conversation and rapid, iterative development to meet the conversation’s conclusions. A user story cannot be built without close collaboration with the user and without the user understanding what the requirement will provide.

If any of those things are not present, do not simply drop “user” from the “user story”, you are probably hiding other problems while pretending all is well.

By William Knight

Then when he told you he was going to invite your spouse, extended family, the council representative and your neighbours, you’d probably send him packing in his ute and put a request for a new contractor out on neighbourly.  It seems incredible that anyone would actively promote such an approach. Doesn’t it?
​
The death-rattle of a stage-gated, procedure-heavy dinosaur

But this is what happens during SAFE increment planning days. Not only are the build teams invited but anybody with the slightest interest is asked to put down their tools and spend two days developing an implementation plan. Think of the cost; all those contractors on hourly rates, the things that don’t get done, and all the expensive technicians sitting around a table discussing options. It’s enough to give finance a heart attack.

The agile community certainly reserves some criticism for SAFE. “From a Scrum perspective, SAFE might be dismissed as the death-rattle of an essentially stage-gated and procedure-heavy dinosaur. It can be viewed as a reflex to agility, and not a species of it; a last-gasp relic from a prehistoric waterfall world,” writes Ian Mitchell for DZone.

Any yet, despite my fear the increment planning would yield no workable results, in fact my first planning day showed just how effective such a program wide gathering can be.

But not in the way you might expect.

First, it was clear the plans the build teams created were unlikely to be realistic. Far too many impediments existed at the time, and it only took the first sprint after planning to see that too much had been unknown, and that the teams had not understood the significance of a whole programme increment plan – this was the first after all.

Under intense scrutiny to deliver

Yet it was the way the business stakeholders and executives reacted to the discussed risks that was the great success. Despite some trepidation, teams were mostly open and honest about the blocks to progress. It seemed that the leadership were not used to, and had not been confronted with such clear impacts before. The executive listened, took action and took actions away.

And how could it be otherwise? The leadership attends SAFE planning because of methodology commitments, and must then seriously consider the messages it receives and has no room for prevarication in such a public forum. They are under intense scrutiny to deliver.

Perhaps none of this would be necessary if business stakeholders and executives spent the time to inspect and adapt the work their build teams are actually doing – as you might expect them to do. But we all know the challenges faced getting stakeholders in regular attendance at reviews and reacting to actions coming out of retrospectives.

This then seems to be the power of SAFE; to give senior management a framework and an excuse to get involved. Without the pull of methodology, they are often unable to work directly for the build teams and without the glare of public acknowledgment are let off the hook when inconvenient actions are demanded.

And there’s another reason SAFE is a good idea in legacy-bound, large-scale organisations.
​
“At scale, we're still in a waterfall world and a poorly implemented one at that. In fact, I'd say that most organizations demonstrate a stage-gated culture, and not the true application of any sort of process at all. That's why they look to SAFE. The barrier to entry is comparatively low,” writes Mitchell. 

“The Scaled Agile Framework appeals to large corporations. It has currency in the boardroom…” he adds.

So next time the builder suggests a planning day, you might want to take him seriously. If nothing else, it could tell you from where the hidden costs might come and determine the risk in your ideas. 

Likewise for SAFE. The planning day will probably not deliver a perfect vision of the future, but run well, it should reveal all the warts, carbuncles and scabs obscuring the view. Focus on those items. Worry less that the actual plans will be wrong, and focus on revealing all the impediments.

Agilists should never be suspicious of revealing ugliness, it gives us focus for improvements and a transparent reason to wield a big mop and bucket.

By William Knight

Good technical skills not only help you take pride in your work and produce error free software, they can also boost the team’s happiness. Let’s take a look at just one aspect: CI or Continuous Integration.
 
It’s funny how things work out. Last week I posted a blog on how agile philosophies can promote a team’s well-being because they align so well with the things that make most people happy. And then over the weekend I saw that Dave Fecak writing for DZone (a famous Developer EZine) had conducted a survey on developer happiness.

There’s a mine of good information in Dave’s article and I recommend you read it. But since CI (Continuous Integration) has become a bedrock of technical practice – and hence a first level agile technique – I asked for a few of the source statistics and kindly received a reply.

Five hundred and four DZone readers** responded to the Continuous Integration question and of those 280 did CI, and 224 didn’t.

Of the 280 that did, 67 were happy, 150 were average happiness, and 63 were unhappy.

But, of the 224 that didn't do CI, 23 were happy, 111 average, and 90 unhappy.

“So the number of unhappy [people] in the non-CI shop were almost 4 times the amount of happy,” Dave Fecak says. “Thus, my theory that CI doesn't make developers happy, but the absence of CI might make them unhappy.”

Why might this be so? Using the SCARF model of Status, Certainty, Autonomy, Relatedness and Fairness, here are a few potential reasons:

• CI helps teams finish their work and reduce surprises just when they want to deploy working software. It means a team can be confident in its estimates increasing certainty and improving status.
• Teams employing CI will blame each other less i.e. it is fairer, because CI increases transparency for everybody.
• CI usually includes an automated test suite. As such code will be better and more fully tested increasing Certainty and Status.
• Good CI will include deployment to test environments meaning teams are more autonomous than when they hand over to others for deployment.
• CI dashboards are a centre for communication meaning teams are better related and can share status or fairness concerns.

I don’t think Dave Fecak’s results are an accident. Good technical practice is essential for mastery of software delivery and CI is a critical technique. Done well it improves quality, efficiency and communication which enable teams to work better, collaborate better and resolve issues faster.

Of course CI keeps you happy.
 
**The audience for this survey was DZone readers mostly or people that read about it on Twitter. “It's not a perfect study by any means, but I thought the results were interesting,” says Dave.

The latest research into what makes people happy intersects neatly with agile philosophies and good collaborative practices. If you want the best from your teams and you want them to be content, you’d better go agile.

Grumpy, uncommunicative work places are a scourge in digital and IT departments. I’ve worked in offices where retrieving a ‘good morning’ was cause for celebration and where a chat round the water cooler was frowned upon as disturbing the work ethic. But common as these things are, they do not help the well-being of staff, do not promote happiness and cause distress among the very people that are supposed to be making a difference to the organisation.

Modern Happiness

​We all know that digital technicians and IT people are fabulously well paid. This is important for recognition but it turns out to be far from the most important factor for predicting happiness.
In David Rock’s excellent book How The Brain Works, he sets out five parameters for mental well-being in work situations:

• Status – how do you compare to your peers and colleagues, are you taken seriously?
• Certainty – what is coming and when?
• Autonomy – are you in charge of your own destiny?
• Relatedness – do you have a shared vision?
• Fairness – are you treated fairly?

Happy agile workers

Agile teams, and Scrum teams in particular, are encouraged to relate to each other, do not blame but look for solutions, and follow a strong vision. Team ceremonies build trust, continuous improvement is highlighted through regular retrospectives, and the commander’s intent, or sprint goal, gives certainty. A well performing team is in charge of how it builds solutions and the work it chooses to do (i.e. it is autonomous).

Agile promotes communication, vision, excellence and well-being through its rigorous processes, and attention to transparency. It turns out these are the very things that make most people happy.

And we all know that happy people are productive people.

Personal organisation is not the strong suit of everybody. But here is a mechanism to get your small tasks under control without becoming attached to agile zen, tied to trello, or upset by updates.

It takes an excellent imagination to see how to profit from getting all your little tasks organised, so you can guarantee you’ll finally get round to completing them. But those creative enough to work out they need organisation, are often the very last to ever put it into practice.

Apparently, there were 14 reasons to get organised in 2014  and who knows, there might be 16 this year (2016). But most of us can agree that being organised saves us time and reduces stress.

But in work I am embarrassed to say organisation has not always been my strong point. I’ve tried electronic tools and find them frustrating, and I’ve seen personal organisation mechanisms, like that one with the elephant, and the filofax come and go. Yet I have always dreamed of a perfect future where all my jobs are prioritised, never forgotten and always transparent. 

In The Key Habits of Organization, on the excellent zenhabits site, Le0 Babauta says, “…when I get my system down, and the habits are on track, things are smooth, I feel good about what I’m doing, and I’m much better able to let everything else go and focus on what’s in front of me, confident that everything else is in its place.”

I too would like a bit of that, but the simple lure of pen, paper and stickies is strong with me; electronics will not work.

Now I tried the Kanban for One desktop board for a while, but found it inflexible with its photo-frame form factor. I wanted a mobile version that could go with me and act as a conversation focus. So I have invented  --  with a little encouragement and help from my colleague Julien Thomas -- a folio Kanban board.

Like a traditional folio this can be used to carry documents, but it also includes a handy Kanban board perfect for the smaller size post-it notes and stickies. Print it out in A3, or, if you can, use the folio size to give a little extra real estate.

I use one for each client I work with and sometimes one for each team or individual I coach. I use them to visually show others what I will be doing next and let my mentees see that I am delivering what we agreed. I can be seen carrying the folio from standup to standup marking little stickies and displaying my tasks to everybody that needs to know.
 
Personal organisation must be simple, lightweight, visual and accessible if it’s going to work for imaginative people, and there’s nothing simpler than opening a folder to see what your priorities are. No need to get out a device or search for a wifi connection, folio Kanban gives you organisation, communication and peace of mind. Download it here, or if you live in Wellington, just get in touch and I’ll get you some. (There might be a small print charge for large orders)

glassworks_folio_kanban_template.pdf
Download File

It's an experiment, but to promote the upcoming Agile Blog in, I have created this little video explaining how I use the Six Ps to create and finish a narrative style blog post. 

To explain, the Wellington Agile Blog-in meetup, is a dedicated time set aside to write a blog have a drink and some crisps. Too many of us want to write blogs but find it difficult to get started, let alone finish. But Blogging is so very important these days, whether it's for self promotion or so that your team can explain itself in confluence to your stakeholders.

So the blog-in is a way to instil just a little bit of discipline while meeting new people and having some fun.

You can find out more at the meetup site: Wellington Blog In

I hope to see you there.

By William Knight

Now I know I’m not alone in being a bit crap at starting blogs. When pondering this issue with colleagues, we came to the conclusion that time put aside for blogging once a month might be a solution.

So the Wellington Agile Blog-In was born. A monthly, or so, meetup for would-be bloggers to get together and actually produce a blog, in the time it takes to eat tea and watch two episodes of Coronation Street.

On the night, we’ll dive straight into the blog pool deep end. As an ex-journalist with credentials from The Guardian and other broadsheets (quick bit of self-promotion so you know I have at least some experience) I’ll do a rapid talk on how I approach blogs and discuss the six Ps of blogging: Purpose, Plan, Produce, Polish, Publish, Promote