Passion, care and the Agile Manifesto is really all you need.

As I sat with a professional services team at my client, launching into my tried and tested description of what agility means and how to do it sustainably, the last 11 years of my life flashed in front of me and I saw something that I hadn’t realised before. It both scare and energised me.

My typical approach to this particular exercise is to begin by introducing my audience to the Agile Manifesto – the spark of the movement. I remember to use that word – ‘movement’ because I truly believe this is what those who truly do agile software development are part of.

Then I pretty quickly move on to processes (or process frameworks) – the ‘how’. I do this partly because I assume that is what folks want to hear – “enough of this happy clappy, pie-in-the-sky bollocks. Show us the meetings, the artefacts and stuff we can put on our CVs”.

I also do it because I hadn’t really stopped long enough to consume the manifesto, to meditate deeply on it. And that might be because I wasn’t ready.

Well now I am.

As I wrote the 4 value statements on the whiteboard, time stopped. For context, here is the Manifesto for Agile Software Development:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

What actually triggered this epiphany was a simple question:

What would it take to fully understand each of those value statements deeply and live them deliberately – every day and in every facet of your team or organisation?

If you imagine a journey to increased agility was a 12 step program where you couldn’t proceed to the next step without satisfactorily completing  the preceding step,  then seeking to seriously answer that question would be steps 1 – 11 and mostly like a ‘formal’ process or framework like Scrum or SAFe would not even feature.

Don’t be fooled – this stuff is complex. Take an even modest attempt at going a little deeper into the first value statement – ‘ Individuals and interactions over processes and tools’ – :

  • Who are the individuals, what are the interactions? How do we know they are the right ones?
  • What personal and professional skills and competencies does each individual need in order to participate meaningfully in these interactions? How do they acquire and develop them?
  • What conditions sustain meaningfully interactions, how we create and maintain them?
  • How do we continuously sense that the interactions are not yielding what they are intended to yield? What do we do when that happens?

This is not a remotely exhaustive list, but they are considerable questions. In my mind, these are not ask-once-and-forget questions, they are to be asked and answered regularly.

There is even an earlier starting point.  Do we have the skills to ask the right questions?
Tools like powerful questions, clean language might be useful places to look to gain those skills. I have met far more people who suck at asking the most effective questions than not.

Now I’m not saying don’t do Scrum or use Kanban or XP or whatever the flavour of the month is. But it is very possible that you might do those and not enjoy the agility you seek, worse still you may get lost in process and without a solid understanding of these fundamental first principles you will struggle to regain direction.

I am saying go deeper into these 4 statements. Fight the urge to go into processes and the tickboxes. Do not simply ask questions and pat yourselves on the back that you answered them – actually execute on the answers. Make those answers make a difference to your work and your life.

And oh, if any of your answers is ‘do process X’ , then please consider getting one of these:

http://i.giphy.com/xT0BKGkoBW46ip9OvK.gif

Make a donation and I’ll speak with, coach, train or mentor your team for 1 day.

A gift for your company or team.

If your company/team needs a spark to improve it’s delivery capabilites, perspectives, focus, vision, value system and (no tomatoes please) culture. Then I have a gift for you. I’ll trade you a spark for £500 before 5pm BST,  Thursday, May 12th 2016.

If you or your company donate a minimum of £500 to my camino walk for ME/CFS  – and thereby help me reach/exceed my funding target of £3000 by 5pm  BST, on Thursday, May 12th – then I will come to your company/team on a mutually agreed day in July or August to help you improve how you deliver software or any products or service.

Whilst there is no magic to it – just experience, honesty, empathy , a desire to cut through the bullshit and help your company/team rise to new heights. I’ll bring my experience of working with  1500+ people and  180+ teams over the last 11 years as a coach with some of the worlds most successful companies.

Things I can help you  with:

  • super easy way to plan your releases (or even get rid of releases entirely)
  • getting pragmatic on just how agile you need to be to get where you want to get to
  • get *everyone* working together to increase value delivery
  • focus more on sustainable value delivery versus some whacky velocity
  • waste a lot less times in meetings

Just think about it – but not for too long – then donate.

