Category Archives: Lean Start-up

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 – #1 Agile is widespread the Manifesto isn’t

Posted on by

WWWA = What’s Wrong With Agile

Welcome “Agile” admirers, haters and the lucky bunch who are still unaware hence unbiased readers. Glad to see a controversial article header gained your attention. It is not a click bait though and may be oddly unsettling to the admirers and haters specifically as you read on. It’s not good news unless we act on them and we need both parties to calm down for a moment, shake hands and stop bitching around.

Recently, I was accused of being an Idealist (no idea why it’s a bad thing) and living in a world of illusion. Pretty sure most Agile Coaches are branded as idealists if they are doing enough effort to highlight constant improvements. Apparently the myth called “Agile” only work in dreams. My reaction to this was rather cold though. Mostly because, there are times I do feel that myself. Not because it doesn’t work but because the perception of what Agile is, is still not clear to a majority of development professionals.

This article is the first of many on a series of articles which will be published every week (following a plan over responding to change.. Can I dare?). Here’s an effort to clarify what really is wrong with the interpretation of what Agile stands for today.

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

Leave the 12 principles aside for a moment, at random just ask for the 4 manifesto statements to a person selling the brand Agile on their product/services. If you can find confident 4 statements in any possible variation, ask how many of them they have managed to use or will be using in the workplace. If the person have taken the effort to memorise the 4 statements, they will probably be honest enough to tell you the truth.

Most of us cannot follow one or another or any of them in our workplace, for various reasons. That’s when we take a moment and question, is it even possible? We are busy doing “hard work”, who has the time for all these? Working the way we are expected to – pays, being an idealist continuous improvement seeker human – will probably get us fired.

Agile principles and values - Google Chrome 2017-06-16 11.41.11

Source: https://www.slideshare.net/TroyLCSMCSPO/agile-principles-and-values-62447757

 

My faith was restored when I saw it working once, only that one time – the company was being agile (a very good one) and had the manifesto and 12 principles bloody engraved in their memory and on the walls of the office. Also, they never used the A-word as a unspoken sacred rule.

Sad that the Agile Manifesto is not widespread like the actual term Agile. May be because it’s written in English which most of the world doesn’t speak/understand.. hang on. It’s impossible to memorise those 4 statements that holds the truth but it’s easier to memorise all answers of the multiple choice questionnaire to get the certification done. It increases our day rate, isn’t it?

Back to basics – a quick recap:

Here’s an unbiased pro-tip:

You can always be more agile, it’s relative.

Providing “fast feedback” depends on what is “fast” to you.

For some it’s a month or a week and for some it’s a day (stop showing off you!). There’s always will be a better version of ourself. Large organisation can be agile too, it just simply won’t be agile enough to call it that and to some it will be a #NoAgileBanter 😉

So, next time you hear someone throwing “Agile” at you and in a mood for trolling or simply like to be a dick, just ask. Just make sure you know it to begin with. Best place to ask is job interviews, if you care. The candidates have no choice but to answer or carry a risk of losing the opportunity. At least you will educate them and make an effort to spread the word directly.

Interactive Persona Modelling – The Game

Posted on by

A niche community of product development practitioners are embracing the use of Personas in their discovery phases. We have a soft spot towards it, which is mostly visible in the implementation of tests in BDD and ATDD, when we discuss it in the context of software development. Although, it should be used from the inception of any product.

Many argues that it needs a lot of overhead, to find an exponential number of ways a user can use a product. Finding a rational method to meet the expectations of these users is smart work, rather than hard work. Here is a good way to use the persona in software development. But I have never seen an interactive way of “modelling” the most effective persona. There’s even a dedicated tool for this online, which helps us to some extent. Although, majority are still exploring the concept and frankly are struggling due to the core reason. Time and cost. So..

How do we model a Persona without wasting too much time/cost ?

This article is about creating these Personas from scratch using a game called “Interactive Persona Modelling” and not about how we use it in practice.

What is a Persona?

  • An Archetypical user of the intended product
  • Fictitious but based on real user information
  • Bringing an imaginary user to real life with immutable set of personal data
  • Quite common to have more than one page of documentation written on each persona

Origin of the Game

Few days back, I was part of a mind blowing 2-days “thing” called Emergent Agile Leadership by Tobias Mayer, an Agile Philosopher and Psychiatrist (opinions are mine) painting a Teal shade among us. He has managed to shake up my thoughts more than any other agilists I have ever known. Why am I calling the event a “thing” though? Well, I am still struggling to find out what it was about and what happened to me during the sessions. All I have is more questions and the rest of the life to figure out the answers. It was the best experience so far, inside a room full of 12 more strangers, who somehow are not strangers anymore.

