What does Agile mean?

The dictionary meaning of Agile is quick moving. Now how does that apply to software? The Agile development methodology considers software as the most important entity
and accepts user requirement changes. Agile advocates that we should accept changes and deliver them in small releases. Agile accepts change as a norm
and encourages constant feedback from the end user.

Figure: Agile

The figure below shows how Agile differs in principle from traditional methodologies.

Figure: Change of Agile thinking

It’s not necessary to have hi-fi tools and processes but a good team interaction can solve a lot of problems.

A working software is more important than documentation.

The management should not just pay attention to customer contracts rather interact with customers and analyze the requirements.

In traditional methodologies, we pledge to stick to our plans but Agile says “If the customer wants to change, analyze and change your plans accordingly”.

Below are the principles of the Agile methodology:

Welcome changes and adapt to changing requirements.

A working software is the main measure of progress.

Customer satisfaction is the most important thing and can be attained by rapid, continuous delivery of useful software.

Day to day meetings between business people and the development team is a must.

Business and developers must work together. Face to face communication is the most important thing.

Deliver and update software regularly. In Agile, we do not deliver software in one go, but rather deliver frequently and deliver the important features first.

Build projects around teams of motivated and trustful people.

Design and execution should be kept simple.

Strive for technical excellence in design and execution.

Allow teams to organize themselves.

Can you explain Agile modeling?

Agile modeling is an approach to the modeling aspects of software development. It’s a practice for modeling and documentation for software systems. In one line:

It’s a collection of best practices for software modeling in a light-weight manner.

In abstraction, we can say it augments other software processes. For instance, let’s say your company is using UML and then Agile applies approach practices on UML.
For example, “Keep things simple” is an Agile approach. So it means that we do not need to use all
the diagrams in our project, use only those which are needed. If we summarize, we can say Agile modeling says “Do only what’s needed and nothing more”.

Figure: Agile modeling

What are the core and supplementary principles in Agile modeling?

Agile modeling defines a set of practices which can show us the way towards becoming successful Agile modelers. These practices are divided into
two sections: “Core Principles” and “Supplementary Principles”. The figure below shows this in a pictorial format:

Figure: Agile model principles

Let’s understand one by one what these principles mean.

Core principles

Simplicity: Do not make complex models, keep it simple. When you can explain to your team with a pen and paper, do not complicate it by using modeling tools
like Rational Rose. Do not add complexity to show off something. If the developer understands only a flow chart, then explain to him with a flow chart; if he understand
pseudo-code then use pseudo-code, and so on. So look at your team to see what they understand and prepare documents accordingly.

Welcome change: Requirements grow with time. Users can change requirements as the project moves ahead. In a traditional development cycle,
you will always hear the words “freeze the requirement”, this has changed with Agile coming in. In Agile, we welcome changes and this is reflected in the projects.

Incrementally change: Nothing can be right at the first place. You can categorize your development with “the most required”, “needed features”, and “luxury features”.
In the first phase, try to deliver the “the most required” and then incrementally deliver the other features.

Model exists with a purpose: The model should exist for a purpose and not for the sake of just existing. We should know our target audience
for whom the model is made. For instance, if you are making a technical document, it’s for developers, a PowerPoint presentation is for the top management, and so on.
If the model does not have target audience, then it should not exist. In short, “just deliver enough and not more”.

It should be light: Any document or artifact you create should be updated over a period of time. So if you make 10 documents
then you should note that as the source code changes, you also need to update those documents. So make it as light as possible. For instance, if your technical document
is made of diagrams existing in UML, it becomes important to update all the diagrams over a period of time, which is again a pain. So keep it lightweight, make
a simple technical document, and update it when you have logical ends in the project rather than updating it periodically.

Keep multiple models: Project issues vary from project to project, and the same project behavior can vary from organization to organization.
So do not think that one model can solve all issues, keep yourself flexible and think about multiple models. Depending on the situation, apply the models. For instance, if you are using
UML for technical documentation, then every diagram in the UML can reflect the same aspects in different ways. For instance, a class diagram shows the static view of the project
while a flowchart shows a dynamic view. So keep yourself flexible by using different diagrams and see which best fits your project or a scenario.

Software is the most important thing: The main goal of a software project is to produce high quality software which can be utilized by your end customer
in an effective manner. Many projects end up with bulky documents and management artifacts. Documentation is for the software and not software for the documentation.
So any document or activity which does not add value to the project should be questioned and validated.

