Consider SHU over HA and RI

We come across many ways to become agile in our organisations, to name a few ways – Scrum, Kanban, XP, XDE and more. We want to become agile by being reactive rather than proactive, so that we can embrace change. We want to provide value, that is the goal. Being agile is one of the means to achieve that goal, not a goal in itself. Same goes for lean approaches which tries to reduce waste, a mean to provide value, the goal. Therefore, “elders” in this context are “scared and healed” thought leaders rather than traditional mindset driven older generation.


So why suddenly elders need respect? Aren’t we respecting them already? Hard to say really, as many of us say we do but may not really mean it, unconsciously. Even educated professionals may think they do but they don’t as they are too busy reinventing the wheel either because their training was not up to the mark or they are returning a favour to an old pal. I heard someone saying the other day – “My friend told me that Scrum slows them down, so we tried Kanban instead which turned out to be a disaster.. agile sucks in general anyway”. You know instantly, they have never understood the values and principles, so forget about the events and activities which binds it together.

Reason why, among traditionally trained professionals we hear so many discussions like – “Scrum is terrible“, “Kanban is the new Scrum” and “XP sounds like exactly the wrong way to go” and many more. Community members who say these, may have never seen it working in the first place OR don’t want to improve OR have seen a bad implementation which focused on goals like “Agile” or “Lean” – they may not realise that the goal is to “Deliver Value” and agile/lean helps you provide the value but not THE goal to show off.


So what any of these have to do with “Respecting Elders”? Well, the above is exactly what you get when you don’t respect the work the founders/creators aka the elders have carried out, number of times they have failed (learned) and amount of sweat they wiped in their lifetime. Most of us don’t spend time actually implementing a method “by book” in the first place. Learning curve is a waste for them and don’t even get me started on how some likes to bend the rules while calling it a “Flavour” of XYZ. This reminds me of a very interesting quote –

Those who do not want to imitate anything, produce nothing ~Salvador Dalì


We need to get into the mindset of learning, mastering and transcending. Yes, I am talking about ShuHaRi. I bet a lot of us may have heard about it, if not you have a link now. Shu is where you imitate without worrying about why you are doing it. Trust the research which has been done for years (some more than your age) and atleast give it a chance.

20 years experience in traditional techniques, does not make you an elder in mordern approaches – unless you have invented/created a better approach !


True elders have spent almost all of their professional life creating the agile/lean principles and practices, if you will. Then “By Book” should be your baseline, unless how can you criticise something you know nothing about? Once you know what by book means, then you can ask yourself if this is the right approach for your organisation or not. Nothing is a silver bullet but these are atleast “a” bullet to hit your targets, from which you gain experience and modify accordingly.


Some Examples of unintended disrespect:

“We have introduced Scrum before and hired a Scrum Master. He ended us hiring a Product Owner who replcaed our BA who was sufficient enough and much more cost effective. The team’s output slowed down since and 1 month later we realised we don’t want Scrum.”

“We have an electronic Kanban board where most of the items are blocked so we started to work on new items. The testers are uselessly slow and we ended up with nearly 20 items in testing swimlane. The developers were awesome though, they worked on all items in time but were kept getting blocked by the testers.”

“We tried TDD and wasted much of our time testing before writing the code while pair programming. We ended up with 90% test coverage but a plethora of defects which should have been caught by Unit tests during CI. So, we are now concentrating more on automated selenium tests after development.”

“We don’t need retrospectives as we never get where it adds value. What’s the point of revisiting past when we can use the time to concentrate on future?”

“In our Kanban board, we have a WIP limit 4 but we change it every week according to our need. Kanban says we can change the WIP limit anytime, as long as we visualise the workflow.”

“Our product owner needs to write user stories in Given/When/Then unless I have no idea what he asks me to build. He needs coaching so we developers can do our job faster. I think working as a Scrum Master alongside is taking a lot of his time.”

“BDD is just a language defining the behaviour and nothing else. Stories should be in BDD unless it is not Scrum, correct me if I am wrong.” (P.S: He did get corrected with a mandatory day long BDD workshop, he asked for it.)

“We need all the daily scrums happening between 9 till 10am, for all our teams. The project manager is only free during that window.”


You get the picture. These are very few examples among a million out there (Feel free to add more examples on comments). The elders are never mentioned but their experiences are challenged and disrespected everytime someone use these phrases in any format. Lack of knowledge is to blame or is it?

Respect these elders, we don’t need to fail the same way they did and learned. We have the wheel, we just have to use it and keep applying the WD40 (common sense) when required.


Annual Budgets – Silent killer of Innovation