Tick tock, thank you.

ps. Open to everyone, everywhere but… I’ll pay my way to Europe based teams/companies. Anywhere else we need to talk about travel costs.

The Process Delusion

We do Scrum (or Kanban or SAFe or..)

How often have you met people – usually executives and management at conferences or other spaces outside of their company and they proudly proclaim ‘we do Scrum’.
I meet them alot – not only at conferences – on planes and more worryingly in their own companies. It’s like the Sixth Sense – only with Process.

Then with the slightest of prodding – examining what they produce, how they produce it, who they produce it for, what feedback they get – and how often they get it, what they use the feedback for and how quickly they apply it – the delusion begins to become clear. This is what I call the Process Delusion:

The Process Delusion is the  pretense – for whatever reason –  that you are doing something a certain way for certain benefits but there is little or no evidence that you are doing it or getting the expected benefits.

Let me say straight off – I applaud the willingness of anyone in any organisation who tries out any process to get some improvement.

It takes recognition that something needs to improve. So many just live with the gross imperfections – often the downright insanity – of how they work. I’ve met them. Through whatever path they came to this point, they don’t really give a crap about what they are asked to to do. They’ve arrived at a place where they gave up or never started trying to improve things for themselves or their organization. But I digress.

So, willingness to try is wonderful. But it is – sadly – not enough.  It is like taking out gym membership. You get kudos for recognising you need to get fit and ‘well done’ for taking out the gym membership. But the real applause comes when – most importantly – you start to see actual improvements. And that takes persistence and focus.

How does the Process Delusion play out in your team or organisation?


Photo by Michael Gwyther-Jones

I ❤️ Agile Testing Day Netherlands

I’ve just been to Agile Testing Day in the Netherlands. And I loved it.

It’s been over two years since I last participated in any agile conference events.
Back then I had felt underwhelmed by most things on offer. My head was in some ‘post agile’ place that I couldn’t find anything authentic enough to attend. Also, as a serial organiser/facilitator of gatherings and unconferences I also didn’t want to be involved in organising anything.

Anyway – out of the blue –  Madeleine Griep from D&H events the organisers of the Agile Testing Days conferences contacted me to present a keynote at their Netherlands one-day event. The Agile Testing Day Netherlands is in its second year and – according to Griep  – had doubled its attendance in one year. Pretty good for a young event. The more established Agile Testing Days in Berlin is in its 7th year, runs over 3 days and enjoys attendance of 600+. So  – really good pedigree as  an event.

I said ‘Yes’ but didn’t really know what I was going to be talking about. For me, these events are about provocative thinking, inspiration and connection. So whatever I wanted to share had to bring people a degree of all of those aspects.

Whilst there was a significant proportion of the attendees dressed in suits and many were consultants of one form or another, there was also a large contingent of actual testing professionals whose daily lives are spent trying to make their products demonstrably better in the face of immense disrespect and organizational pressures.

What really delighted me was that in one single day, an attendee could explore the present – tools, techniques and anecdotes of how their peers are doing things – and the future – like in Rachel Davies’ talk about testing at Unruly. Whilst at the same time they can go deep into product testing and zoom out in how they might effect change in their organisation with a keynote by Olaf Lewitz on Integral Quality

I certainly learnt a lot by attending and was delighted to hear that my keynote was well received. Here,  for your viewing pleasure,  is the slide deck from my keynote. There is no audio but you can get the main thrust of my talk.
If you get the opportunity please check out the Agile Testing Days conferences – either in Berlin or in the Netherlands.

Why Scrum is designed for misuse.

Street Cred

I’ve been in the software development industry for 21 years,  using agile software development practices and principles for 14 years to actually deliver software. I’ve been working with Scrum for nigh on 11 years now and over the last 7 years I’ve coached over 120 teams and worked with over 1200 people.

With all this experience one thing has become clear – Scrum is broken.

How I assess the quality of any agile process

In theory, it seems all neat and tidy, but in practice it is abused, misused and generally ineffective. And I wonder why?  I have seen many more poor implementations of the Scrum framework than successful ones. Actually – let me be explicit about how I assess the quality of implemented Scrum.