Tobias introduced us to his game “Help me to see it”. We were in a circle where one person starts with a name of any person and one characteristic to describe something about him/her. The game goes like this. The 2nd person now have a name and a feature of a hypothetical figure say “This is Simon who is short”. 2nd person now adds another characteristic like “Simon is a short midget who has pink hair”; 3rd – “He also have a fat belly”; 4th.. – “He is wearing leather shoes” — and so on. We ended up with something like this –

“Simon is a midget with pink hair and fat belly. He is wearing leather shoes while participating in a festival. He is drunk and dancing with a Monkey on his shoulder. By profession he is a martial arts trainer. Simon is shouting and swearing to the DJ and expressing his joy while taking a time off from work.”

 

Being a Dragon Ball Z nerd, this conversation immediately reminded me of this guy (that’s when I added the bit “He is a martial arts trainer”):

 

Anyway, as you can imagine things can easily go out of hands if someone start saying “Simon is now riding a unicorn”. At this point anyone from the group can say “I don’t see it, help me see it”. If the weird idea gain support, the next person in the queue (clockwise or anti-clockwise) can explain why Simon is riding the unicorn and keep the game running. Fortunately, we were all mature enough to stop it before it went out of bounds.

For keeping this game a special experience for you in one of Tobias’s sessions, I will not reveal other fun aspects of the game, but you get the picture. You can guess where I am going with this now, can’t you? Some mechanics of this above game helped me to formulate this special game for Persona Modelling.

The Game – “Interactive Persona Modelling”

Prerequisite

  1. Most of the attendees should NOT know why they are meeting on the day. If they do, you may end up getting biased, predictable and pre-planned persona.
  2. More members, the better; For a maximum of 15mins (negotiable) for each Persona.
  3. Invite multiple real users or clients on the day; Or invite employees who knows them very well say Account Managers, Product Owners/Managers or Stakeholders.
  4. A room to accommodate everyone depending on how many are joining.
  5. A Facilitator, who will also be the Scribe

The Game Flow

  1. The facilitator helps create a standing circle of individuals and initiates the first round by calling just “a” name without any behavioral patterns of the desired persona. Next person have to say where the persona adds value, say a “super-admin user”. From this point onwards, everyone starts to add their personal behavioral patterned one by one.
  2. Make it personal – A description of the Persona doesn’t have to be purely work related. Persona is supposed to be “life like” with pure emotional backgrounds such as where they work, how they drive, where they travel or who they supplied hash in past. If you find an image of a real person, go for it. It is supposed to look as real as possible and printed and hung on the wall for display. NO.. cats or dogs pictures are not allowed, unless you are building an artificial food for them as your product.
  3. The role Scribe, sees the facilitator writing down every aspect of the conversation which “no one is in control of”. If a member starts showing authority over this fun situation, the facilitator will have to step in and explain the rules one more time.
  4. Anyone is allowed to stop the game to understand the context of a behaviour/facts mentioned. If they don’t agree, they have to find 2 more individuals who also disagree. If 3 or more people disagree, that characteristic of the Persona will not be documented by the Scribe.
  5. If the game continues, it suggests everyone is in agreement. The cycle can stop after 1 minute or can run a maximum timebox of 15mins. It should be more than sufficient when the right individuals are in the room.
  6. If the game abruptly stops due to a disagreement, that specific behaviour/data/fact should be discussed outside of this timebox. It should not disrupt the 15mins planned runtime.
  7. On purpose, this game have to be played while standing without any distraction like mobiles, notebooks, laptops or even watches.
  8. When the timebox is up, Scribe/Facilitator will read the whole document aloud and let everyone know how the persona feels like to them. They he/she will format in a way the company prefers, adds the image and frame it. Job Done !

Scribe’s Role

The Scribe’s job is very crucial in this game, they have to note everything without thinking if it’s a valid data or invalid. Scribe can be a UX designer or a person with exceptional drawing skills who doesn’t write. Instead he/she create a visual summary. A Cartoonist perhaps, open up show your skills.

A Scenario

If a member says “the super-admin user should be able to search”, you may also expect someone say “the SA user can search any directory”. BUT the next person may say “SU cannot search data from Directory X, due to our software using E2E encryption on that database”. Result – It MAY expose the negative elements which no one really though about and came into picture because a PO once had a hard time dealing with it.

An Example (If I may !)

Say, we are building a software for FBI, where we are trying to use a Persona which represents a hypothetical drug lord near Albuquerque, New Mexico. We want to know what he is like and how he interacts with his fellow dealers, so the FBI can better predict their next move to raid the drug lab full of Crystal Meth, hidden somewhere near an industrial area.

