@mhsutton

heart.head.work.life

Tag: organisations

  • Do you feel appreciated, punk?!

    Do you feel appreciated, punk?!

    Computer says ‘appreciate Mike’

    Corporates are a funny bunch. There is a process for everything. Even appreciation.

    A couple of friends of mine in different companies recently celebrated significant milestones of service. An HR system notified someone to initiate an order for some official commemorative items and also sent an email to their respective managers to ‘put it on their radar’.

    The first – for 5 years of being with the same organisation – earned himself a piece of glassware. The kind that is heavy and feels and looks significant. It also looks like the kind of thing that is still sitting on a shelf of the charity shops with no obvious use to anyone.

    My other friend celebrated 15 years at a different company. There was a Friday afternoon presentation by his manager( who incidentally was 11 years old when my friend started at the company!). For such a long tenure, he received – with thanks – a voucher for £100 and a clock.

    Being a confirmed nomad and allergic to the long term effects of corporations – I would never tenure anywhere long enough to warrant anything beyond chewing gum – pre-owned chewing gum at that – so I was curious about their experience of being recipients of corporate appreciation by policy.

    It’s about the choice

    My glassware friend was somewhat at a loss about what to do with this chunk of glass. To make things worse, he Googled the manufacturer of the piece and discovered – much to his disgust – that it cost about $50.

    Now my friend lives somewhere $50 goes a fairly long way and to discover he had no choice about the way in which it was spent –  when it could have made a real difference to him as cash – left him pretty turned off.

    I made the same mistake many people make when we talk about material things – we got through a list of other material things we think could have been a better ‘gift’. Would he have preferred a $50 bottle of whisky, a contribution to a dinner with his partner or a book or who knows what.

    As I pursued a relentless list of other things he might have valued more – he put it simply

    Mike, being offered a choice is all that I wanted. To have been asked what I wanted or offered the cash

    This is when I realised the deep importance of checking in with the person you think you are appreciating – especially when you are demonstrating it with a gift.
    Offering them a choice can avoid so much negative stuff. I wonder how my friend’s non chalance about his glassware would be perceived by those responsible for the process of him getting it in the first place. My hunch tells me it would be received as ingratitude.

    What thrills me might not thrill you

    My other friend  – with his unsolicited time piece – agreed wholeheartedly about the issue of choice.

    He wouldn’t have chosen cash, but he really would have appreciated a call from the CEO. He said he feels he has contributed so much of his life to this organisation and the people he feels he is supporting have never reached out to say a personal “Thank You”. It has been company All Hands, video broadcasts and other ‘efficient’ channels. He pointed out that:

    Even the the Queen of England demonstrates personal gratitude and celebration with centenarians and  people who have been of valuable service.

    As we spoke more,  it turned out that  a simple 2 minute phone call demonstrating genuine interest by the CEO of the company would have entirely made his day! It got me wondering what the job of the CEO was. If it wasn’t about connecting with the people whose toil makes the business valuable, then what is it?

    Appreciation is double loop learning

    One of the new foundations of effective and efficient process work is double loop learning. This is where we formulate a goal,  for example

    We want to demonstrate our appreciation for long tenures of service

    Then we devise a program to reach that goal – for example:

    We will give people who have worked for 5 years a piece of crafted glassware and a funky timepiece to people who have served 15 years

    Double loop learning in this case suggests that once you have done the program,  gather learning about whether the goal should change – not simply the way you are doing it. I heard no evidence that either of these employers had either the interest nor the channels to gather the learning, let alone the intention to apply anything to their original goal.

    If either of these employers even remotely thought about Double Loop Learning, they would simply ask how the recipients of these gifts felt about what was offered, how it was offered and what might have helped them feel better appreciated. I am absolutely sure that even a tiny act of genuine inquiry would have yielded that the goal must change along the lines of:

    We want to help people who have served our organisation for years to feel appreciated for their long tenure

    Can you tell the difference?  I hope you can. If not – ask me.

    What are your experiences of corporate appreciation?

    Did it lift you up and make you feel deeply appreciated or did it leave you feeling meh?
    I’d like to hear about either and everything in between. Tweet me, comment or otherwise make your opinions known.

    Happy days.

     

  • Why Scrum is designed for misuse.

    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