Get rapid and regular feedback: Software is finally made for the user. So try to get feedback on a regular basis from the end user. Do not work in isolation,
involve the end user. Work closely with the end customer, get feedback, analyze requirements, and try to meet their needs.

Supplementary principles

Content is important than presentation: The look and feel is not important, rather the content or the message to be delivered by the content is important.
For instance, you can represent the project architecture using complex UML diagrams, a simple flow chart, or by using simple text. It will look fancy that you can draw complex
UML diagrams but if the end developer does not understand the UML, then it ends no where. A simple textual explanation could have met the requirement for communicating
your architecture to the developer / programmer.

Honest and open communication: Take suggestions, be honest, and keep your mind open to new models. Be frank with the top management
if your project is behind schedule. An open and free environment in a project keeps resources motivated and the project healthy.

What is the main principle behind Agile documentation?

The main deliverable in Agile is a working software and not documentation. Documentation is a support to get the working software.
In traditional delivery cycle, a lot of documentation is generated in the design and requirement phases. But we are sure most of the documentation where created
just for the sake of it. Below are the some of the key points to make documentation Agile:

Before creating any document, ask the question do we need it and if we do, who is the stake holder. The document should exist only if needed and not for the sake of existence.

The most important thing is we need to create documentation to provide enough data and no more than that. It should be simple and should communicate to stakeholders
what it needs to communicate. For instance, the below figure ‘Agile documentation’ shows two views for a simple class diagram. In the first view, we have shown all the properties
for the Customer and the Address classes. Now have a look at the second view where we have only shown the broader level view of the classes and relationships
between them. The second view is enough and not more. If the developer wants to get into the details, we can do that during development.

Figure: Agile documentation

Document only for the present and not for the future. In short, whatever documentation we require now, we should produce and not what we need in the future.
Documentation changes its form as it travels through every cycle. For instance, in the requirement phase it’s the requirement document, in design it’s the technical
documentation, and so on. So only think which document you want to create now and not for the future.

What are the different methodologies to implement Agile?

Agile is a thinking approach to software development which promises to remove the issues we have with the traditional waterfall methodology.
In order to implement Agile practically in projects, we have various methodologies. The figure ‘Agile methodologies’ shows this in a detailed manner.

Figure: Agile methodologies

Note: We will cover each mythology in detail in the coming sections.

What is XP?

Extreme Programming (also termed as XP) is an agile software development methodology. XP focuses on coding of software. XP has four core values and fourteen principles.

XP has these four core values:

Communication: The team should communicate on a regular basis, share information, discuss solutions, and so on. Teams that communicate very often
are able to solve problems more efficiently. For instance, when an issue gets resolved in a cryptic fashion, send an email to the whole team.
This ensures that the knowledge is shared with everyone and in your absence some other developer can solve a similar problem.

Simplicity: Keep things simple. From a process angle, technical angle, or from a documentation point of view. An over complicated process
or technical architecture is only calling for problems.

Feedback: Regular feedback from the end user helps us to keep the project on track. So regular feedback should be enabled from the end user and testing team.

Courage: To bring change or to try something new needs courage. When you try to bring changes in an organization, you are faced with huge resistance.
Especially when your company is following traditional methodologies, applying XP will always be resisted.

From the above four core values, 14 principles can be derived. The values give a broader level view while the 14 principles go deep into how to implement XP.

Rapid feedback: Developers should receive rapid feedback from the end user. This avoids confusion during the last minute of delivery.
In the waterfall model, feedback is received very late. This is minimized in XP.

Keep it simple: Encourage simplicity in the project design and process. For instance, rather than using complex tools, simple handwritten flowcharts
on a board can solve a problem.

Give incremental changes: Whenever you update patches and updates, release it in small pieces. If you are updating numerous patches in one go
and if there is a defect, it will be difficult to track them.

Embrace change: Do not be rigid with the customer saying that we have already signed the requirement so we can not change the architecture.
The customers or users are finally human beings so they can change as the project moves ahead....accept changes if they are logical.

Lightweight: Keep the documentation and process as simple as possible. Do not overdose the developer with unnecessary documentation.
A developer’s main work is coding and ensuring that the code is defect free, so he should be concentrating on the code rather than the documentation.

Deliver quality: Any code you deliver should be defect free. Be committed to your work and deliver defect free code.

