10 ms·

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently that the amount of time the customer has, and clarity about the problem they want solved is orders of magnitude more ambiguous than is required to actually build and deliver something to their satisfaction. In my opinion successful products, and I mean ones with significant flywheels with customers and viral growth and stickiness are with few exceptions - accidents. It was someone who had an interesting thought and a lot of people for whom the product was good enough for their desire that they often didn't even know they had You can't write down how to do that, it's like asking a nobel prize winner how they came up with their discovery. It's not repeatable. Some people have better intuitions than others and these are the people who are repeatably successful with products. But it doesn't generalize. That said, the fundamental problem isn't wrong in theory, it's just naiive in practice.

catmanjan 5y ago
I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close
- pjmlp 5y ago
  That is the theory, except on the customer side you actually need the people that will use the product. Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be. So the same mismatch is bound to happen anyway. And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause being negative isn't good) and then completely find it unusable on final delivery. Agile misses that many engineering teams lack people skills to actually navigate and avoid these scenarios. EDIT: several typos
  - Clewza313 5y ago
    This is (IMHO) the biggest single miss in most attempts to be "Agile". The customer/end user is supposed to be embedded in the team, doing actual work with the program, raw and hacky as it may be. This way the feedback is immediate and accurate. Passively watching smoke and mirror demos once every sprint is a far cry from this. Of course, this isn't applicable/possible for all types of software (you can't really iterate your way to an MVP nuclear reactor) but there's less of this than you'd think.
    - nicoburns 5y ago
      One key part of this that a lot of businesses miss is that this means that every member of the team shoul have direct contact with thw customer, not just a "point of contact"
      - pjmlp 5y ago
        Because that isn't something their management levels will even consider a possibility, given security concerns, politics, and whatever might come up if the project goes south and a lawsuit is bound to happen. These agile ideas only work in an ideal world of "we are all friends here".
        nicoburns 5y ago
        I'm sure this is true of some companies, but I've definitely seen this done well in a few places. Often software agencies.
      - 2sk21 5y ago
        This is a good point. However in practice we wind up with a number of gatekeepers between the developer and the actual users. These gatekeepers are both on the customer side and the developer side. For example on the developer side, sales people typically do not like being disintermediated since it reduces their relevance. On the customer side, managers often do not want outside developers bothering their workers.
- tarsinge 5y ago
  We kind of successfully to that in my shop, the early stage product usually being graphic mock-ups (wireframes may not be enough when the client really lacks product vision) to iterate fast.
- AndrewKemendo 5y ago
  And in the process you have burned out the client who hired you so that they didn't have to make decisions. "I thought this was your job" is something I've heard a few times from clients when we have sent over wire frames or beta applications.
dirkt 5y ago
> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over responding to change Because that's what makes middle management happy. So this perversion of "Agile", which is actually the opposite of Agile, is the FUNDAMENTAL problem.
- baxtr 5y ago
  It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.
  - outsomnia 5y ago
    You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.
    - watwut 5y ago
      But agile project get effed where management is not messing into internal process too. Developers make agile into hell too.
    - brtkdotse 5y ago
      You can also flip that around. As much as devs try to disagree, technology is not a goal in of itself. Management is an abstraction on top of money in/money out and if in<out it doesn’t matter if you have the crispest tech, you’re going out of business.
      - yobbo 5y ago
        > As much as devs try to disagree, technology is not a goal in of itself Can you find one dev that has ever disagreed with this?
RandomLensman 5y ago
The vast majority of software is not for flywheel type situations. For internal customers or in B2B settings getting the actual users and outcome owners involved early is vital - but they are often poorly incentivized to get into the action as there are layers of business mangers etc in place that are supposed to stand in (but lack the detailed knowledge).
mytailorisrich 5y ago
"Customers don't know what they want": this is something Agile specifically tries to address by releasing often and adapting to change. This is a quick feedback loop: the customer can quickly see a product and the development can quickly adapt. What was the 'standard' way to develop systems when the Agile Manifesto was written: the same as for building a bridge. You gather and freeze requirements. You write a massive plan and plenty of specs. You code accordingly. You deliver. Time to working software is long and a lot of the effort that goes into specs is wasted, especially for design specs.
- eesmith 5y ago
  Your characterization is not true. The reality was quite the opposite. Here's the introduction of Steve McConnell's "Rapid Development" from 1994 - well before the Agile Manifesto! - Chapter 1, page 1: > The product manager told me he wanted to build a product right for a change. He wanted to pay attention to quality, prevent feature creep, control the schedule, and have a predictable ship date. > When the time came to actually do the project, it became clear tha getting the product to market quickly was the only real priority. Usability? We don't have time. Performance? It can wait. Maintainability? Next project. Testing? Our users want the product now. Just get it out the door. > This particular product manager wasn't the manager on just one product. He could have been almost any product manager I've worked for. This pattern is repeated day after day, state by state, all across the country. ... This is as far from building a bridge as you can get. The next page of the book starts: > [1.1] What is Rapid Development? > To some people, rapid development consists of the application of a single pet tool or method. To the hacker, rapid development is coding for 36 hours at a stretch. To the information engineer, it's RAD - a combination of CASE tools, intensive user involvement, and tight timeboxes. To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi. To the manager desperate to shorten a schedule, it's whatever practice was highlighted in the most recent issue of Business Week. Agile drew from earlier methods ("intensive user involvement", "rapid prototyping") which were pretty common even before Agile.
  - mytailorisrich 5y ago
    The 'standard' method is the waterfall model, which proceeds like you would for a bridge (of course this is just an approximate analogy) from specs, to architecture, detailed specs, implementation, and tests. Of course the shortcomings of this model have been known for a long time to anyone building software and so a number of other models appeared.
