Gallery

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

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.

Gallery

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

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.

Gallery

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

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.

Gallery

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

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.

Gallery

Stop Redesigning the UI – Add/Remove Features instead

We are working on a new Project to redesign the current User Interface (UI)

This is what I hear when someone says a version of the above statement-

1) “We were stupid enough to rush our first project following the management triangle and screwed the business over in the name of Digital Transformation. Now we are covering our own shit by spending more money and sugar coating the phrases around it.”

2) “We built 1000 features few years back, out of which only 15 are being used regularly. We are actually in deep shit in terms of coping with the maintenance cost of the rest. If we delete the rest (which we should), our bosses will bend us over and ride our arse off !”

3) “We are calling it a UI redesign but it really is a disguise to hire more developers to recover from the technical debt we ignored for the past few years.”

4) “We need to look busy as we are permanent middle managements. We need more meetings, whiteboards, sticky notes, sharpies and latest gadgets to save our worthless jobs.”

5) Finally, when a fellow “Consultant” says it, I hear – “We have managed to brainwash the client that they need a platform redesign of existing fully working application (not just UI), so we can place more expensive consultants (who will be paid half the amount as permanent employees btw) for the next few years. We can sell frameworks like Agile/Lean/DevOps and processes like SCRUM, xp, KANBAN (yes, someone actually wrote it to me once; god was feeling helpless). We can then convert them to one of the scaled agile frameworks.”

So I am not a fan of these characters, let’s move on. Although it was necessary to set the tone of this article to get things straight around fake “projects” which could have easily been a few months of lightweight but effective revamp work.

What’s wrong with UI re-designing?

Nothing. It’s always a good idea to present a fresher look to keep our application visually attractive than our competitors. Problem starts when we use it as an excuse to authorise a hefty budget for a spurious “Project” and not an improved “Product”.

It leaves a room for uncertainty and make our lives hell when we come across a surprise, which we were not expecting. Most “UI redesign” I have come across are basically the same application (with exact same features and specifications) from scratch with different technical stack aka a full platform implementation instead. You may have a better experience elsewhere. It just didn’t made sense at the beginning and didn’t created a sense of purpose. Instead it added high volume of unnecessary work in the backlog. Would love to hear a positive story, please share in the comments.

Top Root Causes

Product? What’s that?

It doesn’t always happen on purpose by the agents of “Change Management”. It happens due to a lack of knowledge in applying an approach which is based on empiricism and using a little less common sense. As long as we treat “development” as another standard project in the business, we will come across these issues. There are good agents, although less in number and are helpless as they won’t get the support from the culture.

Thankfully, a majority of thought leaders in our current world has made it very clear that we should focus on a product, dedicate a team towards it, iterate with empirical evidence and don’t work on anything which doesn’t have a purpose of providing value. May be the world is not ready for it, may be we need to let the world learn by it’s own mistake or maybe we can educate them faster instead of becoming their critic.

Here’s a Million, Burn it

Another root cause is having way too much to spend. No one care about a drop of water from an ocean or whatever analogy we use to describe it. That’s why the amount of waste is proportionally high when a company starts “scaling” their products. We don’t need scaling for products, we need descaling. We need iterations in burst mode so we can compare them and choose the one which actually provide some value and throw out the rest without feeling guilty about performing those small experiments.

In majority of companies, a predicted increase in revenue is measured as success.

 

“We need a 18% rise in the revenue next year as we managed to hit our last year’s target of 16.5%. To do that we will authorise a generous £2 Million on a re-design project proposed by the application development department for the existing application” – it is practically nothing in compared to that £100 Million+ profit they made last year.

Prediction is the worst kind of lie, it creates a sense of premature satisfaction.

Shareholders are happy as they have received more than their predicted cut last year and no improvement is required in anything as long as that number always increases according to “prediction”. Employees will be given bonus based on that as well, whether they have done their job or not.

Adding or Removing Features – Where to start?

Eat your own Dog Food – The What?!

If this concept is new to you – Dog food eating is a (well) known self scrutinising timeboxed event where you taste your own medicine and for a moment forget that you are part of the solution provider. The application we are building for someone, we use it in our own work and see how satisfied we are as the real user for a moment. In case the product is unrelated to our daily work, we pretend we are the user for the timebox.

Technically we should always be doing this without considering it as an event. Although I have seen only a handful of companies doing this and embracing the huge benefit around it. It’s not easy. You have to mimic that asshole who always wait for your mistake and resurface from the grave to screw your life around by changing your plan of action for another quarter (or worse, a year). Better be that critic yourself than giving a random opportunist take a ride.

Responding to change Over following a plan !

Identify the change needed before someone else do.

 