For me the success of *any* organisation’s way of working – formal or otherwise – can be checked by simple questions that explore 5 fundamental concepts:

  1. Value: Do we know the value we seek to deliver and are we consistently delivering the maximum value?
  2. Flow: Do we understand how we reach that value and are we consistently reducing the time and/or increasing the ease by which we reach it?
  3. Quality: Do we understand how good our product and workmanship needs to be and are we consistently and demonstrably achieving it?
  4. Joy: Do we know what we collectively and individually need to be joyful and are we consistently meeting those needs?
  5. Continuous Improvement: Do we know what we need to improve across VFQJ and are we demonstrably pursuing those improvements?

This simple list of questions invites great questions and other avenues of inquiry. It can function as both binary (yes/no) and range (how well are we doing). Works for me – mostly.

The non-recipe recipe

The fundamental reason why Scrum – as it currently exists – is broken is that it is a set of instructions, roles, rituals and artifacts that purports to *not* be a recipe. But almost every one takes it as a recipe and they follow it. But there is not enough there to be a an all encompassing recipe – there can never be.

The trouble is that, as a product , Scrum needs these illusions of completeness in order that it is taken seriously . By and large this has worked. In a world that is seeking silver bullets, Scrum has succeeded beyond it’s practicality commands. It is by far the leading agile process framework in use today. It is in this illusion of completeness that lies the myriad of problems.

I remember in 2008 or 2009, there was a statement about there never being ‘Scrum 2.0’ – that Scrum was complete as it is. A perfectly chiseled gem that needed nothing removed nor added. This was clearly bollocks and persisted until politics and greed spilled over in the Scrum Alliance causing a bitter split between one of the co-creators of Scrum and the rest of the Alliance. All of a sudden a Scrum 2.0 in emerged in all but name.

When people have applied Scrum as a recipe the commentary from the unsympathetic dogmatics has been of the nature of:

“ScrumBut”

“Scrum shines a light on where you need to fix in your organisation”

“Scrum works, you just did it badly”

“You didn’t have buy in”

Overwhelmingly any reasonable objection to some of the design flaws – and design flaws can emerge after the fact , exposed because of a change of operating environment etc – is often met with “those people are resistant, they are against change”.

When Things Work, Its the Process – When They Don’t, It’s The People

I was first attracted to Scrum because I believed it would revolutionise the ‘world of work’.

10 years on and I’m deeply disappointed. It did not revolutionise the world of work. Instead it got gobbled up by the Death Star of Work. If it had any early promise – for me it was that it would promote unprecedented collaboration between the people focused on delivering value and the people consuming it.

It may have had some success in some organisations – but this is far from ‘changing the world of work’. A tiny street maybe, but never a world!

Of course a process doesn’t do anything – people do. But how a process is designed has a huge impact on how readily the people take to it and how easily they can use it for the intended purpose.

More often than not I see a growing perception of infallibility of a process and an overwhelming blaming of the teams and individuals who play the Scrum roles. I feel deeply sad and angry at this.

Multiple single points of failure

Scrum Master, Product Owner and Team all collaborating beautifully – each with its clear role and responsibility – what’s not to love?

Except that in *most* companies roles are so entrenched and siloed that this is the worst thing you could do – add more roles that become siloed. I hear you scream – “yes but the problem is the organisation and not Scrum” – and you are both right and wrong.

You are right because it is the organisation that is siloed and you are wrong because adding more roles when you *know* that most organisations are siloed is a dumb idea. That is like asking the morbidly obese to incorporate 3 more meals – however small – into their already dangerous diet.

Defined roles and a culture of collaboration are difficult bedfellows in any context. Especially in the context of trying to explore value through . Defined roles present an extra hurdle to overcome as we truly try and work together.

I have seen product development be disastrous for many reasons and the most common one is the single point of failure problem. Examples abound:

  • Overworked, overextended and ineffective Product Owners;
  • Scrum Masters left to single-handedly be responsible for improvement and impediments and latterly ‘coaching’ the team.
  • Teams that aren’t to effectively own their tools, their craft or their collaboration.