Start small and grow big: Many times the end customer wants to start with a big bang theory. He starts with a big team,
wants all the functionalities at the first roll out, and so on. Start with a small team and the “must have” features to be delivered. As we add features
and the work load increases, gradually increase your team strength.

Play to win: Take all steps needed to make a project success. Any type of deadline and commitment should be met with true spirit.

Encourage honest communication: Promote honest communication. If communication happens face to face, then there is less leakage of requirements.
Encourage the end user to sit with developers and give feedback; this makes your project stronger.

Conduct testing honestly: Test plans should not be created for the sake of creation. Test plans should prove that you are on track record.

Adapt according to a situation: No two projects are the same, no two organizations are same, and different people behave differently.
So it’s very essential that our approach also adapts according to situations.

Metric honesty: Do not gather metrics for the sake of gathering or showing off to external people how many metrics your project derives.
Pick metrics which makes sense to your project and helps you measure your project health.

Accept responsibility: Do not impose or assign people on task which they do not like. Rather question the resource once which tasks he like and assign accordingly.
This will increase productivity to a huge level and maintain your project enthusiasm high.

Work with people’s instincts: Normally in a project team there are highly motivated people, moderately motivated ones, and people with less motivation.
So give power to your motivated team members and encourage them.

What are User Stories in XP and how different are they from requirements?

Use Story is nothing but an end user requirement. What differentiates a user story from a requirement is that they are short and sweet. In one sentence, they are just enough
and nothing more than that. A user story ideally should be written on index cards. The figure ‘User story index card’ shows a card. It is a 3 x 5 inches (8 x 13 cm) card.
This will keep your stories as small as possible. The requirement document goes in pages. As we are keeping the stories short, it is simple to read and understand. Traditional requirement
documents are verbose and they tend to lose the main requirement of the project.

Note: When I was working in a multinational company, I remember the first 50 pages of a requirement document had things like history, backtracking,
author of the document, etc. I would be completely drained by the time I started reading the core requirement.

Every story has a title, short description, and estimation. We will come to the estimation part later.

Note: Theoretically, it’s good to have cards, but in a real scenario, you will not. We have seen in actual scenario the project manager
keeping stories in documents and every story is not more than 15 lines.

Figure: User story index card

Who writes User Stories?

It’s written and owned by the end customer and no one else.

When do we say a story is valid?

A story is valid if it can be estimated.

When are test plans written in XP?

Test plans are written before writing the code.

Can you explain the XP development life cycle?

The XP development cycle consists of two phases: ‘Release Planning’ and ‘Iteration Planning’. In release planning, we decide what should be delivered
and in what priority. In iteration planning, we break the requirements into tasks and plan how to deliver those activities decided in release planning.
The below figure ‘Actual essence‘ shows what actually these two phases deliver.

Figure: Actual essence

If you are still having the old SDLC in mind, the below figure ‘Mapping to traditional cycle’ shows how the two phases map to SDLC.

Figure: Mapping to traditional cycle

So let’s explore both these phases in a more detailed manner. Both phases “Release Planning” and “Iteration Planning” have three common phases: Exploration, Commitment, and Steering.

Figure: XP planning cycle

Release Planning

Release planning happens at the start of each project. In this phase, the project is broken into small releases. Every release is broken down into
a collection of user stories.
Now let’s try to understand the three phases in release planning.

Exploration: In this phase, requirement gathering is done by using the user story concept (please read the previous question on user story to understand
the concept of user story). In this phase, we understand the requirement to get a higher level understanding. Please note, only higher level. The user story card is sized normally
at 3 X 5 inch, so you can not really go in detail in that size of a card. We think it’s absolutely fine rather than writing huge documents; it sounds sensible to have
to the point requirement paragraphs. So here is a step by step explanation of how the exploration phase moves:

The first step is the user writes the story on the user card.

Once the story is written, the developer analyzes it and determines if we
can estimate the user story.

If the developer can not estimate, then it’s sent back to the user to revise and elaborate the user story.

Once the user story is clear and can be estimated, the ideal day or story (read about story point, ideal day, and estimation in the coming questions) are calculated.

Now it is time to say to the user, OK we can not deliver everything at one go, so can you please prioritize?
In this phase, the end user gives ranking
to the user stories (in the next section, we will deal with how a user story is ranked).

Once the user is done with story prioritization, it is time for velocity determination (in the coming section, we have a complete question on velocity determination).