mirekrusin 5y ago
I don't think agile was meant to take everything client says without critical thinking. Quite opposite actually, it encourages dialogue. Often developers know better how to solve certain problems. Early in my career somebody said something like "make sure you distinguish between <<what they (customers) want>> and <<what they need>>.". This thought stuck with me for years and in my opinion has been reposible for success I witnessed. It's important to unwrap "what they want" so you, as developer, can apply more first principle thinking to arrive at "what they need". BAs have tendency to project their own solutions, however when unwrapped so you see the problem that needs solving, you may arrive at solution that is simpler (like orders of magnitue is not that rare in my experience), reflects reality better, takes advantage of somehow hidden from BAs PoV system internals etc. Agile enouraged dialogue is the platform where those ideas can surface.
fsloth 5y ago
I disagree mildly all succesfull products are pure accidents. Especially in B2B and technical realm it is feasible to actually plan in every sense of the word "plan" a new product - business, tech, etc. Of course the plan must be malleable on the facts on ground. And probably is incorrect on a few places. But never the less, a plan that will get a business from place a (no product, but strong understanding of customer needs and business plus strong technical savvy) to place b (final product, customers, revenue etc). I've seen this many times, both in startups with a new product and new customers (automotive software) and established companies that just expand their existing portfolio (cad software). I'd say the "not an accident" is feasible if these facts are in place: - enough A-team players (tech,business,sales) - healthy culture (that facilitates long term growth and can focus on the product without too much politics) - understanding of customer business - identified an OBVIOUS need for the customer - strong engineering org (can be just a few coders that get things done or larger) So I agree, you can't train for these requirements like you can train airplane pilots. But I do claim you can have enough understanding that is the current org in possession of these qualities. And if it is, it's a very reasonable risky investment to try to create a product for the need.
rlonn 5y ago
You’re right that customers don’t know what they want and that can make it a bad idea to include them in the dev process directly. But is that what Agile is about? I thought it was about iterative development. As a long time product dev I know that you want to follow your own vision when building your product. You let your vision be influenced by customer feedback for sure, but you should always second guess the feedback, never take it at face value, never just build something because a customer asks for it - that would be Henry Ford trying to breed faster horses.
- lugged 5y ago
  It's probably better to phrase it being a development method that focuses on a tight feedback loop with all stakeholders. You push decisions as far out as possible and gather feedback from individuals every step of the way. This is what allows the greatest amount of flexibility. The biggest problem with agile is that it assumes all problems can be put off to the last minute. I'm frequently finding myself in situations where it is 100x better to hammock program it out for a few weeks before pushing any code. Those systems last ten years. Those systems are able to be modified simply and quickly when business needs change. Those systems do build up legacy code, but it's at a slower rate than other systems. Those systems have fewer hacks over time and fewer bugs as a result. This isn't a dig at agile, it's a dig at using agile as a design process, for which it is utterly inept. Agile is great at pushing products, terrible at pushing thoughtful system design. (On average, sometimes working a problem works too but more often than not you don't get the chance to redo middle sprint 5.)