Large non-IT enterprises are using software development as their supporting delivery strategy which forms a part of their business, but not for the sole purpose of business. They mostly assign a yearly budget on any project to increase predictability.  They tend to keep the expenditure controlled along with a buffer using some validated numbers collected from last financial year. This is a trend adopted from the “manual labour” culture where we can predict expenditure in advance. But it doesn’t work when a work depends on our thought process, experiments and fast fail approaches used in software development we use today.


In manufacturing, budget can be controlled and improved by lean mindset as it becomes predictable. Similarly applying an agile mindset on development works like a charm. Although, the non-IT businesses fail to see the difference between a development line and a production line. This is the biggest impediment which affects many organisations today as it can be completely ignored in many cases.

Yearly budget is the silent killer of innovation and encourages bureaucratic culture in software development.


Many of us have come across this impediment, if we are working in such an industry. We should decouple the budget to be flexible and get support when needed without abusing the freedom. This increases the transparency around the budget expenditure which can be verified after the financial year rather than predicted before a financial year begins. We can never know how a business shapes itself in coming months when you have multiple competitors to worry about.

Decoupling the financial budget creates a “Pull” instead of “Push” mindset.


Decoupling the Budget process

Let’s take XDE Framework as an example. This proposes “decoupling” of all processes to achieve the best possible solution in given time, focusing on independent and futuristic business model. XDE requires us to form a temporary “Bubble” by combining specialist team members from 2 types of permanent teams, One Rule (1R) team and Product Team. This bubble can be dissolved when a planned work iteration is shipped and is successful.

Coming back to budget, as a process and an impediment. 1R team (or any team) can suddenly realise while in a bubble, that they need another technical expert to get through a planned work. Do we want them to wait and check if they have enough budget for that? No, we authorise it providing they have a sensible reason on why they need it in the first place (common sense). Dissolving a bubble is not the goal; it only encourages us to plan well before the bubble is formed.


Don’t hold the development teams responsible

We shouldn’t hold the teams responsible for not seeing an unforeseen impediment like the annual budget. We don’t need funds without knowing where we are going to spend it in a year time.

Common sense should prevail.

We need to be agile as an industry, to support the teams analysing the circumstances pragmatically. As we all know, agile mindset helps an organisation best when it comes from top down rather than bottom up.


“Pull” reduces Waste

WhatsApp Image 2017-06-15 at 5.46.49 PM

Financial budget is dealt by a specialised Finance team in non-IT organisations. Reason why they assume that software development teams are one of many departments providing a predictable service. This is where the mindset need to change and we need to decouple the financial budget for development. Provide funds when required rather than pushing a set amount in and hope for the best.

We might be spending more in software development than required, so that next year’s budget can stay same or more – that’s Bureaucracy


As the development teams are pulling the funds when required, there will always be a valid reason and this increases trust in the culture. This culture will empower the development team members and assure distributed responsibility, rather than hoping they have enough “resource” to cover the work they planned where Finance was never actually involved to begin with.

Does this resonate with your experience working in a non-IT industry? Would love to hear your thoughts around this and will be great to hear your personal experiences. Keep calm and decouple budget for software development !


Scrum Events in Layman’s Term

Scrum helps in developing complex products. It is easy to learn but hard to master. Easy to learn, because we have a guide with rules which beginners can refer back to. Hard to master, because just blindly following the events will not get you anywhere. Many teams try to bend the rules without mastering them first, which is why they fail and end up blaming Scrum.


Scrum guide is clear about the events and explains why they exists. Although sometimes it is not sufficient to just point people towards it and assume they will read it. Shared document is not shared understanding. Some may never read it and they are usually after a much simpler explanation on the spot. That’s why during or after implementation of Scrum, we usually hear some basic questions within an organisation and this article explains one of them.

Briefly explain what we do in the Scrum events in layman’s terms?

Here is what you can explain, assuming you are explaining to a layman who have no idea why the development team have selected Scrum. Before going to the events, lets understand some basic terms which makes it easier to explain the events.


Requirement: A “problem”, because the solution doesn’t exist yet. Our aim is to implement the solution.

Epic: A big problem.

Story: A small part of a big problem

Bug: An unknown problem

Scrum Team: The godly creatures with super powers 😉

Now, let’s see how we can explain the Scrum events and activity.

Refinement Activity: Scrum Team try to understand if they have enough information about the variety of problems.

Sprint Planning: Choose the bigger problems and create a strategy on how to implement the solution.

Sprint: Implement the solution without being distracted.

Daily Scrum: Daily check on “Are we on the right track on creating the solution?”

Sprint Review: Understand the solution and verify if it actually make someone’s life easier.

Sprint Retrospective: Have we learned anything new while creating the solution?


That’s it, it’s just common sense redefined. As long as we realise we are solving a problem of variable complexities and use the above thought as a guide, it all make sense. Hope this article can solve someone’s understanding of the events and what we should be doing in them.


