Click here to view the complete list of archived articles
This article was originally published in the
Winter 2004 issue of Methods & Tools
Click
here to reach PDF area
Delivering Real Business Value using FDD
By Grant Cause, IT Project Services Pty. Ltd. www.fddtracker.com
Introduction
I run my own bespoke software development consultancy firm in Brisbane, Queensland, Australia. I first ran into Jeff De Luca the inventor of the Feature Driven Development methodology about a year ago where he was a guest speaker at a seminar organised by Borland.
I have been in IT for about 20 years now and have heard many people speak on software development methodologies from Waterfall to Extreme Programming. So I guess I was a bit jaded when I went into this seminar, thinking "oh no, not another methodology". To my surprise this wasn’t to be the case. In just under an hour Jeff De Luca convinced me that FDD was the way of the future for all software development my firm would be conducting.
The reasons for this are many:
I certainly do not purport to be an expert in Feature Driven Development having used it for only about a year now. Nor am I an evangelist for FDD. Software development is not a religious experience despite what some people would have you believe. The purpose of this article is simply to introduce the methodology to you and to share my real world experiences in adopting this methodology for my own consultancy firm.
I will let you draw your own conclusions as to whether this methodology is right for you and your firm.
What is Business Value?
Businesses these days are under extreme pressures from all sides. The pace of business has quickened thanks to advances in more efficient business practices and technology. Businesses don’t have the luxury of time that they once had to run large projects and wait for the results to come out at the end. If they did this now, their businesses and their markets would have moved on and the results they were waiting for may no longer be meaningful or relevant.
Businesses are quite simply looking for one thing, RESULTS! These results generally involve some monetary quantification i.e. they can be measured in real dollars. In general the results the businesses are looking for can be broadly categorised as PRAISED items as follows:
P roductivity gains
R educed cost
A voided cost
I ncreased revenue
S ervice level improvements
E nhanced quality
D ifferentiation in the marketplace
If a software development project can deliver on one or more of the PRAISED items then it will have delivered real business value back to the business as a whole. PRAISED items are not part of FDD - it is something I have learned over 20 years about delivering real business value back to businesses.
Many consultancy firms take the wrong approach to delivering real business value. They try and force a piece of technology onto a business with little or no understanding of the business as a whole and the impact that technology will have on the business. Some of this can also be self-inflicted by the business in its desire to gain a competitive edge and have the latest and greatest innovative new technology implemented within its firm without thinking through all the implications of doing so. We will see shortly how FDD avoids this classic mistake from happening.
Another common mistake many consultancy firms make is that they tend to talk technology to business people whom, because this is not their area of expertise, are unfamiliar with the language of technology and all its three letter acronyms. This tends to lead to a lot of confusion and frustration on both sides as they are unable to communicate effectively with each other and as a result fail to get the results they are both looking for. FDD has built in naming templates that avoid this breakdown in communication and allow both parties to use a common language.
As I stated earlier FDD instantly appealed to me as my firm prefers to take a business first approach also and talk business to business people and then technology to technical people once we fully understand the business and its unique business problems. As a result we often take on the role of the trusted advisor acting as the go-between between the business people and the technical people who find they can suddenly communicate in more meaningful ways and achieve results they never before thought possible. Now that we have qualified what we mean by business value we will now explore how FDD delivers on and relates to this.
FDD and Business Value
FDD has as its basic tenet that the features being delivered in a software development project must be "client valued". That is, they have to have some real tangible benefit to the business to be considered as part of the feature list for that project. Generally if it doesn’t have some business case behind it, then it should not be considered as a feature. FDD also reflects business value in the way the feature list is categorised and broken down into a hierarchy of business activities. These business activities are sets of features ("client valued" items) that will be delivered by the project to the business.
This means that when a business person looks at the feature list everything on that list will have some meaning to the business as a whole. For a technical person one of the most frustrating things is to expend time and energy on building something only to be told by the business person "oh that’s not what I wanted". Having the business people involved in helping to define the feature list of what is to be built helps avoid this situation.
FDD is an all inclusive methodology in that all the stakeholders in a project get involved in developing the feature list; that way there are no surprises for any of them when the thing is finally built. FDD is not only inclusive at the up-front design and planning stages but all the way through the software development lifecycle. The reporting mechanisms are for all involved.
The design is on-going and iterative involving everyone. By being inclusive the methodology ensures that real business value is delivered as everyone is firmly focused on and working towards the same set of goals.
FDD is also an agile methodology; remember what I said before about a business not being able to wait a long time for results. FDD defines its features as anything that can be built in 1-10 days effort. Anything larger than this is broken down further until it meets that rule. The emphasis is on as granular or fine-grained features as possible. Thus, most features are about 1-3 days of effort.
The FDD development cycle is dependent on how often you choose to do the release meetings - the checkpoint that collects dates and publishes all the reports, etc. We will typically meet with our development teams first and then meet with and report to our clients on a weekly basis. This depends on what we agree with both the client and the development team. We generally run a two week release cycle where we do a build of working software which we will then make available to the end-users for testing. Only the items that have made it to the FDD promote to build milestone will be included in the release.
From what I have observed most FDD projects typically use a two or three week development cycle. Because of this short development cycle the business gets its results quickly. At each steering committee meeting the business people get used to hearing the word "complete". And when FDD mentions the word "complete" it really does mean complete - the feature is now ready to go into a businesses production environment. This is great for getting management buy-in into the methodology.
Being an agile methodology FDD has an emphasis on producing working software.
Usually traditional "waterfall lifecycle" projects have suffered from a fatal condition known as "analysis-paralysis". I say fatal because research has shown that 80% of projects don’t actually get past the requirements definition stage. In the Chaos report published in 1995 by the Standish Group, 15% of the projects they studied were considered a success this only rose to 34% by 2003
In the past, they would wait and wait for wads of documentation to be completed before any real results are produced, consequently they would get frustrated by not being able to service their business needs and cancel the project and start again.
With FDD they start getting used to seeing working software instead of wads of documentation and as that working software is rolled out they start realising the business results and consequent business value they were really looking for in the first place.
A Brief introduction to FDD
So what is this FDD thing all about anyway? I hear you ask.
Well, the following is a very brief introduction to FDD in layman’s terms.
Firstly I must state that FDD is no silver bullet (The Silver Bullet was first described in the book The Mythical Man month by Fred Brooks). In fact there are no silver bullets to delivering software development projects on-time, to-budget with agreed functionality. That takes hard work, patience, commitment and skill. FDD is a methodology, a good one, but just a methodology none the less. It is not designed to be followed rigidly or to replace good common-sense. FDD does however require street-smarts to be able to decide where, how and to what extent to adopt and adapt FDD to your particular business.
What is FDD?
FDD stands for Feature Driven Development.
Feature Driven Development is a process designed and proven to deliver frequent, tangible, working results repeatedly. FDD is a straight-forward, no-nonsense, common-sense, industry proven approach to software development built around a well recognised core of industry best practices.
Where did FDD come from?
FDD was developed in the field; it first came to prominence in 1997 in Singapore on a banking project known as PowerLender where Jeff De Luca was the Project Manager. Jeff had a bunch of processes and practices he'd been using for years. Peter Coad, who was brought on to do an initial up-front modeling exercise on the project, introduced Jeff to the concept of a fine-grained feature. Jeff then took that concept and implemented it throughout his process framework.
Over time a lot of other people have contributed in some way or another to what is now known as FDD. However the main drivers behind FDD have been Jeff De Luca and Peter Coad, with Jeff being the original inventor and owner of the methodology.
So why use FDD?
To quote Jeff De Luca "To enable and enforce the reliable delivery of working software in a timely manner with highly accurate and meaningful information to all key roles inside and outside a project."
FDD is a simple easy to understand and easy to implement methodology that:
FDD makes use of a core set of industry best practices which include but is not limited to:
Domain Object Modeling is used extensively in FDD. The first process of FDD is in fact the development of an object model representing the problem domain for the project. Initially this model is just a straw man representing more shape than content but the details quickly start to be filled in as the project progresses. As each new feature is addressed, a small design phase ensures the details fall into place quickly so the build can proceed.
An example of this modeling technique is shown in Figure 1. Note the use of sticky post-it notes which get put on a wall to show the model. That way the model is dynamic it can be easily changed as new ideas and requirements come to mind. By keeping the modeling rules simple the business people can participate in the modeling exercise without having to know all the technical details.
For those who want to know the technical details, FDD makes use of some innovative modeling techniques. The most notable are the use of Colour and the use of Stereo Archetypes. Colour is used to differentiate between such things a Role (Yellow), a Party / Place / Thing (Green), a Description (Blue) and a MomentInterval (Pink) as shown here in Figure 1:
Figure 1 - Colour Modeling example / Copyright © 1997-2004 Jeff De Luca
Each of these is describing a Stereo Archetype. Stereo Archetypes are similar to the concept of Design Patterns but in an object modeling sense, they represent solutions to common problems that keep occurring in the real world. Jeff has put these together with a set of rules that govern them into what he calls the ADS or Archetypal Domain Shape. Almost any problem can be modeled by the use of the stereo archetypes contained in the ADS. Each one of these interacts with the other in a set way typically in the order of Blue->Green->Yellow->Pink. I wont go into all the details of what each of these is as that can get quite complex and is best left as the topic of a separate article.
FDD places emphasis on customer participation, by including the customer in the initial up-front and subsequent design sessions. The customer starts to buy into and take ownership for the project and the final project deliverables. For the developers this allows them the opportunity to see how and why things are done within the customers business and who and what interact with the feature in question. It is also a great way of building a rapport between the customer and the development team. It also gives both the customer and the development team a new perspective on the issues faced by each of them during the project.
As the name suggests FDD is "Feature Driven", meaning it makes use of the concept of a "feature".
The term feature is very specific; a feature is a small, client valued function expressed in the form: <action> <result> <object>.
A feature is:
Feature examples:
The use of a naming template for the features helps when you are discussing these features with business people. The business people can understand this language and there is no technical jargon for them to have to decipher. They also understand that anything that makes it onto the feature list is going to have some real value to their business.
FDD places importance on "ownership". It makes use of "class owners". When a Chief Programmer (a role within FDD) schedules features for design and build, he puts them in a workpackage. A Workpackage cannot run longer than two weeks but they could be less. At a single point in time there will be multiple workpackages active, each at different stages.
Each feature is assigned to a team member who then becomes a "class owner"; this means they take ownership of that feature. Each feature the developer is given ownership of now forms part of their workpackage. It is now their responsibility to deliver that feature and in doing so become the expert on that feature. If another team member needs information on that feature this person is whom they would turn to first.
Teamwork is an important part of FDD. It has a concept known as feature teams. Feature Teams form dynamically. These teams represent people working on a single feature or group of like features. At any point in time a developer may belong to one or more feature teams collaborating as needed with other project team members within a feature team.
Figure 2 - Feature Teams / Copyright © 1997-2004 Jeff De Luca
FDD tries to prevent problems before they happen. One of the ways it does this is through the use of Inspections. Inspections have been proven over time to be one of the most highly effective yet under utilised methods for preventing errors in software. FDD has two types of inspections. The first is a design inspection. As designs are done they are inspected. This is more of a sanity check than anything to see if the team agrees with the chosen solution. If not the design is scrapped or modified until the team is satisfied with the chosen solution.
The second type of inspection is a code inspection. Code is chosen for inspection and checked for such things as adhering to coding standards, potential bugs or logic errors. Inspections are also great learning opportunities particularly if your teams are made up of a mix of both senior and junior developers. They can be a great opportunity to share knowledge across the team as well as help to identify potential problems before they happen.
FDD is a highly iterative and incremental methodology. One of the most powerful concepts of FDD is the production of regular builds of working software. This concept really represents the use of continuous integration that can prevent many problems that might normally only show up later in a project by identifying these problems early in the projects lifecycle so they can be corrected earlier.
Another powerful concept of FDD is high visibility and reporting of results. FDD provides a complete reporting mechanism for all stakeholders in a project as part of its process. The project reporting happens by default. You no longer have to worry about how you are going to collate all the necessary information in order to know if the project is on track. FDD will accurately record this information by default and provide a simple, easily understood reporting mechanism. To provide this reporting by default FDD makes use of a number of milestones within each feature and assigns each certain weightings as indicated in Figure 3. At its simplest you just sum the weightings for each of the completed milestones in order to get your percentage complete for that feature. So there you have it instant reporting.
Figure 3 - Feature milestones / Copyright © 1997-2004 Jeff De Luca
The first three milestones above form what is known as the Design by Feature milestone and the last three milestones are known as the Build by Feature milestone.
FDD again makes use of colour to show progress status, White is not yet started, Blue or Yellow is work in progress, Red is needs attention (behind schedule, etc) and Green is complete. Each feature is colour coded to show its progress status on what is known as the Plan View report as shown in Figure 4. When the plan view reports are printed out they quickly give you a sense of how your project is progressing. These can be put up on a wall to give the big-picture view of the project from 30,000 feet. If you want the details on a particular area you can quickly zoom-in (i.e. move closer to the wall).
Figure 4 - Plan View report / Copyright © 1997-2004 Jeff De Luca
Another innovative reporting mechanism is the summary reporting through the use of the car park or parking lot report. The business activities are shown as if they were the lines in a car park on the concrete with a progress bar and other summary information. Again the same colours the plan view report uses are used to quickly highlight progress status information see Figure 5.
Figure 5 - Car park or Parking Lot report / Copyright © 1997-2004 Jeff De Luca
FDD lends itself readily to the use of repositories or knowledge bases of information and the publishing and dissemination of that information which ensures high visibility and reporting of results. These range from simple pen and paper solutions through to enterprise level solutions where all project stakeholders can see the project progress reports.
FDD consists of just five processes as follows:
Figure 6 - FDD Model / Copyright © 1997-2004 Jeff De Luca
As can be seen in Figure 6, FDD has two phases - a start-up phase and a construction phase. Each phase has a series of processes associated with it and each process has one or more deliverables associated with it. The start-up phase is short and once off whereas the construction phase is made up of many short iterations (between 1 and 10 days) which together may last many months.
The start-up phase consists of the first three processes.
The first process is to develop an overall model, here technical people work in collaboration with domain experts (usually business people) to derive the shape of the system to be built.
The second process uses the information derived from this modeling activity the team produces a categorised list of features. The categories used are:
Subject Area -> Business Activity -> Feature
In the third process a plan is derived from the features list and features are assigned to class owners who then take responsibility for them through to their implementation. When planning an FDD project the basic rule of thumb is that for every week spent in the up-front design process there will be 3 months of development time required to build the system.
Once the planning process is complete there is enough information for the business to make a go or no-go decision on the project.
By conducting these first three processes the business now has a low-cost, high-value, low-risk assessment as to whether there is a real business case to develop a solution to solve a particular business problem. These first three processes have also taken a very short amount of time to achieve - typically weeks. With all this information in mind the business can now make a well informed decision as to whether to proceed with the project or not.
The construction phase consists of two processes.
Design by Feature and Build by Feature, as their names suggest means there is an initial design process followed by a build process. It is in this design stage that the details of the object model are fleshed out in collaboration with the customers’ domain experts. Once all the details have been identified a design is finalised and then inspected and once passed the solution is built and then inspected again before being promoted into the build.
Note the term "promoted to the build", a feature is not considered complete until it has been promoted. That is it is now working software ready to be tested by the customer. It is not half-working, it is not nearly there, there is nothing whatsoever left to do on this feature except for the user to test it.
When FDD says a feature is complete it means it. Developers tend to have a problem with this concept, it is too black and white for them. If you ask a developer if he has finished a particular feature you might get some answer like "Yes its finished, but I just have to do …" this answer means it is incomplete - it will not be promoted to the build. Once the developers get through the first few iterations they quickly realise what the word "complete" means and what it really means to promote something to the build.
By having this "promote to build" milestone FDD reduces the risk of a project failure by ensuring that only working software is ever produced and provided to the business.
Conclusion
I know this has only been a cursory look at FDD but even though it is a simple methodology with only 5 processes the depths and nuances that it contains can be quite complex to describe. Indeed books have been written on FDD and even they do not cover all the details. This isn’t surprising given that FDD is drawing on 30 years of industry experience and best practices and Jeff De Luca’s own insights into how to make best use of them.
I hope this article has given you some insight into its value as a methodology that truly does deliver real business value.
How FDD delivers real business value that can be broadly categorised via the PRAISED items I mentioned earlier.
|
P roductivity gains
|
Short release cycles with short iterations that deliver working software. Focused development efforts through the use of features and workpackages. |
|
R educed cost |
Higher chance of project success by involving the customer in every aspect of the design. Being able to develop business systems in a way that allows the business to quickly react to changing conditions in the market. |
|
A voided cost |
By finding problems early through inspections. The high cost of "Analysis Paralysis" is avoided. Project success rates increase avoiding the cost of failed projects which have to be restarted or abandoned. |
|
I ncreased revenue |
Having business systems delivered to the business in a timely manner allows the business to get on with its core business and react quickly to market trends. |
|
S ervice level improvements |
Having good systems enables the business to better service its customers. Employees enjoy a working environment where business systems support their ability to perform their jobs. |
|
E nhanced quality |
The use of inspections means the quality of the business solutions delivered to the business increases. |
|
D ifferentiation in the marketplace |
Being able to deliver on promises to customers by having business systems that support the core capabilities of the business in a timely manner. |
I said at the beginning of this article that I will let you draw your own conclusions as to whether this methodology is right for you and your firm.
All I can do is tell you that it has worked for us. Since adopting this methodology we have had a number of successful projects delivered on-time, to-budget with agreed functionality.
Although we had of course done this in the past, we had never done it with such ease as we have experienced when using FDD. In the past it was always a constant struggle to collate all the information to produce reports for our clients, in some cases it would literally take days to produce these status reports. Now it takes us only a few seconds to print out these reports based on the data we have constantly kept up to date in our FDD knowledge base product.
Since adopting FDD we have had clients compliment us on how well our projects have been run and in particular how we have been able to engage everyone from their organisation in their projects. Our clients have told us how pleased they are with the finished results and how sure they are that the finished results will deliver real business value to them for many years to come.
For my business FDD is definitely the way to do projects. We have only just begun implementing the methodology. There are many more techniques and best practices it contains that we can adopt and adapt that will enhance our ability to deliver real business value to our clients.
And in the end anything that allows us to deliver real business value to our clients is welcome in my business. After all if our clients are doing well, then so are we. FDD has certainly been a welcome addition to our business.
For further reading on this subject I would suggest the following web pages:
|
The FDD community webpage. It has discussion forums, resource pages and further reading. |
|
|
Jeff De Luca’s company home page provides details of the FDD processes as well as training courses and further reading. |
|
|
My company’s home page. The support link provides knowledge base articles that explain certain aspects of FDD. |
Thank you for taking the time to read this article. Your feedback is always welcome.
References
Jeff De Luca is the original inventor of FDD he runs his own consultancy based in Melbourne, Australia see www.nebulon.com for more details and further details on FDD. Jeff has kindly allowed me to use some of his artwork for this article and has provided some editing of this article.
Copyright © 2004, IT Project Services Pty. Ltd.