Agile is all about accepting end customer changes. In this phase, we give a chance to the end user to decide if they want to change anything. If they want to change,
we request the user to update the story.

If everything is OK, we go ahead for iteration planning.

The figure “Release planning” shows the above discussed steps in a pictorial format.

Figure: Release Planning

Iteration Planning

Iteration planning is all about going deep into every user story and breaking them into tasks. This phase can also be termed as detailing of every user story.
Iteration planning is all about translating the user story into tasks. Below are the steps in detail for iteration planning:

User stories which need to be delivered in this iteration are broken down into manageable tasks.

Every task is then estimated. The result of the estimation is either ideal hours or task points (we will discuss about task points and ideal hours in the coming section).

After the tasks are estimated, we need to assign the tasks to developers. Each programmer picks a task and owns responsibility to complete the task.

Once a developer owns the responsibility, he should estimate the work and commit to completing it.

In XP, on any development task, two developers should be working. In this phase, the developer makes the partner of his choice for developing a task.

In this phase, we do the designing of the task. We should not make lengthy and comprehensive design plans; rather it should be small and concentrated on the task.
In traditional SDLC, we have a fully devoted phase for designing and the output is a lengthy and complicated design document. One of the important characteristic
of a software project is that as we come near execution, we are clearer. So it’s best to prepare the design just before execution.

Now that you and your partner are familiar with the design plan, it is time to write a test plan. This is one of the huge differences when compared
to the traditional SDLC. We first write the test plan and then start execution. Writing test plans before coding gives you a clear view of what is expected from the code.

Once the test plan is completed, it is time to execute the code.

In this phase, we run the test plan and see if all test plans pass.

Nothing is perfect, it has to be made perfect. Once you are done with coding, review the code to see if there is any scope for refactoring (refactoring is explained
in more depth in the coming sections).

We then run the functional test to ensure everything is up to the mark.

Figure: Iteration planning

One of the important points to realize is a project is broken down into a set of releases which are further analyzed using short user stories, the user stories are further broken
into tasks, which are estimated and executed by the developer. Once a release is done, the next release is taken for delivery. For instance, the project shown
in figure ‘Release, stories, and task’ has two releases.

Figure: Release, stories, and tasks

Can you explain how the planning game works in Extreme Programming?

The answer to the above question answers this question as well.

How do we estimate in Agile?

If you read the Agile cycle carefully (explained in the previous section), you will see Agile estimation happens at two places:

User Story Level Estimation: In this level, a user story is estimated using Iteration Team velocity and the output is Ideal man-days or Story points.

Task Level Estimation: This is a second level estimation. This estimation is at the developer level according to the task assigned.
This estimation ensures that the user story estimation is verified.

Estimation happens at two levels: when we take the requirement, and when we are very near to execution - that’s at the task level. This looks very much logical because as we are very
near to completing a task, estimation is more and more clear. So task level estimation just comes as a cross verification for user story level estimation.

Figure: Agile estimation

User story level estimation

Estimation unit at user story in Agile is either “ideal days” or “story points”.

Ideal days are nothing but the actual time the developer spends or will spend on only coding. For instance, attending phone calls, meetings,
time spent eating lunch and breakfast, etc., are not included in ideal days. In old estimation technologies, we estimate eight hours as the complete time a developer will do coding.
But actually a developer does not code continuously for eight hours, so the estimates can be wrong if we consider the full eight hour days.

Estimation units can also be represented in story points. Story points are abstract units given to represent the size of a story.
In a normal scenario, a story point equals an ideal day. A story point is a relative measure. If a story is one story point and another is two story
points, that means the second story will take twice the effort compared to the first story.

Velocity determination defines how many user stories can be completed in one iteration. So first the user decides the length of the iteration.
The length of the iteration is decided depending on the release dates. Velocity is normally determined from history. So whatever was the last team history velocity,
the same will be used in further estimation. But if there is no history, then the formula below will be used:

Figure: Velocity determination

There are two formulas in the above figure: the first formula is used when we do not have history about the project and the second formulae is used when we have a history
of the iteration. Below are the details of all the parameters in the formulae:

Number of developers: Total number of developers in the iteration.

Load factor: This means how much productive time a developer will spend on the project. For instance, if the load factor is 2 then the developers are only 50% productive.

How long is the iteration in business days: One iteration is how many man days.

