Agile (Scrum) Coaching for UK GOV

I’ve been providing some Agile coaching to new Scrum Masters at a major UK Government Department (HMRC) and I was surprised by what I found.  Here’s a link to the blog post I put on the HMRC Digital Blog which outlines my experiences….

Posted in Uncategorized | Leave a comment

The Certainty Retrospective

Keeping up the theme of posting on new and innovative Scrum retrospectives my latest attempt to inject both humor and value hit the button last week.
This one worked because the project team was moving across project phases, we’d just finished one and were moving into the next. As a consequence of this there was clear shift from working in the “comfort zone”, with tools, people, activities and the like that everyone was clear on, into something much more uncertain – new tools, people and activities. Basically breaking new ground.
I detected by “walking the floor” (that most essential of Scrum Master skills) that there were maybe certain members of the team who were fully switched on with where the project was going, and others that were not.
From this I took the term “certainty” to be the focus point of the retrospective and the first part of the session was to take a “thermometer” of how “certain” the team was in terms of where the project was going.
First, using a whiteboard, draw a picture of a thermometer. This is where the first humor hit. No matter how you try, whatever you draw will release a flood of innuendo that is hard to stifle. Go with it…..
Then mark the end points of the thermometer “Certain” at the top, and “Uncertain” at the bottom.
Then get the team members to draw a “self portrait” of themselves on a post-it note. Nothing too heavy, just a quick doodle of how they think they look. You will find there are some team members who are budding old artists….and some who cannot draw for toffee….which is what you want! During this the Scrum Master should look away – you’ll see why in a second.
Then, ask the team members to put their post-it note on the thermometer at a position which indicates how certain they are about what they need to do next in the project. Are they are certain about the tools, people, activities or whatever that they will do in the next sprint – if so, these should go towards the top. If the opposite is true and they are clearly uncertain, then these would go towards the bottom.
Once everyone has finished you may (or may not) see a general spread of answers, from people who are highly certain on what they should be doing, versus those who a very uncertain, and the majority somewhere in between.
The next step is for the Scrum Master to try and guess the individual self-portraits – humor check point – as believe me, this will be hard – and scribble the names down on the post-its.
The Scrum Master should then take names from the top and pair or group them with names from the bottom – certain + uncertain to work in partners. The point of this exercise is to try and create balanced mix so that people can become more certain on where they are going or, in some cases, get a reality check and realize not everything is as they thought.
These “break out” groups can then focus on the normal retrospective stuff – what is making you un-certain (i.e. what should we stop?) and what would make you more certain (i.e. what should we continue going?).
Let the usual retrospective idea generation process run its course and then re-convene as a group to share the ideas. The outcome should be a set of actions that allow those that are uncertain to get more certain – training, meeting people, pointers to documentation or whatever.
For one final laugh leaver the whiteboard with the “thermometer” on in full view for other people and teams to notice…..

Posted in Uncategorized | Leave a comment

A Retrospective of Retrospectives – Chinese Style

As an SCRUM master and Agile PM I’m always on the lookout for fresh and interesting ideas for retrospectives. For me the retrospective is a chance for the team to change gear, take time out from the daily grind, and have a bit of fun, while at the same time improving the performance of the team. Making it enjoyable is one of the interesting challenges that face the SCRUM master.
I’ve read most of the books now and searched on-line but often come up with retrospective techniques of my own. I thought I’d put something back by blogging about it here.

This particular retrospective came at the end of a release, and followed on the back of a few other retrospectives. I thought it wise to check back on the actions we took from earlier sessions and see if the team had embraced them all – or if they still applied. By revisiting old retrospectives you avoid repetition of items and allow the team to focus on new things.

At the start of the session I took a post-release team barometer on the whiteboard. I asked the team for a one (or two) word description on how they are feeling. Nothing elaborate, nothing difficult, just one or two words.

Various words came out, as you’d expect, and many were positive feelings (“excited”, “interesting”, “challenged”, etc.) but (importantly) many were negative feelings (“worried”, “blocked” etc.). Once all the words were captured I took a red and green pen and drew a circle around each word – green for positive (i.e. need to re-enforce) and red for negative (i.e. need to discourage).

