Category Archives: Product Development

Justice League has a Single Point of Failure – Does your team have one too?

Posted on by

**Spoiler Alert** – If you haven’t seen the 2017 Justice League movie, reading after the below introduction may spoil it for you. It’s important to go deeper in the story to explain the intended purpose of this article.

Zack Snyder directed Justice League, released last year, is a great example on my team building workshops. Although, IMHO, this is not the best DC movie ever created in terms of mediocre script, predictable plot, over-hyped and overwhelming special effects. My complain is more towards the movie itself not the team. Only good part of this movie is, the absence of Superman – the humble man of steel. Usually, his presence is counter productive in strategic situations that need true leadership like Batman & Wonder Woman.

Not everything needs power, sometimes it’s about tuning down, so your team members can rise.

Most important fact we can learn from this movie – what happens when your most powerful member of the team aka Superman, gets “Hit by a Truck” or in this case already dead. By the way, this was apparently the 2nd most expensive movie ever made.

Single Point of Failure? – Guess What!

Detailed plot can be found here but I will only highlight the part that is relevant to our topic of discussion today.

Relevant Plot – The movie only shines for like 5mins when a zero memory Superman is resurrected. A small mistake by Cyborg’s reactive weapon angers the man of steel and the wrath of Superman begins when he alone dominates every member of the league and almost killed Batman with a pinch. Thankfully the contingency plan pre-calculated by Batman saved his own puny human arse.

Enjoy the moment below:

We all have seen a Superman in most teams; without a plan B when they turn hostile.

Let’s give you an example that might relate to our profession.

Think of a person in your software development team (or any team) – an exceptional developer with a plethora of domain knowledge is being “Productive” with his/her headphones on. He/she might also be known as a “life saver”. You ask a question and most probably get all your answers and your problem is sorted. The rest of the equally competent new team members have potential but lacks the domain knowledge collected over years. But it was never shared neither there are any documentation anywhere. The superhero believes he/she is too busy and someone else should do the useless documentation while he/she can “Do Some Real Work”.

Now imagine the below 2 scenarios when that person becomes the bottleneck –

1) When the Superman is “Hit by a Truck”

Now, one unfortunate day that awesome developer calls in sick before a product launch. After hearing that, if you don’t feel a chilling flow of blood running down your vein right now, possibly in the stomach, I have no words for you. It’s hard to even write about it as an example, as it’s so common. The next thing we know, the product launch is cancelled, stakeholders are furious and our lives are hell.

So what do we do? We call that same person, apologise for calling when he/she is actually unable to stand, requests him/her to connect to VPN and troubleshoot the issue. In most cases, it doesn’t get resolved and we are all in a over-salted pickle topped with habanero bits. Like what happened in the above movie. Superman is dead, so the world is doomed as we were relying on him too much the whole time and never thought of having a Justice league until the shit hits the fan.

2) When the Superman becomes hostile

The person isn’t sick but need a raise 😉 for obvious reasons. Performance review time –

Manager: As you know we didn’t make any profit last year, so no one is getting any raise this time. Not even me.

Superman: It’s not fair. I have been working hard, more than anyone else in the team and usually I am the only one on call even though I never get paid for those live issue troubleshootings. No one else seems to do that neither are capable to do it.

Manager: Well, yes that is true but you never wanted to document anything, pair with them or taught them how to do it either when they asked for it. I understand you are over stressed sometimes but it is because of the unshared knowledge.

Superman: When do you expect me to do it? It’s a 5mins thing when I do it, it’s 1hr when someone else do it. Are you saying you rather wait for an hour to get a live issue looked at or even fixed? Anyway, I will need that raise unless I will have no choice but to leave. I always help out when the company needs it, I deserve it.

Can you blame the superman in this case? Especially when he/she has a point.

Superman will never ask for help !

What we should ask ourselves:

Why wait for that moment to come? Why not be ready for a moment like this?

If you have been to this situation, the first thing you ask – “Only if we had someone who knew a little bit of this person’s work. Doesn’t have to be as efficient but to do the job in anyway, a quick fix” We have all been there and pulled our hair out.

The trick is to not tolerate a superman like the above. It may sound weird, why would anyone not want a superman in the team? Well a Superman is only necessary for short term benefits and when we keep repeating the behaviour and tolerate a dysfunction, no long term benefit can come out of it. Also it’s not really good for the Superman in the team which the person may never realise.