Dr. Walter White aka Heisenberg

 

Walter is a graduate of the California Institute of Technology who once was a promising chemist. He co-founded the company “Gray Matter Technologies”. He left Gray Matter abruptly selling his shares for $5,000. Soon afterward, the company made a fortune of roughly $2.16 billion, much of it from his research.

Walt subsequently moved to Albuquerque, New Mexico, where he became a high school chemistry teacher. He is diagnosed with Stage IIIA lung cancer. After this discovery, he resorts to manufacturing methamphetamine and drug dealing to ensure his family’s financial security after his death.

He is now pulled deeper into the illicit drug trade. He is taking more desperate and ruthless measures to assure his and his family’s safety and well-being. He has recently adopted the alias “Heisenberg” which is recognisable as the kingpin figure in the local drug trade. He remains a national security risk and should be shot on site. A reward of $1M will be paid to find him, dead or alive.

Known accomplish is Jesse Pinkman, who went under deep shit after being emotionally attached to Walter and is currently being hunted by the DEA (Next persona to be built soon).

 

Possibilities and Conclusion

Don’t you think we can make a brilliant TV series based on this story. I will name it “Breaking Bad”. Thumbs Up for this original idea, I have made up just now.. oh Wait ! 😉

Now you know where this game can be used, sky is your limit. Jokes apart, this method can create multiple personas within an hour, to be used in every aspect of the development cycle and not just testing. It can also be used in any other industry and just just software. Have a great time playing the game. Embrace the Personas and make a difference on your approach.

Potential Shippable Increment (PSI) is not always a Minimum Viable Product (MVP)

Posted on by

As a young father, one day I was wasting my lunch time watching a funny moment on a baby video, while taking tips to teach a thing or two to my own munchkin. (Back to post? Good, read on). At that very moment, overheard a fellow Scrum Master explaining to one of his team members what an MVP is, on a lunch break ! Still not sure if they were wasting their lunch time or I was. Anyway, the conversation was something like this:

Member: Bored of these new terms like PSI, MVP.. what’s the difference anyway? I keep hearing this from the new PO.

SM: Potential Shippable Increment, which is basically the same as the MVP thing you read on the book “The Lean Startup”. The POs can throw any of the phrases to specify a working software which is ready to ship.

Member: Ok, so Minimum Viable Product is like the new brand for PSI.. lol.. got it.

SM: Yeah, different POs uses different phrases, just go along. If he likes calling it PSI, let it be.

Eavesdropping paid off, that’s how I remember where I paused my video earlier. Instantly found an opportunity to arrange a training workshop on lean startup to explain where it all went wrong in the conversation. If you have already spotted where it went wrong, you already know where I am going with this.

Potential Shippable Increment (PSI)

I will quote directly from the Source –

“Potentially shippable is a statement about the quality of the software and not about the value or the marketability of the software. When a product is potentially shippable then that means that all the work that needs to be done for the currently implemented features has been done and technically the product can be shipped but it doesn’t mean that the features implemented are valuable enough for the customer to want a new release. The latter is determined by the Product Owner.”

PSIs don’t always add value. A team can build a hundred things which have an awesome quality which may not be needed. On a lazy refined backlog these PSIs can cost a business a fortune. As a great agile team, may be you are good at delivering efficiently but if a PO fails to recognise the benefit of that work, all of that can be pointless.

Minimum Viable Product (MVP)

“A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” – Eric Ries, author of The Lean Startup

MVP does not always have to be a Working Product/Software

It can be an concept which has been drawn on a paper, modeled by a UX designer or simply a bunch of screenshots which we can show to the end user and see what they think about it. Sure, it can be a working software because sometimes it is always good to see a piece of work in action. But it’s not mandatory for the validated learning. You may not need to invest time and money on a product which initially have received a bad review from potential buyers. It’s about working smart, not hard.

Explaining the Differences

MVP of Cars

Concepts of cars displayed to see public reaction, most of the times they are not ready to be shipped. MVPs are often more attractive as they lack practical usability or lack context. Which is why they need early feedback from the end users of a business.

PSI of Cars

Shippable cars being demoed to generate revenue which might be a MVP, before becoming a PSI. PSIs form part of or all of the MVP planned to be implemented. Not every PSI looks as attractive as the original MVP, because validated learning makes us aware beforehand what works and what not. That’s where Empiricism adds value.

MVPs of Smartphones

Concepts of smartphones (We wish these were real)

PSIs of Smartphones

Shippable Smartphones on 2017 (so they say)

Conclusion

So, next time you hear someone saying MVP and PSI are the same, you can share this blog and save the time explaining why they are not. There is a reason Product Owners (alike) call them differently, as to them they are different. Some work items don’t need to be developed before a feedback, some do. Hopefully this clears the confusion and this post finds you well.

