Category Archives: It’s Only Natural

The Manifesto for Playful Product Development

Posted on by

Guest Article written by Graham Holden – here’s a little something about him in his own words:

Graham describes himself as a Programmer, Scrum Jester, Shantyman.

Has been working within the internet industry since 1997, for a variety of organisations.  Has a passion for programming and helping teams become effective.

******************************************************************

 

In Peter Greys Book – Free to Learn (thanks Tobias Mayer (https://tobiasmayer.uk/) for recommending this), he emphasises the importance of Play for children’s learning and development. As a parent, I’m often conscious of not interfering in the play my children embark on. I’ll be present, so that if they need me for anything I can help – but I like to let them get on with things.

Peter Grey outlines Play as the following :

  1. Play is self-chosen and self-directed; players are always free to quit.
  2. Play is activity in which means are more valued than ends.
  3. Play is guided by mental rules.
  4. Play is non-literal, imaginative, marked off in some way from reality.
  5. Play involves an active, alert, but non-stressed frame of mind. (https://www.psychologytoday.com/gb/blog/freedom-learn/200811/the-value-play-i-the-definition-play-gives-insights)

 

It got me thinking about how, when I am programming for “fun” it’s actually me “playing”.

I feel that the 5 “rules” above could be adopted within organisations as a framework. Some might say business is a serious thing, and there is no room for frivolity. But what a lot of us have forgotten, is that as children when we “played” it was serious. When you are in the midst of it, play is all consuming – it is an example of a perfect state of “flow”.

I would encourage organisations to adopt the framework to help teams use play for personal development and learning. This would be a great first step. In the past I’ve been involved in some interesting breaks organisations have put on, these have been called “hackathons”, “hackdays” or just “learning days”. The most successful ones have essentially followed the basics of the framework outlined above.

  1. The Teams chose what to work on, and could switch to other teams if needed.
  2. The experience of the day and the activities trumped the actual end results.
  3. The teams got to work how they wanted, with what they wanted, and produce whatever they wanted.
  4. The teams could work on whatever they liked.
  5. The teams had very little pressure on them, there were no KPIs.

 

I believe more and more organisations should be adopted playfulness at their core, and we can have a playful movement for product development.

 

The only way to “Empower”​ someone

Posted on by

Time and again we hear professionals talk about empowering a being and how it’s the right way to go. How empowering a gender, race, team member or an organisation helps in improving accountability, ownership and peaceful collaboration. How this makes a robust community of respective subject matter to cohabit with shared goals.

Love the idea, it’s marvelous to see many people are embracing these great ideas. With that in mind, I asked handful of them –

How do you empower someone or a group?

 

Majority of the replies had a short pause, usually with a raised eyebrow, followed by a somewhat vague response like “By giving them chance to see the big picture, allowing them to contribute to the greater cause, authorising increased accountability/ownership and removing anything that blocks them”.

Seriously? Isn’t that what we should be doing anyway?

Technically anyone who is claiming to “Empower” someone is not really doing anything productive. Rather they are stopping their own unproductive interference. They are simply backing down from where they shouldn’t have been in the first place and they are taking credit while they do so. *Mind Blown*

Truth you came here to find:

The ONLY way to empower someone, is to stop dis-empowering them.

And stop taking credit while doing so. If we do, we are again not really giving them the credit they deserve while we steal the attention.

A person/group can be “Empowered”, only if they want to be!

The notion of empowering a being or a group also creates an illusion that it’s in our control. Sadly it isn’t. Fact it, if a person/group doesn’t want to be, we cannot really make them. It’s a personality trait where some like to do what they have been told.

What sort of person wouldn’t want to be empowered you ask?

  • “I did what I was asked, ask X who owns it now”. Silos – yes, some do love it and it’s all personal.
  • “Trust me I want to help but last time when I tried, your manager turned on me and requested me to mind my own business” – Fear of rejection.
  • “I told you this wouldn’t work. I can help you if you like? No? Alright then” – Ignorance of Skilled opinion over superiority.
  • “No, don’t want to get involved again. Last time I made a mistake and it affected my bonus. It was not even my domain of work.” – Outdated and demoralising KPIs

What can we do about it? Surely we can do something to Empower as Leaders

There are many ways obviously. I have found the following are good enough to start with –

  • Give them an achievable goal and back off. Support and Serve. Delegate and show trust. Allow failure that can be reversed. Make sure they understand they failed and ask them what they learned from it. REPEAT.
  • Find out what the impediments are and why can’t they remove it themselves. Let them try. If they ask for help, without passing a judgement first sort it out. Revisit on how much more we can/should do to remove the blockers in future. REPEAT.
  • Tailor our KPIs based on Team goals over individual performances. If we really care, let peer pressure handle it and monitor how are they performing as a team.

 

And yes, we should stop empowering people or tell ourselves that we can somehow.

As leaders, create a sustainable culture where people can Empower themselves.

Non-collocation is an Impediment with solutions – exactly like..

Posted on by

While reading the post/comments on an online conversation about non-collocated teams, I felt the need to summarise my views on the discussion separately.

If you don’t believe that non-collocation is a challenging impediment, here are 3 videosto prove that they are.. ALWAYS.

Emails in Real Life

A Conference call in Real Life

Oh you want to do a Video Conferencing? How about all other participants?

You having a lightning fast internet connection doesn’t help remaining participants with speed as low as 2Mbps or worse.

Watch this:

A Video Conference Call in Real Life

Let’s look at the Solutions, to make it work !

Preserving Normality When You Can

  1. Stay in contact
  2. Talk about the mundane, little things
  3. Visit Often
  4. Get to know each other
  5. Remember non-collated team members are humans
  6. Support each other, even over the distance
  7. Create trust
  8. Be committed to each other
  9. Don’t do anything irrational just because you’re angry or upset about something they’ve said or done

Doing Things Together and Bonding

  1. Share something
  2. Do the same things at the same time
  3. Learn together
  4. Make each other feel special
  5. Pursue common interests
  6. Create connection

Setting Expectations and Boundaries

  1. Discuss the nature of your relationship
  2. Talk through doubts, uncertainty, and fear together.
  3. Remain positive.
  4. Have reasonable expectations.

Truth about this Article

Being non-collocated is a challenge and is a reality that we all have to face in this digital world. A long distance relationship have very similar impediments but because we give a shit and we love that person, we try our best to maintain it.

The truth about this article is –

ALL of it’s content are copy/pasted from this Original Source .

 

This original article is about “Long Distance Relationship“ and how we can do our best to keep our loved one closer. After all, that’s all we can do to maintain a healthy relation.

Non-collocation is an Impediment with solutions, exactly like… Long Distance Relationship !

Thankfully, we already know how to deal with those impediments from our personal life experiences. Apply them. The goal is to remove those impediments gradually so the long distance stays a temporary work around. Please don’t make the mistake of asking people work in non-collocated teams for too long.

Debate Settled – 9 women can deliver a baby in 1 month

Posted on by

“More people” equates to “less time” for the same amount of job, right? When we search for “9 women can deliver a baby in 1 month” in google, it usually brings back results which suggests every “Project Manager” thinks like that in the world of software development. Here’s the proof:

 

I disagree on the fact that “every” PM is like that. Anyway, this article is not about a PM though. It’s about anyone who thinks and act the same way as it highlights in the joke. This joke has another dark side which suggests it’s easier for “any person” to think the same.

Let me be the devil’s advocate for a moment and prove that it is in fact possible but isPointless !

Biology as an Analogy

A baby stays in the mother’s womb on an average 9 months, before being officially “born” (natural birth as an example). Dad’s sperm invades mum’s ovule after competing with a million of inferior competitors. Survival of the fittest. It forms an embryo and begins a new life in a state which technically should be known as the moment of birth.

Imagine a Sci-Fi Movie “1 Month Baby”

Goal – Deliver the baby in 1 month

Hmm.. we have only 1 month to make this work and modify the human anatomy so it can produce each limb/body part of a baby separately on 9 wombs.

9 parts are (for simplicity) – Head (1), Hands(2), Legs (2), Chest compartment plus Respiratory organs (1), Spine and back (1), Buttocks (1) and reproductive organ (1) which decides if it’s a boy or a girl. 9 woman volunteers are chosen to make this happen.

To support this, each woman is specialised to deliver a particular organ/part effectively in the given deadline. The incubation period starts off well, everything is hunky dory. It’s a movie so there has to be a twist isn’t it? One unfortunate day, one of them got hit by a truck. Laying in the hospital bed she is not thinking about her own broken spine, she is thinking about the damage to the “head” inside her. Although it’s not a whole baby, it still is a baby for the mother.

Now the plan was to synchronise and deliver all parts on a single date, so we can eventually get a fully grown baby. The accident damaged the head and is not fit for purpose anymore. So the baby will never have a head, which is in fact the most important bit. So basically after a month there are 2 options –

  1. Let the baby live without a head
  2. Declare failure and blame the mother for getting hit by a truck

On top of that, questions will be raised on “Ethical” subjects –

  1. Who gets the baby after all this? Who will be called as the mother?
  2. To do this, don’t we need 9 specialised “Men” as well. So who will be the father?

FFS.. this is getting out of hands, lets plan a sequel to cover that subject later !

Back to Reality !

Question: Have the medical science managed to find a solution like that yet, in real world?

Answer: Not yet, phew ! But we are humans. We are good at breaking nature’s law for our selfish lives. We may one day able to do it in the name of “best breed” of babies. After all, human are playing the new god.

I believe, we should just iterate over each stages of development, on the same baby. It’s only natural.

 

Do you have a better option under your sleeves? Let’s explore it then, shall we?

Leave a comment !

WWWA – #3 Experience of Customer Service is Mandatory to get Agile

Posted on by

WWWA = What’s Wrong With Agile

Hope you had (is having) a great long Easter Holiday with your family. Back to reality.

A quick recap to the goal of this series, which will stay same on every following article – to make some space in our brains for this to stay in:

 

#1 – Agile is widespread, the Agile Manifesto isn’t

#2 – Harsh critics of Waterfall or Agile (or Bacon) are Awful Researchers

#3 – Experience in a Customer Service role is mandatory to understand Agile

Agile is still very much a software development philosophy that we are trying to adopt, mostly due to the fact that it was born within it. Although it applies to any product development as we already know. The candidates who wants to know more about Agile are somehow connected to a career around software development. That’s the biggest blocker in establishing a company wide Agile mindset as it is not considered suitable for everything else. But to understand Agile, we need that consumer focused environment on areas other than software.

 

People – We tend to avoid the term “Resource”. It’s disrespectful to call someone that. Semantics may seem irrelevant at times but are way more important than you think in this context. If you are letting someone call you a resource, you are equally responsible to what comes after. This “People” aspect is what makes it necessary to understand your consumers and get experience on how to serve them. Yes, you “serve” them by not following all instructions they tell you to do. You stay focused on delivering a good customer service.

Serve as a Doctor and not as a Servant.

Before we go deeper in the subject, we need to explore a key aspect of our surrounding culture, the people.

Personas surrounding Software Development and Agile et al

The Hard Workers

Future aspirations includes but not limited to moving on to a managerial/leadership role.

A typical software development professional get where they are by taking the formal route: the learning phase such as BSc, MSc, PhD or similar. Building a software is a knowledge work right? It require investment of multiple years of hard work trying to sharpen those specific skills that helps in doing the technical bit of software development. After all that technical bit is the “actual work” isn’t it?

For MBA (or similar) graduates it’s the non-technical bit that matters the most and ofcourse it’s much better than the the low level work carried out by the technical “Resources” isn’t it?

They all start off with a theory they have (or given) and aim to apply it in practice as a career on their respective fields. “Freshers” are therefore more comfortable in a controlled environment as that’s what their environment was during the learning phase. That’s what they have been taught and that’s what they have been asked to write on exams. Unless they won’t get a ‘Distinction’ required to be placed in an organisation providing “Internship”. They are usually behind (module wise) when compared to the real world.

The Vampires

Future aspirations includes moving up on the ladder to a role requiring Technical Excellence

These are the over enthusiastic kind – the non-academics who excel in every aspect without a formal education. These borderline vampires were busy being that nerd who hates direct sunlight or something. No, it wasn’t me. These form a majority of extremely good developers we see around us today, simply because it’s their passion. Most probably then don’t even consider work life as a separate part from their personal life, which is not necessarily a bad thing (up for a debate).

Road to Customer Service

During these learning phases very few “lucky” academics and non-academics above work (or got a chance to work) in a consumer facing environment e.g. sales, retail, call center or a restaurant. You will find out soon why they are lucky. How do we expect the majority of these candidates to learn what “feedback” means? How do we propose they learn about making a “end user happy” while staying in the boundaries and policies of their controlled environment? How can they possibly know what it takes to be “fair” and honest when they themselves are confused? The dissertation which some are proud of becomes a small book and doesn’t help, again, in a controlled environment with set rules.

Unless a customer looking straight to their eyes and say “You know what, let me speak to your manager” – they haven’t seen customer service at all. If they cannot handle a overweight diner going on and on about a £2 overcooked chips, how exactly are they planning to handle that £2M revenue generating client breathing down their neck? They have a lot to lose, they have spent a fortune (on their passion and certificates/degrees) to get that job. They have to bend at some point because they are more vulnerable and exposed.

The Naturals – Wildlings

Future aspirations always to move up on the ladder to a managerial/leadership role, challenging the status quo with necessary improvements.

Then there’s an interesting third kind, the opportunists, the naturals, the wildlings – one that enjoyed their youth until the mid/late 20s or so. They were confused about what the hell they were supposed to do in life or simply was too busy working on customer facing job to pay the bills in time, assuming that was it. Suddenly one day they found something that they actually love and decided to raise hell by doing something different to make that extra cash and become a software developer (alike) to start with.

The tutorial videos we find in YouTube helped them learn more languages compared to a university degree. Attending those conferences or meetups helped them learn even more in an hour, that they couldn’t have possibly learned in a month by reading a book. Soon they realised that learning a lot is worth fuckall unless they can apply it in practice.

Knowing multiple programming languages may sound impressive but mastering only one of them makes us valuable.

Also they have learned that the above “technical bit” and the “administration bit” complement each other. Both are useless in absence of the other and both needs to work alongside for a successful product/project/business whatever the goal is.

Road to Customer Service

Customer service is something these naturally skilled individuals did everyday since they can remember, it’s their second nature. These personas have knowledge and skills which can rip apart some of the most highly qualified certified professionals, if given a chance. They follow every single word of that Agile Manifesto, which they may not even know is called Agile (to begin with). These candidates are the fastest learners you will ever find in a workplace.

BUT who do these “Naturals” follow and learn from in future? That’s right, most probably from the first 2 types who have already occupied the leadership roles with next to nothing experience on “customer service” in the first place. Back to square one.

Customer Service is about Honesty and Fairness – not bending over when shouted at for money

Honesty is when we convey the truth, doesn’t matter how good or bad it is. Fairness is knowing if we are being transparent and unbiased; and then expecting the same from the end user for their own good. Transparency, accessibility and length of feedback cycle plays a very important role. Just because the end user wants it by next Saturday, doesn’t always mean they have figured it all out. Development work is not as predictable as manufacturing where following a set of precisely designed steps can get to the solution on a predictable date. Development is unpredictable that’s why we need the principles of Agile which can be summarised in the one sentence below:

Being agile needs a swift change in one’s personality:

from knowing how to get shit half done before deadline

to get the most important shit done first, properly.

Stop judging, Start helping

So how do we teach them what customer service is? So far I did manage to judge all the personas above and assumed we only have these 3 kinds. Consider these 3 to be the most popular routes rather than an absolute number of types. However, we have no right to judge anyone of them, as we can barely make a difference by pointing out what is missing in their journey towards agility. Unfortunately, our approaches can be patronising at times as no one likes to hear that then need to improve. For some, whatever we do to help them will never get their attention.

The way I see it is, none of them are perfect and need help to understand what Agile or Lean or XYZ means. There are so many similarities in all type of mindsets, we might as well drop the names and focus on the principles. To do that you need an Agile Coach or some call them Lean Agile Coach or a Scrum Master.

The 3rd kind above, shows the highest potential to become a good Agile Coach due to their “nothing to lose” attitude.

Make 1st Line Support a mandatory role during Probation

We cannot expect any employees to work following Agile principles without giving a formal hands on training, coaching and mentoring. Then making sure they continuously use those lessons in practice in relevant fields. It’s not possible in a controlled environment. If a company paid to make the employees agile in few days, they have been robbed in broad daylight. If our employees are shadowing us they will probably assume we are being agile, as we are good at throwing the A-word now and then.

Making everyone work for a month or so in the 1st line customer support, will expose the new employees to understand the customer needs on that business. Support them and ingrain these basic principles before they actually start working on the relevant teams with relevant skill set. This may sound out awkward but can create a culture which focuses on end users first.

Don’t be Shy, get Help !

To get help in creating an agile mindset in your organisation, find an Agile Coach “per team” (to begin with). Just make sure –

  1. You know why you are hiring them for
  2. Stay out of their ways, as it will most probably won’t be the same as your’s
  3. Listen, listen and listen again.
  4. Agile Coaches need the most support as they have no authority over anything

 

Most Agile Coaches I have come across so far are the mix of all kinds mentioned above and one way or another they live by those principles in their personal lives as well with an aim to be the 3rd kind and stay like that.

If you have hired an Agile Coach as a “Trophy” to show your clients, don’t expect any improvement.

And don’t blame Agile for your own arrogance and bias towards command and control. At first hiring a dedicated Agile Coach per team may seem out of your yearly budget but it is necessary for the longer run (if you really care) as they create lasting changes, which stays when they leave. A true Agile Coach respects the status quo but doesn’t tolerate it. Make sure you understand “Agile” before hiring an Agile Coach unless you will never like what they propose for a change.

 

P.S: Scrum Masters are Agile Coaches. If you don’t agree, you are most probably the above mentioned hard working 1st kind. Open for a debate here.

WWWA – #2 Harsh critics of Agile or Waterfall (or Bacon) are Awful Researchers

Posted on by

WWWA = What’s Wrong With Agile

I know, I said it will be weekly. As it turned out, I actually prefer responding to change over following a plan. A quick recap to the goal of this series, which will stay same on every following article – to make some space in our brain for this to stay in:

 

#1 – Agile is widespread, the Agile Manifesto isn’t

#2 – Harsh critics of Waterfall or Agile (or Bacon) are Awful Researchers

Criticism with opinions is a no-brainer. Although, Criticism with facts require investment of quality time, uncomfortable debates leading to self assessment and the will to learn from the one being criticised by us. In this article, I will take a U-turn to explain a misconception which many of us don’t know exists. We have other follow up articles to get back the respect Agile needs but we have only this article to finally respect “Waterfall” or what it stands for. As always, keep an open mind.

Overly Favourable Views

“People tend to hold overly favorable views of their abilities in many social and intellectual domains… …this overestimation occurs, in part, because people who are unskilled in these domains suffer a dual burden… …people reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the metacognitive ability to realize it.”

Highlight of the abstract of a published whitepaper – the basis of a Nobel awarded (for Psychology) to David Dunning and Justin Kruger.

This is true for both Agile admirers and haters. Both are guilty to some extent. I was too, certain years back. With no actual working experience of “Waterfall” and what it involves, it didn’t made sense to me and simply hated it to the core. Statements were made which were heavily biased towards Agile/Lean.

Then, almost like a Karma (if you believe in that shit), I had to work in a Waterfall project! It was really awkward to realise what was wrong. With an Agile goggle on it was my approach that needed an upgrade, I wasn’t listening to the so called old mindsets.

“Trust me, if we could we would. The amount of dependency and politics we deal with, be thankful it’s not taking a year” – whispered a devil’s advocate.

 

Being used to the XP practices, it took me a while to digest and understand. I kept working in their sluggish pace to provide a value in a quarterly basis which was better than it used to be. Soon it was clear why agility makes sense and thankfully found the mojo back to move on with the experience. It wasn’t the mindset, it was simply the organisation we were dealing with. It made me come to this conclusion –

Mini-waterfalls within a fake sprint on a No-Scrum, sometimes still work. That’s the most we can get out of from certain organisations.

Not ideal but not the worst possible outcome. Now I can say, the traditional mindset/techniques (not specifically Waterfall – more in a moment) lacks the solution to provide values when we need it in today’s world, although don’t hate it anymore.

A brief history lesson to the Waterfall haters

You are about to be amazed if you haven’t really gone deeper into the subject of what Waterfall stands for and why you should – for a moment – take your Agile goggles off to read this.

The term “Waterfall” was an accident. A mere resemblance between a flow diagram and a waterfall. It was originally drawn to explain an iterative and incremental approach.

 

Yeah, you read that right – “an iterative and incremental approach”. One of the pioneer’s of the software development industry Winston W. Royce one day decided to write a paper on 1970 to express his “personal views about managing large software developments” while calling it “Managing the development of large software systems” – without a single mention of “Waterfall”. He managed to draw some visuals expressing his views, one of which is this:

 

Royce advocated that, projects should pass through this at least twice. That’s an iteration described right there, although not perfect for our current world but good enough for the world then. Bell, Thomas E., and T. A. Thayer on 1976 then published their paper on “Software requirements: Are they really a problem?” and coined the term “waterfall” referencing Royce’s article – managed to do the permanent damage, unintentionally.

 

We know the rest. That analogy turned into a topic of mindless criticism which was simply about “an iterative and incremental approach”. In a way, therefore, the concept of “Agile” has evolved from “Waterfall”. I hear you mumbling something, please don’t hate the messenger.

So, the term did more harm than good and may be that’s where “Agile” is heading which we can stop. “Waterfall” has become a word which is now spoken with a guilt; usually an enormous amount of shame is associated with it. Ehm.. “people who are unskilled in these domains suffer a dual burden”. I rest my case.

 

Sounded like a Waterfall lover there didn’t I? Truth is Waterfall (or whatever you like to call it) is still used widely although Agile is the better among the two. Just make sure we understand both before we criticise any of them. Better, just leave the debate behind, it’s not worth it. Respect both, embrace the one that suits you at that moment of time. Be loyal to the one you favour and explore yourself if you can improve.

Technically Waterfall was 20 years old when Scrum was born (1996) which is the most widely used Agile Framework. It’s been over 20 years to that as well.. you never know what’s in the corner waiting to emerge for us. Most probably another framework which offers even more faster feedback 😉

P.S: You may have gathered, this article had nothing to do with Bacon. Although it was about the Beacon.