grecy 5y ago
> The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want I don't disagree, though I firmly believe Agile does a much better job of dealing with the problem you state than any other software development methodology that has been attempted before. Is it perfect? of course not. As a methodology, is it better for building software than methodologies that have been used to build enormous physical structures for generations? Undoubtedly yes. As far as I'm aware, there currently isn't anything better for building complex software with changing requirements (i.e. the real world).
throw2500 5y ago
Isn't Agile more or less gradient descent (well, approximating the gradient for an undifferentiable function), applied to software development? The objective function is some function of the quality of the product, as measured by the customer, and the work put in. The gradient evaluation is then the process of determining which feature gives the most bang for the buck, implementing it, and repeating. But gradient descent has problems with local minima. So if that's what Agile is, no surprise it doesn't do surprising projects - even if the customer does know what they want. If the programmers are too inexperienced and it's not just a CRUD, then you'll end up with something like Jeffries' TDD Sudoku solver.
- dragonwriter 5y ago
  > Isn’t Agile more or less gradient descent (well, approximating the gradient for an undifferentiable function), applied to software development? Lean is. Agile is “It would be nice to do what works for your team in your particular challenges, not some pre-packaged one-size-fits-all processes sold by consultants. Now, here’s a bunch of pre-packaged one-size-fits-all processes, and an army of consultants selling them.”
austincheney 5y ago
> The customer doesn't know what they want If that were true the customer never drop you for the competition. The customer will drop you in a heartbeat. The customer cannot express what they want in a language you can articulate which is something amazingly different. As a product manager you need to account for that.
Robin_Message 5y ago
I'm not sure if Agile ever claimed to be a good process for coming up with unicorn startups though. It's a way to meeting actual business software needs, much more suited to custom development for one customer than product development, which necessarily requires some additional insight into what the market wants.
ako 5y ago
Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go. Agile tries to turn software development into a product design process rather than a product manufacturing process. Together with the client, iteratively you try to find the right solution and design for the customer problem. By being easy to adopt, software lends itself to an iterative design process, where you adopt it multiple times based on the iterative feedback of the customer. But this means that at the end of the design process, you can skip the manufacturing part, as you've already built the software during design. Alternatively you could argue that this is too expensive, inefficient and slow, and you need some design before you begin to manufacture software. Modeling tools could help here, e.g, low code tooling like CAD tools in fysical product design.
- felipellrocha 5y ago
  > Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go. Oh, man. I think you hit the head of the nail. One succinct phrase that describes the entire problem.
  - CRConrad 5y ago
    Two, actually. :-) (And I think for completeness' sake the next two need to be included too.)
xg15 5y ago
So then, what do you advise to do? Give up?
- AndrewKemendo 5y ago
  Develop product engineers to be better. Have empathy and communicate with the target customer more clearly and understand the landscape better. That's pretty much all you can do. How you organize it only matters insofar as it makes your team effective - sprints, waterfall, XP whatever... is kind of a toss up and context dependent.
Aeolun 5y ago
> Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. The only thing that is less likely to have the building team and customer come to the same conclusion is to add many more layers in between. I’ve seen where that ends. It’s not a good place.

catmanjan 5y ago

I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close

pjmlp 5y ago
That is the theory, except on the customer side you actually need the people that will use the product. Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be. So the same mismatch is bound to happen anyway. And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause being negative isn't good) and then completely find it unusable on final delivery. Agile misses that many engineering teams lack people skills to actually navigate and avoid these scenarios. EDIT: several typos
- Clewza313 5y ago
  This is (IMHO) the biggest single miss in most attempts to be "Agile". The customer/end user is supposed to be embedded in the team, doing actual work with the program, raw and hacky as it may be. This way the feedback is immediate and accurate. Passively watching smoke and mirror demos once every sprint is a far cry from this. Of course, this isn't applicable/possible for all types of software (you can't really iterate your way to an MVP nuclear reactor) but there's less of this than you'd think.
  - nicoburns 5y ago
    One key part of this that a lot of businesses miss is that this means that every member of the team shoul have direct contact with thw customer, not just a "point of contact"
    - pjmlp 5y ago
      Because that isn't something their management levels will even consider a possibility, given security concerns, politics, and whatever might come up if the project goes south and a lawsuit is bound to happen. These agile ideas only work in an ideal world of "we are all friends here".
      - nicoburns 5y ago
        I'm sure this is true of some companies, but I've definitely seen this done well in a few places. Often software agencies.
    - 2sk21 5y ago
      This is a good point. However in practice we wind up with a number of gatekeepers between the developer and the actual users. These gatekeepers are both on the customer side and the developer side. For example on the developer side, sales people typically do not like being disintermediated since it reduces their relevance. On the customer side, managers often do not want outside developers bothering their workers.
tarsinge 5y ago
We kind of successfully to that in my shop, the early stage product usually being graphic mock-ups (wireframes may not be enough when the client really lacks product vision) to iterate fast.
AndrewKemendo 5y ago
And in the process you have burned out the client who hired you so that they didn't have to make decisions. "I thought this was your job" is something I've heard a few times from clients when we have sent over wire frames or beta applications.

