INVEST a little more in your stories


I’m a big fan of the INVEST mnemonic, which encourages agile story authors to make their stories Independent, Negotiable, Valuable, Estimable, Small and Testable. There are plenty of great sources for more detail, so I won’t rehash them here. Having introduced a number of teams to INVEST I often find I need to follow up with three more items.  Leading to the notion of INVESTpul, and yes, before you say it, I really should figure out a better backronym:

Provoking – A good story provokes conversation, it is a much an expression of wish as a challenge, how can this goal best be achieved given the constraints the team operates within?  All too often this element is lost, and work becomes about churning stories, regardless of their value, with the dangerous assumption that all the quality thinking has been done already. Opportunities present themselves in different ways throughout an iteration, and we should remain alert and ready to seize them, to pivot based on new information.

Ubiquitous – The language of stories should be readily understood by the team, its stakeholders and drive-by observers. Drive-by observers are often influential, and may even be the ultimate sponsors of the team, packing up late I often see evening board walking by the leadership team. Their support of the team, and agile, may be effected by how well they understand stories, and the impression they get from the board carrying them. Ubiquitous language discourages technical terms, the presence of which often indicates that a solution to the story has already been agreed, diminishing connection to the user and narrowing the team’s potential to find other ways of achieving the same aims.

Legible – It seems incredible that this needs saying, but it does. It should be possible to read stories easily, this doesn’t just apply to handwriting, it means using sensible fonts when printing cards, and avoiding cramming information into small spaces. The ideal story card passes a three foot test – it can be read by anyone participating in a board based discussion, like a stand up, which necessitates some members standing about 3ft away

The Six Foot Test
While we’re on the subject, another distance themed test I like relates to the overall board. The six foot test is simple; from standing that far away what could someone learn about the team’s work?  That distance is deliberately chosen because generally you can’t read individual story cards, putting focus firmly on flow and the system of work. It is particularly useful to forget what you know and don a stakeholder hat for this exercise.  At a minimum I would hope to be able to determine the following:

  • The team name
  • Their high level goal
  • Amount of work in progress
  • Phases or stages work passes through.
  • Who is doing what
  • Which work is blocked, or needs help

From the appointed distance I’d also look around the board, the presence of artifacts like definition of done, column policies, burn down charts and metrics are positive indicators.  Another interesting aspect is the presence, or otherwise, of playful elements, often these are reflections of trust and safety within the team.

So that’s how to write INVESTpul stories, along with some bonus musings on good board practice. The author Antoine de Saint-Exupery once said; “Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away”.  So tell me, what would you add or remove from INVEST?


Why is a Spike called a Spike?


Unusually for an agile practice, it appears practitioners largely agree on what the term ‘spike’ or Spike Story describes:  a brief, focused effort to answer a question, explore a concept or investigate an issue.  Fortunately the unsettling feeling of general agreement is quickly displaced when we try to agree the origin of the term.

Kent Beck is generally recognized for introducing ‘spike’ to software development parlance, as part of the XP movement. However, he has not been forth coming on why that particular word was chosen, at one stage even avoiding the term because it was too nuanced:

Because people variously associate “spike” with volleyball, railroads, or dogs, I have begun using “architectural prototype” to describe this implementation.
Guide to Better Smalltalk:

It is interesting too that Cynefin, much of whom’s focus is on experimentation chooses not to borrow the term spike.  Understanding the source of the term is useful, and potentially interesting, given how often the concept is illustrated by real word example.  Listed below are some of the definitions I frequently hear, do let me let me know if you’ve heard others!

The Mountain Climber – A spike is another term for piton, used to anchor oneself to a rock face.  If the piton in secure it is safe to take that route and hang more gear (and actually yourself) from it, if not it’s time to find another path.

The Railroader – Even within this single domain there are at least two derivations.  A spike is a huge nail used to secure track to sleepers, hence ‘spiking a track’ – in order for a train to move safely over newly laid rail.  Secondly a spike, or similar shaped wedge may be used to hold open a point (switch) and set the direction of subsequent traffic.

The Geologist – A spike is a kind of probe used to assess the layers beneath by inserting a hollow core, which fills with material, withdrawing the core, and inspecting the resulting sample.  From this a geologist may determine if there is firm foundation to build upon, or if there is anything of value to extract.

The Sci-Fi Fan – Named for the Buffy The Vampire Slayer character, a Spike disregards team norms and provides an excuse to go it alone with a focus on what is cool, often leaving behind a trail of destruction for others to deal with.  Actually, I just made this definition up, but all too often I see these behaviors.