The reason a person tries to be/stay a Superman is to create a bottleneck so his/her presence is felt for personal gain, like the salary negotiations or promotions. There are some who don’t do it on purpose though, they simply are not team players and would rather do anything asked without even thinking if it has any business value at all. These members hinders creativeness among other team members who are equally capable but have their hands tied. On above scenario 1, no one wants to work and that’s their punishment if they are doing it on purpose.

In some cases, the person who is a bottleneck may be an introvert or very shy. it’s very common among developers due to the profession. Hence they may not even ask for help even if they know they need, making themselves overstretched in daily tasks. Eventually on one day this shy person won’t be able to cope and simple resign.

 

Create your Justice League before the Superman dies or turn hostile. Shared skills & knowledge are the key to crisis management.

Product Owners are torn between being the “Leader-first” and the “Servant-first”

Posted on by

When we talk about Servant Leadership the first role that comes into our mind is the Scrum Master. It is the first role ever, of it’s kind, which was created specifically for the sole purpose to “Serve”. Only if Robert K. Greenleaf was alive until 1998, he would be the happiest person to know that his whole life’s contribution has an effect on a dedicated leadership role; it changed everything especially the way we see management and leadership now-a-days. Then we started seeing the rise of “Agile Coaches” which was created, I guess, to differentiate that servant leadership exists outside Scrum as well in a equally dedicated role.

But this article is not about the Scrum Masters/Agile Coaches or their unbiased contribution to their teams. Today we are focusing on the role Product Owner (PO); the role which is often seen as biased towards “more and more work in less time”. There’s a reason.

According to the Scrum guide – “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team”.

This is often misunderstood by new POs and their organisation, where they believe it means “maximising the output from a development team”. It is not the same and that subtle difference decides if the person is a traditional Product Manager or a Scrum Product Owner. PO serves the development team (explained later) and ofcourse their job is to serve the organisation, but in very different ways.

For a Product Owner, Maximising Value ≠ Maximising Output

A typical Product Owner will prioritise and try to add work items in the Sprint backlog which may not be part of the Sprint Goal. There is nothing wrong with it, sometimes we have to, if we have higher capacity and we need a live bug fixed asap. As long as majority of the work relates to the Goal, we have a focused sprint.

Things start to become gloomy when a PO knows the true capacity of their development team but still try to negotiate to add that “small” Story, in case someone is free. That’s the biased “leader-first” side which overpowers the unbiased “servant-first” side, so that extra work can be shown as an achievement to a stakeholder who is constantly chasing. Typical phrase on these situations is like “If we manage to finish that too, we will make someone very happy when they are not even expecting it”. That’s a trap.

If it gets done, the stakeholder will assume it is not a one time favour and they can pressure anytime to get more work out of the development team, by going through the PO. If it doesn’t get done and the stakeholder finds out they will most probably be annoyed and blame the development team. Both have side effects and not a very good one. Both fails to manage expectations. On top of that, the development team will now feel guilty when it was clearly not their fault.

The trick is to align, orchestrate and trying to link the work items in a way which have a combined value to someone.

Value doesn’t always have to be for the end user. It can be for an internal stakeholder, operational requirements, legislation or something else. PO should fish for opportunities to “maximise the value” from any form of output. PO should known the capacity of the team from empirical evidence collected on past sprints.

Skill levels play a huge role in slowing down or speeding up the outputs, based on the team we are working with. If we have new team members, expecting same speed of development is futile. Know your team, know the people. If they are new and are on the learning phase, plan more Spikes and let them explore bugs raised which will help them learn the domain. It will also help the more experienced members on those domains, by collecting keys facts that can be used on next sprint. It helps everyone to keep the morale up and have a long term benefit.

Product Owner “Serve” the Development Team

As a Product Owner, we have to choose a “leader-first” bias as we are accountable for the product’s success but we can also serve when it matters the most.

  • While facilitating the refinement activity, PO focuses on the business value while keeping the known format of “must have”, “nice to have” and “can live without” in their head but never writes them down for negotiation purposes.
  • While fleshing out more and more acceptance criterion from all development team members, PO becomes their scribe and does the admin work which liberates the members who needs to think than focusing on where to add a comma or semicolon.
  • If a PO have to be part of the discussion, they ask for help from the Scrum Master to do the same. This is where negotiation begins but with a “servant-first” mindset which is backed by empirical evidence or UX decisions.
  • After Sprint starts following the planning session, PO serves the development team by being present on all the daily scrums to answer any query they may have. When they do this, they serve. Taking status updates is not a service; it’s an anti-pattern.
  • During the work day, PO again serves the team by simply being accessible to them by any mean. Just being there makes all the difference.
  • PO serves by not chasing the team members to create a sense of urgency.
  • PO serves by creating a big picture for each work and explain how it impacts the end users. Creating enthusiasm and showing the purpose is one of the most underrated skill.
  • PO serves them by showing trust on their commitment and being patient even in the most stressful times.