dirkt 5y ago

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over responding to change Because that's what makes middle management happy. So this perversion of "Agile", which is actually the opposite of Agile, is the FUNDAMENTAL problem.

baxtr 5y ago
It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.
- outsomnia 5y ago
  You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.
  - watwut 5y ago
    But agile project get effed where management is not messing into internal process too. Developers make agile into hell too.
  - brtkdotse 5y ago
    You can also flip that around. As much as devs try to disagree, technology is not a goal in of itself. Management is an abstraction on top of money in/money out and if in<out it doesn’t matter if you have the crispest tech, you’re going out of business.
    - yobbo 5y ago
      > As much as devs try to disagree, technology is not a goal in of itself Can you find one dev that has ever disagreed with this?

RandomLensman 5y ago

The vast majority of software is not for flywheel type situations. For internal customers or in B2B settings getting the actual users and outcome owners involved early is vital - but they are often poorly incentivized to get into the action as there are layers of business mangers etc in place that are supposed to stand in (but lack the detailed knowledge).

mytailorisrich 5y ago

"Customers don't know what they want": this is something Agile specifically tries to address by releasing often and adapting to change. This is a quick feedback loop: the customer can quickly see a product and the development can quickly adapt. What was the 'standard' way to develop systems when the Agile Manifesto was written: the same as for building a bridge. You gather and freeze requirements. You write a massive plan and plenty of specs. You code accordingly. You deliver. Time to working software is long and a lot of the effort that goes into specs is wasted, especially for design specs.

eesmith 5y ago
Your characterization is not true. The reality was quite the opposite. Here's the introduction of Steve McConnell's "Rapid Development" from 1994 - well before the Agile Manifesto! - Chapter 1, page 1: > The product manager told me he wanted to build a product right for a change. He wanted to pay attention to quality, prevent feature creep, control the schedule, and have a predictable ship date. > When the time came to actually do the project, it became clear tha getting the product to market quickly was the only real priority. Usability? We don't have time. Performance? It can wait. Maintainability? Next project. Testing? Our users want the product now. Just get it out the door. > This particular product manager wasn't the manager on just one product. He could have been almost any product manager I've worked for. This pattern is repeated day after day, state by state, all across the country. ... This is as far from building a bridge as you can get. The next page of the book starts: > [1.1] What is Rapid Development? > To some people, rapid development consists of the application of a single pet tool or method. To the hacker, rapid development is coding for 36 hours at a stretch. To the information engineer, it's RAD - a combination of CASE tools, intensive user involvement, and tight timeboxes. To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi. To the manager desperate to shorten a schedule, it's whatever practice was highlighted in the most recent issue of Business Week. Agile drew from earlier methods ("intensive user involvement", "rapid prototyping") which were pretty common even before Agile.
- mytailorisrich 5y ago
  The 'standard' method is the waterfall model, which proceeds like you would for a bridge (of course this is just an approximate analogy) from specs, to architecture, detailed specs, implementation, and tests. Of course the shortcomings of this model have been known for a long time to anyone building software and so a number of other models appeared.

mirekrusin 5y ago

I don't think agile was meant to take everything client says without critical thinking. Quite opposite actually, it encourages dialogue. Often developers know better how to solve certain problems. Early in my career somebody said something like "make sure you distinguish between <<what they (customers) want>> and <<what they need>>.". This thought stuck with me for years and in my opinion has been reposible for success I witnessed. It's important to unwrap "what they want" so you, as developer, can apply more first principle thinking to arrive at "what they need". BAs have tendency to project their own solutions, however when unwrapped so you see the problem that needs solving, you may arrive at solution that is simpler (like orders of magnitue is not that rare in my experience), reflects reality better, takes advantage of somehow hidden from BAs PoV system internals etc. Agile enouraged dialogue is the platform where those ideas can surface.

fsloth 5y ago

I disagree mildly all succesfull products are pure accidents. Especially in B2B and technical realm it is feasible to actually plan in every sense of the word "plan" a new product - business, tech, etc. Of course the plan must be malleable on the facts on ground. And probably is incorrect on a few places. But never the less, a plan that will get a business from place a (no product, but strong understanding of customer needs and business plus strong technical savvy) to place b (final product, customers, revenue etc). I've seen this many times, both in startups with a new product and new customers (automotive software) and established companies that just expand their existing portfolio (cad software). I'd say the "not an accident" is feasible if these facts are in place: - enough A-team players (tech,business,sales) - healthy culture (that facilitates long term growth and can focus on the product without too much politics) - understanding of customer business - identified an OBVIOUS need for the customer - strong engineering org (can be just a few coders that get things done or larger) So I agree, you can't train for these requirements like you can train airplane pilots. But I do claim you can have enough understanding that is the current org in possession of these qualities. And if it is, it's a very reasonable risky investment to try to create a product for the need.

