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.


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


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.


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.


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.


Continuous Integration, Delivery & Deploy – It’s part of our lives !

Stakeholder: What do you mean by 2 more weeks? It was almost done yesterday wasn’t it? I was waiting for it for the past 2 weeks and now it will be almost a month. Can’t you do anything about it?

Product Owner: Yes it was but we found a bug which we can’t fix and test in time. Our 3rd party provider never mentioned that X has a dependency on Y. It will be ready tomorrow but have missed today’s release deadline.

Scrum Master: Agree, I have managed to get to the bottom of this but unable to mitigate as contractually they are within their SLA. Look at the bright side though, we have managed to push through 6 other items as planned. The PO and the members have done their best they could.

Stakeholder: I understand. It’s time we do something about providing a solution to these last minute issues. It’s practically blocking a high revenue business critical feature.

Product Owner: That’s true.

Scrum Master: We can try continuous delivery as an option.


We have heard similar complaints several times (at least I did). If you are part of a development team at any level, you probably know what Integration, Delivery and Deploy means. If not then you have this post to guide you to understand the basics. Before we dive deeper, it is important to state a fact –

The terms ‘Integration’, ‘Delivery’ and ‘Deploy’ are not appealing and worthless at times – if it doesn’t have a “Continuous” flow.

If they are still appealing to you, you are probably working within a team who prefers traditional approaches like waterfall over the 21st century approaches to become agile or lean or anything that promotes continuous improvement and based on Empiricism.


Continuous is, in fact the most underrated word in a product development life cycle. If you use it often at your work, pat your back and join me in spreading the word. This article is targeted towards non-technical professionals working around a development team, ideally a stakeholder/product owner/alike. It can be a good recap for those who don’t feel 100% confident about the topic as well.


Feedback – now, this is very appealing. It is quite powerful on it’s own. Imagine what it represents when we talk about “Continuous Feedback“. Feedback in the context of software development means reviewing deliverables after the Implementation + Integration + Delivery (+ Deploy, if we are capable). The moment we go deep inside a “Software” discussion, we end up taking about coding, testing, processes, tools and practices to establish this feedback cycle. This is where many stakeholders loses interest as they don’t give a damn about how we make it happen. Technical experts are hired to help translate those low level information in to high level business goals, not the opposite. Stakeholders just need what they have requested, preferably on or before the timeline proposed.


Continuous Integration (CI)

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.” – Martin Fowler

Continuous Delivery (CD)

Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.” – Martin Fowler, again.

Continuous Deploy (CD – yes I know)

Simply, the act of making a completed product available on Production or Live environment, continuously. – well, me.

It is not the same as continuous delivery. It is confusing because the acronym CD is used for both. Delivery can be on a UAT or a Staging or a Demo environment, which although resembles the production environment to some extent, may not really the same. Continuous Deploy, hence, is not recommended unless we are extremely confident.

The power of “Continuous” (Stay with me)

If you are a heavy commuter like me, live in South of England, use overground DLR/Southern Railway/Thameslink or similar plus the London underground, you are already witnessing the “Feedback” loop every bloody day. The difference is – they all represent a unique feedback cycle which may or may not suit us.

Unless you have given up and made peace with it, you probably feel a shift on your stress level when travelling on different services. I am going to use an example journey from my home city to London St Pancras to explain this.. hold my beer.

Continuous Commitment and Integration

What wakes me up everyday is the joy of working as an Agilist and not the excruciating pain of travelling to London, everyday. Travelling becomes a default daily commitment for a greater good. To commit every morning without a fail and to reach the train door in time I have to make sure that I leave home on time, everyday.

To repeat this everyday, as a human, I have to make sure that I play an hour of World of Tanks (yes, everyday) and get enough sleep. Unfortunately we humans also need a “turn it off and on again” the way our PCs do, unless we tend to screw up badly. This is non-negotiable and if we are not doing what resets our day, we ARE going to fuck up. It’s a matter of being committed “continuously” towards what we have to do and make it our second nature.

When we compare this to CI in software development, we can see where we may be falling behind (if we are). If we are not committing everyday on our codebase and merging the latest changes (reset), chances are we will always see side effects that waste more of our valuable time. We may be working on a branch which should have been synchronised days ago. Hence. everyday. To ensure a healthy codebase, therefore, we need tests to run continuously whenever we commit for the fastest feedback on the changes made. If it breaks anything it’s smarter to fix it now, rather than blaming the lack of sleep later.

Delivery and Deploy – How Continuous are we talking about?

As much as we are capable of, as fast as we can. It’s a culture thing and very much depends on our capability and the people around us. It depends on budget, mindset, commitment and necessity. It can be a week, few days or few times a day which varies widely with the type of product and any dependencies around it. It depends on third party teams we are working with, clients we are providing value to or simply the reason that we are trying to improve “continuously” aka Kaizen.