Rituals become checklists vs  achieved outcomes.

If I have to walk into another planning meeting that is schedul for 4 hours because Scrum said so – with the hope that somehow the information we don’t have about the work we are expected to commit to will magically appear – I may have to shoot some unicorns.

Sprint after sprint, people do the meetings, the stand ups, the reviews etc. Scrum Masters – bless ’em – scour the communities for how to make their standups more interesting. Velocity is going up, teams are 7±2 people – things in the product backlog read like ‘As a …, I want…”. The process seems to be working perfectly.

Yet software is still sitting on the shelf. Customers are not getting anything to feedback on. Developers still don’t talk to customers.

Velocity becomes a stick to beat teams up

So velocity is not a defined part of Scrum – but it is a defacto part of Scrum implementations and it is both a arbitrary and crude measure of something.

Velocity doesn’t mean what you think it means. It is about capacity,not speed It is *always* historic and never comparable to any other team and barely comparable to the same team over time.  Sure it is a number and numbers can be compared – and that in itself is a problem because the human factors that help that number pop out are deeply flawed in most organisations.

Thankfully, the #NoEstimates movement is bringing some well deserved improvement in thinking in this whole area.

Of course you need a measure to know how you’re doing. But velocity is a poor one. The emergent product and how well it is meeting the needs it was intended to meet is the ultimate measure – sadly many organisations are unable to get this – so they overdose on the measure that came with the process.

So narrow as to be quickly redundant

I was in the market for car seat a few years ago and was faced with buying something that was super specific for my son at his then age – he was 3 years old – or buying something that would support him till he was 8 years old.

Guess which I bought.

Scrum purports to be for ‘new product’ development – and I wholeheartedly agree. Except I don’t know *any* teams that only do ‘new product development’.

Even if  a team that started out with only new product development – after their product reached its first users – their work mix would need to change. The fixes, bugs and so on that are different classes of work and different service responses change the mix. You could use Scrum to do these classes of work – but that would be akin to picking your teeth with a vacuum cleaner.

And this is just product related work – but what about the work everyone needs to do to continue to improve? The Human Development work? How about using Scrum for that?

If Scrum was the only thing you did – and many organisations adopt it as such – then it would get misused pretty quickly because getting shit done always trumps following a process. The question is how much of a hatchet job do we have to do to the process to get the shit done.

Scrum Shows You What Needs Fixing, It Doesn’t Fix Them For You

If I had a penny for every time I’ve heard this, I would be rather rich.

Of course Scrum should fix something – everyone I have ever met in a company *know* what is wrong. They don’t need a fancy methodology to tell them what is broken. They need something to help to try and address the problems and Scrum does not not address any of those.

If the problem that Scrum fixes is exposure of problems then it needs to be pitched as ‘a framework for exposing what is preventing you from doing joyful, fulfilling new product development work’.

It ain’t all bad.

I don’t hate Scrum – I’ve just use it long and deep enough to understand which bits I would throw away and which I would keep, what contexts I would use it in and which I would bury it so deep – no one would ever find it.

If you are using Scrum  – I beg you to question it all. Ask yourself, your team, organisation and customers whether this is really helping you and what you are really trying to achieve. Don’t even mention Scrum during that conversation – simply talk about ‘how are we delivering what we seek to deliver” .

As with most things, all this can boil down to simple choices.

Do you choose to blindly follow a process or do you choose to adapt your own way of working that is focused on value and joy?

Good luck whichever you choose.

 

 


Photo by mikecogh

Screw Fast Feedback

Agile teams love faster feedback

Or so the mantra goes.
Legions of agile enthusiasts and countless books, conference talks, webinars and training course harp on about faster feedback as though without it the World would cease.

In the fantasy world we – agile enthusiasts – inhabit, the faster the feedback the better.

Entire hordes of agile nerds are finding ways to make technical feedback – compiles, unit tests and functional tests – faster than ever before. We have frameworks now that give you almost instantaneous feedback on the impact of changes you are making to code and the product you are building. We delight in making the mechanisation of feedback itself faster.