rlonn 5y ago

You’re right that customers don’t know what they want and that can make it a bad idea to include them in the dev process directly. But is that what Agile is about? I thought it was about iterative development. As a long time product dev I know that you want to follow your own vision when building your product. You let your vision be influenced by customer feedback for sure, but you should always second guess the feedback, never take it at face value, never just build something because a customer asks for it - that would be Henry Ford trying to breed faster horses.

lugged 5y ago
It's probably better to phrase it being a development method that focuses on a tight feedback loop with all stakeholders. You push decisions as far out as possible and gather feedback from individuals every step of the way. This is what allows the greatest amount of flexibility. The biggest problem with agile is that it assumes all problems can be put off to the last minute. I'm frequently finding myself in situations where it is 100x better to hammock program it out for a few weeks before pushing any code. Those systems last ten years. Those systems are able to be modified simply and quickly when business needs change. Those systems do build up legacy code, but it's at a slower rate than other systems. Those systems have fewer hacks over time and fewer bugs as a result. This isn't a dig at agile, it's a dig at using agile as a design process, for which it is utterly inept. Agile is great at pushing products, terrible at pushing thoughtful system design. (On average, sometimes working a problem works too but more often than not you don't get the chance to redo middle sprint 5.)

grecy 5y ago

> The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want I don't disagree, though I firmly believe Agile does a much better job of dealing with the problem you state than any other software development methodology that has been attempted before. Is it perfect? of course not. As a methodology, is it better for building software than methodologies that have been used to build enormous physical structures for generations? Undoubtedly yes. As far as I'm aware, there currently isn't anything better for building complex software with changing requirements (i.e. the real world).

throw2500 5y ago

Isn't Agile more or less gradient descent (well, approximating the gradient for an undifferentiable function), applied to software development? The objective function is some function of the quality of the product, as measured by the customer, and the work put in. The gradient evaluation is then the process of determining which feature gives the most bang for the buck, implementing it, and repeating. But gradient descent has problems with local minima. So if that's what Agile is, no surprise it doesn't do surprising projects - even if the customer does know what they want. If the programmers are too inexperienced and it's not just a CRUD, then you'll end up with something like Jeffries' TDD Sudoku solver.

dragonwriter 5y ago
> Isn’t Agile more or less gradient descent (well, approximating the gradient for an undifferentiable function), applied to software development? Lean is. Agile is “It would be nice to do what works for your team in your particular challenges, not some pre-packaged one-size-fits-all processes sold by consultants. Now, here’s a bunch of pre-packaged one-size-fits-all processes, and an army of consultants selling them.”

austincheney 5y ago

> The customer doesn't know what they want If that were true the customer never drop you for the competition. The customer will drop you in a heartbeat. The customer cannot express what they want in a language you can articulate which is something amazingly different. As a product manager you need to account for that.

Robin_Message 5y ago

I'm not sure if Agile ever claimed to be a good process for coming up with unicorn startups though. It's a way to meeting actual business software needs, much more suited to custom development for one customer than product development, which necessarily requires some additional insight into what the market wants.

ako 5y ago

Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go. Agile tries to turn software development into a product design process rather than a product manufacturing process. Together with the client, iteratively you try to find the right solution and design for the customer problem. By being easy to adopt, software lends itself to an iterative design process, where you adopt it multiple times based on the iterative feedback of the customer. But this means that at the end of the design process, you can skip the manufacturing part, as you've already built the software during design. Alternatively you could argue that this is too expensive, inefficient and slow, and you need some design before you begin to manufacture software. Modeling tools could help here, e.g, low code tooling like CAD tools in fysical product design.

felipellrocha 5y ago
> Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go. Oh, man. I think you hit the head of the nail. One succinct phrase that describes the entire problem.
- CRConrad 5y ago
  Two, actually. :-) (And I think for completeness' sake the next two need to be included too.)

xg15 5y ago

So then, what do you advise to do? Give up?

AndrewKemendo 5y ago
Develop product engineers to be better. Have empathy and communicate with the target customer more clearly and understand the landscape better. That's pretty much all you can do. How you organize it only matters insofar as it makes your team effective - sprints, waterfall, XP whatever... is kind of a toss up and context dependent.

Aeolun 5y ago

> Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. The only thing that is less likely to have the building team and customer come to the same conclusion is to add many more layers in between. I’ve seen where that ends. It’s not a good place.