Meetings – It’s all about planning the Interruptions


First thing you will notice while reading this post is the image above. Today at this very moment, when I searched it in google (noticed the new logo?), I could see the most searched phrases as above.. WOW !! It’s quite common to see someone saying “Meetings are such a waste of time” or “Meetings interrupt my work rather than solve the problem”. I bet you heard this before, at least once in your professional life or even felt like that.


Yes, I freaking hated meetings as well, as it never helped me (6 years ago). Sitting together with a bunch of hot shots who mostly try to put their opinions forward and try to route the decisions to their own liking. I used to like the fact that, if I get a call in between, I can finally say “Can I call you back? I am in a meeting right now !” Being a recent graduate these things were in my “Things To Do” list as a ‘Professional’ 😉

I was wrong as you might have already guessed, mostly because I never understood why I was in that meeting room. I only attended just because someone invited me. Realising that I loved the attention when I had something to contribute, whether it meant anything or not, I started regularly attending the meetings and my productivity started going out the window.

So, I did some basic self evaluation as this wasn’t the experience I wanted the achieve during my graduations. Anyway, 5 years ago when I was somewhat serious in my career, I read few blog posts and professional opinions about Meetings in general. Most mentioned that meetings are always a controversial topic for sometime and a successful meeting is widely dependent on the organisers ability to achieve something. Months later, co-incidentally I was introduced to Agile development which changed my views forever, for good.

This post about Meetings is not about Agile though but Meetings in general. In these 5 years, here is what I learned about it and ways to make use of some basic concepts.


Ask yourself: Do you have a ‘Goal’ to reach after this meeting?

That’s a simple question so just answer it to yourself first. If not satisfied with your own answer, ask the organiser. You may find them acting all rad about it and even a little annoyed. Your answer – “I am sure you have your reasons but does it have to involve me?” Let them think and answer to that question. It will simply rectify any confusion right away. You will get an answer on yes or no, simply explaining why. There won’t be a grey line if they are 100% sure.

Benefit – You know why are you attending the meeting and what will be your contributions to it.


Ask the members: Is this the Goal we are trying to discuss?

Yes it is, unless they wouldn’t be joining it. So where’s the ‘controversy’ coming from? Well, the moment we start discussing a topic which slowly takes another road, which seemed important at the time and ended up discussing nothing, especially the original topic. Who is responsible? – All of us involved in the meeting. It’s like watching a crime and not reporting it which is actually a crime too.

How do we cope with it? Be the hard nut and “Raise Hand” interrupt everyone discussing the topic which is diverted from the original. People may look at you like you are a maniac but you will save your valuable time as well as their’s. Politely say that you think this conversation is not in the scope of the current meeting and should be discussed separately; if really necessary to be kept short.


Meeting are interrupting if it is not planned

Sitting quietly in a corner, deep into your thoughts/work and listening to your favourite tune.. “Hey! Can we quickly have a meeting about the XXX with the team?” What the.. why? I was..? why now?

Bet you were in that situation at least once, may be even more times and may have also finished the sentence starting with “What The..”. I can completely understand and this is mostly the reason many people find meetings interrupting. A meeting has to be done immediately for an “urgent” reason and the organiser (it can be you) have to define “urgent”. Just because you have some free time and want to get a thing or two done is not the right  reason to arrange an urgent meeting, whoever you are.

Plan the meetings and never assume that the people your are asking to join are free. You will not get things done in the meeting as the attendees are not in their right mind to discuss it. They are there because they had no other choice. May be you are their Boss and they don’t want to annoy you.


If your business needs frequent unplanned meetings, create time boxed meeting placeholder and send invites even if you don’t use it

I found this extremely useful in businesses where unplanned meetings are regularly necessary. Create a 10-15 minutes slot in every 3 hours and let everyone know. Everyone can use that session for any urgent discussion and not just you. Everyone will know that in their calendar, today they have 2-3 placeholders and they have to be free for that. If no meeting necessary, they can just continue working, simple.


Never attend a meeting with a mindset which reflects the attitude ‘it is a waste of time’

If you join a meeting thinking it is a waste, it will be. You will definitely waste your time and regret the decision of joining it. Worse, you may end up making it a waste for everyone else.


Never attend a meeting to control it, attend to contribute

The most important aspect of any meeting is, you can see everyone else’s view on the topic. You have an idea or a topic to discuss, you are pretty confident about the goal and have ideas to achieve it. So you invite others to ‘share their opinion’ on it. Stick to the goal, discuss and forget you organised it. Advocate your opinion but always keep in mind that ‘you may be wrong’. Just because you think it is right, doesn’t mean it is right for others. Contribute to the discussion with what you know and listen more to understand rather than waiting for the other person to stop talking.