Summary of steps:

  1. Plan a half day timebox for this session.
  2. Make sure everyone on the team except the stakeholders join this. This is important – stakeholders will influence your opinion, so excluding them is a necessary step. You ARE the stakeholder in this session and you have to be brutally honest about it. If you don’t want to, don’t participate.
  3. Create a template of activities to plan a basic layout, sort of like a session based exploratory testing protocol (get help from a QA member if necessary). Remember you are the end user of that feature – establish who that feature in intended to, doesn’t have to be of one kind.
  4. Run the session and be a harsh critic of the platform, find anything that annoyed you.
  5. Document everything you felt and found.
  6. Plan few hours with stakeholders now, show them what you have found. Done.

 

From this point onwards, what a stakeholder decides will take effect, of course. But at least you have a much better understanding rather than reading a list of requirement which you always hated for being too vague.

If you are planning to achieve a sense of purpose start “dog food eating”, start analysing your own product, be your harshest critic and hire someone who makes sure the criticism doesn’t stop and call that role – Chief Nagging Officer.

Implement Analytics – as if you are prep’ing for a legal hearing

A Zombie feature don’t need to be loved, it needs to be shot in head on sight.

Analytics should be the simplest way to help a company on taking informed decision about “removing” a zombie feature. We don’t need analytics to add a new feature, addition is purely based on empiricism and can happen anytime. If we have implemented analytics (most does) but haven’t removed a feature based on the data, we are already doing it wrong. The deeper it is ingrained on our platform the better for greater insights. The purpose is simple – “We like to find out what part of the feature/platform is barely (never) used and delete the code to save maintenance cost”. It helps us in reducing technical debt and remove the stress of handling the legacy code.

It’s hard to throw out months of work knowing it is not being used. We can only blame ourselves for not doing enough research before implementation and make it right in the first place. Guess what, it’s never too late.

Adding or Removing Features – Why does it matter the most?

It’s in the name. We either add or we remove. It’s simpler, it’s almost black and white. While we are adding/removing a new/old feature we will always perform some background work on making it compatible with exciting features, redesign the UI in places, refactor the codebase or simply change the way it works or appear.

At the end, the value will be provided no matter what and it won’t become a worthless internal change with no real visibility of a new improvement. It can be a performance improvement which is not visible to naked eyes but an informative slide show can make up for it. There is always some value on everything, selecting the highest value is what matters.

There is a genuine reason a development team don’t get buy in from the stakeholders for removing technical debt. Often the team fail to provide an effective reason or simply fail to explain why it is important over providing a visible value.

New feature can equate to cost on one way or another, directly or indirectly, which is easier to articulate. When we remove a feature we have to heavily base our recommendations on analytics data explained above. It can still be equated to cost but still good luck with explaining why a working but unused feature was built in the first place. Some understands, some don’t. Be brave enough to raise concern but calm down if your job’s in question.

Conclusion

It comes back to the culture aspect, every time. The culture needs to translate these kind of failures as a learning. A zombie feature can use as much as the “resource” needed, as an actively used feature which makes them very expensive in long run. By resource, I mean real resources like storage, supporting work and maintenance costs which are a great form of waste. So focus on adding a new feature in demand or simply remove the one that nobody owns.. just don’t call it UI redesign.

Gallery

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

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.

Gallery

Agile – It’s not about delivering working software faster

What is agile? Most cliched answer to this translates to “delivering working software faster”. Because, agile principles clearly states – “Working software is the primary measure of progress”. It doesn’t mention anything about the speed though. In rest of the article, where ever you see “value” translate it to “shed-load of money” if that works for you. It is very important to establish what is the definition of “value” for you, to understand the true meaning of what agility is.

If you buy a new bike or car, it’s performance will always be lower than a well oiled 2year old vehicle with similar specs. Agile teams are like that. The team members can be experienced and brilliant but to really know what part of the product is making the most value, requires investment on thought process. That’s where a Product Owner/Expert comes in with data to prioritise the most valuable work on top of the backlog and own the decision. It’s their job to also convey “why” it is more valuable to the team as well to validate the possibility.

Example Problem Statement

A company hired 10 team members paying £500/day. Screw prioritisation; an expenditure of £5k/day needs to be used up in anyway possible on that 8hrs contracted. Even if that means we make the member work on items no one really give a shit about or have any value. If we focus on priority we will end up wasting 3hrs a day, out of which the members will celebrate a 2hr lunch and will be milking the strategy. How do you propose to handle that?

Solution

Assuming a 20 days working month, paying £5k/day or £100k/month is actually a lot of money to go down the drain, if they work on features no one asked for. The cost can only be justified if they focus on the most valuable item first, instead of an item you may not need for a month. In many cases, as much as 80% work remaining are actually not necessary for early feedback, as the most valuable 20% decides the fate of a product. Work on them first and save your time and money and stop focusing on what the members are doing, as long as they are working on the right thing you require.

