STOP TECHNOLOGY STEREOTYPING: Developers ain’t cyborgs buddy, they are artistes!

Man, sometimes the smallest bit of ear wigging – sorry – I meant unintended observation – can give you the greatest of light bulb moments.

So I’m sitting here drinking a protein shake.

Chocolate chip cream infusion.

Sounds more like a frappuccino right?

It is a frappuccino.

So I’m drinking this high calorie,sugar fulled, high fat, artery clogging milkshake that will spike my sugar levels & make me feel like god for 3 minutes & then turn me into a lifeless corpse.

I have no issues with my choice in fattening,disgusting beverages which will contribute to the death toll of human’s through some cardio vascular related disease.

Completely comfortable here, no insecurities.


The heads of sales walks into the room. He’s talking to one of our UI/UX guys (a designer), he says…

“Yeah, Pete following what we spoke about. What I’m after is something really punchy, something clean looking that delivers the message of being hip but professional you know?”

blah, blah, blah – but the next line killed it for me.

“Yeah, yeah sounds good Pete. I mean you’re the designer so how you make it sing, that’s your thing so yeah… go for it!”

Let’s just be clear on what happened here.

So, a customer walked over to the designer & told ’em what they wanted, what their goal were WITHOUT prescribing ANY kind of solution.

INFACT – the customer made the point of the designer bringing their creative juices to the table with the “that’s your thing… go for it!”.

How comes we don’t see the SAME customer, approaching developers with the same mindset?

That guy in sales will approach a developer with a request & the conversation will go something like this:

“You see Tim, what I need is a little pop up box here & when it pops up right I want there to be two little buttons on the box which allow you to either say yeah I’ve done that activity or actually I want to dismiss that activity”.

So sticking with the format we had above (when the customer approaches the designer, let’s apply it to how the customer approached the developer).

The customer walked over to the developer & told ’em what they wanted, how they wanted it & prescribed a solution.

Are developers seen as cyborgs who need to be told WHAT & HOW?

Do they have no creativity?


How come the designer is told the goal & is given a reign on how to deliver that goal WITH NO SOLUTION – BUT the developer is NOT told the goal, is NOT given a free reign  on how to deliver the goal & IS PRESCRIBED THE SOLUTION.

Stereotypes of developers being cyborgs


Just because developers write ‘code’ that you don’t understand or do ‘techy’ things which you in the business might not care for – that does not mean that they are not creatives.

Developers ARE creatives.

Creative people are NOT just those who have a fancy set of colouring pens that can draw cool funky pictures and logos.

I’m not trying to patronise, I’m just saying we need to think of creativity in a much broader sense.

And no, I ain’t looking to open up the can of worms that is defining what creativity is.

For me, when there are a 1000 ways of getting to a goal, then that suggests that it takes creativity in the number of things which we can consider to deliver that goal in an awesome way.

If those 1000 ways have been practised & apply by experts in a particular field, is it not a good idea to support their creativity to get me the best solution?

I mean really?

If I was a CEO who’s life blood was built upon technology – technology which is used by a group of guys day in day out – technology which a group of guys have studied, applied and continue to study & apply this technology in 1000’s of different ways to do awesome things – would it not be a good idea to simply tell these technologists what I want as a business goal & LET THEM use their creativity with the technologies that they are experts in to DELIVER my business goal?

What would give me a better product?

A product which is developed by a team who have been empowered & encouraged to utilise their creativity in their chose field (technology) to present to me a variety of options on how they can deliver me a great product?


A product which is developed by a team who have had no encouragement to utilise their creativity, are fed solutions by people who are not experts in their chosen field (i.e the business telling technology how to create stuff) – and therefore having limited options in how a great product can be delivered.

I think we know what we’d pick.

We need to realise that developers are creative technologists.

They are experts in their chosen area of technology, they understand the technology, they know how to utilise their choice of technology in many, many different ways to achieve different desirable outcomes.

It is in your interest to treat your developers like you would your designer.

Challenge your technology stereotypes.