Product Owners are torn between being the “Leader-first” and the “Servant-first”

From above we can see where the true confusion lies and why POs may be torn between two contradictory ways of leadership. PO is accountable for the product success, a single emotional bias can affect the potential ROI. Unless they lead and focus on getting them done fast, it might seem impossible to even finish in time as every work has a cost of delay. We cannot have the “Servant-first” approach all the time with the development team as we are serving an even bigger team, the organisation.

When it’s possible POs can show the “servant-first” side but is it real? May be, may be not. Usually one person cannot be both.

POs will always remain biased towards the product, the goals and faster delivery. Reason why we have Scrum Masters to neutralise that dominance by guarding the development team when needed. Every role on Scrum has a purpose of why they are dedicated, this is one of many.

Are you a Product Owner, what’s your take?

Do you Lead first or Serve first?

Let us know.

Mentor, Trainer & Coach – as described by the Agile Community

Posted on by

Some posts are too valuable to just stay as a post, it needs to be documented for everyone to read atleast once. When you ask for a clarification from the Agile community, they never disappoint you. Hearing things like “Training and Coaching are the same” or “My mentor is <an influencing personality who died a century ago>” – I started to question my own understanding of what they really are. Have I been thinking wrong the whole time?

So, I decided to throw the question out in public and let the community decide and help me restore my faith on the differences between (an Agile) Mentor, Trainer and a Coach. I have managed to categorise them in 4 parts to narrow down any duplication as follows-

A simple and effective visual to settle the Debate

 

Julie Hendry wrote about above – “As a coach you can be called upon to take different roles … much like a consultant ..here’s something from Jerry Weinberg that helps describe the stances I use in agile coaching practice…having said that training as a part of coaching practice doesn’t replace the need for formal trainers in my opinion.”

To this Paul Boos‘s view was – “… these are all potential roles a coach can take… And I am thinking a very different model from most. I think where the responsibility of delivery and responsibility for improvement are the axes… This would be 1/3 of the roles one might take on as a coach… Oh wait coach isn’t a role of a coach (no recursive refs), so 2/9….”

Clear Explanation by Community members

Rick Waters decided to clearly distinguish the roles in a “Lucid. Brief. Practical” –

“Mentor: Did you see what I did there?… Trainer: This is what you could do there… Coach: Do you see what you did there?… Guide: What you might see over there is…”

Frederic Ducros extended Rick’s depiction by saying –

“Coach: What do you feel happened? Or What else would you consider doing? And I would add: 4) Agile #Facilitators. Coaching is a skill set on its own. Learning agile doesn’t teach you all the coaching mindset and skills required. I had not realise how much there was to coaching when I went through CSM CSPO…”

Sanjay Kumar wrote – “Trainer helps trainee gain new knowledge. Mentor helps mentee acquire new skills. Coach helps coachee explore and enhance their potential.”

Can of Worms – oops !

'No, please continue. We're finally making some progress.'

The Pyramid Scheme

Travis Birch mentioned “There’s even a pyramid scheme for this.”

This out of nowhere opened up a large can of worms which I wasn’t even thinking about while finding the right answer.

Kevin D. Martin described how consultancies are using the Pyramid scheme and these roles to harvest top salaries –

“Yes! One Agile Poser gets a gig, then brings on more agile posers to carry the water, skimming $$$ of the top. Classic mob business model.

Based on my experience 80% are Agile #Posers, until they are discovered to be none of the 3 categories you listed. Then they are Agile #Available for next robbery.”

The Certification Business

3 very interesting comments caught my eyes and changed the way I looked any certification business exists in the world today, not necessarily in Agile community.

Murali Varadarajan started it by saying – “It starts with the certifications model on who can sell, resell or receive a paper. Check the model of any popular framework.”

Jonathan Kessel-Fell replied – “You see a prime example of this within Agile through PSM / CSM or DAD / SAFe. One you can self study, discuss in a group and gain for a one off payment of $150. The other has a huge sales team, you have to pay for their training and have to pay an on going fee.”

Julie Hendry extended the fact by saying – “I don’t see it as any different from ITIL, PMI, CMMI, any vendor certifications… most certifications are a commercial venture not a learning service. And folks eat it up – providers and customers!”

Mentors, Trainers and Coaches – Take “Agile” out of it

Reading all the views and analysing the outcomes it was clear that a Mentor, Trainer and Coach have resemblance on any industry and not just in Agile community. We have a tendency of adding “Agile” to everything which automatically seems like unique but it isn’t.