Pareto Principle

Does the above solution sounds familiar? Yes, I am referring to the Pareto Principle which is known for a century now. Albeit, saying that 4:1 distribution is “accurate” would be a wrong generalisation as it’s application varies. But it does make a point about how we should approach the product backlog. Empiricism, hence is the only way to go with faster feedback to continuously update the backlog as we know more and more about the product and end user’s expectation.

Source**

 

Working software is mandatory but the trick is to convey the message like this –

Agile is NOT about delivering working software faster, it is about delivering the most valuable software faster.

End Note

Prioritisation is all that matters. If you have adopted “Agile” and still focusing on speed or amount of work for monitoring purpose, then you are doing it wrong. There, Agile defined the way most businesses want to hear. Value can have different definitions for different businesses, “Money” being the most common form, which we should really focus on.

Hope this article makes it clear why “Agile” makes sense in development.

Gallery

Velocity – a fallacy often blamed on Scrum

Overheard someone saying the other day – “Point based estimation is still a pointless metric and so is the velocity calculation in Scrum”. Yes I strongly disagree, not because I believe in the fallacy called velocity but because it has nothing to do with Scrum or being agile. Scrum is not a silver bullet, agree, but that comment clearly indicates a misguided anti-pattern. I am not a Scrum fanatic unless I wouldn’t create XDE, but this concerns every Agilist out there. It is about the trend of misinterpretation and the habit of many professionals to modify an immutable framework.

Scrum being a framework (not describing a method or practice) is being misinterpreted by many even after it’s 20 years of existence. While many organisations are still learning and implementing Scrum, we see more and more discussion around “Velocity” and “Point based estimation” which is not even part of Scrum in the first place (no mention in Scrum Guide).

Capacity is what we should focus on, not Velocity.

Velocity calculation is a result of the point based estimation techniques, which are also misused as a performance metric. Ask an average Scrum team how they measure team performance, the first word will be Velocity. Be it linear or relative estimation, when we use a number for anything, our beautiful minds translates it to an “absolute value” which is not negotiable. We start writing it in a card or add it on a tool to track velocity. Then we slowly & voluntarily dive into deeper political horizon of team velocity comparisons, false sense of predictability to never come back out again.

Intention of point based estimation is to break the ice.

Technical experts are usually shy, they love to just to get it done, write the code or test while listening to their favourite music. Estimation sessions gives them an opportunity to open up and be valued for their knowledge. They agree or disagree or share a fact that no one thought about before, to establish a shared understanding. Then they leave the room to start working on it but never leave the number behind. It stays in the card/tool and makes them uncomfortable when they find out a hidden issue which will screw the estimated number. This is frightening, as it becomes a matter of their honour and a measure of their knowledge, which makes them look retarded in front of their team.

“We said it’s 5 but now it seems like a 13, WTF ! If I tell the team they will think I am stupid.” – This, we can live without. This stops us from being brave and fail fast as failure is not an option. To be agile we need to embrace failure as learning opportunities. This negative Hawthorne effect goes against agility and get blamed on Scrum because of the time boxed sprints where velocity really applies.

We “estimated” the avg. velocity as 40 but it somehow becomes a “promise” to stakeholders which is not open for negotiation in many cases.

It creates an obsession among us to match the velocity every time or more to show off. Truth is, Velocity can easily be manipulated and somehow the “people” aspect get thrown out the window. Where is the trust? Where is the working software? That’s why, even though the point based estimations and velocity calculation were created to “guide” us, as human beings we cannot trust ourselves on showing our true nature – urge to control the uncontrollable. Therefore, to become agile we have to let go of this metric from Scrum, for good. We don’t want to be that person who focuses on these numbers and not outcomes.

Let’s get back to the basics of Agility

  • The fact is, we try to measure the scope in units like time, but we can’t. That doesn’t mean we have to use numbers. Be creative and find another way which doesn’t promote false sense of control over the development cycle. It’s development not manufacturing, you will fail many times before finding the right product. Scrum is for development not manufacturing.
  • RTFM – there is a reason Scrum has a guide so stop associating Velocity and Estimates as a “mandatory” Scrum metric while implementing. You are digging your own grave by doing so.
  • Stop asking Scrum Masters to report velocity as a metric. Even if they are in place, they are private to the teams, not open for all.
  • If you can’t negotiate, you are NOT agile. You might as well do Waterfall, it will give you the same results.
  • Stop making “Promises” on deadlines using velocity. If a person have never worked hands on in a code base, their knowledge about the product is at best worthless. If that person is making promises by predicting velocity, the joke is on them.

End Note

Velocity is a fallacy, whether you like it or not. Use it only if you are still winning. If you are failing then please let it go, just don’t blame it on Scrum. Scrum is much powerful without it.