Frequently Asked Questions
How do you know what process works best
for a company?
Why would an organization consider agile
development methodologies?
Are there other agile software
development methodologies?
What are some of the key differences between
traditional and agile methodologies?
Are there situations where traditional
methodologies are more viable than agile methodologies?
What is Feature-Driven Development?
How long has FDD been around?
Is FDD a widely accepted agile development
methodology?
Why is ProcessExchange® focusing on Feature
Driven Development (FDD) services?
Can an organization embrace FDD in
conjunction with other methodologies?
Is FDD the silver bullet?
What is the advantage of FDD over other
application development process methodologies?
One of the biggest problems in implementing software development
methodologies over the years has been the mismatch of culture
and methodology. Recognizing the inherent differences between
people, project teams and organizations is critical in implementing
any formal process successfully.
Successful development organizations, regardless of the methodology
employed on specific projects, had development teams that
valued the concepts of the four points expressed in the agile
manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile approaches are ideally suited to software projects
where development teams operating in this zone are being asked
to deliver too many requirements in too little time. These
projects do not lend themselves well to rigorous, plan-driven
methods. This is where agile approaches shine.
Yes, “Agile Software Development” encompasses
individual methodologies such as Feature Driven Development,
Crystal methods, eXtreme Programming and adaptive software
development.
Some of the differences are summarized below:
- Agile and rigorous organizations tend to view people and
performance in a different way. Rigorous methodologies are
designed to standardize people to the process, while agile
processes are designed to capitalize on each individual’s
and each team’s unique strengths: they adapt the process
to the people.
- Agile organizations focus on building individual skills
and on fostering a high degree of interaction among team
members and the project sponsors. Agilists believe that
complex projects require more understanding from face-to-face
interaction than from documentation. Agilists do not believe
that a reliance on heavy processes makes up for lack of
skill, talent and knowledge.
- Historically, managing projects in an unpredictable environment
result in goals that are not achievable, project details
that are often unpredictable and repeatable processes are
unattainable. Many successful projects have met the customer’s
vision, but in the end, looked nothing like the original
plan. FDD provides ways to manage and adapt to a project’s
unpredictable nature by identifying and managing risk issues
early and often and giving project developers, architects
and project managers the tools and techniques to manage
ever-changing and expanding requirements in a controlled
and predictable manner.
Issues like contractual requirements (typical in government
development projects or government regulated industries),
organizational maturity and the rate of change of the business
environment will dictate the degree to which a development
organization can use an agile methodology. The idea behind
agile processes is just enough, or sufficient structure. If
the contract requires a lot of documentation and formal signoffs,
then that needs to be taken into account when choosing the
process by which the product will be built.
Each of the agile methodologies has their strengths and weaknesses.
Many projects that use traditional, formal development methodologies
can benefit from the application of agile methodologies and
techniques to many areas and tasks.
Feature driven development is an agile software development
methodology that enables and enforces the repeatable delivery
of working software in a timely manner with highly accurate
and meaningful information to all key roles inside and outside
a project.
FDD was introduced as a formal concept in Peter Coad’s
book Java Modeling in Color with UML, published
in 1999 by Prentice Hall. The first implementation coded to
FDD requirements was by Herman Veluwenkamp in early 1998.
FDD is recognized as a viable and valuable methodology by
the Agile Alliance. Interest in FDD and other agile methodologies
is increasing, as many companies cannot keep abreast of rapidly
changing requirements and demanding timelines. FDD is attractive
to many organizations as an alternative or modification to
heavy weight processes like RUP.
FDD is also attractive to organizations that use XP because
it is model driven, provides a little more formal structure,
FDD’s accurate project reporting, and its ability to
be adapted to fit an organization’s needs. Large and
small companies like Sprint PCS, Glaxo SmithKline, Wyeth,
TogetherSoft®, Qwest, Amgen, US Naval Weapons Station and Solid
Source have adopted some of the best practices of FDD, or
set FDD as a preferred or standard software development process.
ProcessExchange® is focusing on FDD because it provides project
managers and clients with quality results in short time frames.
It addresses the needs of each of the interested parties in
a project (something for everyone) and can be implemented
incrementally or augment areas that companies need additional
support with.
Other processes may not completely support the project’s
need and parts of FDD can be implemented to close process
gaps. It provides project managers and project sponsors with
the ability to make informed business decisions based on accurate
projects costs, timelines and dependencies.
It provides architects, team leaders and developers with
specific guidelines for producing the necessary artifacts
and performing a minimal set of tasks needed to produce a
quality product.
It gives project sponsors and users the opportunities to
review the product and project at frequent intervals during
the development of the system, giving them a very high degree
of control over the development of the system and the management
of risk issues that is not available in many other, more formal
methods.
FDD can be a modular way of augmenting existing processes.
This augmentation can target specific aspects of a process
methodology that do not work well for a group, project or
company.
There is no silver bullet when it comes to application development
projects. FDD is a tool that produces results. The reason
many projects attain their goals has little to do with repeatable
processes and much to do with the skill and adaptability of
the people who are working on the project.
Good project managers that embrace FDD become more effective
contributors and drivers of enterprise development initiatives.
FDD embraces and accepts software development as a decidedly
human activity. The key is having good people—good domain
experts, good developers, good chief programmers. No process
makes up for a lack of talent and skill. A good recipe cannot
make up for a bad cook; the results are predictable and the
food will be ruined.
There are a number of benefits to FDD including:
- As an agile process, FDD is collaborative, by nature.
There is sufficient data that supports the benefits of collaborative
processes.
- FDD is adaptable to rapidly changing business requirements.
- FDD provides accurate project reporting.
- FDD provides the development team with specific roles
and focuses on accountability for the deliverables for each
role (e.g., Class owner or artifact owner is responsible
for delivering all changes to the classes or artifacts that
they are assigned. eXtreme Programming assumes that all
developers own the entire system and are therefore responsible
for every change that they make, which is more difficult
to enforce and track).
- FDD, like all of the agile methods, focuses on producing
results vs. simply focusing on the process (e.g., task sign
offs, tools to manage and protect against scope creep).
- FDD focuses on small cycles, small deliverables with user
identifiable functionality and ongoing feedback. This methodology
builds credibility throughout the process with project sponsors
and avoids unexpected surprises or misunderstandings.
- FDD is analogous to building a prototype but instead of
being a prototype with throw away code, it’s actually
working software. With eXtreme Programming, it’s common
to throw away code because you’re doing prototyping.
- It gives project sponsors ultimately more control because
of the two-week communication cycle with real-time updates
on features, with time to adjust, manage risk, re-think
deliverables, outcomes and project priorities. You can’t
do that with RUP, the CGE & Y Navigator.
|
