Business Agility are we back to CMMI?

Business Agility are we back to CMMI?

Admin aaSunday, September 13, 2020

Agile is around for at least +20 years. However, one big complaint was "how can we scale agile" or "how we go beyond teams". You might consider business agility as the 3rd wave of agile.  But is really hat the case? The world changed a lot in the last +20 years there are many other things to change in the next years. COVID-19 amplified lots of the issues that was already in place.  It's really business agility something entirely new or just an aggregation of previous movements, practices, and values? Business Agility is a hot topic right now, lots of people talking about, very few really doing it. It's hard to get real agile teams nowadays, imagine whole orgs being agile, even harder. IMHO to make the org agile is super hard, however, some of the reflections that business agility is proposing sounds right in the sense we might be asking these questions anyway. 

What is Business Agility Anyways?

Business Agility is about having agile at the core of the organization, the boards, the executives, the C-levels, the high-level mgmt, the leaders of the company but also going outside the IT and have it in other departments like Marketing, HR, Financial, Sales, etc. We can see business agility about having some core capabilities well established such as:

 * Agile Delivery

 * Product Innovation

 * Organization Adaptability

 * Leadership effectiveness 

We are talking about applying agile principles beyond technology. The word hard does not express how hard this is. All these capabilities can be considered new capabilities because if the org had it we would not be talking about them. 

Business Agility Relation with other Movements 

IMHO Business Agility it's backed by several other movements such as: 

 * Agile

 * Lean

 * Lean Startup

 * DTA / TTA / Lean UX

 * CMMI

Ok. I can see some relationship with all previous movements but CMMI. Well maybe because you are thinking about the bad parts of CMMI (Slow, process-driven, inefficient, certifications) which are very bad things. I would recommend no company to get a CMMI label. CMMI had 1 idea which was very good even if CMMI executed super badly. I see some people in Lean also backing and supporting this very CMMI idea, which is levels. 

Are we going back to CMMI? 

CMMI had levels 1 to 5. Meaning you need to improve your company as a whole from one level to the next level. IMHO the idea was super badly executed by everybody. However, if you think deeply you will see its not complete waste. Let's consider a football player, you might consider JR, Amateur, and PRO. A-Pro player might be able to do things that an amateur or JR might not be able to do it. 

IMHO CMMI's mistake was the content and being process-driven. The issue with levels is also that it might be different from company to company so I would say is not that static. If you Look David Anderson's approach to Lean/Kanban to enterprise it has lots of CMMI ideas on that. 

If we think about an org being Agile, definitely is not a 3-month work. Lots of ideas are business agility sounds like Lean principles to me, 14 points of Deming to be more specific like (improve leadership, break silos, drive fear out, create purpose, etc..). 

In some sense, I believe we are going back to CMMI. Since we might not be able to fix all problems at once we might need to go trought some multi-stage change phases. Do each phase need to last 1 year, no, hell no.  Otherwise, we might be talking about some change which is very hard to drive and a problem that is too big to fix at once. 

Business Agility Challenges

There are many challenges ahead. Lots of companies have politics, empire-building rather than focus on innovation and learning. Product is a area where lots of change also need to happen. Product is often a project management organization rather than being a product management organization. The product often pushes for Features and turn Tech into a Feature Factory. The product needs to stop focusing on deadlines, features, and cost and focus on Discovery and customer-centricity. Business agile is bigger than product or tech so imagine the size and the number of issues we need to go thought here. 

We also need to talk about the big elephant in the room. Culture and People. It's very hard to make some people to change. I believe people can change, but not all people. Sometimes what companies do to make change happen is to fire the leadership group. Companies are struggling to apply agile at the teams levels, imagine to apply at the execs level. At the same time looks like thats one of the big reasons why agile fail in the first place. So looks like talking the heart of the problem. 

The Catch 22

On thing, the agile community was always worried about was about being prescriptive. So focusing on the principles rather than tell people what to do (process). Which makes all the sense and is completely right. However, if you don't give guidance to people you end up with abuse. Some people say thats how success looks like. Agile has been abused and people are doing it wrong because for lots of people that's how success looks like. So how can we focus on principles and at the same time tell people how to do things because at the end of the day people need guidance. Before I explain what I think I need to elaborate on what I mean by "tell people what to do". 

