7 ms·

Ignore this person's advice. It is objectively wrong. How would you build a rocket if you only thought about the next 2-4 weeks? How would you scope the size

Ignore this person's advice. It is objectively wrong. How would you build a rocket if you only thought about the next 2-4 weeks? How would you scope the size of any given project if you didn't think about it in totality? Successful development is always a balance of waterfall and sprints except maybe when you're in maintenance mode for long living legacy projects. Waterfall = strategy Sprint = tactics

Jtsummers 6y ago
Waterfall is shit, don't think waterfall. Better is to think about things like work breakdown structures paired with an iterative schedule (aka, sprints). Your WBS establishes the things that you know now, the things that can be done in parallel, and the things that depend on other actions. Your WBS also gives you a rough schedule (but do not take it as gospel because you aren't a prophet). Based on this, you can start prioritizing the work that goes into the iterations. Periodically (with each iteration or after several) you revisit the WBS and determine if what you're doing is keeping you on track, or if it's even still the right structure.
softwarefounder 6y ago
Yep - the hilarious thing is even the most Agile/Sprint heavy consulting companies usually have to succumb to some Waterfall concept in order to provide an estimate or meet a fixed bid.
- tchaffee 6y ago
  Because they aren't good at selling agile. Why do people ask for estimates or fixed bids? It's to manage risk. And how often do projects not go over estimated budget? Even fixed bids are poor at managing risk. Lots of consulting companies will walk away from a fixed bid contract after months of work at the point they realize they will lose money on it. And honestly, what's the quality of work once the contract is no longer profitable? We've all seen it. Everything is a quick hack at that point in a desperate effort to achieve the minimum that could be defensible in court. A fixed bid project means the consulting company and the client have opposing interests: the consulting company wants to get it done as cheaply as possible and will make every shortcut they can get away with. And the client wants every last bit of quality they can squeeze out of the contract for that price. No wonder it so often ends in dissatisfaction for both sides. What are the options for the client when the consultant says "sorry we didn't actually finish and we are out of money"? They either pay more or have to be willing to sue the consulting company. Most companies suck it up and pay more. This is so endemic to the industry that most companies put extra in the budget for software project overruns no matter how tight the fixed bid contract is. So one way to sell agile is to help clients understand how it can help manage risk better than a fixed bid contract or always inaccurate estimates. And how it can be used so that the interests of the consulting company and the client are better aligned.
  - satyrnein 6y ago
    I talked to a consulting company once that offered me a fixed price per sprint, with no commitments on how many sprints the project would take. I did not feel like our interests were any better aligned than in a fixed bid contract.
    - tchaffee 6y ago
      So one data point. Sounds like they didn't differentiate themselves well enough from the fixed bid contract. The great thing about fixed price per sprint is they have to impress you with progress every sprint or they risk losing the job. That's great at motivating them to deliver value to you every sprint. Another way your interests are aligned: you know how many sprints you want to pay for. That motivates you to prioritize the most important features so they are completed before you run out of budget and sprints. What a great way to manage risk.
      - davidivadavid 6y ago
        But lack of alignment is known to be an issue with both flat AND time-based fees. Charging per sprint is only superficially different from charging hourly/per day/per week/biweekly. Consultants will want the project to last as long as possible. Clients will want it to be over as fast as possible. You have to impress the client with every sprint? Just like a regular contractor must impress the client with every milestone. How do you know how many sprints you want to pay for? So you have a budget, just like any regular old project. You can prioritize features? But why wouldn't you do that without sprints? What am I missing?
        tchaffee 6y ago
        > But lack of alignment is known to be an issue with both flat AND time-based fees. Agreed. Agile only puts you in a more flexible relationship. It does not fix every alignment issue. For that you need to be more creative with the contract. However it does spread the risk more evenly. And by you as the client taking on more of the risk instead of pretending an estimate or contract erased it, you will do a better job of managing the risk. Every sprint you'll decide what must be built next. Every sprint you get the opportunity to change requirements. Both of those are far better ways of managing risk than fixed price contracts or estimates. > Charging per sprint is only superficially different from charging hourly/per day/per week/biweekly. Not if you are delivering a working product at the end of each sprint. And yes, milestones are somewhat similar to sprints. Except as a client you've now locked yourself into what gets built and if requirements change you've got to renegotiate the contract. > You can prioritize features? But why wouldn't you do that without sprints? Because your fixed price contract legally "guarantees" all the listed features will be included. > Clients will want it to be over as fast as possible. And you can have that if each sprint ends with a working product. Up to you when the product has enough features included that you are happy with it. Or that you are out of budget. And you've managed risk aligned with the consultant instead of getting an unrealistic estimate they won't meet, or having a to head to court with a broken contract.