Whatever the reason, it is always preferred to choose the fastest option and use the right approach to get it delivered without waiting for a stage gated process of batch deployment, treating it like a ceremony. If we are making a big deal of it, we are already accepting that we need improvements.

Back to travelling…

Choose what works for you over what is “Best Practice”

After I reach the Brighton station, I see 2 train services which varies way too much in terms of providing value to me as a commuter. T (Thameslink), stops in almost every station in the route, as it provides a “cheap” service and takes more than 1.5hrs to reach London St. Pancras. G (Gatwick Express, same owner), stops in limited stops and reaches London Victoria within an hour or so; and yes it is expensive. Around 20% more towards the cost. T services are reputed for being late in a regular basis and can be quite frustrating at times.

Careful observers might have spotted that I mentioned G only reaches to Victoria. Which means to reach St Pancras it will take another 30min anyway. Technically, I am not saving any time and literally spending more money. But the “Values” I am receiving are more important to me such as, a peaceful travel where I get a seat which faces the way the train is heading (yeah.. you are not the only one !), free wifi (most days), socket for charging, table for the laptop and always be on time. From Victoria, the tube is also extremely reliable even though it IS a dependency.

In software delivery, this is what matters the most. True, 2-3 commitment of continuous delivery a week is possible and is the end goal for some but is it possible with your skill set, dependencies or culture? May be not. If you are being forced to do so, you will most probably go and look for better options in your career elsewhere. We can aim for it but we shouldn’t try to be the superman we are not, we may actually won’t even need it. So technically it will become a waste of time, effort and will create a stressful environment.

Stress is a bitch !

Do you experience a shift on your stress level when travelling via Overground vs Underground?

The T service have a train every 30mins on peak hours to St Pancras. The G service have it every 15mins giving me a flexible and less stressful commute, on top of what other benefits it is providing.

Even though it is stage gated, it just works for me.


There is another reason. If we manage to reach any London terminal and see a Tube Strike.. no brainer, there are other means to reach your destination. It will delay your journey for that day but not everyday.

Even more stress free flexibility – The underground Victoria line have a service every minute or two. You can practically watch a train leave and still don’t give a damn; the next is moments away, as close as 100m. That’s the power of “Continuous” – anything.

As a Stakeholder..

Similarly, a stakeholder should be stress free about a missed release and shouldn’t worry about missing a delivery window; just to be told that they will have to wait for another 2 weeks even though it will be ready for production the next day. That’s the most irritating “process” which doesn’t makes sense to them and to anyone who favours common sense.

How do we handle this stress as a stakeholder? We do understand that things go wrong, after all we are professionals. It doesn’t mean that we now have to wait for another 2 weeks. So we will stress out and pressure the team to do a “Hotfix”. Even though we know it can have bad implications, we will be biased to push it anyway and most probably will get what we wanted. We wouldn’t care about another stakeholder as it is not important anymore. Our success is based on how well we get things out of this team, so screw the team or any other stakeholder.

If the team was delivering continuously, a deploy to production would be considered as just another step to add in the Definition of Done .


It’s a win for sure but for a short term. The fix we pushed out may have bugs as the development team members were rushed and may miss out few bugs. It will turn on us the moment we show our back. The reactions to this will be fatal. Now the team knows that the stakeholder is being unreasonable. They want to help but they can’t as the process don’t allow them. So next time when time will come to commit to something, they will commit to less amount of work to avoid a conflict.

Do we need this shit? It’s not worth the hassle trust me.

Aim to reduce batch sizes, continuously

If we are moving from traditional to modern approaches, batch release makes sense. In fact you cannot have an agile transformation without it. The fact that we have to reduce the feedback cycle from quarter/year to 2/4 weeks (as Scrum suggests for example), is still alien to many companies. ‘Continuous’ in this case is the length of the iteration cycle.

But this doesn’t mean once we have achieved the 2-4 weeks cycle, we cannot aim for even more granular continuous releases. The whole point of reducing batch sizes to as small as one item per release, is to provide support to the stakeholders’ need.

As a Development Team Member..

We don’t need a hostile environment, instead simply use common sense and be human for a moment while thinking about providing a feedback, if there is a need. Do a hotfix if that’s what it is necessary, just don’t say we can’t do anything for another 2 weeks. What will go wrong? It will slow the team down for the very same reason the resistance is there. At least we can reflect there is a change needed on process or tool or whatever that is blocking us. Stakeholders will be forced to understand as they are on the same boat and will stop pushing as it will force them to think long term.

Hope you all have a great week ahead, be continuous.. stay agile.. think lean 😉