Technical Debt: 3 ways to articulate and get buy-in from “that person”

Posted on by

The decision of removing technical debt can be crucial and is often a grey area. In some cases, to increase the speed of delivery, we have to carry the debt as long as we have control over it. When shit gets real and everything is slowly getting out of hands, we need to repay this debt by investing time and effort in, say refactoring. But it can be a hassle to carry out when we need it the most; not because we hate it but because we never get buy-in from “that person” who doesn’t think it’s important.

 

In self managed teams it may not be an issue but other teams may have faced a discussion at least once around this in their lifetime. “Refactoring doesn’t provide any value to the end user” – most common reply when we try to prioritise housekeeping. In several cases the person standing in your way is non-technical or have limited knowledge of the architecture which needs this debt removed asap. At this moment we have to open up bravely and explain “that person” why we need it happen, now. Here are 3 analogies that I use often to articulate the situation and get the buy-in.

Swim back to Shore Alive

I came up with this after watching Gattaca (**spoiler alert**) where two brothers compete to swim as far as they can, far from the shore. In the climax, Vincent was willing to die to beat his brother Anton, to prove to himself that his dream is larger than his own life.

 

Anyway, as a regular swimmer the hardest part of challenging yourself is to know your true capability and stamina. Just because you have stamina to swim 1 mile at one go, you don’t attempt to swim 1 mile inside the sea. You go 500m in and pivot so that you can use the other 500m capacity to come back to the shore, alive. You repeat this thousand times to increase your stamina and never ever lie about it. Lying to yourself and being overconfident will kill you. You will be fooling no one but yourself.

Now, apply this analogy to technical debt where the distance and capability is comparable to the threshold of debt we can carry at a given time. Within a team it should be non-negotiable, we shouldn’t keep building technical debt because someone have promised a deadline to launch, without asking us. You can try going that extra mile to deliver more ignoring this technical debt but sooner than later you will be screwed big time, your software will not be scalable anymore. You will have no choice but to stop everything and start from scratch. Stop early to analyse and always keep a recovery plan.

The Boiling Frog

This analogy is out there for a while (Source – 1, 2), although not used often in reference to technical debt (except the linked articles). Here’s how the story goes.

Researchers found that when they put a frog in a pan of boiling water, the instant reaction from the frog is to jump out asap. Because it’s sudden, it changes the environment within fraction of seconds and the pain is unbearable (I guess).

On the other hand, when they put a frog in cold water and put the water to boil over time, the frog just boiled to death. This time the change in temperature was so gradual that the frog does not realise it’s boiling to death.

When our business is hit by a sudden change and we see it going out of hand, we react quickly. If a continuous integration run fails blocking everyone from using the code base without rebuilding it, we have to fix it right away. Therefore, we act asap and jump out of the problem right away. In case of technical debt, it is slow and gradual, a death threat on the rise. It’s so subtle to begin with that no one cares (we may not even know). We eventually find it out and choose to delay the necessary changes. At one point it becomes so bad, we cannot recover anymore. Before we realise that the threshold of acceptance has crossed far back, we are already in deep trouble.

Financial Debt

The most widely used analogy around technical debt is simply comparing it with financial debt.

Assume you got a new credit card with a 40% APR. Your card limit is £1200 and you get a month interest free usage. As long as you borrowed money and paid within that 1 month window, you pay nothing on interest. Even if you go above the duration and keep paying a minimum about back every month it is within your control. The moment you stop paying anything after borrowing, you are screwed as the Capital plus the interest becomes your new capital which adds more interest and your loose the control.

Technical debt is exactly that. If you have to borrow debt to go fast and deliver an extremely important feature, by all means do it. Just make sure you keep a track of the debt you are creating by not maintaining the code regularly. Loose coupling is fine and still scalable. The moment we start writing hard coded software and tightly coupled features, we slowly increase the debt to never pay it back fully without loosing everything and starting from scratch. Pay the minimal debt back when you can and make it a habit, a practice. Don’t let the debt ruin your business.

End Note

Be true to yourself and leave the decision of controlling the technical debt to the community who knows best, the developers. We are not working in the code base daily, they do. Trust their instinct. If you are a big fan of velocity like me, let them estimate keeping refactoring in mind. The team shouldn’t entertain “that person” who always ask a silly question like “can’t we wait till the next month?”. On the contrary, if they have a business strategy to back it up with data, don’t ignore it either. We just have to know what we are capable of supporting and stop lying to ourselves.

Hope this helps. If you have few more ways, feel free to share the ideas/analogies !