The figure ‘Iteration and release calculation’ shows a simple sample with a team size of 5, load factor of 2; an iteration takes 11 business days and there are two releases in the project.

Figure: Iteration and release calculation

Task level estimation

As the Agile cycle moves ahead, a user story is broken down into tasks and assigned to developers. The level of effort at the task level is a form of task points
or ideal hours. Ideally, a task point represents an ideal hour. An ideal hour is the time a developer spends only on coding and nothing else.

Individual velocity determination defines how many ideal hours a developer has within an iteration.
The below figure ‘Individual velocity calculation’ shows in detail how to get the number of ideal hours in an iteration for a developer.
Below is a sample calculation which shows with 8 hours a day, an iteration of 11 days, and a load factor of 2 (i.e., developer codes for only 50% time, i.e., 4 hours),
we get 44 ideal hours for that developer in that iteration.

Figure: Individual velocity calculation

On what basis can stories be prioritized?

A user story should normally be prioritized from the business importance point of view. In real scenarios, this is not the only criteria. Below are some of the factors
to be accounted when prioritizing user stories:

Prioritize by business value: A business user assigns a value according to the business needs. There are three levels of rating for business value:

Most important features: Without these features, the software has no meaning.

Important features: It’s important to have these features. But if these features do not exist, there are alternatives by which the user can manage.

Nice to have features: These features are not essential features but over the top cream for the end user.

Prioritize by risk: This factor helps us prioritize by risk from the development angle. The risk index is assigned from 0 to 2 and is classified in three main categories:

Completeness

Volatility

Complexity

The below figure “Risk index” shows the values and the classification.

Figure: Risk index

Can you point out the simple differences between Agile and traditional SDLC?

The figure “Agile and traditional SDLC” points out some of the main differences. If you have worked on both these, you can point out more differences.

Lengthy requirement documents are now simple and short user stories.

Estimation unit man days and man hours are now ideal days and ideal hours, respectively.

In the traditional approach, we freeze the requirement and complete the full design and then start coding. But in Agile, we design task wise.
So the developer designs just before he starts a task.

In traditional SDLC, we always hear ‘After signoff nothing can be changed’; in Agile, we work for the customer, so we accept changes.

Unit test plans are written after coding or during coding in traditional SDLC. In Agile, we write unit test plans before writing the code.

Comments and Discussions

Thanks for the article.You always try to share with others what you have learnt in a very simple manner.Yes I see comments people give why this is for very beginners etc etc, But I feel you are doing a great job becuase after reading your articles a beginner can dare to jump into advanced level.

There are 90 % 'genius' developers who doesn't share what they learnt from their experinaces just they don't want to create another competitor.So you are like an oasis in a desert.

The one area this article, and a lot of Agile talk in general, conveniently misses out is secure development lifecycle issues. This is the one true weakness of these processes, if all the agile processes dealt with this it would mean that they were addressing one of the biggest issues in software development that isn't getting the attention it deserves.

I'm introducing Scrum into the company I'm now working for, but we're modifying it to conform to the SDL guidelines.

What I want to point out is that agile development is sometimes called "liquid" development. It can be good for on-going projects (e.g. a new product that your company sells but is not bound to release at a specific date), but it can mean a disaster for projects with a fixed deadline.
Example: The team of 3 developers that is a part of a larger development team completed a complex application block in 4 weeks (4*5*8*3=480 hrs). Now, requirements change 8 weeks later because initial documentation was incomplete ("agile" approach), developers interpretation of the requirements was incorrect or incomplete and new problems surfaced. You can argue that the key in agile development is communication, but people are different. Some are afraid to look stupid when they ask too many questions. Plus, not only developers make mistakes... The problem here is that at this stage of the project the application block has been integrated with the rest of the application. Now, you must perform impact analysis, many test cases should be re-written, the entire application must be re-tested. And, it takes 2 more man-weeks to make the changes. What this creates is time pressure, and consequently stress, on the team because the project has a fixed deadline. There is a good chance that these 2 weeks don't feet into the project schedule, and team members have to work overtime. It is also a question about billing client because he approved initial documentation developed by your business analysts and the reason for the change is questionable. The things get even worse if it is a fixed budget project.
What I want to stress out is that you have to be very clear of your intentions taking agile approach to development. It is not always appropriate. Especially, when project time and budget are fixed. And, if your client demands agile approach, you should clearly outline the risks that he is going to face to make expectations appropriate, protect your team and succeed with the project.