With all the emphasis and near-dogmatic fervor directed in favor of fast/faster feedback, I think it’s time for some perspective – screw fast feedback. I mean really – screw it.

Why do people who understand the value of fast feedback impose the idea on everyone else? There are clear reasons why you make the investment in discovering – and discovering quickly – what someone or something has to tell you about something you did. Whether this is software, a customer or anyone!

3 Reasons For Not Seeking Feedback – at any speed.

We – enlightened folk – prance around thinking the value is self-evident to man and beast. It isn’t.
Let me put more succinctly:

  1. If you are asking for it but not going to act on it – and yes, considered inaction is ‘acting on it’ – then don’t seek feedback.
  2. If you are asking for it and not going to act on it as quickly as you get it – then don’t  go through all the trauma of seeking it faster.
  3. If the source of the feedback is unwilling to give it to you quickly or even at all – don’t waste your time trying to seek it faster.

I have seen too many teams pursue the delusion of Continuous Integration but not write tests – the equivalent of asking for feedback – or not write enough tests to tell them anything meaningful. Then even when they get some feedback – “Red Alert: the build is broken” – it remains broken for days.

Don’t release your product early and often If your customer is not prepared to do anything with it when you release it . Why take the considerable pain of changing how you work to do something that no one needs. That is just dumb.

Every optimization you make costs you something – so think twice about what you will use that optimization for:

If it will not enhance the value you deliver, ease the flow of delivering that value, improve the quality of the valuable product or increase the joy of working on this valuable thing – then do not make the investment.

Why I wrote this

This piece is about giving the rest of the world a break from the pressure to seek feedback and act on it. I hope we can all get back to what works for each of us.

Note: On the subject of feedback, I care that you share your opinion about this post. If you tell me what you liked, I’ll do more of it, if you tell me what you didn’t – I promise I’ll consider doing less of it.

Want 30 days of free #agile #coaching for your team? Help me on my project and it’s yours. Pls Share.

By: Andreas Klinke JohannsenCC BY 2.0

A little about me?

I’m Mike Sutton – a deeply experienced agile coach with a background in development. I have built products, led teams and small companies, consulted with some of the biggest enterprises and helped  dozens of  teams and hundreds of  people to work more effectively. I tend to focus more on people and outcomes than on process and output and seek to leave places more joyful than I found them. Check me out on LinkedIn to find out who I’ve worked with or book a conversation with me  and I’d be happy to answer any questions you have.

I need your help

After over seven years of coaching enterprises of all sizes – usually on site for periods ranging from a few weeks to many months – I have become convinced that this is not the most effective model to help people genuinely learn and make sustainable positive changes to how they work and think about work.

Whether you are a big 20,000+ employee organisation or a small ten person team – I don’t believe this model of concentrated transformation or ‘shock’ coaching actually helps deliver sustained positive outcomes.

Here are 5 of the biggest reasons I don’t believe this is a model for sustained change:

  1. Cost: hiring a consultant coach is expensive – sometimes very expensive. It can run into tens of thousands of dollars for just one coach. When you multiply this by a few coaches on a large ‘transformation’, it gets crazy costly.
  2. Negatively disruptive : the cost also drives an unhealthy level of disruption. The unspoken sentiment is ‘Mike is here, the meter is running, drop everything now to get his help’. This has the effect of creating a pressure cooker situation that hardly encourages the learning that we want.
  3. Learning is rushed –  most enterprises I have worked with seem to consider a transformation to be a ‘project’. They’ll hire a coach and once the agreed period has passed, they will be ‘agile’. This is an unreasonable approach. The essential elements of making small changes, reflecting on the results, adjusting the next set of experiments all take time – they cannot be rushed. But because the meter is running and the costs are high, the journey is rushed and often abandoned because the learning has not been given a chance to stick.
  4. It wastes my time and your money: there are times when a coach must do nothing. Times when the organisation must do its own heavy lifting. Most organisations I have coached have expected me to still be on site even when it is counter productive to their learning and erodes their ability to stand on their own.
  5. Poor ongoing support: I see many companies that paid money to have their employees trained and certified. Some might even have hired a coach like me on site to do some work. But once the training is over and the coaches leaves,  their Scrum Masters, Product Owners, developers and even management are left with little or no ongoing support. It soon returns to business as usual because there is no one to help them stay focused or to whom they can turn for help with the next steps – at least not without another large cost. Some might create an internal coach role to keep improvements going – but in my experience the key ingredient of objectivity and honesty often get lost over time because of internal politics and familiarity.