The Builder – This definition, from Ron Jeffries, appeared during a debate on Stack Overflow: “Spike” is an Extreme Programming term meaning “experiment”. We use the word because we think of a spike has a quick, almost brute-force experiment aimed at learning just one thing. think of driving a big nail through a board.

The Electrical Engineer – This one I remember from my brief time as an Electrical Engineer, in the days when it was far more necessary to tinker with hardware to support our software habit.  We used to spike relays to hold them on or off, isolating part of the circuit as a temporary measure to assess behaviour and assist problem solving.

The Statistician – I’m sure you’re familiar with this one; when charting a values over time a spike is a sudden sharp increase in those values, often of short duration.  When monitoring production systems this sharp rise frequently correlates with increased shouting and coffee consumption.  In terms of a spike story then, this is a burst of effort towards a goal, a sprint within a sprint.

Of course, there is another option, one that perhaps we’d rather not consider.  Thanks to a cognitive bias we all have (yes, even you) called the Halo Effect, we are prone to liking or believing things from certain sources.  Simply because we believe the term ‘spike’ was coined by a person we admire and respect we believe it must have a respectable and admirable definition.  I’m afraid it is entirely possible that little thought was given to the term, the wrong word was used, it is an in joke, or that the reference is something only the author would understand.  Luckily for agile and XP practioners everywhere, we’ll probably never know.



An introduction to ChatOps

I first heard of something resembling ChatOps about five years ago when I had the good fortune to share a beer with Scott Chacon, one of GitHub’s co-founders, while I ranted about Deming, he talked enthusiastically about their fledgling organization.  Surprisingly, one of the things he talked about with most passion was Hubot a sort of robot butler who hung around in Github chat rooms serving useful data and whimsical content with equal aplomb.  It seemed a great concept, simple and powerful, it improved operability whist increasing knowledge sharing and encouraging collaboration.

I often wonder why chatOps doesn’t garner much attention, especially as it appears to have played an important part in GitHub’s success.  Perhaps that’s because everyone is gazing adoringly at Docker, or perhaps because ChatOps sits discretely and indistinctly on the boundary between Culture and Tools.