Even if it means kitting out development with  soft, round, flat-crowned,hand-knitted berets speaking in a french accent wearing cashmere roll necks who wear bright coloured socks.

Did someone say stereotypes?



Ahh the sweet smell of creativity!


Bin your sins or stay blocked – illustrating annoying context changes on your Scrum Board to promote change!

Recently I was working with a team that were dealing with a number of disturbances.

When I say disturbances I’m talking, the sprint kicks off & Unplanned Work comes in.

Is that unique, is that unacceptable?


My view, Scrum teams need to have all the support in the world to ensure they are left alone to deliver the Sprint goal.


Scrum teams also have to provide some level of a support function when it is needed for multiple reasons.

1st & 2nd line can’t resolve an issue impacting a client in production.

Something just exploded in Production and no ones noticed yet, but it needs gravitas from a Scrum team to help support nail the issue.

The sales team need to confirm business logic on how something works for a pushy client & the only guy that knows is Bob in the Scrum team cause he’s been in the same company for 10 years.

And so.

I ain’t saying we should have a stream of Unplanned Work.

I am saying I understand the nature of delivering a project (the sprint work) & helping the business keep it’s wheels on (the support work).


When the disturbances are constant.

When the disturbances involve pulling developers off of work they are working on to address issues.

That’s expensive.

Expensive because it involves context changing.

I would like to show you a mini case study of a team who were made to do this allot & what we did about bringing this problem of context changing to the attention of the Product Owner.

I’ve simplified this board to give you the focus on one developer’s pain….

Tim is working on Story 1. There are 2 stories, Story 2 & Story 3 which are blocked.


An unplanned piece of work comes in. The PO has explained that it can’t wait and needs attention ASAP.


Tim stops working on Story 1, and picks up the Unplanned Work. Story 1 is then placed into the ‘Blocked’ box.


Tim is working on the Unplanned Work when suddenly the Product Owner comes over and explains that it’s “vital that this ‘request from the business is handled ASAP -since a customer needs to know the answer to a question which only Tim would know”.


Now the 1st Unplanned piece of work goes into the Blocked box & Tim begins working on the new Unplanned Work item.

Now take a good look at the Blocked box.


Does that look right to you?

Does it seem right that we have stories & Unplanned Work placed into the Blocked box?

It didn’t sit well with me.

The fact that we were not illustrating that there was a problem.

A problem in the high disturbances we were receiving.


Here’s the 1st thing I did.

Some healthy antagonising 🙂


Sad smileys anyone?

“Why do we have sad smileys on those cards” asked Tim in the Stand up.

So we had a discussion, with me asking the below question to the team:


We were hiding dysfunction through misusing the Blocked box.

Think about it.

When something is blocked its an external dependency & we accept that the artefact belongs in the Blocked box.

But when someone is pulled off an existing piece of work to do ’emergency’ stuff a la Unplanned Work – that item is not Blocked.

If I am working on something, and I am pulled off of that something and made to switch context, then that item belongs in one place and one place only.

Meet the SINBIN.


This is a quick, easy modification to your board which shows how many times the team have been disturbed/pulled off whilst in the middle of something to handle an Unplanned Work item.

Here’s how our Unplanned Work items look now.


Now we have clear distinctions between work which is truly Blocked & work which has been Sin binned.

When that SINBIN box begins to mount, nudge your Product Owner…

“Looks like we’re pulling off the guys to deal with Unplanned Work, all that context changing isn’t healthy…. it’ll most likely effect our Sprint goal”.

This is how we need to handle Unplanned Work which forces developers to be pulled off existing work.

Every context change impacts the effectiveness of getting a card through to done.

We need to show on our boards, the frequency of these types of requests to drive home the point that context changing slows us down.

Scrum – Let’s stop talking about speed, let’s start talking about what’s possible.

Scrum is the art of the possible.

Let’s talk about what we can really deliver WITHOUT ever compromising quality!

Getting ‘more’ story cards over the line which do not have quality built in only means more defects & an application which will become harder to manage and sustain.