I then broke the group into smaller teams. For this I used the Chinese Zodiac to inject a bit of fun (I’d recently enjoyed a speaking event in Beijing). All participants were asked to find their sign (Pig, Dragon, Ox, etc.) and using a previously prepared crib-sheet (widely available on line) compatible signs were placed together. There was some hilarity around the personality characteristics described by the Zodiac cards as they applied to some people exactly!

I then handed out pre-printed cards containing the (positive and negative, i.e. “do more” and “stop doing”) feedback and actions from earlier retrospectives. These were shared across the teams. The teams were then asked to look at the cards and see if they were still relevant. Those that were not (either because they are implemented or are no longer applicable) were placed in a ceremonial “bin”. Those that still applied (and the team agreed it was great to revisit previous feedback) were then affinity mapped against a positive or negative feeling on the whiteboard.

Stepping back and watching the team at work gives a SCRUM master great pride. Once all of the cards had either been mapped, or binned, the teams were asked to come up with new and fresh ideas for what the team should “do more” of, and what the team should “stop doing”. Basic retrospective stuff, I know, but much more relevant and up-to-date having reviewed all the previous feedback.

Playing the results back to the group there were two key areas of focus. Any negative feedback that has a “stop doing” card against it gives a real concern, and should be the focus of the main actions coming out of the retrospective. If you really don’t stop doing these things then negativity in the camp will persist. Conversely, any positive feedback supported by a “do more” card are the good habits that the team need to keep on doing.

Once the plan of action was wrapped up the team then indulged…..cakes, drinks, food – I’ve tried them all and they all work!

Posted in Uncategorized | Leave a comment

Speaking about DevOps

I was invited to speak about DevOps by Ranger 4 recently (look here) and I summarise again here what I had to say:

1) What’s your preferred definition of DevOps?

I prefer not to use the term DevOps these days at is a misused term and doesn’t encompass the full range of what the “movement” is about. I prefer to use the term “Continuous Delivery” as that is the ultimate business objective.

2) When people ‘do’ DevOps, what’s the most common mistake you see them make?

Doing DevOps for most people is about being a “super-admin”. Doing DevOps is NOT about being a “super-admin”. DevOps requires involvement from people across the business involved in making – and keeping – applications and service live.

3) How do you recommend an organisation new to DevOps start?

DevOps at a business level is about reducing the time it takes to take a value-realizing idea or concept through to production – and keeping it fresh and relevant. To do this requires analysis across the value chain – looking to see where bottleneck lie and reducing those bottlenecks. An Agile approach is perfect for organisations new to DevOps as it allows for regular, focused bursts of activity, with regular feedback loops to the wider business.

4) What’s your prediction for what DevOps will look like in 2020?

In 2020 the concept of Continuous Delivery will be the norm for most organizations and by then we will all be on to something different. Even slower moving, bureaucratic organisations are embracing DevOps and continuous delivery so it will definitely be in the mainstream. From 2020 there will be the onward exploitation of what DevOps has already realized – self-monitoring, self-healing, self-growing and, who know, self-developing, systems.

5) Where do you like to go to get a DevOps hit? (i.e. event, website, podcast, LinkedIn, Twitter etc)

I try and stay close to a mix of vendors and independent thought leaders. Webcasts and podcasts I tune into include the DevOps café, broadcasts from Puppet/Chef/Ansible/Salt etc., Agile Weekly, The Cloudcast and Radio TFS (for the Microsoft view of things). On LinkedIn there are a large number of DevOps groups from which I receive many (too many sometimes!) updates. I’m also receiving updates from the contributors to the above via their Twitter feeds.

Your biography: After many years working with some of the biggest names in Software Development and IT Consultancy I set up CAP project services, with a focus on “Enabling Continuous Delivery” through Agile and DevOps approaches. Our consultants focus on the business value of DevOps and Continuous Delivery, cutting through the vendor hype, allowing continuous delivery to happen within organisations. More about me is available via my blog:

Your Twitter handle: @craigpearson004

Your website:

Your LinkedIn ID:


Posted in Uncategorized | Leave a comment

Charity Challenge 2014