By way of introduction ChatOps combines three key technologies: Asynchronous Chat, Robot Assistants and Automation; let’s spend a moment looking into each.  (The pictorially minded may prefer to spin through my spring DevOps Summit talk where ChatOps was one of my ‘Collaboration Catalysts’.

Asynchronous Chat
Asynchronous Chat needs no introduction, it allows people to congregate in a virtual space to view and post messages and media.  These apps are a good way for a distributed team to collaborate, but there are more subtle advantages – chats can be saved enabling a searching and reference.  Chats allow broadcast, without the publisher having to manage their audience.  You’ll understand the value of this if you have ever been trying to chase down a gnarly production issue with your manager over one shoulder and Project Manager on the other asking for updates.  Oddly, the speed of work does not increase with the frequency of update requests, quite the opposite in fact.
In this situation chat could be used to broadcast progress, without having to manage a distribution list, when people monitor chat, the originator doesn’t get distracted, and may even get proactive support.

In the context of ChatOps it is chat apps which can be readily extended that really matter.  That’s because many of the operations performed will be specific to an organisations and it’s systems, processes and integration requirements.  HipChat FlowdockSlack and Campfire are popular options, and choices are often driven by the lingua franca of the development team.

Robot Assistants
Robot assistants lurk in chat rooms waiting to do the user’s bidding.  They may wait to be summoned by a specific command, or step in when they think it’s needed.  Assistants may grab things, like logs from production, or find out who is on call.  This reduces the interruption cost for a user, who is already thinking and collaborating in chat.

A good bot also recognizes the value of play, amusing features are almost mandatory, from adding a mustache to a photo, meme generation to playing tunes.  A useful side effect of this is it encourages folks to hangout in chat rooms, humor keeps people engaged, and generally engaged people are more productive and ready to innovative.  Notable bots include LitaHubot,  Err and Stack Storm.  Iron Man’s J.A.R.V.I.S is similar in concept, but somewhat less likely to inundate you with pictures of small miserable faced dogs.

By way of an aside, Terri Winnograd, who later went on to mentor one Larry Page, pondered the utility of robot assistants as early as 1970.  Perhaps he had a premonition of clippy when he wrote:

“I should reiterate that good programming systems do not demand a super-intelligent program. We can get by with a moderately stupid assistant as long as he doesn’t make mistakes. The degree of Al needed is much less than that needed for a full-fledged natural language or vision system”

Automate, mate.
The third component is Automation.  Hooking the bot up to automation, and other deployment and operations tools, is where things get really interesting.  If a bot can integrate with search engines and meme generators, why not link it to development environments, perhaps even production?  Then, if people are discussing a thorny deployment problem they can call in logs, graphs and pertinent data.  The chat room, becomes the war-room; distributed, observable and documented for later learning.

Perhaps the pinnacle of ChatOps is allowing deployment orchestration through chat.   As Jessie Newland describes it succinctly in his highly recommended ChatOps at GitHub talk “Chat becomes the primary control surface for ops”  not only is it is convenient, but a chat client is more portable.  Chat can also serve as a layer of abstraction over the under laying tech, enabling it to change and evolve independently of the commands driving it.   This abstraction opens an opportunity for training, enabling production commands to be executed against a sandbox.  Of course, there is some risk to be considered, and it is possible to restrict commands to people or rooms.

Still not impressed?  In the same talk Jessie outlines a scenario where he makes a deployment, observes a problem, orchestrates load balancers, fixes and redeploys.  Impressively, it all happens in chat, all while keeping his team updated, and leaving a record, with minimum extra effort.

More than just tools?
Looking beyond tools, ChatOps brings more to teams than mere efficiencies. ChatOps liberates Institutionalized knowledge once locked in the heads of key, time challenged, individuals.  Once in the open, ways of doing things can be inspected and built upon.  This isn’t necessarily a threat to those people; often freeing them up to tackle more challenging problems.

ChatOps can be an excellent training tool.  Like the gallery trainee doctors use to observe a surgeon at work, chats can be reviewed and replayed for education.  Need to know how something is done?  Check the archives, and look at the commands used last time, or ask in Chat, someone can demonstrate directly, and show everyone else at the same time.

Having written this, I realize I have to some extent answered my own question: Why don’t we hear more about ChatOps?

Effective ChatOps requires maturity of culture and tools.  Even small things, like knowing more senior or experienced people are able to see, and potentially respond to, every comment, takes some getting used to for both parties.  The organisation’s culture must encourage the openness which allows productivity to thrive in the chat.  As such, striving towards ChatOps may provide a useful mechanism to highlight organisational and cultural impediments.  To make operational features available in chat requires not just trust, but investment in tech, safely connecting all those moving parts is not trivial.  To the many organizations who struggle to deploy once a month, ChatOps must seem like a distant Nirvana.

Despite the necessary investment ChatOps can bring many benefits, and can do it unobtrusively, at a pace of change that suits the community.  Using Chat as gateway to operations, adding capabilities when it is considered safe to do so, is an excellent way to introduce and observe new ideas.  ChatOps invites collaboration, and not just because it’s novel.  If all the engineers, regardless of title, hang out and work in the same space it helps build an appreciation of other’s challenges and responsibilities, not to mention attitude and sense of humour.


There’s no script for agile – what can we learn from Improv theatre?

It’s always good to hear a new perspective on a seemingly familiar subject, it often provokes thought, inspires action, and encourages change.  Paul Goddard has introduced one such perspective on coaching teams in his book ‘Improving Agile Teams’.  There are plenty of books with similar titles, but the clue here is ‘Improv’ – the book shows readers how improv theatre techniques and games are of benefit to agile teams, both aspiring and experienced.  

I’m confident improv needs no introduction, the likes of Paul Merton, Josie Laurence and more recently, The Mighty Boosch have brought the art to the mainstream. Something you quickly realise reading the book is just how spontaneous improvisers are.  There are subtle cues, and openings the players use to both support, promote, and challenge each other.  Take a look at the expressions on the faces of Ryan Stiles and Jeff B Davis in the first minutes of this Improv-a-ganza clip, you’ll see reactions to unexpected events, and rapid adaptation to changing circumstances.

The idea of using improv techniques to improve team collaboration is an appealing one, the principles of agile and improv seem closely aligned, success in entertaining an audience and working effectively on complex, creative projects requires trust, collaboration, respect and a sense of play.

The book draws out five principles;
Safety – concerned with creating an environment in which teams (players in improv speak) can trust and rely on each other, supporting, encouraging, accepting failure and learning together.
Spontaneity – the business of developing an open mind, to increase creativity and receptiveness to others ideas.
Storytelling – as a method of engaging, inspiring and developing empathy, not just applicable to conversation, but also in user stories.
Status – identifying status, and manipulating it in a safe way to identify issues and further creativity and collaboration.
Sensitivity – the ability to sense, or listen and respond appropriately to others, in order to work effectively with them.

These are novel choices for what must, by extension, be agile principles, but the book explains the thinking behind these, and grounds them in current theory. For instance, in safety pointing out that absence of trust is one of the five dysfunctions of a team .  It’s nice to see Mihaly’s flow model get a mention too.

What I really like is that these principles are used to introduce a improv games and tips designed to further the maturity of teams.  These range from simple, everyday exercises that most teams would be comfortable with, to techniques that may challenge both team and coach.  It’s interesting to run through the techniques, and think “Could I run this with my team?”  if the response is ‘no’ then it’s likely attention to one of the five principles is warranted.

There are fifty or so techniques in the book, some quick and simple and great for livening up stale meetings (like conducting a stand up without using the letter ‘S’) while others require more time, and set to explore a particular area with a team.

One technique is ‘The physic Stand Up’, when team members aim to give someone else’s daily report.  I’ve seen this in action, and it’s fascinating, especially when vociferous people give reports on behalf of more timid people, there’s a strange mix of relief (that’s what I’ve been wanting to say) and shock (did they really just say that?).

I found the status techniques are particularly interesting, especially as it’s an area less explored by agile.  The Dinner Party game is aimed at understanding and recognising status, and the responses it elicits.  In brief, players are invited to an imaginary dinner party, split into two groups and asked to show either high or low status behaviors.  The groups then switch for the same amount of time before retrospecting on the experience.  

Sounds simple?  I’d suggest reserving judgement until you’ve tried some of the techniques, either in a safe environment or on the ‘stage’ of the shop floor.  There are great benefits to be found, experimenting with improv is both challenging and thrilling, the learning is definitely in the doing.

In a similar vein, I’d highly recommend the book Artful Making, an unlikely collaboration been a Harvard Professor and a director/playwright.  It draws agile and leadership lessons from the world of makers, particularly experiences running a busy theatre and working with groups of actors.

An Agile Cambridge Reading List

Welcome to my not-entirely complete Agile Cambridge 2015 book list.  Why isn’t it entirely complete?  For starters, many books were mentioned in passing, Kevlin Henney in particular throwing out quotes and titles at rate so ferocious my free conference biro melted into wispy nothingness.  I’ve listed books which either cropped up in multiple talks or seemed interesting and novel (groan).  Secondly, the list currently captures recommendations from talks I attended – a fraction of the content across three tracks and around fifty talks, tutorials or workshops.  If you think I’ve missed any crucial reads do let me know, I’d be happy to include them.

In all cases I’ve aimed to link to the home site, rather than anyone’s favorite online re-seller

Mindset by Carol Dweck, on building a growth mindset to reach our potential.

Drive by Dan Pink, influential book on motivation, summarized at TED.

Thinking Fast and Slow by Daniel Kahneman, the source of the System 1 and System 2 thinking styles.

Eight Behaviors For Smarter Teams, and Smart Leaders, Smarter Teams by Roger schawarz, A PDF is available here.

Minimum Viable Book by Emily Webber & Amy Wagner, a growing collection of stories from people who create things.

Lateral Thinking by Edward De Bono, the inventor of the technique describes its value, and approaches.

Being Agile In Business by Belinda Waldock, primarily aimed at non-software businesses, but relevant to software organisations, introduces agile with practical methods.

A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware by Gary Gruver, Mike Young, Pat Fulghum.  This book has solid agile and continuous delivery content.

Build Quality In by Steve Smith Matthew Skelton et al (I’m one of the al!)  experience reports from a diverse range of continuous delivery practitioners.

More Agile Testing by Janet Gregory and Lis Crispin, they have a neat mind map of the book, in their words: “two world-renowned agile test experts ask tough questions about agile testing – and provide definitive answers”

Five Gators Of The Apocalypse?

Wacky gators arcade machine

I generally dislike war and military metaphors for team and making activities.   Admittedly IT has a lot to learn from the military in terms of teams and scale, but in the wrong hands these metaphors seem to encourage unproductive conflict and counter-collaborative behaviours. This strikes me as odd because although prepared for conflict, the military spend much of their time avoiding or minimising it.  However, I do need to call upon a slightly violent metaphor to describe the relationship between constraints encountered when building a continuous delivery capability in an organisation.

The process of change reminds me of the nineties arcade game Whacky Gators, where a number of cheeky gators poke their heads out of caves, and you biff them with a large hammer, hands, or other appendage depending on personal preference. You never know which gator will appear, or when, and more than one might show up at once.

When encouraging continuous delivery (and by extension DevOps) those gators might be named: Culture, Tools, Organisation, Process, and Architecture.

These five are interdependent constraints, each affecting the other.  However, while inside Whacky Gators is a fairly simple randomiser determining which gator will surface, behind the scenes our organisations look more like a hideous HR Giger meets Heath Robinson mash up.  We can’t readily inspect them to determine what to change.

My theory is that when one constraint is eased it will reveal a new constraint in a different area. This is a tenet of most agile and learning methods – surface a significant issue, deal with it, see what surfaces next.  Often a method, and our expertise, focuses on just a couple of areas, we’re well versed at solving problems with technical solutions, or just improving our own team’s capability in isolation.

A good continuous delivery capability involves the whole engineering organisation (a great one involves the entire organisation). This means it is crucial to consider all five constraints, and when there is a problem be ready to shift focus and look for the solution in one of the other areas.  In fact, this simple shifting may lead to the root of a problem.  Do reams of process indicate a risk adverse culture?  The solution may not be more process, but a different attitude.  Are those tools covering up or compensating for some thorny, unspoken issue no one dared to face?  When trying to improve delivery capability there may be a temptation to replace an old tool with an improved version, maybe the need for that tool (and associated overheads) can disappear with an ounce of process and a healthy dollop of collaboration?

Returning to our Whacky Gators metaphor, the big question is how are you playing?  Do you simply wait for that same familiar gator to return?  The one you’re most comfortable dealing with?  Do you hover where you are comfortable while other opportunities pass by or, are you nimble, and brave enough to tackle each constraint as it appears?

While I was looking up Whacky Gators, I couldn’t resist a peak in the machine service manual, there I found this uncanny quote on success, as applicable in the game, as it is in change:
“The player does not score extra points by hitting harder; a light touch will activate the circuits and will lead to higher scores.”


Change, Disparity and Despair

Models? Meh.  We all know Box’s quote: “essentially, all models are wrong, but some are useful”, a quote generally heard seconds before someone presents an alternative model to the one you’ve just put forward.  However there’s an undeniable utility to models and diagrams, the way they convey concepts in a fashion that people can quickly understand and start to explore together.

One of my favorite diagrams, and theme of this post, is David Viney’s ‘J curve effect observed in change’.  Change in this instance is just about any planned change that impacts an organisation.  This is a distinct, but close relation to the Kubler-Ross individual change curve.

This J curve aims to show that for any desired improvement in capability (or fitness to achieve some purpose) there will be a decline in capability before there is an improvement.  This is virtually impossible to capture and graph accurately, but we can talk in general terms about transitions, duration in a state and trending.

Annotated J

The Danger Zone
When introducing Kanban David Anderson points out that time and depth an organization is comfortable in the trough reflects it’s appetite for risk.  Push change deeper or for longer, and the organization’s appetite risk is exceeded. End result: change agent gets fired.  Of course this danger zone applies to just about any substantial change, and practitioners of Scrum, DevOps, DSDM and so forth should be just as wary.  A further observation is that if a change is halted once in the trough things don’t magically return to the start state, and a second iteration through the curve is required – starting from a point of reduced capability.

The swan song
In a recent talk I added a hump near the start of the transition.  That’s the point where people hear about an incoming change.  Sometimes, if the instinct is to resist, this inspires efforts to prove original methods can and will work.  Alternative practices are implemented with renewed diligence, energy and fervor often leading to a short term uptick in capability.  This reinforces arguments that change is unnecessary, but will not yield the desired improvements in the long term.

Change Disparity?
While the J curve represents an organization’s progress during a period of change, it makes the assumption that people are moving – or adopting – at more or less the same pace.  In fact this is seldom true, and different adoption rates lead to significant gaps in understanding and approach.

This ‘change disparity’ hampers collaboration and can be as damaging as any silo or clique.

For simplicity let’s consider early and late adopters.  The reasons for being in those groups may vary greatly: work allocation, meddling by people with influence, environment, personality, good or bad luck.  Unaware of circumstances both groups get frustrated. There’s a temptation to say the late adopters are at fault and should hurry-up, but running too far ahead and expecting people to keep up, or ‘just get it’ regardless of circumstance seems no better.  This is common with technology zealots, characterized by a disparaging attitude towards people not using their tool of choice, or voicing concerns about it.  Of course this reaction actually discourages adoption, and serves to hinder the change they would like to bring about.

The awfulness of the situation reminds me of the Inuit game ‘Ear Pull’ in which two players face each other, linked by a string around their ears, and pull.  In opposite directions. You can almost feel the pain in this clip.

Ear Pull Leroy

Note the string does not cause pain by itself  – it’s pulling in an opposing direction, forcing another to follow at a rate they are not comfortable with.  If both players agreed a distance, or form of feedback, they could move together without discomfort.

This is something to consider when introducing change, new tools or ways of working.   This adoption gap, or Change Disparity, is easily overlooked but potentially damaging.  There are numerous solutions, but it all starts with recognition of the problem, when rates of change are outside productive limits, and willingness to do something about it.