But, as with every methodology, Agile has its place, which for me (and my employees) is smaller projects, conceptual projects and experimental projects.

I wouldn't use Agile for a large scale project that is on a fixed deadline and a fixed budget although I am sure that with some effort it could work just fine and without major issues. It is just easier to use more 'traditional' methodologies in that case.

All in all the article is a good introduction to Agile, although some side-note somewhere regarding the issues that increased flexibility can produce for a development team and the business would be a good idea.

Your example is very poor the whole point of Agile is that it can adapt to a change in the requirments well. You should also be clear are you saying that the requirments changed or that they are captured wrongly. Both scenarios are a potential issue with any methodology, agile however is more likely to identify the issue earlier as the customer should see the software sooner.

Also your argument about weak developers not wanting to look stupid applies to any situation. If you compose your team well you should be able to mitigate this risk.

Yep, but the changing requirements actually have nothing to do with the methodology but with the actual business rules. You can't have any guarantee your customer is not going to change something in the middle of a project. the point is how do you adapt to that situation. Right now I am facing that very same problem, I am on a team who is developing a very important API for a multinational to make business with a big Chinese bank, the deadline is fixed on stone, but just yesterday they found out they forgot to add some rules for US anti-money laundry in the functional spec. So, should we tell the customer since we are using RUP they should have known better before handing us the functional?, should they tell the bank from china they can't make business with them because they forgot something?, should they say to U.S. Treasury (or whomever that audits them) they can't be in compliance because they signed a contract with us?.
Well, we don't think so, and our customer neither, simply we are addressing the problem and changing everything that needs to be changed in order for the software to work properly.
Painful, yes, for us and for the customer, but sometimes life is a bitch.

I think his argument was that allowing changes will result in a less thorough initial specification and also allow the customer to many unnecessary changes. But in my experience this is unlikely and doesn't fully appreciate the methodology.

However I agree with you that there will always be essential changes, for a myriad of reasons from oversights, changing laws etc. Agile methods assist in coping with these changes and in some cases even detecting them.

almost two years passed from my previous comment and now I have a better understanding of what agile can and can not do for your project. Now I've seen a couple of really big projects failed because of paralysis by analysis and another big project where full specs were delivered to programmers but never checked with the actual users so many things have to be re written.

Now I believe in sprints with a clear goal and asking a lot of questions.

> [Agile] can mean a disaster for projects with a fixed deadline.
This was my initial reaction to agile methods too and actually you are right that if the client (or their representative) likes to fiddle and make arbitrary changes then time and effort can be wasted. However, in your argument you seem to be comparing a Waterfall methodology with changes precluded versus a Waterfall model with changes allowed. Obviously the former is going to be delivered earlier than the latter, though even then I would argue that there may be no point in delivering something on time if it is unsuitable. The customer would also argue that developers changing their interpretation of the requirements (one of your examples) is not a change in the requirements.

The whole point of an agile methodology is that there is continuous feedback from the client about the course of the project. Problems with the requirements, or their interpretation will become obvious much sooner. The client inspects the product at the end of each iteration so that if the project has gone completely off the rails then at worst all the work of the last few weeks is wasted. This contrasts with a waterfall approach where you can even get to the end of a project before the customers realises there is a problem.

In practice I have found that using agile methods, projects are much more likely to meet deadlines. This is fortunate as all projects I have worked on (even on-going ones) have had deadlines. Clients are not going to make lots of changes unless there is a good business case for it. If they do they are the ones responsible for the cost and time blowouts.

Within the world of commercial software development, one should ALWAYS know more than one way of designing and developing software.

Where Agile may work great for small teams working on projects that are not tied to fixed deadlines and/or fixed budgets, Agile has the potential to be a REAL nightmare on large scale, fixed deadline, and fixed budget projects.

Flexibility is great and definitely welcome but it does have the tendency to produce major issues if not monitored correctly or enough. Flexibility in this case increases the non-income workload of the team, and as thus costs more for the developers to develop.

I always tell people who are relatively new to this line of work (and also a lot of highly experienced people for that matter, stubborn as they are) to study all of the most commonly used methodologies and, more importantly, learn to choose the correct one to use for the given project.

Never specialize on one thing, as a developer or a company you need to be flexible, and being able to develop software based on whatever methodology fits the project is definitely one of the things that makes a developer and/or business more flexible, not to mention more profitable.