Bottom line – If you can’t make use of the meetings don’t blame someone else. Meetings are necessary, useful and in fact improves the communications among teams/members in every way possible. Just make sure it is done right and not just a date in your calendar.


6 reasons why An Established Brand Stops Innovating !

Innovation and Reputation goes hand in hand. The history of every brand involves at least one “Epic” event which makes them an Established company. Brands follow a typical growth stages around it. These stages depends on how good you have managed to retain the existing customers and kept adding new “Brand Loyals” on your company network. This can happen by Social Media, Public announcement or High Profile merges between 2 companies.


That one epic announcement or innovation mostly happens during the Loyalty Marketing strategy which uses the Gamification approach as shown here:

Now, don’t go too deep into these statistics. What we really gain from this info is Existing and New customers are the main reasons why a Brand succeed and continue to flourish until there is a new game changer in the market.


That “Game Changer” is usually a start up trying to make a difference and Innovate to get noticed. Once they are big enough, innovation goes out the window like the previous company they “used to” challenge !

Hence, for the consumer, it is necessary to know why this happens and how the consumers can make a difference by choosing the right Brand in right time. Why a Brand stops Innovating?

1) Too many Blindly Loyal Customers

Brands pay huge and analyse Social Media Data closely to create a big fan base. They engage actively and keep the virality in check so customers themselves can start sharing and be a loyal guinea pig.

Oops, there, I said it. Yes, we are guinea pigs for the Brands as they experiment with our needs and actively manipulate the market to create a futile hype, often. Eventually as consumers after spending a fortune, end up with a product that they “thought” can make a difference. Consumers are the culprit, because of whom the Brands stops innovating as they know, whatever they build, we will give it a try without a second thought !

If you don’t make them run for their money, they will never look back. Brands won’t care if you are impressed or not unless you let them know what you feel and start being a pain for them by sharing negative comments now and then.

2) Reinventing the wheel, keeps the wheel of fortune going

Several brands are great in hiding their potential source of copy/paste achievements. Naming a few would be biased, so just imagine a Brand that you love, search the history and see it for yourself. You will be surprised.

Say an old technology ‘was’ marketed a while back, which couldn’t gain any attraction then. After 10 years finally people getting attracted towards it and another brand developed similar product and capture the market.. hell.. even tried to own a patent for that tech which wasn’t there original idea in the first place.

3) Third party businesses create unnecessary hypes

‘Marketing partners’ aka the middle men boosts a Brands image exponentially and they are present in every industry. Example you ask? Well, when you get a new gadget on contract in UK you go to O2, Orange, EE or Vodafone to name a few. If a gadget costs £500, it is usually been sold at a 24 months contract for £35 a month = £840 while you are stuck in a locked device (mostly) for 2 years..

“BOOM” – no innovation needed for a while !

4) Not many serious rivals

This, we all know and will agree together. If a Brand which has no innovative competitor they won’t feel the need to impress you. Monopoly is a curse. If you want to innovate, you often do it for free to get noticed. This is the reason why there are so many start ups challenging the established market leader as they feel the need and they know customers feel the need.

5) Timing of an Innovation is Important

Timing makes an innovation a hit or a miss. We as a consumers do not appreciate new feature as much as we should, as we got it when we didn’t asked for it. If you want innovation to continue, agree and let the Brand know that they have done a great job even when the timing is wrong.

6) Lazy Marketing sometimes supersede the power of the Tech Team

Some Brands release a feature without any marketing strategy. If you can’t show the consumers how the new feature is different, you will fail. It’s a two way street. If consumers are lazy, sometimes the Brands are too.

There might be awesome engineers working day and night for an innovative idea but if the marketing team forget to highlight the facts, brands can’t help it. Eventually we as a consumer feels that the Brand is not doing so well, when they really are.. may not be as a good team.


Therefore, if you want to see innovation constantly coming out of any brand, as a consumer do the following –

  • Don’t be blind fan and be very selfish, unless you think it worth your money.
  • Don’t go easy on them, be a dick and go hard on Social media.. spread the word (just don’t lie). Social media is a serious business, it’s not about fun anymore for Brands.
  • Encourage Brand rivals when they do something good. It will help make the community more innovative.
  • Remember: Slow Innovation is no Innovation. If you become a legend just before the day you die, why would you bother anyway? Make them do it fast, make them move from their arse and force them to go out of their comfort zone.
  • Remember: It is always about the money; no matter what you say. A Business can’t be just for a hobby or interest. If you are an app developer, at some point you will want to gain some profit.
  • Treat Non-profit organisations and Start ups as legends. Applaud and appreciate them, as they are the main reason why we see innovation day by day and not by an established Market lead.