So Tom Mellor decided to finally explain the way I learned it to begin with – “There are people who understand agility and mentor others in understanding it. There are people who understand agility and teach train agility values, principles, practices and thinking, and guide people in understanding agility and practices. There are people who coach people to use their knowledge of agility and practices more effectively and become more proficient in agility.

So, there are mentors, trainers, and coaches who understand agility and help people understand it. I don’t believe there are agile mentors, agile trainers or agile coaches.”

!

Credit: https://www.td.org/Publications/Blogs/Sales-Enablement-Blog/2014/08/Training-Mentoring-or-Coaching

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.

WWWA: #4 Fun is secretly frowned upon in most workplaces

Posted on by

WWWA = What’s Wrong With Agile

 

X: I have a great idea of doing it in a fun way.

Y: We aren’t getting paid for having fun. Get back on your slides.

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

#4 Fun is secretly frowned upon in most workplaces

A client requested me the other day to come and give an “Elevator Pitch” on Agile, to all their teams. They have a fun atmosphere they said, always making employees happy. So a counter request followed from my side – “Great, can I give the pitch on the park while we soak up the sun?” The client’s rep looked perplexed and said “I don’t think my manager would authorise me to arrange it or even pay for the arrangements”.

He is right, simply doing his job. A company asking for an “Agile” pitch obviously don’t know what Agile stands for or is capable of. That’s when we come in as Agile practitioners. We take the burden of making them realise what they are missing out. Work can be fun and most Agile related workshops, sessions and training rooms are full of such activities for that very reason.

When you are having fun, you take personal measures to do it right.

When was the last time you had fun?

Usual Stories – ***All events and characters are fictitious, no animals are harmed and any form of resemblance is a mere coincidence*** 😉

1) Over the weekend when I mixed few drinks for fun I pissed myself near the ATM, got proper wasted while bar hoping and woke up on a strangers bed.

2) That holiday in Prague, when I finally had a lie in for 7 days with no actual visit to any touristy spot ! Well, my wife do hate me for that. Hard to care when I was that relaxed.

3) Last year when we had that poolside BBQ, the whole neighborhood joined us without an invite and trashed our place. Ironically it turned to be a great fun overall.

What triggered these (un)fortunate events?

1) I hate my work, it’s full of miserable pathetic corporate bureaucrats. Finally the weekend is here, now I can pull my tongue out my manager’s arse.

2) I worked hard for months, so I deserve the lie in, even if I have to spend a fortune on hotel rooms and wasting the site-seeing opportunities with my family.

3) It’s fun to have distant family members come over for a BBQ. It changes our focus towards “the better side of life”. I need a work-life balance.

Am I getting through to you yet?

If you love your work, you won’t “schedule” a date to have fun

I love my job. Although the fact of life is, not everyone loves their job. In fact, some of us are even in the wrong job due to financial pressure. Because it’s a job, paying for the bills and letting us survive in the rat race.. or dare I say the rat wheel. Reason why in every CV there’s a section called Hobbies, Interests or Other Professional Activities.

Ever wondered why we have the hobbies section in our Resume/CV? That’s where our definition of “fun” lies.

Because it’s a notion in most workplaces that these “activities” are not permitted at work and are frowned upon as they are not considered as work you are getting paid for. Not saying that we should allow all employees to “Watch TV” or “play Counter Strike” at work everyday. But we can allow half a day every month on a chosen activity which is a popular demand. Make it a brown bag session and use it to know the people better. Use it to train and coach without a power point slide. Invest on personal relationship for a long term goal.

Fun breeds Creativity, Common Sense and Purpose – that’s what “Agile” is all about

If you can’t have fun, you can never be agile. Agile is not about software anymore, it used to be. The Agile Manifesto above basically states the obvious which we should know better anyway but in workplace we don’t as most of us are a different person at work than in real life. A classic depiction of that habit in 3mins from the popular show –

When we have a fun activity, it makes us happy.

When we are happy we take interest and learn faster like a child.

When we take interest and evolve, we tend to give our best at whatever job we are in, whether we like it or not.

When we do our best at the job we get recognition, satisfaction and the urge to do it better continuously.

When we do all this, Agility smiles standing on one corner for making you feel good about yourself, about your colleagues and your workplace. Suddenly, the weekend doesn’t interest you as much, you might already had a few drinks during the week. You see Monday mornings in a very different way and NOT posting a status update on social media saying “Mondays are Shit”. Be agile and see the difference, it’s on your best interest.

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 !