That’s a blocker for Agile delivery, since we need an application which has been built that is easily maintained & allows easy changes to be made.

Let’s stop talking about speed, start talking about what’s possible.

Behaviour Driven Development – How to actually BDD! No tech skills required :)

What is your approach to creating acceptance criteria ?

How do you describe the expected behaviour of the requirements you capture?

Maybe your a business type who complains that IT ‘don’t make things work the way you wanted it to’ or  a business analyst who finds its hard to best describe what ‘stuff’ should do.

Or maybe you’re a developer who’s writing code and you’re constantly having to go back and make changes because the AC isn’t what you ‘thought’ it was.

Before I go on, let me put it out there from now –

People will always misinterpret things. Interpretation is an individual way of processing information & so there is always a chance of people seeing things differently -even though their looking/listening/experiencing the same thing. The only thing we can do is reduce the likely-hood of misinterpretation – not eradicate it!

So maybe the real question is…

How do we explicitly explain what the business want to help developers get it to as close to what the business want – as humanly possible!


Its called BDD.

Behaviour driven development.

BDD is more than an approach to acceptance criteria writing – its a technique that was introduced to deliver (to quote the creator Dan North) ‘well crafted software’. There are a few facets to BDD but I’ll be focusing on the acceptance criteria part in this blog. So lets get some specification by example going.

First, we need a case study for us to example on.

So lets say that a company  (Sky maybe) wanted to stream the olympics from a smart phone app but want to ensure that users streaming the live Olympic event were informed on the TV Licensing laws to actually watch Live TV from their phones. Lets first knock up a story for this requirement:

Here’s an example: 

#Story 1

Title:  Customer with TV Licence

As customer with a TV Licence

I want to view Live video items

So that I can watch the Olympics

Great we have our story. Now this story could have a few behaviours. Lets look at modelling the first scenario, for those users who do have a TV Licence, or at least say they do 😉

Scenario: 1

Given I have selected a live video Item

When the pop up box appears

And I select

|Watch Now|

Then Launch the selected Video

There it is.

Given, When, Then.

This is a very powerful approach to describing behaviour. When a developer picks up this user story and spins the card round, he/she has a pretty good idea of what the expected behaviour is for customers who do have a TV License. Lets create another story for those customers who do not have a TV License:

#Story 2

Title: Customer with no TV Licence

As customer with no TV Licence

I want to view Live video items

So that I can get a TV Licence to view Live TV via the I-Player

Scenario :1

Given I have selected a live vide item

When the pop up box appears

And I select

| I don’t have a TV Licence|

Then take me to the below URL:

Hope the examples inspire you to try it out 🙂


Try removing your QA section to get MORE done!

So this was the problem we were seeing:


Look familiar?

QA field jam packed with stories?

Finding out about issues (stories created during sprint) at the end of the sprint?

Seeing hangover at the end of your sprint?


Maybe your QA got sick.

Maybe your QA was more busy than normal with support requests.

Maybe your QA was spending time writing acceptance criteria with the PO for the next sprints set of stories.

Or, maybe we need to stop thinking as the QA as the only person who can QA work.

Acting as teams, not individuals 

Scrum is about teams & that means we ultimately need to think about what WE as teams are trying to accomplish. Team goals should be the most important thing in any Scrum team.

That’s what makes Scrum so powerful, you got this disciplined timebox with a specific focus, a goal, which a team work together to deliver.

When we focus on our individual goals over the team goal the Sprint goal suffers.

Delivering the message

When I saw the QA bottlenecks, I asked at the stand-up:

Looking at the board this morning, we need to ask ourselves that question. What can we possibly get through to Done today?

It was my way of hinting that there is plenty in the QA section available to be tested.


The bread and butter of any optimised approach to delivery is focusing on whats in progress to increase throughput.

Something that Kanban principles push hard.

So we can ask the team to focus on getting ‘In Progress’ cards delivered first before picking up new Sprint backlog items.

