Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I believe that Agile is nothing but another implementation of Spiral Model. I am a big supporter of Spiral (The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts) since its beginnings and have seen that lot of projects implement Spiral without knowing that they are operating in a Spiral world. Since the day Agile started gaining popularity the concept of spiral started getting overlooked a little bit. I am sure that for complex projects spiral is still the best alternative but I would like to get a better understanding of the similarities and differences between Agile and Spiral techniques. Can anyone explain their differences/similarities?
Agile is spiral. Totally. In part, the name was changed for marketing purposes.
The problem is that spiral tends to imply "big design up front" -- where you plan out many spirals, each in order of risk. Spiral, however, isn't Agile -- it's just incremental execution in order of risk.
One big distinction that Agile adds is the "don't overplan things you can't know yet."
Agile is spiral, but you create detailed plans for just one increment at a time.
Agile adds a lot of other things, also. Spiral is a very technical approach. Agile, however, recognizes that technology is built by people. The Agile Manifesto has four principles that are above and beyond the Boehm's simple risk management approach.
The basic difference, as I see it, is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.
They are similar in that they are iterative. They differ in the implementation and understanding of what an iteration is.
I'm not an expert for the Spiral Model, but from the wikipedia-definition, it seems to me that there are some significant differences.
For example, in an Agile project, at the end of an iteration doesn't stand a prototype, but a fully functional, fully tested, potentially deployable (1) system, containing the highest priority features on the feature list.
The requirements gathering at the start of the project is meant to be just barely enough to get going (to take the next step) and are meant the be fleshed out just shortly before they get actually implemented. Changes are to the requirements are welcomed.
Also, there is much more to Agile than just doing iterative development - a focus on faces to face conversation instead of written communication, a focus on bringing business people and technical together in their day-to-day work. A focus in collaboratively maximizing value instead of defining and then fulfilling a contract.
In case you didn't see it yet, take a look at the Agile Manifesto, which basically is the definition for Agile Software Development.
(1) That doesn't mean that it has to make business sense to deploy the system, "just" that it is technically feasible. It should be a pure business decision whether to deploy the system at the end of an iteration.
I believe Agile is type of Iterative SDLC while spiral is type of Incremental SDLC. Scrum is one the type of Agile other are DSDM/FDD/XP etc.
All SDLC after waterfall followed same set of acts(Requirement Analysis, Design, Coding and Testing) in some different combinations. So basic set of action in sequential OR Iterative OR Incremental are same.
As far as Agile and Spiral are concern both have common advantage
1.Changing Requirement handling
2.Short term releases
3.Risk management is easy due to shorter duration of SDLC
4.Cross team helps product and project going smooth
First Agile is actually a number of different processes that follow a similar philosophy. One of the philosophy's that makes it different is that each iteration produces a working product. It could be described as iterative and incremental. A lot of emphasis is placed on the working product and on testing. In many agile models testing comes before coding.
In the spiral model the number of iterations are fixed, while each phase of an agile model may consist of any number of iterations.
You are right that there are similarities but the underlying philosophy makes the difference. This page explains in more detail and compares agile to other methods.
You can say that agile processes are Use Case driven...placing a lot of emphasis on people, the end user.
I'd say spiral and agile are similar. However, lately agile has often seemingly become a propaganda system to excuse cowboy coding. I.e.
Extremely minimal requirements
Minimal technical analysis
Minimal documentation
No code comments
Special Bonus-- misuse of Domain Driven Design to over-complicate the object model
This was never the idea with spiral. I would argue that it's not really the point of Agile either, although you'd be surprised how many times I've seen this recently. More and more experienced developers/PMs are beginning to see the wisdom of a more balanced approach between waterfall and "agile" -- perhaps this simply brings us back to spiral.
Although there are some useful ideas in the Agile mind-space, it often seems as though it manifested from people who were in organizations that had particularly over-burdensome/unhelpful software design methodologies, and was a reaction/over-reaction to that.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Obviously the differences in the impact to teams, customers, ROI, etc. of applying the two approaches is huge and is the subject of many books and endless discussions and conferences.
But as I think more about it, I am having a hard time finding any difference between the two that doesn't ultimately map to a single root difference which is the frequency of release.
Waterfall spends time on a design, then writing the code, then testing and finally releasing. But Agile does exactly the same set of steps - its just that each one is smaller.
A key piece of the Agile approach is about learning from each release and using that to let the larger design emerge instead of trying to predict it at the beginning.
But Waterfall does this too. Its just that instead of learning every 3 or 4 weeks, the Waterfall team only learns every 6 or 9 months. But the Waterfall design still emerges. That is, waterfall release 2 will reflect what was learned in release 1. So the process is not different, its just that it executes at a different speed.
Agile focuses on close customer collaboration. But Waterfall does this too. Its just that since waterfall has a longer iteration time, an enumerated list of requirements in the form of a contract is more needed to keep everyone on the same page over the long period of time. But again, this is just an artifact of frequency. The higher the frequency of delivery, the lower the need for a contract.
Are there any other primitive differences that I am missing - or is it really just frequency?
Waterfall:
you design the product
you build it
you test it
you document it
you release it when you have developed all the requirements
Agile:
you design the most valuable feature (or user story) first
you test it (TDD ;))
you built it
you document it
you repeat the process with the next most valuable feature
you can potentially release it at any time
(after each feature you completed or after the time boxed period (usually called sprint or iteration))
The difference is pretty clear to me.
With Agile, you can adapt what to build by delivering small chunk of the software frequently. You can stop when you have enough.
Faster feedback - at all scales, not just releases, is certainly one common factor in many agile practices. But I don't really think it's the primary difference between agile & waterfall. For example:
Waterfall teams tend to be built around group of narrow specialisations. The analysts/architects/designers/coders/testers tend to be separate groups of people working alone. Agile teams work together.
Waterfall processes depend on lots of documentation and handovers. Agile teams are oriented around working code/products.
I'd disagree that waterfall focusses on customer collaboration. There is a single point of contact, with a small group of the overall development team, often only at the start of the process. Agile is built around continual collaboration throughout the whole development process. Very different.
Waterfall processes are built around the idea that you can fully define the product & architecture before development begins. Agile processes are built around the idea that you discover the product/architecture as you go.
Waterfall spends time on a design, then writing the code, then testing and finally releasing. But Agile does exactly the same set of steps - its just that each one is smaller.
Agile is not a single entity, but an umbrella for many varying methodologies.
In at least some of them, as others have noted, these "phases" overlap much more and are in somewhat different normal order.
In fact, in XP, the order is more or less:
test (TDD/test first)
code
design (refactoring)
repeat and eventually release
which sort of inverts most of the sequence.
And the test, code and design is done at a finer grade than the release.
A key piece of the Agile approach is about learning from each release and using that to let the larger design emerge instead of trying to predict it at the beginning.
But Waterfall does this too. Its just that instead of learning every 3 or 4 weeks, the Waterfall team only learns every 6 or 9 months. But the Waterfall design still emerges. That is, waterfall release 2 will reflect what was learned in release 1. So the process is not different, its just that it executes at a different speed.
This depends heavily on practice. As described in DOD-STD-2167A, (Section 4.1.1) the waterfall model does indeed allow for the phases of the development process to overlap and iterate (in short, to be somewhat agile). But most actual practice missed that, and there was no learning until the end of the project.
Agile focuses on close customer collaboration. But Waterfall does this too. Its just that since waterfall has a longer iteration time, an enumerated list of requirements in the form of a contract is more needed to keep everyone on the same page over the long period of time. But again, this is just an artifact of frequency. The higher the frequency of delivery, the lower the need for a contract.
Again practice-dependent. I don't see in the spec referenced above much mention of the customer responsibilities at all, let alone continuously.
As Jerry Coffin noted in a comment, Waterfall is indeed a strawman used to argue in favor of Agile (as indeed I'm using it now...), but it's worth looking at this document and thinking about what it implies and how it's been applied.
What this spec does show is an intense focus on contracts, delivery and maintenance of plans and documents, and adhering to plan. And I believe that did carry over into practice.
The contrast with agile is not the timeboxing, but a change in values.
As The Agile Manifesto proclaims:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Curiously, this values statement says nothing about frequency of delivery (though the following "Principles" section does). It does however shift the value system away from plans, documents and contracts and back where it belongs, on actually delivering working software.
Frequent release is a mechanism for fulfilling these values.
If you worked in "mini-waterfalls" it would indeed be a bit more agile than the strawman BDUF waterfall. But frequency of delivery is certainly not the whole story.
One difference is transparency: whether people outside the dev team, during the dev cycle, have any visibility into the process, the progress, the obstacles, and what the end result will look like.
Waterfall does not imply transparency. Often (though not necessarily) it's implemented as "programmers go into their cave and emerge n weeks/months later with a 'finished' product". The business experts write the specs up-front, and that may be the end of their involvement -- they might no longer be available when the programmers have questions during implementation. The programmers might not show any deliverables to anyone until the end of the cycle.
Agile requires transparency -- it's part of the basic fabric. People outside the team will (or at least can) see what the team is doing. (If not, the team is lying about being Agile.) This might be the daily stand-up meetings of Scrum, or the Big Visible Charts and information radiators, or the demo at the end of the iteration. It might be XP's requirement that the Customer make all the business decisions, instead of leaving the programmers to scratch their heads and blindly pick an option when the requirements aren't clear. It might be the fact that the testers -- and the Customer -- are considered part of the team, not separate teams.
You certainly could run Waterfall with transparency, and in a well-run Waterfall shop, you probably would. But with Agile, it's a given.
Mark,
As you pointed out, both approaches share "good things" that should be in every good project. For instance take these two: early feedback and transparency. While it is true that Agile has an structure that encourages this, these two "good things" can (and should) be in any waterfall project, too.
However, I tend to (respectfully!) disagree with the idea that release frequency is the only difference. One substantial difference is the following:
Waterfall spends time on a design,
then writing the code, then testing
and finally releasing. But Agile does
exactly the same set of steps - its
just that each one is smaller.
I don't think so.
In Agile, you attempt to do all these things concurrently, with a multidisciplinary team.
I say "attempt" because is not something that can be easily done... but at least trying helps.
On the traditional waterfall, on the contrary, you expect to have separate teams (research/analysis, QA, design, marketing, etc.) and hand offs between them. You mix disciplines and form a special team only in exceptional cases, or when you need to do exploratory research or risk analysis in a complex project.
Just my two cents...
I really like this question.
I have worked maintenance with bad examples of massive waterfall projects. The deliverables for the initial developers were several sets of documents, and one codebase. Once the high-level design document was completed, it was delivered, and never again updated. Ditto SRS, Detail design etc. There is documentation, all of which is unreliable and suspect.
With Agile, there is code. The long-since-gone developers thought it was self-documenting, because they were current with the project when it was written. (Have you ever proofread your own memos? They always make sense to the author.) I will try to discern the architecture from looking at 1500-2000 modules. Likewise trying to figure out the high-level design. I will take copious notes. Maybe even binders full. Looking at the "self-documenting" code will tell me what is being done (in that module), but not why. Oh yeah, the staff who collaborated with the developers got promoted (or scared) and are no longer available.
Bad agile is not better than bad waterfall. In fact, bad agile may be worse than bad waterfall. Is good agile better than good waterfall?
The manifesto says nothing about documentation. The real danger here is that "agile" means to many developers and clients a justification of a quick cheap heroic model. Do you think the customer enjoyed reading the three thick three-ring-binders of high-level design? We all heard in Computer Science 100 that the majority of the cost of software is maintenance, not development. Am I incorrect in thinking that the maintenance aspect is totally ignored in this discussion?
The difference may be that modern clients cannot afford to not specify "agile" because they fear being thought backward.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Looking for work at the moment, I'm seeing a lot of places asking for Agile experience, but until I get a job with a team that is using Agile, I suspect I'll never get the experience.
Is it possible to adopt Agile methodologies with just one person?
Sort of answering my own question, there's similar questions at :-
https://stackoverflow.com/questions/1407189/can-agile-scrum-be-used-by-1-or-2-developers
(I guess I should get better at searching.)
You seem to be coming at this from a work experience point of view; if you are looking to build relevant experience to get you a job on an agile project I would probably think a little more laterally.
Firstly could you work with others, maybe on an open source project? That would be a good opportunity to try out agile methods with others who may have more experience.
Secondly, you could look at using some of the common techniques or tools, even if it's just to learn how the tools work - e.g. you could set up a continues integration server to run builds and unit tests when you check in code. If you are working on your own you won't gain much in terms of productivity by doing this but you would gain some skills and have something relevant to say to future employers which would indicate you are committed to the agile style.
Yes
Check out PXP or Personal Extreme Programming.
http://portal.acm.org/citation.cfm?id=1593127
Summary from the paper:
Personal Extreme Programming (PXP) is
a software development process for a
single person team. It is based on the
values of Extreme Programming (XP)
i.e. simplicity, communication,
feedback, and courage. It works by
keeping the important aspects of XP
and refining the values so that they
can fit in a lone programmer
situation. PXP can still be refined
and improved. It is in the tradition
of XP practitioners to vary XP to
encompass whatever works. We hope
that PXP inherits these pragmatic
roots, as well. Giving up XP tenets
like pair programming is not
necessarily a tragedy. We still
believe that following XP strictly is
a more effective way to pursue
multi-person projects. But we are also
convinced that many of the XP
practices and methods can be applied
to individual work. The PXP
approach tries to balance between the
"too heavy" and the "too light"
methodologies. PXP will inject the
right amount of rigor for the
situation without overburdening the
team with unnecessary bureaucracy.
Yes - it is possible to do many agile practices as an individual.
If you already know how to do these, you can do them as a sole developer:
test-driven development - great place to start
refactoring
continuous integration
doing the simplest thing that could possibly work (and evolving it through refactoring)
automated deployment
planning meetings (a team of one plus customer)
Things you can't do on your own:
pair programming
CRC/RRC workshops (... you'd have to talk to yourself quite a lot)
Pair programming would be hard this way :)
Let's check Agile Principles:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
You can do all of those things even while working on some personal project alone. You can use also GTD while working alone, you can develop your product through iterations, you can adopt timeboxing, you can ask some family members or friends to do usability tests with you (and this works really well).
As a conclusion, you can really get tons of Agile experiences alone. I strongly recommend you to read some books first tho, as some of principles can be easily misinterpreted.
Some aspects can be done alone: running a product backlog and using a task board come to mind. See what the secretGeek is doing.
Of course some cannot: pair programming, scrums etc...
I recently interrupted a big project. It was a medical software project. While working on it, I realized some patterns about solo programming. I want to share my experiences here:
Your software's working logic must always reflect the real world. You catch fish with fishing rod, not baseball bat; so forget it.
Always start building from the project element to which all other elements refer. That makes sense if you think that like the function in a software project which is called at most. That might be database modeling. It would be useless if you model data access layer first, before modeling database.
Never mind changing variable names. That's the most written entry in a programmer's diary; so no need to be ashamed.
Methodology changes the world. Make worth of it. Make every single logical process with a function or procedure. When project gets huge you will understand thats the best way.
If you're not designing a language compiler in assembly do not hesitate using huge procedure call chains in which one calls another and that calls another and so on. Use methods everywhere, nearly resemble every single entity with classes and be modular.
Modularity is everything. Set modularity your primary goal. Have i said it is everything meanwhile?
Last word for beginning the project. If you're building an apartment you install main entrance at last. But when using, you enter the building from entrance. Be aware.
These are some of my design principles I learned and learning day by day. I hope having been useful. Do your best.
While some Agile practices are directly targeted at more than one person teams, they are just practices, they are just a mean, not an end. I mean, Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context. So, back to the initial question, it's definitely possible to adopt Agile practices (that make sense in your context) to maximize the delivered value: continuous planning, limiting Work In Progress, Stop-the-Line culture, time boxing, high quality, just enough specifications, just enough and just in time documentation, etc, etc.
Definately. Agile is very flexible in terms of how many people are involved. Some methodologies, like Scrum, focus mostly on doing as much as possible in a limited time, like two weeks (sprints). That includes whatever you want it to. If your team requires QA, then that is part of it. As a loner, you decide what you want to include.
After the scrum sprint, you look at what you could have done differently to get more done, and move to the next one.
Some other methodologies focus more on getting features done in each iteration, say three small features developed, tested and refactored.
As you can see, there are tons of ways to apply agile to any project. You decide which aspects you want. Though obviously one integral part is doing things in small increments.
Yes
XP/TDD scales from one to one thousand. Pair programming is optional.
YES.
Agile is more of a state of mind than just a methodology of software development like waterfall.
Scrum is one of the very popular agile methodologies. You can study below aspects of scrum in detail:
Benefits of Scrum/Agile over Waterfall
How can you create better "products" with Scrum/Agile
What are the types of projects better suited for Scrum
Pros and Cons of Scrum
Scrum Rituals and why are they necessary (What advantage do they
bring)
Different roles in scrums and their responsibilities (Scrum Master,
Product Owner and Development Team)
After you have good understanding of working of scrum and its benefits, try to create a pet project.
You will have to play all the roles yourself. You can try to distinguish between what role you are playing currently by wearing different colored hats for each role.
Example:
Product owner : Think from product perspective, what should be the features in the product and why would they be important for your users etc. Then proceed with all the scrum practices.
Scrum Master: Keep checking if you are following all scrum rituals in the right sense and spirit and are you able to derive benefits out of it.
There will be limitations,example you cannot have Daily stand-up meeting, obviously because you are the only person in the project. But if you follow above, you should be good to secure a job and play your part well in the team.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have been looking at different programming methodologies: Scrum, waterfall, spiral but someone told about one called Object-Oriented. Now as far as I know that's a paradigm and not a methodology.
If it is a methodology can someone please explain how it differs from Agile or waterfall?
Well, Google found some traces of such a beast which is clearly describing a methodology-like thing:
This document aims at introducing briefly to the readers the Object Oriented Methodology (OOM). Information covered in the document includes a brief overview of the OOM, its benefits, the processes and some of the major techniques in OOM.
OOM is a new system development approach encouraging and facilitating re-use of software components. With this methodology, a computer system can be developed on a component basis which enables the effective re-use of existing components and facilitates the sharing of its components by other systems. Through the adoption of OOM, higher productivity, lower maintenance cost and better quality can be achieved.
This methodology employs international standard Unified Modeling Language (UML) from the Object Management Group (OMG). UML is a modeling standard for OO analysis and design which has been widely adopted in the IT industry.
The OOM life cycle consists of six stages. These stages are the business planning stage, the business architecture definition stage, the technical architecture definition stage, the incremental delivery planning stage, the incremental design and build stage, and the deployment stage.
But this thing didn't spread (likely) very far. Maybe you should ask your contact for some references.
Object Oriented programming is a programming technique used when writing code. This is something different from a methodology which is a way of planning, managing and implementing a software project.
see: http://en.wikipedia.org/wiki/Object-oriented_programming
Apples and oranges. OO is a way of designing code. Scrum/waterfall/spiral, etc... are about how you manage a project. They're independent of each other.
That said, you really should look into OO.
In the late 1980s and early 1990s, some authors published work (especially books) with titles and blurbs including the word "method" or "methodology" in them; these works focused on object-oriented modelling approaches, explaining in detail the modelling primitives (metamodel) that one should use to construct structural and dynamic models of systems. Their treatment of the process to follow, however, was minimal. Later, they were criticised by applying the term "methodology".
Nowadays, "methodology" is usually thought of including a process aspect, a modelling (or product) aspect, and a people aspect, at least. The modern methodologies that were built on the tradition of those 1980s-1990s works that I mentioned above are often called "object-oriented", because the modelling approaches that were used then were, in fact, object-oriented.
Actually, it is a debated topic in research circles whether the process aspect of a methodology is substantially different depending on the modelling aspect of said methodology. For example, is the process aspect of an object-oriented method very different from the process aspect of an agent-oriented one? If you think it isn't, then the term "object-oriented methodology" may make no sense to you.
Object-orientation is an entire iterative methodology, with each stage used to validate or expose holes in the previous. It covers everything from identifying ALL stakeholders, requirements elicitation from them all, documenting the requirements in Use Cases (not part of the original O-O methodology, but adopted when Jacobsen joined Booch & Rumbaugh at Rational & UML merged in his Objectory), Analysis of the requirements begins once they had been validated with text-based Use Case documents the stakeholders can understand. Analysis is still in the business problem space, not the software solution space. Architechure & System-level Design are the first steps in creating the solution space for the identified business needs. The tasks can then be broken up and Low-level Design and Programming, implementing the Design via the case hierarchy originally created during Analysis and refined in System Design in UML Case/Object diagrams is finally handed off to the coders. One hard-and-fast rule in OOADP is that the Analysis and Design artifacts are baselined BEFORE coding is allowed to begin. Any changes that the business or marketing departments want during coding MUST be submitted to a Change Control Committee, dominated by Development. They will prioritize requested changes, evaluate their effect on the canonical class hierarchy and distributed design, determine how much extra time, money, and resources each change will impose, and go back to the business & marketing people and say - "This is the cost in time, money, and resources. Are you willing to accept the cost?" If not, the change may be discarded or moved into the next release. When you design an enterprise-sized project, you only really get that one chance at creating its skeleton of the class hierarchies. The later you try to modify the systems and have to modify classes and dependencies, the more likely you are to incur extra expenses, time delays, requirement needs - and bugs. Often subtle bugs in areas you had formerly regression-tested to hell and gone.
Agile people used to refer contemptuously to the full OOADP methodology as "BDUF" (big design up front). Scrum is designed to be the antithesis of this, with 5 or 6 programmer teams working with only one Product owner who is responsible for business/customer needs, and knows only a keyhole view of all requirements, occasionally bringing in other SMEs as she identifies a need or gap. Tasks are written out as "stories" (that is a bit of a simplification - they can be any one of several forms of requirements or requirement changes) on 3x5 cards and are tackled a small group at a time, with the intention of finishing each group by the end of a 2 or 3 week "sprint." Undone tasks are put back in the backlog of stories, an analysis is done to determine the state of the piece of the project this team is responsible for, and some of the remaining stories are passed out for the next sprint. Business & marketing LOVE Agile as much as they HATED O-O because they can insert new or altered stories or Use Cases, or other forms of requirements almost to the end of the development stage. The final product keeps changing to meet what business & marketing see as quickly shifting needs and time windows (usually hysterically exaggerated). The various little stovepipes caused when you scale a project up to more than one Scrum Team are dealt with using periodic Scrums of Scrums, where the Scrum Masters of the teams get together and try to keep every team on the same tracks and determine if any teams have backlog items that block progress within another team. The bigger the project, the more bureaucracy is added to coordinating all these teams, each subtly changing their original mandate as stories are updated or new ones added.
I've worked with O-O since the original CRC cards and Wirf-Brock refinements all the way through today's iteration of UML. I even spent several years as part of a four-man team from Bell Labs, teaching O-O and C++ to AT&T development teams. I've also worked with Agile (mostly Scrum and ScrumBan, a merger of Scrum and Japanese Kanban). I have used Agile Scrum since 1998, before there was an official standard. Agile is only a partial methodology, so every project has to find other tools or methodologies to fill in the gaps. I've seen thing get REALLY ugly if the teams were not made up of 1st-level ScrumMasters and all expert developers, cross-trained in each others' skillsets. Corporations today have made rates so low, that most of the truly gifted programmers I worked with 15 or 20 years ago are doing something else for a living & getting their coding jollies working on mobile apps or open source projects. You rarely see a truly talented team. Companies hire people without the necessary 10x "rock star" skills for some of the roles, and Scrum teams can be erratically staffed. Also, the more you try to scale Scrum for larger projects, the more problematic the results and the more the department begins to shed canonical Scrum rules, looking for some hybrid that works better.
Agile is, as its early proponents first said, excellent for doing maintenance, enhancements, and smaller non-time-boxed projects and I've seen it used very effectively. However, for a corporate enterprise project that is not driven by the fickle winds of marketers and business people's hysteria about slight changes in an external market's needs or time windows, I'll take O-O every time.
Whenever I'm presented with a contract opportunity that has both Object Orientation and Agile in the same set of requirements, I run the other way.
Back in the day people believed that Object Oriented programming was going to solve world hunger. I suspect that now agile is going to do that, they've lumped them together :-)
Seriously though, although some people took object oriented design to the status of a design methodology - identify actors & behaviours in a formal way to develop the design, it is really a set of principles about how to design software. It certainly isn't a methodology for managing the development of software projects like Scrum and agile might be.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What are the myths or misconceptions related to Agile?
There are lot of misconceptions related to Agile that an average new comer may fall into. What are the misconceptions in the Agile world and how do you justify that it is truly a misconception?
Update: Summary of Agile Myths
Agile doesn't allow documentation
Agile methods do not scale
Agile means no plan
TDD covers all the unit testing needs
Pair programming always results in better code
Agile is a silver bullet solution to software engineering problems (There is a silver bullet solution)
Agile doesn't need up front design
We're doing scrum so we don't need to do TDD, Refactoring Pair Programming, etc.
One can learn Agile from a book
Agile only works for trivial projects
Agile always uses "User Stories"
Read the following answers for more information about above myths and for more myths.
"Working software over comprehensive documentation" means you do not need a functional spec...
Wrong!!! It just means that you can iron out the wrinkles iteratively with the users - speaking as a vendor, you still need good documentation to assist with the QA and sign-off phases...
"We're doing Scrum - so we don't need to (pair | refactor | do TDD | ...)" Actually the Scrum founders - Ken and Jeff have been saying that all the high-productivity scrum teams implement the full range of Extreme Programming practices.
Test-driven development won't find all the bugs / isn't easy to apply to everything - so we're not going to try! - Learning TDD isn't an "all or nothing deal" and you get better at judging what to test and how to do it efficiently. I've been doing it for ten years now and I'm still finding better ways to do it and new things to consider.
I can learn all I need to apply agile methods from a book. - You need to learn by doing and that often means coaching and meeting other people that can help. Lots of things go wrong when people just try to learn it from a book.
Hysterical (and quite real) "The candidate must take direction from, and support the scrum master" (From a job spec I was sent last week...) - The scrum master isn't supposed to tell people what to do. He/She is there to facilitate - i.e. to help the team learn to sort things out themselves. It's a massive failure mode - having a scrum master that "commands" people!
Talking about "the agile methodology" - big cluelessness indicator. Firstly, talking about "agile" like it's a specific thing whereas it's a very vague umbrella terms for many different things. Secondly, use of "the" agile methodology - there are loads of them, and loads of different ways of doing many of them! Thirdly, a lot of people in the agile community got here in the backlash against the big, heavy UML-laden methods of the nineties. These people don't tend to use the word "methodology"...
You need especially talented people to develop software the agile way. Jeff Sutherland says that they considered using the "chief programmer team" model for managing teams in banks - but found they didn't have anything like enough "chiefs". Scrum is designed to get best productivity out of a lot of moderately able programmers. In fact removing one, disproportionately productive team member that doesn't want to help the others can "unblock" the mediocre team members and bring their combined productivity up to more than compensate for the super-productive former team member... That's what Jeff says anyway...
There are quite a few other XP-related ones that we came up with in an open space workshop that I led recently: http://xpday-london.editme.com/WhereHasXpGone
Myth: using Agile development practices is a silver bullet solution to software engineering problems.
Myth: Test-first development forces your project to have adequate unit testing.
Fact: Many developers get lazy, and the unit tests they write before their code are often weak and inadequate.
Myth: Pair programming always results in better code.
Fact: Programmers tend to be slightly anti-social and to have significantly different thought processes from one another. Having someone breathing down your neck as you code is very unpleasant, and the result is often a tense work atmosphere with a reduction in both code quality and quantity.
Myth: Agile means no documentation
Fact: Agile value working software more than comprehensive documentation but this doesn't mean no documentation at all. Documentation should be written just in time, and just enough. And no, Agile doesn't say one should always using user stories. Use them if, and only, if they are appropriate!
Myth: Agile means no plan
Fact: Agile does not support development without planning. Agile uses continuous planning and estimating to maximize the ROI. Actually, Agile is about scope management.
Myth: Agile means no discipline
Fact: Agile developers must be more disciplined for success.
Myth: Agile only works for trivial projects
Fact: Agile (actually Scrum here) has been used for
FDA-approved, life-critical software for x-rays and MRIs,
Financial payment applications,
24x7 with 99.99999% uptime requirements,
Multi-terabyte database applications,
etc
Myth: Agile doesn't scale
Fact: Sutherland used Scrum in groups of 500+, Cohn used Scrum in groups of 100+
Myth: "No Big Design Up Front" means no design.
Myth: Waterfall always fails.
Reality: Most of the software you're using on your agile project was developed with waterfall. Even BDUF waterfall, in many cases.
There's no real myths - but anything taken to an extreme will be wrong. An Agile project that does zero design in the hopes of "designing as it goes" will likely fail. A Waterfall project that designs everything down to the last semicolon will likely fail due to budget, time or changed user requirements.
It has been repeatedly said "Agile design methods do not scale" whereas Agile development will effectively scale to any size if implemented and thought out properly.
Myth: You need to carefully plan and schedule each sprint.
This leads you to do lots and lots of up-front planning so that you can fully plan each sprint.
This leads you to defeat agility and create a waterfall called "Agile".
The biggest myth I have seen is that people think it is better than other development processes.
It is the usual silver-bullet snake-oil that we have been seeing in this industry for years.
https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060
Myth: Agile is always a better option when compared to other alternatives.
Fact: depending on project size, requirements (particularly flexibility of such), external schedule, and customer attitude, it may not always be more productive compared to orthodox methodology.
Myth: Agile means XP and Scrum
Fact: There are other practices like OpenUP, AMDD, etc.
It's easy to know what to charge your customer. This is alway the biggest problems for us, because we don't know the scope of the project we can't give the customer a fixed price, and most customers demands a fixed price.
Great thread. While I offer nothing new in my related blog post, I do illustrate the top two reasons why Agile fails when it does fail. 1) Lack of upfront requirements (taking the 'begin coding with incomplete requirements' to an extreme) and
2) Lack of adequate unit tests (because CHANGE will happen - and unit tests are the quickest way of catching all the breaking points resulting from the CHANGE).
http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx
You're completely right that there are a lot of myths around Agile, some coming from outside, and others from inside. Here are a few more I thought of to add to the list:
"You don't need project managers or business analysts any more"
Although we're not doing BDUF and teams are self-directing, as things scale up there is still a need for people whose job is coordinating what's going on. And if you have a very complex business scenario, you may well need someone to help you make sense of it. IME, a lot of the projects that really needed PMs and BAs still need them (and those that don't need them now, probably never needed them!). But, of course, the roles of the PMs and BAs tend to be different in the Agile world, and that can make people uneasy.
"Agile can't be used for fixed price projects"
It can, but it is quite a bit harder. Especially since we all know that "fixed price" really means "fixed price, scope and time"...
"We don't do BDUF, we do it all as we go along"
The only way to work is JEDUF (Just Enough Design Up Front). Sometimes you need more, sometimes you can get by with less, but you don't do more than you need at that point.
Myth: Agile is anti-thetical to security.
Fact: This is only true, if you try to force a full-blown waterfall-style SDL (security development lifecycle) onto supposedly Agile teams. In fact, I have designed and implemented Agile-SDL variants in numerous organizations, and I can say that putting the Agile into the Security, can actually afford a higher, more robust level of security. it just takes a change of security mindset - from control to visibility and guidance.
If you don't show real value with agile, it will fail. And fail miserably as in bankrupt a company miserably. Going to agile just because it is 'agile' makes you look as silly as the CIO in this video:
http://www.youtube.com/watch?v=nvks70PD0Rs
John
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Developers can learn a lot from other industries. As a thought exercise, is it possible to build a passenger aircraft using agile techniques?
Forgetting cost for now; how feasible is it to use iterative and incremental development for both the hardware (fuselage, wings, etc) as well as software, and still come out with a working and safe product which meets the customer’s requirements at the time of delivery?
Does it make sense to refactor a plane?
Agile in software and Agile in manufacturing are really quite different, although they share similar principals and values.
Agile in manufacturing emerged in Japan in the 1950s. Read up on W.E. Deming and the Toyota Production System to find out more. It's all about constantly improving the process whereby a product is reproduced.
Agile in software evolved in the early 1990s as a rapid development model. It's all about constantly improving the product.
You can certainly build a plane using Agile manufacturing methods, I've no doubt that some already are. Anything built in Japan definitely will be as Agile manufacturing is very well established there (it's taught in primary schools).
You couldn't build a plane using Agile software methods because you can't afford to rapidly change the product - in software changes and mistakes are cheap and reproduction is free. This isn't the case for aviation.
You could design a prototype plane using something like Agile software methods - but it would have to be standardised in order to be reproduced (a design task in itself).
How would you work using Test Driven Development? Would you automatically build and test a plane every iteration? Would you be able to make a ten minutes build? How easy is to make changes to the airplane? Even if you are really flexible in your desing the building some components need to be sent to special factories so there is not inmmediate feedback.
From de design using CAD software you need to make a mould, take the piece of fiber, put it in the plane. Etc. So here a trivial change has a non trivial cost. In Agile you can make a very little change and have it tested, built and an ready to ship in 20 minutes. If small changes are expensive then the short development cycle and refactoring won't be so usefull. Your feedback can take longer than a week so there is a strong reason for thinking in advance like in the waterfall model. And every attempt has a cost in physical materials unless you are programming. The Idea is not new. Carpenters measure twice. Programmers just first code and then test.
In summary. There may be some similarities but it will definitively be the same.
I'm going to say "kind of". In fact there's one example right now that I think is pretty close to answering this question.
Boeing is attempting to do this now with the new 787 - see following: Boeing 787 - Specification vs. Collaboration (From the 777 to the 787, the initial specifications document supposedly went from 2500 pages to 20 pages with the change in technique.) Suppliers from around the world are working independently to develop the components for this aircraft. (We'll call this the "teams".)
So, I want to say yes, but at the same time, iterations in creating the aircraft has resulted in delays of 2+ years and has resulted in stories like this one - (787 Delayed for 5th Time)
Will the airplane ever get built? Yes, of course it will. But when you look at the rubber hitting the road here, it seems like "integration test" is having one heck of a time.
Edit: At the same time, this shift in technique has resulted in building a new breed of aircraft built out of entirely new materials that will arguably be one of the most advanced in the world. This may be a direct result of the more Agile approach. Maybe that's actually the question - not a "can you?" but a "if Agile delays complex systems, does it provide a more innovative product in the payoff?"
Toyota pioneered Lean Production which Agile methodoligies followed on from. For the building of the hardware of the aircraft lean production would be the way to go and for the software an agile methodology would be the way to go.
Pick the right tools for the job.
A great book following how TPS was created and works
http://www.amazon.com/Machine-That-Changed-World-Production/dp/0060974176
http://en.wikipedia.org/wiki/Toyota_Production_System
I think in this case you are thinking too big. Agile is about breaking things down into more managable pieces and then working against that. The whole idea of Agile (XP in particular) is that you do your testing first so that you cut the number of bugs out and because plane software needs to have a very high code coverage for its testing it fits in quite neatly I think.
You aren't going to 'refactor' the mechanics of the plane but you will tweak them if they are unsafe and thats the whole iterative approach for you.
I have heard of Air Traffic Control software written with Agile Methodologies pushing it forward.
This is taken from http://requirements.seilevel.com/blog/2008/06/incose-2008-can-you-build-airplane-with.html
***Actually, that’s not true,***
My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?
All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.
I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.
Agile Can Work With Complex Systems
He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:
Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.
There is this story of an aircraft engine plant (September 1999). Their methods seem quite agile:
http://www.fastcompany.com/magazine/28/ge.html
Yes, you could do it. If you followed Agile Software Development techniques too closely however, it would be astronomically expensive, because of the varying costs of activities.
Consider the relative costs of design and build. If we include coding as part of the software design process, then design is definitely the expensive part and build is ridiculously easy and cheap. Most Agile projects would plan to release every few iterations at least. So we can work in small iterations with a continuous build process. Not so easy when you have to assemble a plane once a fortnight. Worse if you actually plan on "releasing" it. You'd probably need to get the airworthiness & safety people on to an Agile process too.
I'd truly love to see it tried.
Yes, you can use agile techniques for building complex systems, but I don't know if I'd use it for this particular system.
The problem with aircraft is the issue of safety. This means every precaution needs to be taken, from correctly identifying and interpreting the requirements to verifying and validating each and every single line of code.
Additionally, formal methods should probably be used to make sure that the system is truly safe by making sure the programming logic is sound and satisfies its conditions properly.
I'm fairly certain the answer is irrelevant. Even if you could, you would not be allowed to. There are too many safety requirements. You would not even be allowed to develop the flight software using Agile. For instance, you do not have a Software Requirements Specification (SRS) in Agile. Yet, for any avionics software onboard an airplane that can affect flight safety you will need an SRS.
Of course one can refactor a plane.
When one refactor, one modifies the source code, not the binaries. With a plane it's exactly the same thing: one modifies the blueprints, not the plane itself.