The photo at the top of this page is quite apt, it is the causeway to Holy Island of Lindisfarne (at low tide, thankfully), that I’ll be passing during this year’s charity challenge.  I’m doing “Joppa for Jo“, which will take place 27-29 June.  A group of MAMIL’s (middle-aged men in lycra!), my very own self included (although stretching the definition of a “MAM”, I know), who will be cycling from Newcastle to Edinburgh, 210 miles across 3 days, following the “coasts and castles” route.  This is in memory of Jo O’Hara, and is helping Cancer Research UK to find a way to defeat this terrible disease.  If you would like to support this worthy cause then go to the fundraising page.

Posted in Uncategorized | Leave a comment

Absolutism and the barrier to Agility

Operating Agile is fine for start up’s and small independent teams with clear autonomy.  However more and more larger organizations are attempting to go Agile with varying degrees of success.  A lot of the challenges within large organizations come from the management bureaucracy that is prevalent, and built up, through many years evolution. Managers in positions of long standing typically adopt a command and control mentality with processes, meetings, reporting lines all structured to support this ‘absolutist’ model. Attempts at Agile typically involve the establishment of the eponymous team and limited independence – the prevailing management relationships, requirements and influences still remain. The result is a team operating Agile in name only, needing to ratify and vet key decisions and attend checkpoints in the legacy way, with little to no clear autonomy and hence, no improvement in delivery speed or quality.  Agile is all about doing more quicker and better, remember.

Absolutism is a clear and historic human trait.  Read any work of history and you will see Absolutist leaders dominant throughout history (Andrew Marr in his History of the World tome outlines the historic evolution of Absolutism extremely well) and it is only human nature for this to manifest itself in organizations – bureaucracy after all is one of mankind’s most successful inventions. However the Agile manifesto emerged and began to fundamentally tackle some of an organizations key assumption – the concept of a ‘minimum’ viable product viz-a-viz the finished solution, responding to change rather then stoically following “the plan”, engaging with customers during development rather than contractually selling the resultant solution. Critical to all of this is the establishment of a team with the autonomy to drive the manifesto and make their own decisions.

The Agile Weekly crew (podcast 131) advocate clearly autonomy as a critical success factor within Agile, and the many ways autonomy is blocked within organizations and what can be done to sensitively introduce autonomy.  They also go on to challenge some of the current thinking on Agile team roles and how some Agile teams are re-introducing non-autonomy through process-driven roles such as the SCRUM Product Owner.

However autonomy is anathema to the absolutist manager, no matter how much he or she may advocate a new way of working.  “Lets get some SCRUM training and we’ll be Agile, right?”  Wrong. Sending people on courses (and there are many Agile courses advertised) is NOT what Agile is about (although I am a CSM by the way….).  The Agile manifesto advocates individuals and their interactions over process, so why do a lot of organizations trying to become Agile introduce yet another process, such as SCRUM?

Agile has historically grown out of software development but is being increasingly used in other service delivery scenarios.  Frameworks such as SCRUM, and others, will continue to evolve but must enable an Agile approach, not dictate it.  Do organizations want to be good at SCRUM or good at delivering services?

Trust is at the heart of any transformative change, confidence that the correct new path is being adopted and courage to see the process of change through.  This is often why published frameworks are followed.  Assurance from those experienced in Agile transformation to “man the tiller” as it were through the choppy waters of organizational change (which the move to Agile is fundamentally about) can often help. As someone who has introduced Agile to FTSE100-scale organizations I know how rough that sea can get! However a fundamental stand-back by the absolutist management team is essential to allow Agile to flourish. So the next time your CxO, Head of, or Manager butts in to your Agile efforts tell them to “back off”.


Posted in Uncategorized | Leave a comment

No role, no organisation

Managing change effectively is so important when constant change is the norm, and the VMware view that roles/organisations are becoming outdated is certainly something that resonates with my recent clients. To breakdown the barriers (silos) that prevent effective continuous delivery I’ve asked organisations to take radical steps – I’ve blogged on “undercover IT” here and activated a “new organisation” to make real change in heavily bureaucratic environments. Only organisations with a culture of innovation allow this kind of thing to flourish – and creating this culture is the hardest change!

Posted in Uncategorized | Leave a comment