Developers can QA each others work, so checkout the QA section first to bring down that bottleneck & get stuff into Done.

But we can still reinforce this message to create the right behaviour!

How to visually bring the message home

Change your board.

Remove your QA section.

Here’s one I prepared earlier:


Now when a developers done with his user story, he/she can push it just a notch to the right which means the story is STILL ‘In Progress’.

That is a subtle but powerful visual representation which says “Hey just cause we have done our part developing stories, the stories are still In ‘Progress’.

Pockets full of power: Physical location counts in Scrum.

I  promised myself that I wouldn’t get too precious with how perfect my blogs are before I hit publish.

So here you go.

This is a nice example of a Scrum transition I just worked with in creating Scrum teams.

We had physical  rows of the same people sitting together (The Design desk,The Product desk, The QA,Desk , The Developers Desk)

We needed little pockets of different people sitting together.

Cross disciplined little pockets of people.

And thats what we did..


Its basic.

It’s also very powerful.

The physically located pockets of people makes Scrum powerful.

Power is the ability to act.

When we are physically located in our Scrums we are exposed to all the information we need, to be able to act!

“Oh that User Story isn’t quite like that”

“Ahh I got an idea for that implementation!”

“Nah, the GIVEN, WHEN, THEN should go like this…”

We need to overhear things, we need people local to us so we can be bothered to ask questions, decipher things, bounce ideas & so on.

The best Scrum teams don’t just exchange information in their Scrum events (Stand ups, Retros)


They exchange information continually.

That’s allot easier when your physically located in your Scrum team.

Get moving!


What the hell does a chief Scrum Master (CSM) do anyway?

Ok, I get it.

On the surface it sounds like some sort of moronic contradiction.

When I first heard the CSM role I thought to myself, ” How the hell can you have a ‘chief’ ScrumMaster role?”

It made no sense.

Scrum is a framework built on servant-leadership, a flat hierarchy, the focus is the people not the creation of people who need authority in their titles.

Scrum ain’t about power in titles.


I feel ya.

To me to, it felt weird.


And if I’m honest I’m still not 100% comfortable with it.

But….my role simply evolved into what it is.

Maybe this blurb can give you some insight as to what this role actually is, does and why I can see the value in a Chief ScrumMaster role.

Let’s start from the T.O.P

You join a place where Scrum does not exist.

You’re given support to hire, create & facilitate the creation of a Scrum team.

In parallel you introduce the organisation to Scrum. 

Top down, bottom up, sideways.

Explain the empirical approach to software development, the Scrum framework, the buzz terms, the essence the mind-set.

Agile Evangelist to some.

Agile terrorist to others 🙂

The Scrum team gets up and running.

3 months in, the team have the fundamentals down. 

They know the Scrum events, understand the Scrum artefacts, have a good understanding of empiricism…you get the picture, they’re starting to look pretty solid.

Yep they’re a little rough around the Scrum edges.

For example sometimes say, in the stand up, they make a few errors (they miss something stuck in blocked or maybe they ramble on a few times when they need to off line stuff etc) but all in all, although different people have different experience levels in the Scrum team – as a team – they can pull it together and self-organise. 

You encourage ‘em to think about their own ScrumMaster.

The new ScrumMaster emerges.

The business is scaling.

You hire new players, you help facilitate the creation of Scrum  no.2.

Again, different developers – different experience levels in the tech & framework of Scrum.

You work closely with the new Scrum whilst being there for Scrum 1 to provide feedback, guidance, ideas – just making sure they get that support they need to stick to Scrum principles (Maybe the PO’s not ‘letting ‘em’ pair program – maybe hard dates are being set by the business without engaging the team…good old Scrum challenges)

Whilst this is all going on, you’re trying your best to educate from the top down.

Any chance you get – you’re actively speaking with the business, the head of sales, the head of marketing, the CEO, the COO – whoever, however – you’re trying to champion Scrum. 

So Scrum 2 are getting the Scrum mindset down as well, maybe not as quick as Scrum 1 so you hang around and work closer with ’em to guide a little more.

