Do you really want an agile coach?

The term agile coach is as misunderstood as the role of Scrum Master… Probably much more so! with titles such as Team coach, Enterprise coach and Lead agile coach to name just a few further complicating this space.

An agile coach is not a higher ranked Scrum Master! nor a lead/chief Scrum master or a Scrum Master that can work with both Scrum and Kanban teams! Although you would expect they have deep knowledge of both in addition to many other frameworks and practices.

There are so many ways to define what an agile coach does….. So it’s important to be clear about the type of help required before going out and hiring one! To be successful an agile coach will need to actually coach…. Not just inwards within teams but outwards working in all directions. Many of the forces that determine success at the system level are usually outside of the remit of individual teams. Indeed very often local optimisations made at team level can and do de-optimise the system as whole! An agile coach need…

Why do agile IT 'projects' fail?

"It's meant to be an agile project why are we still making changes?" "Why didn't you capture those requirements earlier?" "It meets MVP why can't you release?" "Why are we only discovering these issues now? It needs to hit this deadline so no more changes!"

Does any of that sound familiar? It's something I've heard lots of times.

Unfortunately by the time people are asking those questions it's probably already far too late. I'd probably go further... Most IT projects have already failed before a single line of code is ever written!

So why? The problem certainly isn't because it's an 'agile' project! I've seen many of the same problems with waterfall deliveries!

The Waterfall Sandwich!

So... You take a development team and decide they'll be agile, Agile with a little 'a' of cause  - We couldn't possibly be totally agile because the risk of failure is too great! We'll use Scrum, P…

Clean language for Agile Coaches!

I've been seeing a lot of talk and activity around the use of Clean Language with agile coaching... But what is it? And what's it all about? To find out more I did a 2 day course back in November last year ran by Judy Rees and Olaf Lewitz to try and delve deeper...

Clean Language is a technique developed by David Grove in the 1980's which was a result of clinical work helping to resolve clients traumatic memories - Encouraging clients to develop and build metaphors which are then explored using clean language questions.

I really struggled with the course - I couldn't do the metaphor concept and as a participant I couldn't construct metaphors for people to explore,  I must have been a right pain for those pairing with me!  I left feeling very uncertain about using it....

However I've since experimented with it several times - In coaching sessions and retrospectives and have been really surprised with the conversations and insights generated.....

So myself and f…

Portfolio Management with Starbucks

I've been trying to design a game which will teach some agile & lean principles around running a portfolio of work.. And to be honest I've been struggling!! So many learning points to get across whilst making it fun.

Anyway - I've been doing some work today with some teams that are using SAFe..  Upon arriving back at Euston I find my train is delayed.... Yet again! So I decide to spend 42 minutes or more in Starbucks.....

Whilst watching the queue in Starbucks I observed that just about every behaviour to explain portfolio management can be learn't from watching the queue in Starbucks!

For those familiar with Little's law - The time between joining the queue and being served (delivery) is relational to the size of the queue (Lead time). Okay.. Nothing surprising there!

However the speed the queue moves at is variable..... But why.. Well if everybody in the queue orders a single cup of tea (And that's all you should order, A nice tea) the queue moves at a p…

Story Mapping

I've used the technique of Story Mapping countless times at project inception to assist in understanding the problem domain area, ensuing a shared understanding of the problem and a collaborative approach to building a product backlog. Unfortunately I can't really claim any credit for this methodology!!

Story mapping starts with an overarching vision of what's required...  And is then broken down to a more granular level.

I did this exercise with a large well known e-commerce brand...... Working on high level user journeys within the system- Done with blue index cards - The colour isn't important.. But it's nice to visually see the different types of stories/epics or NFR's (Non functional requirements)

Browse the catalogueSearchAdd to basketPayment  Each section was then broken down into smaller stories.... So Payment was broken into different ways of paying
Card PayPalYandexGift CardsAccount customers

We then tried to find the simplest user journey which took u…

Working Agreements

A team’s working agreement is a set of rules/behaviours set by the team itself to govern how the team will function.
It’s important for the team itself to come up with the list of rules (As ever the Scrum Master  should be there to facilitate the meeting) the team is also responsible for enforcing the rules!
Some of the Items to include are…..
Definition of DoneDefinition of ReadyConduct in meetings

I usually find that the retrospective is a good time to both define this artefact and to refine as required.
Some of the rules previous teams have come up include…..
Already be on time for meetings (And the stand-up)Always listen to others and don’t speak over peopleNo mobile phones in meetingsDon’t commit to unknown storiesDon’t estimate on work with no acceptance criteriaStories over 8SP need breaking down smallerPhysical and electronic board kept up-to date

Metrics in Agile

I've been meaning to write a blog post all about metrics for a very long... It's a really important subject and one that doesn't get spoken about anywhere near enough - I also plan to come back and add to this as time allows.

Metrics in Kanban as opposed to Scrum is perhaps more common place, Kanban is much more a case of bench marking where we are, Conducting 'experiments' and measuring the result before rolling back or continuing.

But, Good metrics not only allow you to understand the effects of experiments made but also allow you to start planning with at least something approaching a scientific methodology! Although admittedly it does take more effort than the old finger in the air, double it + a safety margin trick that!

Below are some of the main metrics I use regularly.

Flow efficiency

I love this little metric - It gives a quick indication as to how efficient your process is.

The exact way you record it might differ based on what you're trying to measur…