I need your help to make this better.

I’m working on a project to help and support people in maintaining a sustainable pace of continuous improvement and learning. To do this,  first I need to really understand the problems facing people who are trying to apply an agile approach with very little support. I want to understand what the barriers to support are and experiment with ways to remove them.

My offer to you

If any of the following apply to you:

I am in management struggling to understand how agile should be working for me and my organisation, my role in it and what should I be doing next

I am in a team that is seeking ways to improve our outcomes and how we collaborate and learn;

I am a Scrum Master or Product Owner feeling isolated, unsupported and outnumbered;

My organisation claims they are doing Scrum or are agile – but it’s all wrong and very frustrating. We could do with some help.

I am a C-Level executive with people in my organisation that fit the above and I want to help make it better.

Then I would love your help on my project.

I am offering to personally coach five lucky groups remotely  free of charge for 30 days.

Each group will enjoy great benefits including having:

30 days of remote access coaching available to anyone in your organisation. This could be ongoing coaching of Scrum masters as they perform an incredibly difficult role or mentoring Product Owners in keeping a vision shared and relevant and maintaining a healthy backlog. It could be starting from scratch with setting a strategic direction with the inclusion of your entire organisation or helping established teams get even better.

A skilled facilitator  – to help you and your organisation rediscover how to collaborate transparently and effectively so that you can finally start to address all those issues that affect you all.

An untainted observer – to help you with my objective observations untainted by any political influence.

An improvement partner – to help work through those tough problems and help you find your own way through them. From vision to delivery and everything in between.

Access to lots of games, practices and experience –  to help your teams improve their capability to reflect, experiment and collaborate and to deliver product and learning more sustainably.

Help to start and grow your communities of practice  – to help sustain an almost permanent and continuous state of learning.

Support when you need it – it is not in the interest of self-sustainability that a coach is there for everything you do – this is a journey where  you will ultimately outgrow a coach. But at every step where you falter, you will have my experience, expertise and network  to overcome it.

What’s the catch?

I am usually paid thousands of pounds/dollars to offer my expertise and experience to help teams and organisations improve. I’m making this offer absolutely free of charge – gratis!

While I will not charge you for my remote services, this offer is not free – I am offering this in exchange for learning!

I want to learn how the remote coaching experience works for you, specifically:

  1. To what extent does having unrestricted remote access to independent and experienced expert improve the outcomes for agile teams and their management?
  2. How much expert access is “just right” to keep continuous improvement at its highest sustainable pace?
  3. What is the most effective kind of access and for what kind of situations?
  4. Can the business value of remote strategic coaching be measured?
  5. If, given affordable access and no-pressure, will the individuals in an organisation use the help that is offered? What will it take for the organisation to support it?

That’s it. I coach you remotely for free , you and your organisation improve and have a great basis for continued improvement and I get to learn to what extent this can be done remotely. Want free agile coaching for 30 days? Sign up now.

How it works

  1. If I haven’t worked with your group for 6 months or more, we are best to start with 2 days on site where I meet your group –  the teams and individuals – and we work together on what we want out of this. We’ll come up with goals and a near term starting plan to reach them. We’ll setup a review cadence and start working on the items on the plan.
    This on-site time will be expenses only – so you cover the flight, accommodation and meals. I won’t charge you for my time.
  2. After the 2 days on-site, I leave and we continue the work on the plan remotely  – adjusting it as we learn more. We will collaborate using every remote channel available to us – video, screen-sharing, email and phone calls – perhaps even an interactive whiteboard!
  3. After 30 days, we end the partnership happy, we would both have learnt a lot and have actionable data to fuel improvement.

Does this sound doable for your organisation? Let’s try it together..