In the interim you’re being told about a new Product that the firm want to work on.

It’s a mobile device.

Again, we’re back to hiring, creating & facilitating a Scrum team.

So at this stage, you’re facilitating 3 Scrum teams – 1 team has a ScrumMaster, 1 team’s still trying to get there & 1 just got created.

So, who are you at this point?


Well you’re not the ScrumMaster exactly because you’re floating around multiple Scrums doing loads of different things – it’s fair to say that you aint  dedicated to one Scrum.

You seem to be spending as much time educating on Scrum and fighting the uglier battles (stuff at the top down) more than being in the trenches with the Scrum team doing the good old ScrumMaster stuff (y’know, talking about what user story contains the solution, or facilitating the power of 3 discussion when stories get picked up, not being the guy who facilitates the planning poker session, not being the guy who tallies up key metrics at the end of the sprint etc)

It feels like you’re pushing the Scrum mindset at a higher level, for both the Scrum teams and to the key ‘senior’ stakeholders who directly impact your scrums (i.e. stopping sales from committing to low level features – educating on how to deliver through themes and that Scope can change etc)

At different points your hands on: maybe you go along to a Sprint planning meeting since scrum 2 always seem to over commit, or you join a refinement session because Scrum 1 are lacking the right amount of detail in their backlog at the right time.

It’s a constant act of dipping in and out at the micro level across the Scrum teams to give support, guidance or enforce Scrum rules.

And then zooming back out at the macro level to try and keep the education piece of Scrum moving amongst the business & at board level to make the transition towards Scrum organisation wide, easier.

It’s a really challenging but satisfying role.

I didnt start out asking to be a CSM.

But after growing & facilitating 1 Scrum team, there was a further need to hire and grow another.

And then another.

The scaling was fast and continues to grow.

It felt like the next natural step for my existing role within this organisation to have a backseat and help when necessary (at the micro level) but to help push the cause of Agile constantly (at the macro level).

Kinda tricky but if I could summarise what it means to be a CSM, I’d go with the below!

To me, the CSM role is and has involved:

  • First and foremost tirelessly pushing Agile across the organisation – Proactively educating from bottom up (Sticking to the rules of Scrum or the agreed Kanban process) &  top down  (presentations, informal chats, invitations to events etc)
  • Creating the right environment to allow Scrum teams to work effectively –  Making sure Scrum teams can physically sit together, having the right ingredients to each scrum team available (PO, Dev, Design, QA), slapping down whiteboard paint as much as you can to encourage system thinking, doodling, general interaction points everywhere etc.
  • Supporting & feeding back to ScrumMasters – learning from one another, helping when Scrum events are being compromised (be it tech team or business challenges) hearing their pains to open a dialogue with senior heads in the organisation to address the root cause of problems to effectively drive change (“we’re not getting a clear picture of why we’re doing this work from the PO”, “We’re seeing the business commit to stuff we do not know about” etc)
  • Helping to create a good rhythm between Scrum teams – Feature driven Scrum teams may need fellow Scrum teams to make changes or support their changes to get what they need – this is about knowing the refinement schedule of fellow Scrum teams to get your needs placed into their backlog. So rhythm in respect of timing,  getting work booked in before their sprint planning meeting for one example.
  • Driving the Scrum of Scrums – Again, changes from one team can effect the other. There needs to be a commitment from teams to meet regularly to mitigate risk, reduce duplication of effort and of course bounce ideas!
  • Creating a council of Scrum excellence – This is about getting the senior heads from Marketing, Sales, HR, Operations, all together so that you can educate, gain support to drive a Scrum transition organisation wide.

I know for sure there is allot that I’ve missed from the CSM role but if I were to only write blogs when I knew everything than I’d probably end up with empty pages!

Nothing like a working prototype to give immediate value to customers ;p

The CSM does work, it allows you to be hands on and off with your fellow Scrum teams whilst championing & driving the Agile transition.

It’s a very cool role.