@mhsutton

heart.head.work.life

Category: WorldOfWork

  • 5 Steps to Becoming a More Effective Scrum Team

    I often get to work with teams trying to ‘do’ Scrum and after about 100+ teams, I can confidently say one fundamental issue comes up again and again as a key stumbling block to how effective these teams are. In this post I’ll tell you what it is and 5 steps to addressing it. The rest is up to you.

    So the fundamental issue is this:

    The Scrum team does not understand the nature and type of work they are doing and so are not self-organising around it effectively.

    This post might help your team if you suffer any or all of the following symptoms.

    • You don’t have a product backlog
    • You have a product backlog full of much more than items adding direct value to the product
    • You have a Product Owner who is struggling to navigating the crap that found its way into their backlog
    • Your development team is screaming that they often do not have enough work to keep some of their members busy during a sprint
    • You are delaying sprint starts and/or extending sprints to absorb the impact of hidden work and compromised capability
    • Your team is having Sprint Zeros like they were 2-for-1 at the supermarket
    • You are doing analysis sprints, design sprints… and so on

    If you have these problems here is what I suggest you do:

    #1. Understand the work you are doing:

    Specifically, understand the work in terms of time and value.

    First and foremost, let’s look at value:

    • Direct value – work to implement features or fixes that people will pay for or have paid for. I group non-critical bugs and enhancements and such like under ‘fixes’.
    • Capability value –  work to add things that increase your capability to deliver or remove/refactor the things that are reducing your capability to deliver.

    That is it. If any work does not fall into either value type, it is waste – do not do it.

    This product elaboration picture illustrates this a little better:

    product_elaboration_funnel

    Direct value are the green and reddish-orange items (basically that stack is your product backlog on its side) and the capability value items are the things you know you did,  that narrow ‘your development team capability’ aperture or the things you know you can do, that will widen it.

    Next, consider time:

    • Past – this is usually work to improve capability value by addressing stuff you put on the never-never. This includes known hacks, fudges, crappy code you added that “TODO” on, shoddy design, smelly tests, no tests , all those outdated comments that everyone spends an hour wading through only to find they aren’t relevant, those manual tasks you thought you would only ever have to do that one time and then you actually do them several times a day and they are long and boring. Basically anything that affects your ability to sprint effectively.  This is not an exhaustive list.
    • Present – the ‘READY’ items that your team comprehensively knows enough about to be confident enough to commit to deliver in a sprint. Deliver as in ‘DONE” – meeting a Definition of Done that your team and your Product Owner agree is a consistently achieved level of goodness. For example it meets the conditions of acceptance, it hasn’t broken any existing value , the code is clean and generally efficient etc.
    • Near Future – items from the backlog for upcoming sprints that you need to create knowledge for now – basically the next reddish-orange items. If you don’t know why you should be doing this, allow me to elucidate.
      See the product elaboration picture above? Basically if you don’t do work on elaboration now, your team will arrive at a future sprint planning with big reddish-orange items that won’t fit. Except you will need to commit because your management will be screaming at you and you will be too chicken shit to say no. So you’ll pretend they are green and ‘ready’  and ‘commit’ to them knowing fully well there is little hope of them getting ‘DONE’. Of course you’ll try your best, you’ll work hard when you should have worked smart. You’ll cut corners and more than likely build crap and increase your tech debt., further reducing the capability of your team.

    FYI: Typically most ‘past’ work affects capability and most ‘present’ and ‘near future’ work is around direct value. Also the Product Owner owns the Product Backlog and the development team owns the Capability list.

    So now that you know what to look for, you’re ready for the next step.

    #2. Make work visible

    Now go gather work. People are clearly busy – raid the backlog, declare a ‘hidden work’ amnesty, collate it all and make it big and visible. I prefer using post-its in the first instance. Put it all on a big wall.

    Bring stuff from the product backlog, get the programmers to ante up their secret side projects, encourage testers to confess all the work they end up doing that no one gives them any credit for. Ask the rest of the organisation what others are doing that you secretly depend on every sprint but no one acknowledges.

    Take the view that any work that isn’t on the list doesn’t get done – simple as that.

    Invite ideas for capability work (you might need to first talk about what capabilities you need though – so do that). It might be training or having a consultant in to give an injection of skills, it might be building up specific expert knowledge. Whatever it is, get it , write it down and make it visible.

    None of the lists of items is locked down – that would be denying emergence and is a recipe for undoing your improvements. Resist the temptation to get Gestapo on it. Instead, consider just making it absolutely visible and develop a cadence of reviewing it regularly.

    product_elaboration_funnel

    One thing though – when you have your capability value items list up – go round and make everyone swear on the life of something precious to them that they won’t knowingly add anything that constitutes any kind of debt without stopping the line and getting everyone to agree to it. That is not to say you are going never have any more, only that you all knowingly accept to do so.

    With all the work visible and normalised – you’ve removed all the duplicates and everyone is clear what each post it represents, you can move on to the next step.

    #3. Prioritise the work

    The Product Owner should already have the backlog items prioritised by business value anyway – if not – they need to do that. Everyone can help with that, but ultimately it is their call. The immediate goal for this is to have a backlog is at least prioritised for the next 2 sprints. At this point, you need to make a clear distinction about what is ‘ready’ and what is ‘not ready’ for a sprint.

    Next, prioritise the  capability value items based on how much you all generally believe they might enhance your ability to deliver over time – the stuff that will speed it up now at the top and the less impactful stuff further down the list. Crappy code that rarely gets touched – whilst crappy – might hold little value for tackling now. But don’t worry, they are on the list and will get done.

    So now, all the work is in an ordered state, you are ready for step 4 – making time to do it.

    #4. Make time to do the work every sprint

    Now you need to figure out how you’re going to spend the time to do each type of valuable work. I recommend you do some of each type every sprint. The basic idea is, every sprint, to do a combination of now work (ready items off the backlog), elaboration (non ready , near future items , again from the product backlog) and capability improvement work.  FYI – only the ‘now’ work – ready items off the product backlog count as your sprint commitment.

    Without this you are going to get screwed. One or both of the following things will happen:

    1. You will run out of ready items to work on for later sprints and return to that place where your sprints are crap, nothing gets delivered, you work long hours just to create the knowledge you needed to have to even consider committing to anything.
    2. You keep delaying the capabilities improvements until everyone would rather drink arsenic than touch the code and you are delivering far less that you ever did. Frustration and mistrust is growing and most likely your team is shrinking because people just got fed up and found a different job.

    Without getting bogged down in numbers, I suggest you start with 70/20/10 and adapt.  This means figure out the time you have for the sprint and then:

    • Spend 70% of it working on the items you committed to get DONE in the sprint. Clearly you will need to adjust your sprint commitment too – so DO NOT commit to items based on 100% of your time and then work like the clappers to get them done in 70% of the time. That is just nuts.
    • Spend 20% of it working on elaborating near future ‘not ready’ work (this covers every knowledge creating task that enables your team to be able to commit to doing the near future work in sprints like UX analysis, exploring test cases, reviewing with customers, tech spikes and all that kind of stuff).
    • Spend 10% of it working on the capability improvements. You might only get to start them – when you are in sprint planning try to find ways to dissect the large capability improvement items into things that you can complete in a sprint to minimise branching issues and gates in the code to separate large refactoring.

    The fact of the matter is, with the type of work you have to, you have to invest to do it. You will end up paying one way or another.

    #5. Retrospect

    The preceding 4 steps are hard to do and sustain, but are essential. At your retrospectives remember to acknowledge that you got this far and celebrate too. Then seek ways to improve. Check your percentages  – are they still working for you? Evaluate your capability now, are you getting the benefit you expected to get? How are people feeling about being more open with the work they previously had as covert ops?

    Pay attention to what the ways the work is requiring you to self organise. Are you learning and amplifying that learning? Is everyone helping out the best way they can?

    The larger the development team capability grows, that more strain on your Product Owner to make enough backlog to sustain the development team. Is it time to slow the elaboration? Or maybe the team needs to help by doing more.

    Lots of ideas – but the key is to retrospect effectively. Please do so with care, respect and openness.

    Great you got this far – well done! Now go do it for real and let me know how you get on.

    Gratitude

    I am profoundly grateful to all the teams I have worked with who been the experimental jets for this learning. Also all the wonderful agile practitioners who I have known and whose ideas have mingled with mine. The product elaboration funnel is inspired by the work of Jeff Patton– who rocks in so many ways. Please check out his site and say I said ‘Hi’.

     

  • Developer or Programmer? Why it matters.

    By: Seattle Municipal Archives – CC BY 2.0

    For nearly 25 years, I have been writing some form of software code or another. For nearly twenty of those years I was paid to do it. When I started I was called a ‘programmer’. I don’t know exactly when everyone – including myself – started using the term ‘developer’ as a synonym for ‘programmer’, I do remember spending all 12+ years as a Java programmer being called a Java developer. But really I still just programmed – this time in Java.

    Then along comes all these fancy shmancy process frameworks that talk of teams. One in particular – Scrum – boldly calls out the ‘development team’ as a cross-functional group who deliver an increment of a product at regular iterations.

    Now as I help teams and organisations be more effective by applying Scrum (amongst other things), I am often asked who is in the Scrum development team. Typically I say:

    Developers, testers and everyone who can carry out the required functions needed to sustainably deliver a working product increment

    Often this response gets some push-back along with a sense a alienation – “But I’m a QA, I’m not a developer – am I in the development team?” or “I’m an Interaction Designer, am I in the development team?”.

    My revelation

    These questions left me puzzled and during one of my thinking sessions it dawned on me that:

    Yes, all those people are in the development team and they are all expected to be developers. The problem is not them. The cause of the confusion is not their function, it is the hijacking of the term ‘developer’ and making it mean the same as ‘programmer’.

    Being developer is not a function, it is an attitude.

    Programmer, tester, UX, cryptologist, devops, CM engineer and other similar things are specialist functions. You can have a group full of these in your ‘cross functional team’ without them being a development team. Likewise, you can have them all in a group and they can simultaneously be developers with certain functional expertise.

    About programmers

    Programmers like to program. Actually let me rephrase that. Programmers love to program. It is our passion. We love to play with code for no other reason that it makes us happy and it fuels our curiosity.

    In programming, we push the boundaries of our knowledge, gain skills and explore a world where we make things – sometimes pretty cool things – happen. Programmers are curious people – not about everything – but certainly about how computers tick and how we can make them tick differently. I say again – it is our passion. The thing that makes our eyes light up in an otherwise uninteresting conversation.

    As a programmer, I don’t really care whether what I wrote is marketable or whether it is usable by anyone but me. Even broken code is interesting to a programmer and as for tests – screw them – I know how this sucker is put together and where it breaks and how to avoid it. Also, I don’t care if it solves anyone’s problem other than mine – even if my problem was “I was bored”.

    Programmers are not lone wolves or billy-no-mates. We have friends, not many and typically they are other programmers. Programmers are collaborative even if sometimes a little competitive.  Our focus is inherently narrow, oh but what focus. We think deeply about the problem and delight in reaching a state of elegance and great technical design that makes our every future move in the code sublime.

    Now, please don’t misunderstand me. Programmers are vitally important. The World is deeply computerised and will continue to be. It needs people who are curious about computers and passionate about making them do things. The World also needs at least some of those programmers to apply their skill to developing solutions for the challenges that face us all.

    Expanding this further, let me say that functional specialists are vitally important. That is where expertise is created and boundaries of the possible are pushed out further and further. Functional specialists are driven by the curiosity and fulfillment that their specialisation provides.

    There is no shame in wanting to remain only a programmer or any functional specialist. Personally I would be delighted to simply code stuff in my study all day and all night and never attend a single meeting about any damn thing. In fact I would like to not talk to anyone and have no one talk to me. My brain gets shafted with all the things I have to hold in it as a developer AND as a programmer and I would be quite content not having my brain shafted. Luckily the stuff I know as a programmer is pretty much instinctive now, but nevertheless, being a developer is still hard work.

    Whilst there is no shame in choosing to be only a programmer, there is pain and suffering in privately and silently choosing that but publicly being expected to be a developer. Choose who to be and be who you choose.

    About developers

    If programmers are focused intently on a narrow and often technical problem, developers focus on much broader and often business-centric problems. The broader problem that developers are challenged with may need nothing to be programmed nor tested or designed. They care that the solution meets the need. They care that it is usable and valuable and they seek feedback to those ends.

    There is always a big picture and developers make time and head space to understand it and be part of evolving and delivering it.
    Developers seek feedback and are prepared to do whatever is needed to get to it. Developers seek collaboration with other developers because they realise it takes more than their specialisation to deliver a solution. This collaboration takes behaviors often missing in certain functions and developers seek to gain those behaviors so that they can collaborate better.

    Critically developers recognise that the most functionally correct thing is not the same as the most effective solution. They know when enough is good enough.

    In my line of work, I come across many functional specialists who complain they often do not have enough to do during an iteration. They often say this when there is an abundance of work to be done to deliver the solution. They argue that it is inefficient or ‘poor resource utilization’ for a programmer to test or get involved with elaborating requirements. A developer contributes in whatever way they can to develop the solution.

    Re-defining the development Team

    A development team contains developers. A cross functional development team contains developers who together are able to perform all the functions required to deliver the solution.

    A developer is, almost always, also a functional specialist. That is they have the attitude and have deep skills in one or more functions.

    A development team is fundamentally a learning vehicle. Its members recognise that in order for each person to consistently and effectively contribute to the solution that they must they learn from each other. They know that sometimes the nature of the work needs different measures of the functions and they adopt behaviors – like pairing – to create that learning towards helping each developer contribute as much as they can. So programmers learn to test and design and do configuration management – at least a little. Testers learn to code and design and manage configuration. At least enough to be useful.

    Why I wrote this

    I wrote this post because it I consider it to be cruel to expect people to be what they don’t want to be and worse still, to penalise them when they do not meet those expectations. This cruelty saddens me deeply.

    I wrote this because I witness the violence that is done in the name of delivering software and I have unwittingly been part of that violence. From the sense of exclusion encouraged by functional silos to the treating of certain functions as second class citizens, peoples’ feelings are marginalised and their needs ignored.

    I wrote this because I sincerely want organisations and specifically their management to understand the distinction between the attitude and the function. I want them to act more humanely when they hire and when they reward. I want them to explore more non-violent ways to design an environment that encourages developers AND functional excellence.

    I wrote this because I want programmers to understand what is expected of a ‘developer’ and to make an informed decision whether they want that. I want them to make that choice without coercion.

    If they choose to be a developer, they accept that they may be called upon to do things not in their expertise and they do so happily. I want them to fully realise that their choice means they are interested both in the joy of programming as well as the satisfaction of developing something that makes a difference.

    Finally, I wrote this so that the word ‘programmer’ is no longer considered synonymous with ‘developer’. I believe that, by breaking this defacto equivalence, programmers will be happier people and simultaneously other functional specialists will feel equal and included partners in delivering a solution that meets a need.

    What do you think?

    If you are a developer, do you recognise that it is an attitude and not a function? If not, why not?
    Do you disagree with the distinction between developer and programmer? I’d love to know why you think they are not different.
    What are your experiences of one being confused with the other?

    I’d love you to drop me a comment below or let’s chat it out on Twitter.

  • Managers as Ecologists

    I have recently been gripped by what I consider is a very powerful idea and I would love to share it with you, in the hope that you might ‘Yes and‘ it (make it better/ enhance it) and perhaps explore it in practice at your business.  ‘Business Ecosystem’ is a much abused term. I find that many CEOs and senior management use it as buzz phrase to mean their organisation structure (typified by their organisation chart).
    In the most common misuse it depicts no more than the chain of command or the boundaries of blame.

    What might happen if corporate managers reframe their roles to understand their organisations more like natural ecosystems and set about being stewards of understanding what needs to thrive in that ecosystem and helping to establish and sustain the conditions to support the organisation’s vision?

    This is simply a first pass at this idea. Enough, I hope to get the early adopters amongst you thinking more deeply about this approach. More will follow.

    Disclaimer: I cannot be held responsible for the untold learning and outright wonder that this information may unleash in your life.  Proceed at your own caution, but enjoy it. 

    A Word About Ecology.

    Ecologists are interesting  people.   Geeky (i.e. intelligent and obsessive)  for sure, but interesting. They study nature at various scales. The stuff that lives in it and the stuff that lives on them and so on.  They think about the conditions in which life exists in the space they are studying ( those conditions that most of us wouldn’t give two hoots about like how much nutrient is in the earth, what puts it there etc).

    Ecology is painstaking. It all starts with a study of what is present in the space under study and how those components are related. This is complexity in action.
    In natural ecosystems, ecologists talk  of food webs and chains, nutrient flows etc.  All of which point to how energy in the system flows (through death, decay and being eaten by some predator).

    It all starts with a Picture.

    Artist’s rendering of the complexities of the Gulf of Alaska marine ecosystem. Image courtesy of Exxon Valdez Oil Spill Trustee Council GEM (Gulf of Alaska Ecosystem Monitoring and Research) project. Click for a larger version.

    This picture is, as you may have guessed, from the Exxon Valdez oil spill case. Take a moment to really look at this picture. It has a lot of detail. Go on, get comfortable with it.
    What is it saying to you?

    But why all this effort for a picture. Well one word…understanding.  Very deep understanding of the forces at work in the system. Understanding of the subtle and delicate balance that exists between apparently independent components.  With understanding comes wisdom, with wisdom comes better informed and more responsible action.

    Let’s test just how much understanding you have gained from this picture alone.

    Let’s say I asked you to suggest ways to help salmon thrive, purely from the detail in this picture, what might you say?
    Or what might we do to increase the population of rare sea birds?
    What if I asked you to imagine another potential spill occurring around the center of the picture, what might be the immediate likely risks and how might we need to respond to minimise it?

    The point is, you can make a pretty good set of suggestions and recommendations (and you likely aren’t an expert, geeky ecologist!) just from this picture – let alone the deep underlying data that went into creating it.

    Beware Social Engineering

    Now before you freak out and accuse me of advocating social engineering, let me say that in the brave new world of business agility – in which we are seeing the biggest challenge to traditional management since the industrial revolution, the role of management needs clarification.  Coaches and ‘thought’ leaders talk of ‘servant leadership’ and ‘change agents’. All that is well and good, but still managers are generally befuddled. The rise of self organising teams to solve complex problems has only amplified the need to get the role right

    I am suggesting that management can  be that part of the organisation that is specifically tasked to pay attention to the conditions  under which work is done.
    They can understand what they should be measuring and monitoring (like water quality to understand health of fish stock!) and measure them effectively (and efficiently). They can explore the feedback loops that will be most effective.

    The beauty of an ecosystem  based management approach lies in where it leads the curious and engaged mind.
    It leads the ecologist to follow the threads of interdependence, encouraging them to widen the boundaries of their ecosystem until they form a clearer, richer  picture of the real dynamics that exist in their organisation.  It leads them to ask ‘what should our ecosystem be optimised for and why?’ (goals!).
    It leads, if you let it, to a more holistic and human view of a deeply human system that is often deeply dehumanising. It may lead to more joy at work.

    Note of Caution:  Using this approach is , of itself,  neither good nor bad. It is informative.  It rests with a healthy organisation to hold itself accountable to act ethically and not use the visibility that an ecosystem based management provides to megalomaniac ends.

    The Metaphor Only Goes So Far.

    But it goes far enough to be useful.  Be creative about how you consider this methapor, particularly about:

    Food Chains.
    In natural ecosystems, the primary way energy is released or transferred is by predation (i.e. something eating something else).  Now hang on, I’m not advocating that you start feeding on your colleagues.  What might be the analog of ‘food’ in your organisation? What forms the ‘energy’ of your organisation.  In many that I work with, it is information.

    The ecologist is part of this picture.
    Usually, the ecologist is studying a system as an observer (unless they are studying systems with human components that include them) . In this approach, the managers are part of the ecosystem they are tasked with studying and understanding. The other living components of a corporate ecosystem are other human beings, with opinions , feelings and the ability (and intelligence) to articulate them. So ecosystem management here is more about doing things with the the ecosystem vs doing things to the ecosystem.

    My Challenge To You.

    Hopefully I have described the basics of my idea well enough for you to do something with it. I would like you to consider these as next steps.

    • Draw a picture of the components in your ecosystem (start with your team as a space under study) – look at living (e.g people, pets, plants) and non living components (e.g code, servers, food!)
    • Identify what represents the things that are exchanged (the energy that is flowing) – what is the primary thing (e.g money, information, code?)
    • Identify how your components are related and interdependent. If it helps, consider who influences whom and how?
    • Then, think for a minute about something you would like to see improved in your ecosystem (for example, attitude to risk, reduce blame) and see if you can identify how your picture might need to change to help this improvement emerge.  If you can’t, try reworking the components and relationships until you can.

    It’s worth it.

    Drop me a line @mhsutton on twitter to let me know how you get on or if I can help you think it through.  I’d be delighted to.

     

  • 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.

  • Planning is good, Execution is better.

    A Little Secret

    I have to admit something, please keep it quiet. Come closer, I’ll whisper…

    “LATELY, I HAVE BEEN ALL PLAN AND NO EXECUTION!!”

    Its a damn nuisance, every time I am about to get going on something, life conspires to really slow me down, in the form of pesky childhood illnesses messing with my children, moving countries or more work (at work) than I know what to do with.

    So, on Sunday night (yeah, March 25th) I gave myself an ultimatum –
    “Execute or revoke your planning rights”.

    The deal was to start burning down on some of all this work that was queued up or just admit defeat and never add anymore.

    What kind of work am I talking about anyway – well here is the broad list:

    • Work on startup idea #1/17: Something called ‘StoryTeller’. Its stealth right now, so ssssh!
    • Do more yoga, specifically Bikram ‘hot’ yoga. You can share that experience in “Getting Sweaty – My First Bikram Yoga Experience.”
    • Read more (more variety, more often)
    • Knit more
    • Blog more at wizewerx.com, blogs.chittych.at and mhsutton.me (here)

     

    Paralysed By Planning

    Like I said, I spent a couple of months in planning paralysis, pinned by fear (of failing, learning curve sickness), plagued by self doubt (“Am I good enough, am I still hungry enough to code till 3am every night and still hold down a highly responsible job?”) and prone to sudden bouts of laziness (“Screw work, I’m watching the Mentalist!”).

    So rather than start anything, I simply added more stuff and planned, planned and planned so more!
    To make things worse, as an agile coach and advisor to startups, I know that execution is where the goodness is.  Winners plan and ship and losers just plan.

    This knowledge is like a Jiminy Cricket on ecstasy – reminding me at every turn to do what I ask others to do when faced with a slump – take some time out, collect thoughts, mobilise energy and just do something (anything!) on the list. Most times this will lead from one thing to another and the execution engine just kicks in.

    Faced with doing something or giving up,  I chose to do something.

     

    Plan as though you mean to Execute

    To get out of my quicksand, I had to act.  What worked for me was to plan my next week like I really meant to go through with it.  I went into my calendar and added the time for Yoga, reading, writing and working on the startup.

    So on Monday – I called and booked a Yoga class and actually went to the Monday evening session. I paid €50 for 30 consecutive day trial. I already know how many days I will be going for. Its not 30 though.  This Yoga is different – its Bikram ‘hot’ yoga and I endured the most exhausting 90 minutes I have done since I stopped chasing chickens for sport. Then I started to write about it.

    On Tuesday, I did more yoga at home. Not the hot kind, but really enjoyable Vinyasa ‘Flow’ yoga.

    Did I read?  You bet.  Its too early to call it a routine, but I start with 30 minutes of my book (its on iBooks and its called ‘Calculating God’ by Robert J Sawyer)

    Tonight I also started work on Storyteller.  Nothing fancy, just some basic javascript to test some ideas.

    Oh. And I wrote this blog.

    Pearls of Wisdom       

    Here are 7 of the main learnings I could distil from my experience.

    1. If you can help it, don’t beat yourself up too much for not executing. Recognise that you aren’t and move on.  I didn’t do this soon enough, I hope you will.
    2. Act like you are going to do what you plan to do. Book a place on a class, pay the money, commit to someone – whatever.
    3. Be specific about what you want to do (I already had the specifics in my plan!)
    4. Give yourself a shorter timeframe than ‘forever’. Pick a week and see if you can sustain it for a week.
    5. Don’t give up. Email me and I’ll help you keep going, have a beer or two. Maybe take a break, just don’t quit.
    6. Get some early success, it helps.
    7. Have something to show for the work you do. Visible results of execution are fantastic motivators (I have the sore legs to show for the yoga and this blog to show for the writing).

    Thanks for reading, I would love to know what you thought of this post.

  • Managing Mirrors

    It was a great pleasure to facilitate the recent Agile Coach Camp USA (twitter hashtag #accus) open space. During my regular walkabout to ensure all the sessions were happily bubbling along, I happened on an intriguingly titled session called ‘Steal My Frustration’ convened by @azagile (Michael Kutch). My observations on that session are contained in another post called ‘Pausing for Thought’.

    During Michael’s session, we got into an interesting discussion about conflict management situations and what options existed for coaches or team servant leaders when trying to minimize harm and help contain the situation.

    Sometimes a person can get so angry about something that the only option in the moment is to let them vent it to a point at which you can safely and reasonably engage with them. When this person is in a team and their actions can be destructive/disruptive to either themselves or to others, the teams servant leadership (coach or scrum master) has a duty to protect the person, themselves and the team from as much of the energy as they possibly can.

    I coined the term ‘Managing Mirrors’ to describe the visual that came into my head as the discussion progressed.

    I imagined the angry person in their period of anger, as running amok with a laser beam indiscriminately cutting down anyone around them. At a time like this, the most anyone could do might be to run around with mirrors, deflecting the beams away from not only the bystanders, but also away from angry person and ,of course, the coach.

    Whilst it is tempting to assume it is only one person’s responsibility to ‘manage mirrors’ in a scenario like this, I feel that it falls on other members of the team (even if purely for self preservation) to, perhaps, manage their own mirrors. To ensure they are not cut down, whilst also ensuring they are not deflecting anger at others as they try and protect themselves.

    As I described this visual to someone else, their view on the title created a different possibility, one that I feel could yield a powerful coaching metaphor as a a way to help people effect the change they would like to see in their world.

    Our behaviours often reflect what happens around us. For example, if an organisation does not demonstrate it respects its employees, it can be difficult for employees to demonstrate respect for each other – particularly if they have no other social bonds beyond working together.

    At a personal level during interactions with others, being able to ‘reflect’ the other person’s behavior in a non-violent way, might lead to opportunities to improve. Or being able to project the positive attitudes in a way that is then reflected back to you (almost as a measure of improvement) is very influential technique.

    From a servant leadership position, sensing what a person might need in terms of what is reflected to them at any one time, is an interesting way to think about ‘managing mirrors’, because it might help to guide our decisions on how to offer connections (I know, some example would really work here!).