My ideal group

  • Are based within 7 hours of GMT+1  –  so  Europe, east coast USA, middle East and Africa are all in!
  • Are not larger than 400 employees. For huge companies, this refers only to the size of the group that will be using my offer.
  • Are building any product – software or otherwise.
  • Are in whatever stage of adopting an agile approach.
  • Are committed to improvement and are open-minded enough to try this.

Does this sound like you? I need just 5 – be one of them, sign up now.

What you need to do now

Places are limited. Once I find 5 groups willing to help with this, the offer will close and you will have missed the opportunity. 

If you feel this opportunity would suit you and your organisation and you are willing to help me learn – get in touch now – there is not a minute to lose.

Finally , as a personal favour to me and your contacts – please share this.

Agile coach as recogniser of courage

An Audience for Courage

At my current client, we have a weekly Scrum Master Community of Practice meetup. This week on the agenda was an experience report proposed as the results of an experiment. So far, so good. I was sold on it – anything with experiment that didn’t involve animals and/or genitals was fine by me.

Anyway this Scrum Master tells a story that to me sounded like exercise in complicating the simple, he highlighted many deeply dysfunctional practices that exist in his team. No reviews to speak of, month long sprints, hardly any retros etc.

The assembled community members were stunned at some of the things he shared. Unfortunately I couldn’t stay for the entire thing.

I caught up with some of the members later and overwhelmingly they all said it was a tremendously courageous thing to do. To bare one’s dysfunctions to an audience one hardly knows (the community is young and memberships has not stabilised).

Agile Coaches recognise and acknowledge courage.

So today, I went to this SM and told him how much I appreciated the risk he took and that he demonstrated immense trust and openness to his peers in sharing his experience and seeking help. He was taken aback, I don’t think he expected anyone to do this. His reply convinced me that despite the monstrosity of mega-corporations, there are individuals who will rise above the pettiness of self-interest, take risks to build trust and grow sustainable communities.

He said ‘we have to start somewhere, so why not with me?

In many organisations, we have institutionalised what we recognise. In rewarding delivery competence, we have undervalued learning and the relationships that foster community. We have made it harder for people to be courageous and to take risks to help their teams, communities and companies grow (and I mean knowledge and goodness growth, not merely financial!).

Coaches need to be good observers of courage and be explicit in their recognition of it (if not publicly, at least privately to the individual concerned).

So I challenge you to look around your team or work colleagues and seek out the examples of courage amongst your colleagues and celebrate them in whichever way makes sense to the person. What would your organisation look like if you did this?

Agile coach as connector.

A little story I wanted to share, about making a difference without realising it.

Today, around lunchtime, as I was heading to the coffee area to get a cup of joe, I noticed a team (one I had met briefly) in a presentation. The title had caught my eye through the glass fronted room.

A ‘User Story Mapping’ presentation, led by one of their business analysts. This chap had been in a 3-hr workshop I had run as ‘Agile for System Analysts”. We had done some very basic story mapping in that workshop but hadn’t completed it, however I told them to connect with the BA on the team I was on to learn from him if they were interested and thought no more about it.

Anyway, I walk pass, stop to read the title and consume the slide – my gawking caused a fair amount of laughter in the room and I was invited in. The team was really pleased to have me sit with them and help their BA talk through  the topic. I soon established that they were thinking of using the technique on some new work and this was their self learning series on it (the first of its kind – something again learned from the team I coach!).

Learning Comes Full Circle

After some really abstract slides the guy showed, I suggested the most useful way to connect this might be to see concrete examples. I ran back to the BA on my team to print out one of his story maps. To my sheer delight, he told me he had already shared this with the BA on the other team (totally different part of the organisation) during an hour long session they had to talk through the technique!!

To see various aspects of this strangely unconnected organisation start to make these connections and little burning embers of passion radiate their knowledge so generously to others and get them fired up was tremendously heartwarming.

As coaches, we often don’t build software, often the rewards of our efforts elude us or are reaped long after we have left, but if we are lucky, we glimpse the difference we make and for that we must be thankful.

Have you had a similar experience?  I’d love to hear about it.