I rarely publish the feel-good emails that circulate amongst family members, but this one was a gem. Who doesn’t love cute baby chimps!?
A mother chimpanzee who lived in a Zoo died recently and one of the Zoo employees took her baby chimp home to care for it. It never crossed his mind that his dog, who had recently given birth would adopt the chimp and raise it with her pups. Judging by the look on her face at times, she is not quite sure why this particular offspring has hands to grab her with, but all the same, this strange little “pup” which has joined her litter has brought out in her – AND her real family – for all the world to see – a portrait of exactly what unconditional love is all about.
Even as you sit in judgement of my colour, my clothing, the way I walk, how I talk, of my tattoos and my piercings. I wonder.
Even as you deny my humanness and create for me a false history of menace and incivility from your dim view of something I said or didn’t say. I wonder.
I wonder why your world is so small when your mind is capable of endless curiosity
Even as you condemn me for loving someone just like me, or for not loving someone just like you. I wonder.
Even as you deny my freedoms when recognising them makes you no less free. I wonder.
Even as you commit crimes against my person, my name and against truth. I wonder.
I wonder what crime was committed against you to turn your heart so cold when it seeks only to dance in the beautiful warmth of fellowship.
I wonder who judged you the way you judge me. Who didn’t love you the way I want you to love me?
I wonder all these things and and I am sad.
I wrote this in a moment of deep empathy for all of those who are the victims of the judgement of others – from Oprah to emos. From muslims to orthodox jews.
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:
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.
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:
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.
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’.
Earlier today, I watched a Ted talk by Alain de Botton and one of the points he was making was that Western civilization has become more individualistic and this might have something to do with how we view the attribution and responsibility for ‘success’ and ‘failure’. Combining what Alain was exploring, in part, with my own long running musings yielded something profound for me. That is what I want to share with you.
FYI: This is not about religion. It is about the beliefs that we each operate on when we are on the edge – about to fall or to fly. When I mention Christians or Muslims I simply do so to describe the fundamental belief – not the structures of their religion. So chillax with the fatwas and threats of Hellish damnation.
Life is hard, it has always been and probably always will be. Hardships can be big and all-encompassing – something we face collectively like a meteor striking the Earth or a global epidemic. More typically, there are the personal hardships that we face as individuals or in small groups – friends, families etc.
Hardship could come from natural disasters like earthquakes and tsunamis that bring hardship swiftly and on a mass scale. There are the hardships that we do to ourselves – wars, genocide, persecution of the different. They might be hardships as a result of the way we collectively choose to live – economic poverty, hunger, unemployment and so on. They also include personal hardships like depression , low self esteem and so on.
One of life’s primary sources of hardship is uncertainty. We don’t know what will happen and that scares us.
Whilst hardship is perpetual, it is also ever-changing. In the middle ages in the western world, ‘hard’ was plague and sanitation, peonage and deeply laborious work.
As we make advancements in medicine and technology, ‘hard’ again is redefined – at least for some of the world. We hear things like ‘first world problems’ – my phone battery only lasts a few hours, I have full fat milk in my latte when I asked for soya!
Hardships are relative in time and between people. Some things that were hard – like infant mortality in 1800s are much less a problem in the 2000s. Yet where you might consider a chipped nail to be ‘devastating’, another person’s ‘devastating’ is losing both their legs.
As we advance ways to make life easier, we seem to create new ways for life to be hard.
Even when we can explain what we previously could not, the wonder remains and is even more wondrous. The joy and wonder of life also operates across the grandest scales – like the endlessness of Space – to the smallest – like an ant being able to lift several times its own body weight. From the chaotic formation of new islands from volcanic activity in the Pacific to how, in an instant, smelling your favorite food from your childhood can transform sadness into delight.
The wonders of our natural world, of Space and the diversity all around us are truly breathtaking. How do we explain them? Our advances in knowledge and technology help us not only to seek answers to old questions, they help us discover new things to be wondrous and curious about. Yet more remains inexplicable.
Our timeless need
So in the middle of this mash-up of hardship and wonder is Homo sapiens – the human. However you believe we got here is irrelevant at this point. We are here.
The human is a sentient being. We are capable of perceiving and feeling things around us. We are generally well adapted to converting those perceptions into emotions and reacting accordingly.
Our ability to feel may also be the single biggest contributor to our timeless need.
Life’s hardships and wonder can generate such powerful emotions in each of us. We act on those emotions – we kiss, we kill , we flee , we fight and we sometimes do nothing. Each action generating more to be perceived and more emotions generated in us and in others. These emotions can be so powerful they could be life changing or life ending.
They can be so overwhelming that the person feels they cannot contain it, it is too much and it is greater than them. For example, imagine your entire family being wiped out by volcanic eruption, suddenly and violently. How do you cope with that? Or watching your loved ones systematically cataloged and slaughtered by other people who believe you not to be human. Even imagining it is almost impossible.
I remember seeing each of my children being born and the feeling is a little overwhelming.
I can explain how a child is conceived, how they grow in the womb of the mother and how gestation works. I understand the chemical reactions that occur to help that baby emerge into the world. Yet none of that prepared me for the feeling of being overpowered by love and humility as this little life was placed in my arms.
What would happen if, at that moment, that life was denied – how can any new parent even comprehend that?
There are things that are bigger than our ability to emotionally process them. Our timeless need is that, whether through hardship or wondrous joy, life provides things that we are powerless to comprehend but need to make some sense of, lest the emotion destroys us.
And this is where God comes in.
Explaining God
Before I go any further and to help us both understand what I am talking about, it is useful for me to define what the word ‘God’ means for me:
God is that non-human power that transcends everything around me and who sees all, knows all that ever was and ever will be. This power is also invested with justice against all that I consider unjust but am powerless to bring to account
And what are the properties of God?
God is all good because there is inexplicable goodness in life.
God is just and all-powerful because there is such senseless injustice in the world that we are emotionally overwhelmed by and yet are individually powerless to make ‘right’.
God is all-knowing because life is uncertain and implicitly we know there are things we cannot yet know – we just don’t know what we don’t know.
God is kind because there is unbelievable cruelty in life and it happens to us and the people we love.
God is fair because there is such inequality in life. There are natural variations in people’s circumstances that result in hardships. There the inequalities that result in the way we choose to live – hunger and poverty in the midst of such financial wealth. The ethnic and social caste systems that seek to institutionalize these variations.
In some religions, God is entirely the positive and to explain the negative, another deity is required – like Satan in Christianity. In others, both hardships and wonders are the faces of the same power.
My friends who actively practice their religion – Christians, Muslims, Buddhists etc simultaneously amaze and inspire me with their faith.
They tell me their belief provides a framework to put all of the emotions they cannot deal with in context. The wonder of life is God’s doing and the hardships – wherever they come from – are a test to help them grow as people and closer to God.
God is both the giver (birth). Infertility is a test and in any case it is God’s will. God is the taker (death) – so even as you grieve it might help to think there is a higher ,albeit unknown, purpose to why you have lost your loved one.
My Buddhist friends tell me that to be closer to God we should disassociate from those perceptions – a sort of emotional protection. Having the discipline to detach what you perceive from the emotion that you generate from it is the road to Godliness. Developing that discipline is the lifelong practice that we must commit to.
Hinduism diversifies things a little – there is one God that is manifested in several other deities that address particular aspects of powerlessness. Vishnu is the protector and the preserver who is our source of sustenance to endure. Shiva is the God of annihilation , the destroyer and the enforcer of justice and more than 330 million other deities serve as a means of making sense of the various permutations of collective and personal powerlessness. Hinduism really extends the specialisation of deity along the same lines of Greek and Roman classic beliefs.
Regardless of how many Gods we have – the purpose is pretty much the same, make sense of what is beyond our personal comprehension.
Yet what happens when we do not have a belief in God that we operate on?
This is what really triggered it for me in Alain de Botton’s TED talk. Botton asserts that in Western societies, we have removed God from the core of our beliefs and focused more on individual and collective responsibility. We rely on Science to offer the answers more than ascribing the unknown to God.
We seek evidence and not simply invest in faith. The outcomes of personal success or failure are attributed to the individual more than the plan of a God.
This is new or at least it has been so long since it was the norm that is might as well be new. Not even communism had this effect. In communism the collective had the answers, personal ambition and therefore personal success or failure were much less relevant. In theory anyway.
Yet the timeless needs still remain. The hardships are still there, so are the joys and the wonders. In the absence of God, who are we supposed to pin our powerlessness on?
Where we cannot rationally take responsibility for something – like the death of a parent from a terminal disease, we simply absorb it.
We put it in a box and bury it. Some might become philosophical about it – another mechanism to try to make sense of powerlessness – but ultimately the emotion is locked away. Ask anyone who has lost a beloved parent to go back to that box and explore its contents – especially without a framework of God – and observe how raw and powerful the emotion is, triggered by the memory of their loss.
Sometimes absorbing it causes huge emotional problems – breakdowns, deep depression – that lead to ever more self-destructive behavior.
What of the things that we can somehow see our responsibility in? Like being the survivor of a terrible fatal accident or accidentally causing the death of child?
Where a God framework might serve to blunt that emotion by saying “you are human, you can fail, it’s God’s will”, a godless person has no such shelter. The full perception is there. Most people can rationalize it and remove some of the potency of the sense of responsibility and emotions associated with. Others cannot and they get depressed, might seek self harm maybe even suicide. Could this help explain the rising incidents of depression in Western societies?
My friend – a Catholic priest – tells me that when he is in the confessional, it is fundamentally about helping the other person forgive themselves so they can move beyond the powerlessness.
Fundamentally, I believe Man created the concept of God. We invested the antidotes for all we are powerless against into that concept – kindness, forgiveness , justice, certainty, strength, immortality and eternal well-being.
What might happen if we took these virtues back and invested them in ourselves? What might happen if we were each kinder to ourselves, were more forgiving of ourselves and others or that we were able to eradicate the causes of avoidable powerlessness?
Why I wrote this
I wrote this because we are complex beings living in a complex world. We are making it more complex by our actions. I wrote this because I want us to make things simpler for ourselves so we can focus more of our abilities on addressing the complexities around us.
I wrote this because being in the uncharted territory of Godlessness is not the same as being lost and I want us to seize this opportunity to be kinder and more humane to each other. To evolve to become closer and more connected as human beings. I believe we can do it – we don’t need God, we need the virtues of God.
I wrote this because I want us to begin to focus more on tackling the causes of powerlessness and not simply fight the often explosive consequences of it – like religious radicalism that ends up in massacre and mayhem or mass revolts that trigger further repression.
I wrote this because whilst religion provides mechanisms of human connections to each other – fellowship and a sense of community – and a powerful sense of personal connection to God, it also invites other behaviors that promote new hardships. Judgement and condemnation of others and the easy abuse of position by the administrators of that religion. I want the good bits and frankly, none of the other stuff.
I wrote this because the institutionalization of God – religion – has long caused and continues to cause more conflict than it resolves. We are fighting about whose hose is better even as the fire threatens to burn us all. I want the divisions to stop. I want us to see that we have fundamentally the same needs, challenged by the same forces and we are unbelievably more powerful together than as we fight these ineffective ideological battle.
Finally I wrote this because I want the next young Mike Sutton who is wandering the internet confused about feeling outside the mainstream and dissatisfied with religions he sampled and the beliefs he explored – including atheism – to have something to read that offers an understandable and reasonable account of a different, kinder, more empowering and more human perspective.
I’m in Galway, Ireland for a few weeks to do some work for a client.
The last time I was in Galway, I was here for year with my family. This time I’m here for 5 weeks without my family and no cooking facilities in my digs. Combine that with an allowance from my client that I can only get if I spend it, leaves me with no choice really – I have to eat out.
So over the next 20 days, I intend to have dinner at 10 choices from the Top 20 restaurants in the Galway city center area (because they have to be within walking distance!) and another 10 – randomly selected – from all the other 230. I’ll blog about each one and perhaps suggest an alternative ranking based on my own experiences.
The aim, first and foremost, is to get fed and have a good time getting so. The other is to check how wise the TripAdvisor crowd is. Is their #1 really worthy of being a #1?
Join me as I eat my way through Galway’s most popular eateries, sponsored by my client.
Some of the first restaurants I shall be checking out are:
Oscar’s Seafood Bistro
La Fine Bouche
Kai
Kirwans Lane Restaurant
The Pie Maker
The Park House
Brasserie on the Corner
Brasserie on the Corner
Sushi In the Sky
The Quay Street Kitchen
How I intend on reviewing these restaurants
Well I’m no restaurant critic – I lack the pretension that I can tell my wines apart or that my steak is blue, green or grass fed.
Frankly I’m going with trying to review the entire experience – from making the reservation to how welcome they made me feel, how lovely their food looks, smells and tastes and how accommodating they are to my requests. I’ll include how they value my time (I get fairly upset if I’m kept waiting too long for stuff) and I’ll consider the ambiance of the restaurant and the providence of their ingredients – locally sourced vs otherwise.
Where I can I would like to hear the story of the restaurant – preferably from someone other than the owner.
If there is anything you think I should include, please let me know and I’ll consider it.
Wish me luck, I’m doing this for you (ok, who am I kidding)!
My bro sent me these images showing new and imaginative ways old products are reused. I feel very inspired – if a little inadequate a designer!
What interesting ways are you reusing old materials?
ps: I don’t know what the copyright status of any of these images are. If you believe any of them are not to be freely published under some sort of creative commons license, please let me know and I shall take them down.
I ceased work on ServiceChat – the startup that I have been working on for six months. It might not seem that long to you, but to me it is a very long time of illusions and self discovery.
My learning from why ServiceChat didn’t go where I had ambitions for it to go will continue to emerge over time, but one thing that pops straight out is that I didn’t know my own my mind. Let me explain?
Too many sources of information
We are in an age of startup frenzy. All the cool kids are in startups and it is an exciting time that is all the more exaggerated by the media feeding on the spectacular valuations and fortunes. Politicians rest the recovery from recession on startups and entrepreneurs, kids are encouraged to code from a young age and be the next Zuckerberg and dreamy eyed youth are cluing on to the fact that the barriers to realise their ambitions are lower than at any other time in the history of business – well at least for tech startups anyway.
There is such a rich ecosystem for startups – blogs, books, incubators , accelerators, coaches, advisers, mentors and so much more – maybe too rich. The reality is that almost everyone in this ecosystem is a startup themselves. They are selling something – their idea, their learning and some times their services. So you are their customer – of sorts – and their messages can be interpreted to make you think their way is better or your goals are the wrong ones. With so many opinions competing for your attention, it is easy to get distracted.
I got sucked in. I bought and read the books, I read the blogs and heard expert after expert tell you how to do it – or how not to do it. Everyone means well – absolutely – and there is a wealth of anecdotal sense in what they say. But in a blog or a book, you read what was written whereas the learning you might need is in what was unwritten. In any case, as much as you recognise the symptoms they talk about, they are not talking about your particular condition in its entirety. I still needed to know my own mind.
But there is no recipe for growing a successful startup. There are general ingredients – test your idea, continuously validate and others. The exciting bit is that you get to decide what you are cooking and what the recipe should be.
Fail on your own terms
My trouble was I was seeking my mind in the words of others. That took a huge amount of focus away from what I was supposed to be doing – finding customers and trying to find market/product fit. It was also emotionally wrecking, constantly second guessing myself when yet another blog implied to do the opposite of that the previous book advocated. Was I following the *exact* process or was I doing what the book said? Occasionally my rational mind would chime in and say:
‘Screw them, they don’t have to find next month’s rent, you do – you have to do what you have to do to build this thing!’.
But I would mute it. Failure is hard to accept. But it can be easier to deal with if you understand why you failed and you learn from it. Failing on your own terms is perhaps the best you can have. In my case, one of the reasons I failed was not knowing my own mind.
My Learning
I’m not blaming anyone or anything – I don’t believe in blame.
I do believe in behaviors being more or less effective towards a goal. My learning here is that focusing on a process or a body of other people’s experiences to build my own startup was not an effective way for me to achieve my goal of a successful and viable startup business. The next time – and there will be a next time – I won’t do the same thing.
I will have my plan and I’ll be comfortable with my plan. I’ll formulate it from my own experiences and instincts. I may run it past advisers or check for obviously stupid aspects of it with books or blogs or other sources of information. I may otherwise revise it but ultimately I will do it because it makes sense in my mind.
I encourage you to completely disregard this post. It was my learning and my experience and it absolutely may not apply to you. Know your mind.
A few years ago I spent a few weeks working in Berlin. The work was through the consultancy owned by my friends Marion and Andrea. To keep costs low and to help make my stay in Berlin more enjoyable, they offered me a room in their lovely apartment.
Marion is a beautiful human being and absolutely WYSIWYG – What You See Is What You Get – and she also speaks her mind. From the get go she declared that there shall be no peeing standing up. This applied to me and the other visiting consultants.
Her reasons were perfectly logical – you sprinkle when you tinkle and the wipe up can be a little hit and miss, so be a sweetie and sit down when you pee! It almost entirely eliminates the mess. Also reasonable because she has a cleaning lady come in a couple of times a week to clean the apartment and no one really needs to be wiping up other peoples’ pee.
A few jokes were made, but we all knew that she made sense and even if her directness was a little grazing, we would still be more mindful of her request. Now I don’t know how the other guests complied with her request or the need behind it – leave the bathroom clean and dry after your visit, but I actually tried to do what she suggested. I tried to sitting down to pee.
A history of being upright
For a guy who has spent 39 years peeing upright, this was a fairly unnatural stance. I would guess I’m not alone in that sense. I’ve never been in a men’s bathroom that had the urinal area that was anything other than gross. Granted there are different degrees of gross, but gross nonetheless. There is always bits of hair, occasional dandruff and chewing gum in the urinal, legacy wee on the flow and the ever present danger of you peeing on your own shoes. And don’t forget the awkward avoidance of looking down when you are shoulder to shoulder with other men draining the camel.
Typically, going for a pee is a super fast job – in and out. There is no lingering by the urinals – unless there are other agendas afoot. You wouldn’t anyway – the stink is fairly overpowering.
Even peeing upright in the privacy of your own bathroom is fraught with risk – so much could go wrong. Toilet seats dampened and left up, lids not put down and the potential for puddles all make this a risky venture. Many a loving relationship has been strained by this recurring risk.
You might think that with so much opportunity to practice that there would be no problem. I have a theory about this – You only get good at what you deliberately try to get good at.
If I pee on average twice a day everyday for 39 years – that is 14244 days or 28,488 opportunities to practice. You would think that I would be an expert at peeing. But no, I still get seats wet, the occasional drip on my shoes and certainly leave the seat/lid in the wrong configuration many many times. So if it’s not the lack of practice, then it must be about the lack of deliberate focus.
Time for something different
So with this in mind, I was determined to explore something different – to deliberately get better at peeing. I tried sitting down and over time the sense of weirdness disappeared. Not only that, but I also found there was no spillage and no puddle. It was all tinkle with no sprinkle. The toilet seat is left down and it is clean and dry for the next occupant. The residual hair dropping was also greatly reduced. I never had a dandruff problem so no view on that.
What amazed me more was the opportunity to take a break. Sit down, take a load off and enjoy the experience. At least twice a day, you get a moment to yourself. It takes marginally longer than an upright pee but you get so much more. Peeing upright does not really afford you that opportunity, you’re on your feet, you got places to go and people to see. You might wash your hands or not and often if you do, do you really wash them well enough?
I found myself consistently more relaxed and remembering to wash my hands more often and more deeply than when I was an upright urinator. (ok that is not a real word).
For all the benefits I mentioned, there is still one bit that I am not yet entirely consistent at doing – putting the lid down. But with time and deliberate focus, I expect that will happen to0.
Thanks
I have to say a huge thank you to Marion for that suggestion two years ago – I know we joked about it, but it really worked for me! Olaf, my male German friend says that men peeing sitting down is far more common in Germany that anywhere else he had been. I don’t have experience of that either way.
So fellas if you are looking for something that will help you be more hygienic, delight the ladies you share your lavatories with, give you back a few serene minutes of your day and leave you with dry shoes then consider peeing sitting down. You might thank me!
Whilst researching a post about Morrisons and its customer service on Twitter, I discovered that even though I could see all the customers that had an experience on a given day, they couldn’t see each other and at least one person commented on her impressions being totally different when she discovered the ‘big picture’. This left me intrigued.
Then I was reading about Elon Musk and his suggestion about first principles as great place to start looking for innovative ideas. I prefer this idea to thinking in analogies – which are great for many things, but perhaps less for disruptive innovation.
That is when a weird thought came to me – a first principle of human interaction is that we seek connection. What if we could be connected by shared experiences as customers – what might happen?
Honestly I don’t know and I would like to find out. Better still I would like to see if what I find can form the basis of a viable startup business. Regardless – it would still be interesting to explore what a direct interactive connection between consumers around a shared experience would mean for customer services, how commerce is conducted and maybe even how we think of each other as human beings.
What’s with the timer?
So my last experiment took me almost 6 months to fail – that is way too long – I need it to be 6 weeks or less. I got distracted and I lost my sense of urgency. This timer, along with my plan and a new found discipline are to help me not make the same mistakes again. If this experiment is still running when this clock runs out – it may have been validated as unviable before – I will stop it unless I have a paying customer for something. It sounds aggressive and it is. Game on!
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.
