The following principles of Agile development makes it look like Agile is mostly suited for services companies:

  • Customer satisfaction by rapid delivery of useful software
  • Welcome changing requirements, even late in development
  • Working software is delivered frequently (weeks rather than months)
  • Working closely with the client. Often this involves a client representative to be a part of the development team.
  • Face-to-face conversation is the best form of communication (co-location)

My question is: Is Agile exclusively suited for service oriented companies or do even product development companies (including web based companies) benefit from Agile techniques?

closed as primarily opinion-based by dan_waterworth, gnat, user40980, Dan Pichelman, World Engineer Jul 22 '13 at 22:11

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Agile works everywhere. The only place Agile does not work is mission critical code (military, nuclear, flight, etc) – Raynos Jan 14 '12 at 11:34
  • 4
    @Raynos There's no reason why Agile methods can not be used in mission critical code. However, when you start having dependencies on hardware for final system and integration tests, it becomes a bottleneck that prevents or limits what can be done on an iteration. However, when working in a purely software environment (including software simulations of hardware/systems), Agile can be applied. – Thomas Owens Jan 14 '12 at 11:45
  • @ThomasOwens I think it's more a limitation of the government safety rules and procedures you have to comply that get in the way of agile. But that might be country specific – Raynos Jan 14 '12 at 11:49
  • 3
    @Raynos I've worked in the defense industry, including on a Scrum team for the US Air Force. It gets pretty strict with procedures, but we didn't encounter any bottlenecks or issues until we had to move from building software (both production and system simulation tools) to integrating with a system that contained hardware components, at which point we had to adjust the methodology. – Thomas Owens Jan 14 '12 at 11:53
  • 1
    In some domains, changing a requirement or an interface becomes a very expensive proposition because you are working with outside companies, standards, and other things. Agile is a piece of cake if you control the whole project and all the sw/hw it interacts with. When you have to interface with other sw/hw, it becomes very expensive to iterate on your interface. Agile can be used, but not for the component to component interfaces (unless you like paying contract adjustment fees). – anon Jan 14 '12 at 21:58

Agile (and any iterative) method is even more helpful for product development companies as opposed to service industry.

In one of my first assignment in a product development start-up, we went with the management a very detailed (including fine print) scope and my boss threw out most of it and trimmed down the requirement to almost all bare basic; the product won't have any gizmo's not even bells and whistles.

After the conclusion the crux is need to experiment with the market, as he said

... look, we are not a services company. Many typical service contracts (he gave examples of companies) starts out with unnecessary stuff; later on when people realize gaps, it's essentially more money to the services company. In a product development, we cann't afford to waste resources like that.

he continued ...

... when you build a product, you really have to go out and experiment with the market to understand what is really needed, that's when you go and build this (extra) things on top of the core product.

So from the product development point of view any methodology that begins with focus on minimum and essential requirements first is most important. Agile fits in perfect.

Second, there is another key things that product development companies face far more fiercely, time to market.

While you are developing, invariably, you will realize that some competitor will pop-up, and you do tend to either try to minimize scope as much as possible to get to market fast, or you may learn that need of the market needs to adapt.

Agile is even more important for product development environment than services companies.

One Caveat:
May be one place where i can think of Agile being misfit is where there is quite a bit of research work involved. Even research based work requires planning for individual task; however, suddenly one realizes some huge problems or a fresh new idea arrives, and the planning goes for a toss. Probably here, any structured approach finds somewhat limitation. Any one has tried Agile in research oriented work?

  • not sure I agree that product companies are more effected by time to market, the rest is sound though – jk. Jan 17 '12 at 8:24

Agile traces its origins to the Toyota Production System, which eventually influenced the entire auto manufacturing industry, which in turn influenced the entire manufacturing industry.

Software engineering is product design. Our code is the equivalent of the tool & die design and industrial process design required to manufacture physical products. Compilers are the workers.


Define who you believe your customers to be. Are they the people who buy your company's products, are they the people within your company who might use and test your code, or are they perhaps both? When you write your code and submit it for testing, do you complete the entire product first, or do you deliver it in stages to be tested and signed off?

Whether Agile works in any company all comes down to the mind-set of the the people working with it, how the team thinks about it, and how committed they are towards making an Agile methodology work for them.

Ultimately, Agile is suited to the team that wants to make it work for them, and yes this means it can be successfully implemented in even some of the more "scary" development situations provided the methodology is adapted to suit. It doesn't matter if you feel your company is service or product focused.

The thing to remember is that going Agile isn't about copying someone else's methodology verbatim, which would be fine if the methodology can gel with your particular company's needs. In the end, when changing the way you go about writing software, something has to give. It's about achieving a compromise between your vision of an agile workflow, and the existing business processes that may need to be modified to accommodate agile processes. This is not something you can easily change overnight, but which changes gradually, and in stages as you fine tune both the agile and business process so that they will gel well with each other. It may also require a shift in your thinking, so that you apply all of the agile concepts that your developers need, and ignore the ones that might create problems for your team, and your "agile customer" becomes a "customer representative" within the company who takes responsibility for being the product champion, acting as the customer's "voice" in the team just to keep everyone firmly grounded.

In the company where I work, we probably only do about half of the things that all of the standard methodologies recommend we should do, and for the rest, we've fine-tuned things to suit ourselves. Whenever we run into something that is inefficient, we implement changes to the method to deal with problem. This can happen from project to project on rare occasions, depending on who we are working with, and who we end up working for. So in the end, how you specifically go about implementing agile in your workplace is really down to you to ultimately decide. The key to it all is to simply keep an open mind, and to regularly re-evaluate your team's performance, removing practices that make things worse, and introducing the practices that make things better.

Good luck.


Customer satisfaction by rapid delivery of useful software product

Welcome changing product or engineering requirements, even late in development

Working software product is delivered frequently earlier (weeks rather than months) and product cycle time is reduced.

Working closely with the client product owner. Often this involves a client representative the product owner to be a part of the development team.

Face-to-face conversation is the best form of communication (co-location)

In short, how can Agile not apply to product development?

  • Actually agile is derived from product development practices, so it is rather the other way around: agile started as an attempt to adapt product development practices to software development. – Giorgio Jul 20 '13 at 10:01

One previous employer used both agile and delivered "shrinkwrap software". Some of the products have been shipped annually for 2 decades. Sprints were generally 2 weeks long, and pair programming was common, especially when deadlines were tight.

Welcome changing requirements, even late in development

Some of their products were used by customers to fill out government forms. Generally, the IRS has annual forms updated by the October/November time-frame for things that need to be filed in January (and April). Some years, Congress spends too much time goofing off to get the tax law changes done in time, so there have been a few years where forms that have a filing date of Jan 31 (such as W-2) are not finished by the IRS before Jan 15.

The goal was to have several scheduled releases during a year, but there were some years when we had a lot of updates due to changing regulations (and bug fixes).

Not the answer you're looking for? Browse other questions tagged or ask your own question.