jordache 6y ago
maybe this person is thinking of a scope similar to an elaborate to-do app? Many enterprise scale business centric applications have tremendously complex business rules and overreach. One can not simply make a casual decision last minute, and expect perfect execution, towards an end result of increased business value. EDIT: I see he is a Drupal consultant. There is a very explicit ceiling on the complexities of primarily CMS driven sites.
jrochkind1 6y ago
Would you use an 'agile' methodology to build a rocket at all? There some projects not suitable for an agile approach, especially if we're talking "projects" generally beyond software engineering, perhaps MOST aren't. "Agile" is software engineering advice. OP is advance for projects that an agile approach is suitable for. Ie, not building a rocket.
- jordache 6y ago
  many real world complex software is also not suitable for dogmatic application of agile/lean principles
- Jtsummers 6y ago
  Agile isn't, strictly, about software though it certainly is the predominant application. So first, let's separate two things: - building - designing Some parts of agile do apply to building. See Lean Manufacturing, parts of it are responses to maintain quality (Andons used to stop production) and parts are to change over the manufacturing floor to build something else (same plant can make many kinds of cars without a fixed production line for each, letting them meet demand). Other parts of agile, though, are aimed more at the design portion. Sprints, for instance, are meant to give you short iterations that let you frequently evaluate both your process and your product's success/failure. You can apply agile concepts to developing almost any kind of thing. Actual rocket scientists create simulations, scale models, full-scale models, prototypes and other things on their way to the final system. So they're already applying the same iterative approach that most agile proponents endorse. The question is, is the iteration deliberate or accidental? Or do they try to deny the iterations even exist? Once they get to building the rocket, that might be less agile depending on circumstances (is it the first one they've built? are they setting up a production line? is it a one off?).
  - bluGill 6y ago
    Note that when building cars flexibility is a trade off. You can switch car type, but the jigs for the car you are not currently making is still a cost, separate lines at near full capacity are a better use of resources. Only if you can forcast demand years in advance to build the factory to the right size. This is a hard problem. Note that flexible factories have other limits. Honda can't make a large truck in their factory as there isn't room. I don't know if Honda regrets this cost or not.
tchaffee 6y ago
Agile is the wrong model for building something that must fly or you die. The opposite of much of the software we build where a quick prototype in front of real users gives you far better information than any amount of internal brainstorming.
- thinkharderdev 6y ago
  This is a common sentiment but I don't think it's actually true. Users like software the works and is performant. Putting a quick prototype in front of users doesn't tell you anything beyond what the users think of the quick prototype. Did they have a bad impression because they ran into one of the many edge cases you didn't account for in the prototype? Or is it because the software is ill-conceived and not something they would like even if executed flawlessly. It's hard to tell. I think you run the risk of putting together a crappy prototype and then iterating your way into a local optimum that is still far inferior to what a properly engineered piece of software could be. Or it never gets that far because users hate the initial iteration because it doesn't work very well.
  - tchaffee 6y ago
    The vast majority of invented products - software or not - are complete market failures. No one wants to use them no matter how well engineered they are. When we talk about building an MVP (minimum viable product), the V part is very important. It does have to be useful. It does have to look great and work great. It does have to be performant. Edge cases should not get past your QA department. So with those constraints, about the only way you can get out a prototype in a sprint or few is by ruthlessly reducing scope until you get to the core part of your product that is adding value. That process in itself results in far better products. My goal (that I sometimes don't achieve) is that each sprint results in a product we can ship that is better than the last iteration. Run out of budget? Company priorities change? No problem. We still have a useful feature we can ship. Per my previous comment, this is the wrong process for plenty of products. You have to know what you are building and what the risks are, what the constraints are that you are optimizing for, and the pros and cons of different types of processes before deciding which process is the best fit. If you have a strong idea of what you are building ahead of time and you have experience building those types of things and you know there is already a market demand for those types of things, then by all means come up with a solid plan ahead of time and then execute it.
thinkharderdev 6y ago
Setting aside the specifics of particular agile methodologies like scrum, etc I think the core insight of the Agile manifesto is that building software products is fundamentally different than building things like rockets. When you are building a rocket you more or less know exactly what you want to build from the beginning so doing a detailed up-front design is definitely the right way to go. When building a software product (or really most software products, there are of course pieces of software that are well specified in advance) you don't know what the end state is or even if there is an end state. The information flow is bi-directional in the sense that observing how the software is used in the wild feeds back into how the software should be designed.
- gt565k 6y ago
  Ughhh, you do realize that there are software systems out there probably just as complex as rockets, as they are, well, used in rockets themselves to control the physical parameters. You do know what the end-state is. It's called the minimum viable product, MVP. The most successful product owners are ones who are technical and can bridge the gap between the business requirements and technical implementation. For example, there would be no SpaceX and vertical landing of rockets if it wasn't for Elon Musk, who is both an engineer, a businessman, and an entrepreneur. He gets the full picture and can talk to all divisions of the company with incredible competency. If you have a product owner who knows nothing about building software, in charge of a software product, you'll have a much smaller chance of succeeding, than if you had someone who was both business and technically savvy.
  - thinkharderdev 6y ago
    For what it's worth, I agree that the advice in the article is badly wrong. I'm just saying that building a rocket is fundamentally different than building a software product because a rocket is well-specified in advance. To you point, the MVP is different from the product as it will exist once fully realized. And the reason is because you don't know in advance how users will respond. You're not trying to satisfy the physics of rocket flight, but trying to please actual human beings who have weird and idiosyncratic preferences. So you build something (an MVP), let them use it and then incorporate their feedback into the next iteration. I'm with you in the sense that once you have a concrete MVP that you want to build, then you should approach building it as you would approach building a rocket. It's just that you may find that user didn't actually want a (proverbial) rocket, they wanted a helicopter.
iainmerrick 6y ago
How would you build a rocket if you only thought about the next 2-4 weeks? Okay, I’ll bite... I’ll grant you the 2-4 weeks part isn’t quite right for building a rocket; but the key insight of Agile, of developing in small steps and staying flexible, definitely applies. You do not start by designing the entire rocket before building anything. Your rocket won’t work. You start, you must start, by building a series of prototypes and exploring the design space. As you do that, you gradually refine your ideas of what’s possible and how to do it. As far as I know, every successful rocket design has followed that path. Sure, at some point along the path, you put together the blueprints for the final design. So there’s an element of waterfall in there. But staying agile is still critical. Unexpected stuff is sure to come up and you have to retain the flexibility to deal with it. As others have noted, software is somewhat special in that it’s cheaper and faster to build than physical stuff, can be copied and refactored much more easily, etc. And that shifts the agile-to-waterfall balance where you can realistically talk about working entirely from short term requirements.
- rubidium 6y ago
  Yes and that’s what almost everyone does. Learning loops with prototypes til you have a feasible product. But then you need a big development plan for how to scale it to a polished, sellable product. Because there’s a lot more to the product then the artifact.
  - lmm 6y ago
    > But then you need a big development plan for how to scale it to a polished, sellable product. Because there’s a lot more to the product then the artifact. That's a total non sequitur. Agile is all about building the sellable product. But doing it iteratively works a lot better than doing it via a big development plan.
    - rubidium 6y ago
      You’re getting downvoted because you may have missed my point. To clarify for your sake, once you have hardware in the loop (eg mechanical engineers designing things, manufacturing scaling for production) and a large commercial organization who needs to be ready for a product launch, you need a waterfall type plan. Agile principles (customer focus, respond to change) can apply, and you can break up the work into 2 weeks, but you do need to look past the next 2-4 weeks and know where things are planned. Commitments matter in the $millions. Software-only SAAS has the luxury of avoiding that complexity.
aphextron 6y ago
>How would you build a rocket if you only thought about the next 2-4 weeks? We're not building rockets. We're building business software. And the requirements for that are not a hardline set of rules laid out by the laws of physics. They are soft and fungible. Beholden to the whims of a product manager, designer, or client. Generally almost nothing is truly understood about the shape and function of the resulting software at the beginning of a development process. And sticking to a "plan" that was laid out before these things have actually been discovered is a recipe for disaster. Better to build in tiny, discrete chunks of usable MVP that can be used as a guidestone to the next desired level of functionality.
- rubidium 6y ago
  If you’re building business software then yes mostly. Change is cheap. If you’re actually building a rocket or any other physical thing with real world stuff (like some of us here) you need a real plan. The fits software engineers get into about agile is odd at times. I don’t really get it.
- talaketu 6y ago
  Business software projects can have very clear requirements known months in advance. Eg a project to ensure we comply with newly legislated tax regime. Yes, details will be discovered as the regulations are released, but to embark on that project with a 2-4 week planning horizon would be malpractice. "plans are useless, but planning is indispensible".
- pjmlp 6y ago
  Except that we mostly are, unfortunately getting penalised for faulty deliveries still isn't as hard as it should be. Also not every department is agile and wants those 6 months delivery plan.
maerF0x0 6y ago
its called "Manifesto for Agile Software Development" Only software is in scope
projektfu 6y ago
Rockets were an iterative process of gradual and revolutionary improvements that made engines you would actually be willing to put a person or nuclear warhead on top of. Remember that the “build” phase of software is relatively instantaneous. The design phase is the only part anyone sees anymore. (The heroes who wove the Apollo ROM were examples of actual program builders). Making the Saturn V static test rocket was heavily design work slowed by manufacturing. Making Apollo 11 was a process of knowing mostly what was needed and building it from start to finish.

Jtsummers 6y ago

Waterfall is shit, don't think waterfall. Better is to think about things like work breakdown structures paired with an iterative schedule (aka, sprints). Your WBS establishes the things that you know now, the things that can be done in parallel, and the things that depend on other actions. Your WBS also gives you a rough schedule (but do not take it as gospel because you aren't a prophet). Based on this, you can start prioritizing the work that goes into the iterations. Periodically (with each iteration or after several) you revisit the WBS and determine if what you're doing is keeping you on track, or if it's even still the right structure.

softwarefounder 6y ago

Yep - the hilarious thing is even the most Agile/Sprint heavy consulting companies usually have to succumb to some Waterfall concept in order to provide an estimate or meet a fixed bid.

tchaffee 6y ago
Because they aren't good at selling agile. Why do people ask for estimates or fixed bids? It's to manage risk. And how often do projects not go over estimated budget? Even fixed bids are poor at managing risk. Lots of consulting companies will walk away from a fixed bid contract after months of work at the point they realize they will lose money on it. And honestly, what's the quality of work once the contract is no longer profitable? We've all seen it. Everything is a quick hack at that point in a desperate effort to achieve the minimum that could be defensible in court. A fixed bid project means the consulting company and the client have opposing interests: the consulting company wants to get it done as cheaply as possible and will make every shortcut they can get away with. And the client wants every last bit of quality they can squeeze out of the contract for that price. No wonder it so often ends in dissatisfaction for both sides. What are the options for the client when the consultant says "sorry we didn't actually finish and we are out of money"? They either pay more or have to be willing to sue the consulting company. Most companies suck it up and pay more. This is so endemic to the industry that most companies put extra in the budget for software project overruns no matter how tight the fixed bid contract is. So one way to sell agile is to help clients understand how it can help manage risk better than a fixed bid contract or always inaccurate estimates. And how it can be used so that the interests of the consulting company and the client are better aligned.
- satyrnein 6y ago
  I talked to a consulting company once that offered me a fixed price per sprint, with no commitments on how many sprints the project would take. I did not feel like our interests were any better aligned than in a fixed bid contract.
  - tchaffee 6y ago
    So one data point. Sounds like they didn't differentiate themselves well enough from the fixed bid contract. The great thing about fixed price per sprint is they have to impress you with progress every sprint or they risk losing the job. That's great at motivating them to deliver value to you every sprint. Another way your interests are aligned: you know how many sprints you want to pay for. That motivates you to prioritize the most important features so they are completed before you run out of budget and sprints. What a great way to manage risk.
    - davidivadavid 6y ago
      But lack of alignment is known to be an issue with both flat AND time-based fees. Charging per sprint is only superficially different from charging hourly/per day/per week/biweekly. Consultants will want the project to last as long as possible. Clients will want it to be over as fast as possible. You have to impress the client with every sprint? Just like a regular contractor must impress the client with every milestone. How do you know how many sprints you want to pay for? So you have a budget, just like any regular old project. You can prioritize features? But why wouldn't you do that without sprints? What am I missing?
      - tchaffee 6y ago
        > But lack of alignment is known to be an issue with both flat AND time-based fees. Agreed. Agile only puts you in a more flexible relationship. It does not fix every alignment issue. For that you need to be more creative with the contract. However it does spread the risk more evenly. And by you as the client taking on more of the risk instead of pretending an estimate or contract erased it, you will do a better job of managing the risk. Every sprint you'll decide what must be built next. Every sprint you get the opportunity to change requirements. Both of those are far better ways of managing risk than fixed price contracts or estimates. > Charging per sprint is only superficially different from charging hourly/per day/per week/biweekly. Not if you are delivering a working product at the end of each sprint. And yes, milestones are somewhat similar to sprints. Except as a client you've now locked yourself into what gets built and if requirements change you've got to renegotiate the contract. > You can prioritize features? But why wouldn't you do that without sprints? Because your fixed price contract legally "guarantees" all the listed features will be included. > Clients will want it to be over as fast as possible. And you can have that if each sprint ends with a working product. Up to you when the product has enough features included that you are happy with it. Or that you are out of budget. And you've managed risk aligned with the consultant instead of getting an unrealistic estimate they won't meet, or having a to head to court with a broken contract.

jordache 6y ago

maybe this person is thinking of a scope similar to an elaborate to-do app? Many enterprise scale business centric applications have tremendously complex business rules and overreach. One can not simply make a casual decision last minute, and expect perfect execution, towards an end result of increased business value. EDIT: I see he is a Drupal consultant. There is a very explicit ceiling on the complexities of primarily CMS driven sites.

jrochkind1 6y ago

Would you use an 'agile' methodology to build a rocket at all? There some projects not suitable for an agile approach, especially if we're talking "projects" generally beyond software engineering, perhaps MOST aren't. "Agile" is software engineering advice. OP is advance for projects that an agile approach is suitable for. Ie, not building a rocket.

jordache 6y ago
many real world complex software is also not suitable for dogmatic application of agile/lean principles
Jtsummers 6y ago
Agile isn't, strictly, about software though it certainly is the predominant application. So first, let's separate two things: - building - designing Some parts of agile do apply to building. See Lean Manufacturing, parts of it are responses to maintain quality (Andons used to stop production) and parts are to change over the manufacturing floor to build something else (same plant can make many kinds of cars without a fixed production line for each, letting them meet demand). Other parts of agile, though, are aimed more at the design portion. Sprints, for instance, are meant to give you short iterations that let you frequently evaluate both your process and your product's success/failure. You can apply agile concepts to developing almost any kind of thing. Actual rocket scientists create simulations, scale models, full-scale models, prototypes and other things on their way to the final system. So they're already applying the same iterative approach that most agile proponents endorse. The question is, is the iteration deliberate or accidental? Or do they try to deny the iterations even exist? Once they get to building the rocket, that might be less agile depending on circumstances (is it the first one they've built? are they setting up a production line? is it a one off?).
- bluGill 6y ago
  Note that when building cars flexibility is a trade off. You can switch car type, but the jigs for the car you are not currently making is still a cost, separate lines at near full capacity are a better use of resources. Only if you can forcast demand years in advance to build the factory to the right size. This is a hard problem. Note that flexible factories have other limits. Honda can't make a large truck in their factory as there isn't room. I don't know if Honda regrets this cost or not.

tchaffee 6y ago

Agile is the wrong model for building something that must fly or you die. The opposite of much of the software we build where a quick prototype in front of real users gives you far better information than any amount of internal brainstorming.

thinkharderdev 6y ago
This is a common sentiment but I don't think it's actually true. Users like software the works and is performant. Putting a quick prototype in front of users doesn't tell you anything beyond what the users think of the quick prototype. Did they have a bad impression because they ran into one of the many edge cases you didn't account for in the prototype? Or is it because the software is ill-conceived and not something they would like even if executed flawlessly. It's hard to tell. I think you run the risk of putting together a crappy prototype and then iterating your way into a local optimum that is still far inferior to what a properly engineered piece of software could be. Or it never gets that far because users hate the initial iteration because it doesn't work very well.
- tchaffee 6y ago
  The vast majority of invented products - software or not - are complete market failures. No one wants to use them no matter how well engineered they are. When we talk about building an MVP (minimum viable product), the V part is very important. It does have to be useful. It does have to look great and work great. It does have to be performant. Edge cases should not get past your QA department. So with those constraints, about the only way you can get out a prototype in a sprint or few is by ruthlessly reducing scope until you get to the core part of your product that is adding value. That process in itself results in far better products. My goal (that I sometimes don't achieve) is that each sprint results in a product we can ship that is better than the last iteration. Run out of budget? Company priorities change? No problem. We still have a useful feature we can ship. Per my previous comment, this is the wrong process for plenty of products. You have to know what you are building and what the risks are, what the constraints are that you are optimizing for, and the pros and cons of different types of processes before deciding which process is the best fit. If you have a strong idea of what you are building ahead of time and you have experience building those types of things and you know there is already a market demand for those types of things, then by all means come up with a solid plan ahead of time and then execute it.

thinkharderdev 6y ago

Setting aside the specifics of particular agile methodologies like scrum, etc I think the core insight of the Agile manifesto is that building software products is fundamentally different than building things like rockets. When you are building a rocket you more or less know exactly what you want to build from the beginning so doing a detailed up-front design is definitely the right way to go. When building a software product (or really most software products, there are of course pieces of software that are well specified in advance) you don't know what the end state is or even if there is an end state. The information flow is bi-directional in the sense that observing how the software is used in the wild feeds back into how the software should be designed.

gt565k 6y ago
Ughhh, you do realize that there are software systems out there probably just as complex as rockets, as they are, well, used in rockets themselves to control the physical parameters. You do know what the end-state is. It's called the minimum viable product, MVP. The most successful product owners are ones who are technical and can bridge the gap between the business requirements and technical implementation. For example, there would be no SpaceX and vertical landing of rockets if it wasn't for Elon Musk, who is both an engineer, a businessman, and an entrepreneur. He gets the full picture and can talk to all divisions of the company with incredible competency. If you have a product owner who knows nothing about building software, in charge of a software product, you'll have a much smaller chance of succeeding, than if you had someone who was both business and technically savvy.
- thinkharderdev 6y ago
  For what it's worth, I agree that the advice in the article is badly wrong. I'm just saying that building a rocket is fundamentally different than building a software product because a rocket is well-specified in advance. To you point, the MVP is different from the product as it will exist once fully realized. And the reason is because you don't know in advance how users will respond. You're not trying to satisfy the physics of rocket flight, but trying to please actual human beings who have weird and idiosyncratic preferences. So you build something (an MVP), let them use it and then incorporate their feedback into the next iteration. I'm with you in the sense that once you have a concrete MVP that you want to build, then you should approach building it as you would approach building a rocket. It's just that you may find that user didn't actually want a (proverbial) rocket, they wanted a helicopter.

iainmerrick 6y ago

How would you build a rocket if you only thought about the next 2-4 weeks? Okay, I’ll bite... I’ll grant you the 2-4 weeks part isn’t quite right for building a rocket; but the key insight of Agile, of developing in small steps and staying flexible, definitely applies. You do not start by designing the entire rocket before building anything. Your rocket won’t work. You start, you must start, by building a series of prototypes and exploring the design space. As you do that, you gradually refine your ideas of what’s possible and how to do it. As far as I know, every successful rocket design has followed that path. Sure, at some point along the path, you put together the blueprints for the final design. So there’s an element of waterfall in there. But staying agile is still critical. Unexpected stuff is sure to come up and you have to retain the flexibility to deal with it. As others have noted, software is somewhat special in that it’s cheaper and faster to build than physical stuff, can be copied and refactored much more easily, etc. And that shifts the agile-to-waterfall balance where you can realistically talk about working entirely from short term requirements.

rubidium 6y ago
Yes and that’s what almost everyone does. Learning loops with prototypes til you have a feasible product. But then you need a big development plan for how to scale it to a polished, sellable product. Because there’s a lot more to the product then the artifact.
- lmm 6y ago
  > But then you need a big development plan for how to scale it to a polished, sellable product. Because there’s a lot more to the product then the artifact. That's a total non sequitur. Agile is all about building the sellable product. But doing it iteratively works a lot better than doing it via a big development plan.
  - rubidium 6y ago
    You’re getting downvoted because you may have missed my point. To clarify for your sake, once you have hardware in the loop (eg mechanical engineers designing things, manufacturing scaling for production) and a large commercial organization who needs to be ready for a product launch, you need a waterfall type plan. Agile principles (customer focus, respond to change) can apply, and you can break up the work into 2 weeks, but you do need to look past the next 2-4 weeks and know where things are planned. Commitments matter in the $millions. Software-only SAAS has the luxury of avoiding that complexity.

aphextron 6y ago

>How would you build a rocket if you only thought about the next 2-4 weeks? We're not building rockets. We're building business software. And the requirements for that are not a hardline set of rules laid out by the laws of physics. They are soft and fungible. Beholden to the whims of a product manager, designer, or client. Generally almost nothing is truly understood about the shape and function of the resulting software at the beginning of a development process. And sticking to a "plan" that was laid out before these things have actually been discovered is a recipe for disaster. Better to build in tiny, discrete chunks of usable MVP that can be used as a guidestone to the next desired level of functionality.

rubidium 6y ago
If you’re building business software then yes mostly. Change is cheap. If you’re actually building a rocket or any other physical thing with real world stuff (like some of us here) you need a real plan. The fits software engineers get into about agile is odd at times. I don’t really get it.
talaketu 6y ago
Business software projects can have very clear requirements known months in advance. Eg a project to ensure we comply with newly legislated tax regime. Yes, details will be discovered as the regulations are released, but to embark on that project with a 2-4 week planning horizon would be malpractice. "plans are useless, but planning is indispensible".
pjmlp 6y ago
Except that we mostly are, unfortunately getting penalised for faulty deliveries still isn't as hard as it should be. Also not every department is agile and wants those 6 months delivery plan.

maerF0x0 6y ago

its called "Manifesto for Agile Software Development" Only software is in scope

projektfu 6y ago

Rockets were an iterative process of gradual and revolutionary improvements that made engines you would actually be willing to put a person or nuclear warhead on top of. Remember that the “build” phase of software is relatively instantaneous. The design phase is the only part anyone sees anymore. (The heroes who wove the Apollo ROM were examples of actual program builders). Making the Saturn V static test rocket was heavily design work slowed by manufacturing. Making Apollo 11 was a process of knowing mostly what was needed and building it from start to finish.