I dont believe in micro-management. However, at some times the structures will not change by them-selfs and managers will not change by themselves alone. So thats what I mean by "tell what to do" which is not micromanagement, is not command and control but having a strong leadership who drives change.  Leadership is both the problem and the solution that business agility needs to tackle. 

Cheers,

Diego Pacheco

Big & Micro Retrospectives

Big & Micro Retrospectives

Admin aaSaturday, September 5, 2020

I'm doing retrospectives for more than 10 years. I saw it all, the good, the bad, and the ugly. Retrospectives are fundamental and instrumental part of Agile. Even if you are not doing Agile or is not agile-ish in our way of work I would 100% you need o to have some form of retrospective. Retrospectives are an important mechanism to introduce improvements. Pretty much all companies spend lots of time in planings sessions. Long planing sessions are pretty normal(4h or more). However long retrospectives are not popular at all. It's possible to work without classical retrospectives however you would need some form of Reflection and Guilds/Chapters might be a place to have retrospectives. IMHO Retrospectives is something you want to do without mercy(Maybe I'm watching too much Cobra Kai). Meaning you should do lots of retrospectives. Retrospectives have different flavors and styles however I believe there are 2 important ones: Big & Micro. Retrospectives help to change the status quo and shape the culture. Retrospectives can be hard. Specially on the beginning. IMHO Retrospectives are like going to the GYN, you might not like to get in but you will love it when you get it out(finished the workout). Let's understand why retrospectives are hard.  

Scrum and Culture

Scrum shapes for Long planing and small retrospectives(15min to 1h). However, what happens is retros become a compliance thing.  Often people do not challenge things and they often do not tackle hard and complex problems. I would say 100% you want to have longer retros and small plantings. We live in a Feature Factory world where features are the only thing that matters.  

However, having a SOLID Foundation which is called STABLE SYSTEM in Lean teams is important to have better productivity and Scale and still operate with Fast innovation pace. Facebook at the beginning had the motto: "Move fast and break things". Because in the beginning, you cannot move fast if you dont break things. Them later on Facebook change his motto to: "Move Fast with Stable infra". Mark said that the principle did not change. It's the sample principle. Which is fascinating. Meaning, When you dont have a scale you need to break things when you have a scale in order to move fast you need to do the things in s STABLE way which has 100% synergy with Lean for instance. 

Which leads to the heart of the question. How do we know what is the right thing? We have diversity, people think differently, so how we take the best from everybody and reflect upon what we did to do it better? How do we review our systems, practices, culture, and improve? I would say retrospectives are fundamental for that. 

Retrospective Alternatives

You don't need to do retrospectives. However, you need some embedded mechanism to handle discussions and improvements. IMHO the best practices to tackle that are Chapters/Guilds however even with them I would still do retrospectives. Why? Everybody is busy, we are always dealing with tons of issues, incidents, being paged, attending meetings, getting things done. Often we dont have time to STOP and have human conversations about everything thats going on. 

It's possible to book meetings and always be discussion things and do improvements. However often we are very reactive when we just operate on that why. Doing formal big and long retrospectives allow you to be proactive and improve things before problems become a big deal. 

The Case of Big Retrospectives

I'm all about Big and Long Retrospectives often taking from at least 8h and maximum 12h. I have to say I did retrospectives bigger than 12h. It's very easy to have +8h retrospective if you think about 3 simple dimensions: People, Process, and Product. People dimensions you want have sort of 360 feedback where everybody gives feedback to everybody, this makes the team stronger and re-enforces relationships. For the Process dimension, you want to review how you are working if you are missing anything or also what's not working well. Finally, there is the product dimension where you want to improve your product, your software. Having Deep and Long conversations with your team is priceless. 

How we can do that in 15min or 1h? It's very hard. What happens is lots of "blind spots" and we end up losing some many good opportunities to improve. Often people have "resistance" too long retrospectives because is hard to book 8h in someone's calendar. However, that can be done by getting ahead and booking retros beforehand and maybe 1 month early. Are you too busy to listen and improve? 

Often people are afraid of retrospectives. They are afraid of what people might say. But think about this, let it sync for a minute. If that's the case I 100% believe we have bigger issues, are we addressing these issues or just pretending they are not there. Some problems need to be addressed in 101s, not in retros. Specially problems that are very personal or not related to the team. There are some tricks about Big Retros such as:

  * Do it 1 time per month or every 2 months - so they are affordable. (1 per month is ideal).

  * Set up ground rules, Team agreements, and rules (such as turn on your video). 

  * Talk about them in 101s to make sure people always open in retros. (this is a good extra). 

  * Experiment before judging. It's easy to say 8h is crazy :-) 

The Case for Micro Retrospectives

So you also can combine Big Retros with small retros. Micro-retrospectives are 5-10minutes retrospectives you introduce at the end of everything. Every meeting, every planing, every 101. They allow you to look for "signals" which you might elaborate further down on 101s or in Big Retros. Micro-retrospectives cannot focus on the action because you dont have time to deeply discuss the problems and agree on actions. However, they are a good mechanism to collect feedback. It's very appealing to do micro-retrospectives and skip big ones, I would say you want to combine both but not skip the big ones. 

Experiments: This is the way

The number 1 thing you want to avoid in Big Retros is to not have actions. It's 100% important to have actions. If you dont do actions retros are just "complaining sessions". Feedback is critical to improvement in people, processes and product dimensions. However, sometimes is hard to get people to change without experimenting with things. The Agile(Also Mandalorian way) is to run experiments. So run some experiments, try 2-3 times before making your mind one way or another. 

Experiments are great ways to learn and to try things and they decide if they work if they don't work. Teams should run multiple experiments, Agile Coachs / Engineering Managers (Coach Engineers is the term I like to use :-) ) should use experiments as the number 1 tool to drive change. 

So go run your experiments, have fun, and grow with your team. 

Cheers,

Diego Pacheco

Hardening Production

Hardening Production

Admin aaMonday, August 24, 2020

Often successful companies have significant growth. Meaning: grow in structure. More people, more departments, more managers, more coordination and often more overlaps. Enterprise companies always end up having some form or governance issue. I remember at the beginning of the SOA world "Governance" was a very bad word and there was abuse. After 3 waves of Agile manifestation, we are with much less "Governance" look like we still have plenty of abuse. Abuse can be also called WASTE(Lean Concept). Some rules can really promote best practices and better software like: Do not share your internal data stores, Expose data via Common Interfaces like (HTTP / gRPC).  Systems tend to grow and get more complex as companies grow with them. Every single improvement(refactoring) often means more investment($$$) which also can be saying as business entropy as the time passes it only gets worst(more complex and more expensive). When we analyze refactorings individually(business impact) they might not make sense but that cannot be the only measure otherwise entropy will kill you in the long run, so there is the complex chess math going on. Bad code or bad design is not the only source of entropy, tests can be big offenders too. 

Unit Tests have can have Waste

People often value unit tests as they are the best kind of testing technique. IMHO that happens for a couple of reasons. One because there was a lack of unit tests in legacy applications, often legacy web apps and desktop apps. So it's natural to say unit test all the things. For the frontend, there are better ways to test and have value like double down on linters and static tying like TypeScript for instance. Also for the frontend, you can double down on Snapshot Testing and tools like Jest. However, backend Unit Tests have more value and are more important. We need to understand that unit tests can have waste, meaning: Flaky tests that break all the time for bad practices, coupling with external things like database IDs, or just because of mocking abuse. One thing companies always want to do is raise the bar, which makes sense however often that bar means more coverage. 

All metrics can be gamed 

That's the issue, as you as for more coverage the goal became to produce more tests, not often means produce better tests or make sure we dont have waste in tests. Whatever number you get 100%, 90%, 80%, 70% you might have WASTE but higher numbers have a higher chance to have waste there. Should we have no metrics for them? well, thats a hard problem. Since this is subjective is really hard to measure and really hard to have a clear safe a universal signal. 

The Issue with Mocks

The issue is people end up abusing from mock. Either you have the real thing and you are doing a real integration or E2E test or you want to test something else and the mocks are a way to isolate your code from other stuff so you can test in isolation. That is fine, however, the issue is most of the time people are testing mocks. There is no value in testing mocks. Mock is a form of coupling if you have a shared library mock that could be a huge step into migrations and patches. 

More Diversity (CI/CD, Observability, More types of tests) 

IMHO there are other things we can do than just (add more coverage) like have a continuous CI/CD pipeline working which will increase ownership and by having the code being potentially deployed at any time(Readiness) you increase the health of the codebase by saying you need to keep the build and test passing all times. The issue with Release Trains or Release calendars is often there are components you are not deploying and people end up no caring and creating a state of build failures and tests that do not pass. With CI/CD there is no such thing. No having CI/CD means you will afford much more waste which is bad. 

Observability and the ability to understand what's going on is also a huge improvement and observability is also a form of testing. So it's another dimension that can be explored. Finally, I would say you can look for having more test diversity like Mutation Testing, Property-Based Testing, Snapshot Testing, Chaos Engineering & Stress Testing. These other forms of testing allow you to do more with less and also uncover issues you might not catch with regular unit/integration tests. 

Hardening Production the whole point 

Finally, I would say it does not matter if works in your machine. The whole point is to work in production. Working in production means, testing in production, because able to deploy software there and test with real traffic and real production hardware without impacting the user experience, so we need to have isolation and automation mechanisms in prod in order to deal with the then. We need to understand that production is a shared responsibility and everyone should be holding accountable in regards to production. We want to harden production because is where the value is and where we deliver value to customers. The best place to be improved is the production. 

Cheers,

Diego Pacheco

Productive Disagreement

Productive Disagreement

Admin aaWednesday, August 5, 2020

Building products(software) is hard. There are so many things that can go wrong. At Scale, everything becomes more laborious. More people, more coordination needed, more things that can go wrong and more pieces and more dependencies. To scale, we create team structure and software, often in the form of SOA Services. Any architecture or Design should survive a set of hard questions; otherwise, the idea or solution might not be good enough. Having people thinking into different dimensions, with varying points of view and various schools of touch, would create disagreement with could be an excellent and healthy thing. However, not always thats is the case.

When is Disagreement not Healthy? 

I would say that disagreement is not healthy if create one or several of the following side-effects:

• Affects team morale(mature team) by not empowering that team
• Prevent progress by power from Comand Control Structure
• It's not logical or rational, and It is just a decision based on fear or emotion.  
• Becomes a Power dispute(it will proceed via John or Petter way?)
• Promotes a toxical environment with lots of politics

Some companies have toxic and un-secure cultures and environments. Often Top-down and old school. Steve Jobs once said, "There is no sense in hiring smart people and tell them what to do." IF you can't change the culture, you should consider leaving, at the end of the day it's what happens and is what people do. 

When is Disagreement Healthy?

First of all, To have a productive disagreement, you need to have a psychological safety environment. Wich requires mature people(a lot of them) and careful management. Not every company is like that, unfortunately. If you have that, the environment(be glad). Having that environment than disagreement become a valid tool to:

• Promote team ownership
• Cultivate a non-silos culture of collaboration
• Generating new ideas
• Hardening Solutions 

Ownership ends up promoted because people get into conflicts, and thats okay because of this is just ideas, it's not personal, and that makes the team grows. 

Non-Silos culture is promoted when you add other stakeholders from other teams to have that discussion and listen and participate equally. 

However, all of this is not possible if you don't have psychological safety at the company level. 

Generating new ideas is a super cool side-effect because you end up exposed to different points of view, and thats super constructive at the end of the day.

Hardening solutions is one of the best outcomes because collectively reviewing ideas, architectures, designs, and solutions is much cheaper than figuring out this issue in prod. 

I always believe in a Double-check mindset. Having Productive Disagreement is like having Doudle-check at the team or company level, which is super sweet and makes the whole team and the entire company to grow.

How to Enable Productive Disagreement?

There are many things you could do to promote a better culture and, therefore, a better working environment. Such as:

1. Get executive By In (Management)
2. Promote Psychological Safety
3. Replace Blame for Curiosity
4. Have regular 101s
5. Do regular retrospectives and clear out misunderstandings. 
6. Give and ask for Feedback.

Building a better culture is hard and takes time, commitment, vision, and continuous efforts, but it pays off in the long run. 

Cheers,

Diego Pacheco

Reflections on Hard Decisions: Avoiding Coupling, Denial and Dogma

Reflections on Hard Decisions: Avoiding Coupling, Denial and Dogma

Admin aaWednesday, June 3, 2020

Previously, I was blogging about two very HOT Button Issues (The Death of Microservices and Why Waterfall can be better than Agile(Sometimes). Today I want to expand and correlate these two topics a bit more. It's important to say again that I like agile, and I do it for +14 years. I have no problems talking about Agile issues. You shouldn't either. Hard questions sharpen our solutions. There is a huge difference between go trough a set of hard questions to justify investment harder than power or politics game to archive a result. The difference is one is healthy the other is not. There are "Healthy" matters like: Coupling, De-coupling, execution, Agile / Waterfall we should be able to navigate, talk, analyze trade offs without dogma or any issue whatsoever. However is hard to us to talk about some subjects right? What happens is that there is so much FEAR and TABOO on companies that some subjects cannot be ever on the table. Effective Learning means, we can talk about things, effective leaders allow it, they don't hide it. The only way to do proper due diligence and take hard choices is with taboo-free environment. The market / IT-Industry is not quite there yet. Getting back to the Agile. Why are we talking about not doing agile in 2020? Sound wrong right? 

Did you realize Agile has issues? 

In my previous posts, I was not taking hard on agile. However, I was talking trade offs with several explanations, and it bothers people. Why? We are in 2020, and we still cannot understand that Agile is not a Religion? Therefore, Agile can and has defects! In not saying is right or wrong, but some people do not believe in Good / Religion, and I get it, there are idiots everywhere doing the wrong things in all possible fields. Easily we can say that Agile is the ultimate Religion because it has much less criticize. 

Waterfall Execution VS Waterfall Contract

95-99% of all times, we want, and we should do Agile. However, there are 1-5% of cases where agile is worst. However, this is too abstract, and we need to make a difference between a couple of things. 

#1 Talking about Contracts: Waterfall contracts meaning (Fixed scope, price, and time) are bad for all parts we should never do, and I sincerely believe they are evil—bad Deal.

#2 There is a difference between Waterfall execution and waterfall contract. Ideally, you want to do incremental execution because there are so many benefits:

• Risk Reduction
• Ability to Change direction
• Reduce Waste

However, some problems do not have this Incremental nature or incremental benefits. There are some examples like Real State, Building a Boat, or making a Video game, for instance. A video game is a pretty waterfall because you need to say when the game will be released, and it needs to be lunch on that date, which got released one year ago or more. 

For a boat, there are no much increments you can do as well, either you have the whole ship or you don't, there is no incremental into production. I'm not saying we should not do Agile, We should, as much as we can, however, some problems are coupled by nature like Buildings, Boats or Games, and there is nothing much else we can do. 

Could we mitigate risks with Waterfall? YES. By doing:

• Discovery and UX Validation Work(Before we deliver)
• Good and Extensive Design work
• Planning and Estimates

You might be wonder, that are things agile fought for decades(Waterfall execution, BDUF, Analysis Paralysis, Documentation, and even Planning and Estimates and they are correct; most of the cases, you should not work this way. However, there are always different scenarios. 

Right, but what are the issues in Agile?

• Lack of Discovery/product focus and practices
• Agile was made for Teams, hard to scale to company level.
• Lack of Architecture (Scale and you will see the PAIN in your Spotify model)
• Poor DevOps and SRE practices and focus.
• Coordination is an issue - The same problem in microservices is push to blank spaces or upstream(like in your Spotify model). 

Don't get me wrong agile manifesto was around 2K year, so there was no:

• DevOps Movement
• No Really Digital Products
• No Cloud
• There was Architecture, but they ignored - Big Mistake

That's why MODERN AGILE was born pretty much. But again, some issues in "original agile" does not reflect all the things we need in 2020. Also, that's why in 2012, there was a rise in DTA(Dual Track Agile) and others multi-track agile forms because there are gaps. 

Different Reasons - Same Coupling

(A) Are you a Good Leader / Executive? If you SELL by delivering software on exact dates one year before you "announced" on an event, are you the right Sales Person, or is your Tech releasing on time doing the selling? What drives the adoption of your choices, our guessing skills? Do we need salespeople for Games? In software word sales is on death spiral for decades, it's not sales who sell, easily is Tech itself or marketing but not sales. 

(B) Do we have real coupling or induced coupling by years of technical debt not being paid? Sometimes the problem is a couple by it-self, but I would argue thats not the majority of cases. Tech debt is like poison, slowly kills your ability to:

1. Be productivity 
2. Reason about the Code
3. Deliver new Capabilities
4. Retain People
5. Re-shape your product/focus

(C) Natural Coupling - may be on a Building, GAME, or an in a Boat. However, there are some cases where both can be Incremental, therefore agile, and have value. For a boat, you might say let me give you the BOAT, and you decorate as you want, them we DE-COUPLE the problem in 2 boats as infrastructure and ship as decoration/customization. The first part will be a Waterfall, but the second can be more agile. The same could happen with a building. For TellTale (which bankrupt btw), you got games released by chapters every X weeks or Y months. They did this for TWD and Batman(Pretty good games BTW). However, you CANT do this for all games. You might argue DLC(Downloadable Contents) are ways to make the games more agile, accurate. However, the CORE of the game itself will be a pretty waterfall. My point is, increments are not always possible; you should be Agile and look for increments when they are real and potential. 

So, Should we always do a Waterfall? 

No. Agile should be the Default. But we should have no Dogmas about it. We should be able to see the weakness and do trade offs analysis all the time. IMHO Agile can work 95-99% of cases. Do I hate agile? No. I love it. I think it is a good thing and you should use it, don't be blind about it. 

Easily someone could argue, Buildings(Apartments, houses, bridges) and boats are not software, they are hardware. Hardware projects(In software - IoT, Infrastructure, Appliances) have similar properties; even when you have a software part, your execution will be Waterfall or part-agile only if you depend on hardware. There are gates, you can, and you should be as much agile as possible, but it's unlikely to have a company 100% agile. It's okay. Why we always need to be ALL THE THINGS, ALL THE TIME? 

Hard Decisions

My main issue with microservices is that people did not understand the principles and always want to eat the cake and have the cake. A similar problem happens with Agile and with discussions like: Should we Re-write or should we refactor. There is no One Size Fits all; there is no silver bullet; Decisions need to be tactical, case-by-case bases. 

There will be scenarios where re-write is BS(Netscape case); there will be scenarios where re-write is the sensible thing to do(Ramesh case). The hard decision is not to make easy and comfortable choices for you, but think trought options and trade offs and have a balanced and sensible choice. 

IMHO the right decision is also balanced between Business, Product, and Technology. If technology or business pays the price all the time is a wrong balance for sure. 

Cheers,

Diego Pacheco

Waterfall could be better than agile(sometimes)

Waterfall could be better than agile(sometimes)

Admin aaMonday, June 1, 2020

Sounds crazy, right? How could that possibly be the case? Before I continue, I need to say I',m doing agile for +14 years non-stop, and I sincerely believe Lean / Agile does good things. However, like everything in software, there are trade-offs. You might be thinking(Crazy Brazillian), and Agile is about incremental, fast feedback cycles, effective learning, and practical, tactical way to avoid waste and risk by shipping code to production often. How could that be bad, after all? To understand the hidden trade-offs here, we need to understand what is behind the principles of Agile. Hold on bozo; there is no such thing as assumptions behind principles. Recently I was challenging microservices. Today is Agile, tomorrow I don't know but something else might come up. To some degree, I feel agile needs to be challenged because last time I did it was around 2015. It's healthy to disagree if it helps to harden your decisions and as the whole team/company you take better decisions. My goal here is not to make a flamewar against Agile but say that we need to think all the time and understand there is no one size fits all even for things like Agile, Lean, DevOps, etc. So without further due let's get started. 

Agile Manifesto

The agile manifesto talks about the principles, not the process, not the methods. If you analyze the declaration, we could easily group the declaration in 2 groups of interest.  

https://agilemanifesto.org/

Assumptions behind the Principles

1. Are you going to change? Belives and Org-Structures? 
2. Incremental work as value (It's about coupling, Can you decouple?)

Before I elaborate more, let's define what I mean by Increment. The Increment is a piece of software, module, service, component. It does not matter. You chose to release the Increment by steps, let's say, every one, two, four weeks, or during two years on quarters release, it doesn't matter. 

#1 it's already a big issue. People in companies often don't want to change. Because they often want to do Empire building, and there is HIPPO dictating all product decisions. Agile will only work if you're going to change your beliefs system and your organization charter. So basically should we change or surrender? I always think we should change and improve things, in other words never surrender but maybe some changes won't happen right now so why bother? Maybe save the energy to a future battle? 

#2 Here is the catch. Most of the time, incremental work makes sense; however, not always. Sometimes we are making work incremental just for the sake of having the work incremental not because we are getting benefits from it. Quickly, we could architect things both in Business/Product and Tech the wrong way, which would explain why breaking into increments is a wrong move. So let's understand the properties of proper Increments: 

• Real incremental benefit(value on each increment release) 
• Ability to discard future increments(some increments might be optional)
• Ability to change future increments direction

So not all increments are created equally so that a Bad increase would look like this:

• There is no real benefit on each Increment (only when you have all things there, it can be used or will have value). 
• Therefore there is high coupling on the product/system. 
• No ability to drop anything or change direction. 

Agile works better with loosely coupling.

Most of the time, we can architect products and software in a way that can have benefits working on incremental ways. For those cases, which I believe is the majority of cases, there is a massive benefit by doing Agile. 

It's possible that some companies/people don't have enough talent and expertise in the house or don't want to let them HIPPO go away. Therefore they can do proper agile, but don't be mistaken. It's often very possible to break problems into small increments and have benefits but not always. Agile works best with loosely coupling. If you can decouple your business problems and use them independently, there is tremendous value there. 

Waterfall works better with coupling

Such problems like building a boat, it's very waterfall by nature. These are problems or systems where the coupling is so high that either you do it or you don't. There is no middle ground, and there is no adaptation. You won't see proper increments benefits here, so breaking problems in increments is fake. How can you be agile in those cases? When you could make a waterfall discovery / UX / Software Design before the project and experiment and have feedback before you build. Once you decide to build or start building, there is no turning back. Either you get the whole thing done, or there is nothing done. For these cases, you could either be fast or be slow, but at the end of the day, you need to have all or nothing. By nature, we are talking about high coupling which could be manifested by a series of lack and caused-by like:

Business Debt

1. Lack: Lack of exploring other markets/options
2. Caused-by: High Tech debt witch killed flexibility over many years(forcing migrations now).

Nature of the problem / Tech Debt

1. Lack: High Coupling. Lack of Module product/problem proper increments. 
2. Caused-by: Historical bad Decisions or Natural coupling. 

For that case, the waterfall will be better because agile would be fake anyway. Because making incremental software just for the sake of making incremental software without real benefits is like taking agile as a silver bullet with no drawbacks. I',m not saying Agile is terrible; I' m saying there is a small number of cases where it is better to be waterfall for more crazy as it sounds. When I say waterfall will be better in some cases and it seems complete non-sense might make me think we see Agile as religion and therefore agile is perfect, and there are no drawbacks, no side effects, no issues just good things, it's no true. Agile is excellent, you do it, but we should think because not all problems are the same. Agile, Lean it does not matter; we should be suspicious if something doesn't have issues. Denying could quickly making us bling and definitely would be bad for us in the long term. 

Cheers,

Diego Pacheco