Hi
I am looking for improvements in my organisations development practices. I have been looking into the various agile approaches and the one that appears to most fit our organisation is FDD. There does not appear to be a lot of activity (forums, newsletters).
Do we know how prevalent it is in the industry. Have people tried it and decided on the others.
I am just interested in opinions before I embark too far down a road.
Thanks
Ron
how relevant is popularity?
Hi Ron,
since it already resonates with you my advice would be to try it and if it works keep using and if it doesn't then try something else.
Here's my open and honest thoughts on this.
It's easy to form that opinion. I do nothing to evangelize fdd or promote it in that way. The Rx to do so is simple and well known. You regularly publish content at places like this or via newsletters and at other sites, you get a USA-based person to be an evangelist, you get back on the speaker circuit and do the conferences, write articles, write books, re-establish a presence at the agile community, and so on.
I don't do any of that in way that would make a site like this or fdd in general appear vibrant. I did used to speak at conferences, and still do rarely, and I did speak at a couple of agile conferences but I haven't been for several years now. Some think that's because of the infighting that started to appear at them (people being dogmatic about agile is ironic don't you think?) but that wasn't the main reason. It was because it costs money to appear at a conference and the agile conference never led to any business. Other conferences did.
I've never written a book on fdd and I've no plans to do so (note: I did come close at one point, but my publisher said one thing, then did another, and despite their being a book approval I walked away from it).
I like to run projects and do my consulting. I'm not that interested in the marketing and promotion that this would take to give the appearance of a highly active community. I've wanted to (for a couple of years at least) change this site to not give the appearance of an active, community, participatory site. Again, that appearance is part of what leads to the perception. You look at active topics for example, and they are few and infrequent. On the other hand, occasionally someone asks a question that gets and answer and that is helpful. That said, most of the really good questions have already been asked an answered and that is what is captured here in various discussion threads.
Some years ago, Cutter produced a study that said fdd was the 2nd most popular agile method (or maybe it was 3rd but by a small margin from #2 - I don't recall anymore). Would that still be the case today? I doubt it, but then again, I would have doubted that survey result back then. So who really knows.
If you go to the agile conference or an agile company like rally, they'll tell you the world is going xp and scrum. Well that's true; THEIR world is going xp and scrum. But there's a much bigger world than that community or a company whose purpose is to sell you xp and scrum services, and fdd has a different appeal and has resonated much more strongly with corporates. That's the larger world I see, but at the end of the day I'm happy with people using whatever works. Just as long as they do something that works!
Finally, when can popularity matter? risk reduction in that something more popular means there are more places to go for help such as books, classes or people. From what I know of fdd adoption, there's already more than enough of it around for risk to not be a factor and of course there's the other view. There might be lots more XPers out there - but would you want them?
If it doesn't resonate with you, it really doesn't matter how many people are using it.
Thanks for the reply. Your
Thanks for the reply. Your response gives me a little more confidence. I am planning to put together a proposal to management in coming weeks and I may have some further questions.
Ron
FDD works, but adapt it to your project and culture
Ron
I have applied FDD on three projects and found it to be very effective. The tecnique of breaking a large problem into parts makes good sense but FDD tries to at least get a handle on the whole problem (as far as that can be discerned quickly - you will never understand it all up front) and form feature sets. This framework allows you to answer the 2 key questions "How far along are we?" and "How long 'til we're finished?". You can't get answers to these questions from a SCRUM backlog.
The FDD reporting (especially the parking lot) is very simple and clear to all parties involved (techos, PMs, analysts, testers and the business).
The main challenge is to effectively capture and manage requiremenst as they emerge (and they will!) while still demonstrating and repoting progress. At least with FDD, when the % completed goes down you can point the Steering Committe or Project Board at the extra features that caused the shift. They can then slap the business around, not the delivery team.
I'll post a bit more background on the projects (each about AUD15M, team of 20) tomorrow if I get a chance.
My view is there is no "one true way" but FDD principles, process and reporting do work. Usually a project demands you use "a methodology" and FDD is broad enough (and not so restrictive) that you can say "We are using FDD" but draw upon useful bits from other methods (SCRUM, DSDM, XP) in the process.
FDD is what Scrum wants to be when it grows up...
Not quite but I am seeing FDD influences appearing in Scrum contexts:
- parking lot charts in Mike Cohn's agile planning and estimating book.
- the use of feature teams as a way of scaling Scrum to larger development efforts in my Certified Scrum Master course.
- a slowly growing admission in artciles that there is work to be done (just enough only) on understanding complex problem domains and the necessary technical architure/infrastructure before the iterations start (sometimes referred to as Sprint Zero)
I think the bottom line is that FDD's influence is wider than the explicit use of FDD as 'the one right process'.
Personally, I'm doing more Scrum these days than FDD because I'm working on projects that are more about designing and rolling out design frameworks and tooling than developing software. Scrum fits better here because it is purely about managing teams based on a prioritised backlog and says nothing about engineering practises. There is considerable noise on the .Net and in books about using Scrum as a management wrapper around XP. FDD does not need this because it covers both areas more than adequately and, in practise, managing a Scrum project feels a little bit like leading an FDD project with only one feature team. This is probably why I'm fairly happy using Scrum but its not the full story; being purely a management warpper makes Scrum easy to adopt but does not necessarily improve the ability to design, construct and test more effectively.
After waiting for 2-3 years for De Luca to pull his finger out and write up FDD properly, Peter Coad gave me the opportunity to write a book on the subject. My book keeps dribbling out of places like Amazon so someone is reading it somewhere. However, it is only, a best effort 'Practical Guide to FDD' and not the more definitive work that we'd all like to see from Jeff but would inevitably open up more pointless debates about 'the one right process'.
FWIW: I've also worked on two eXtreme Programming projects in the last few years but by the time I joined, they'd both dropped pair programming, and had, therefore, lost nearly all peer-level checking on design and code quality.
I've not met any other agile processes actually in use in my travels so far. DSDM gets pushed hard in the UK but not encountered it in practise yet. Same for Crystal Clear, etc.
FDD in use
Hi Ron, Greetings from the United States.
The largest development project currently using FDD is Wells Fargo Bank. This is the biggest IT project in the bank. The business need is to de-silo its business to have an enterprise view of the bank. It is cheaper to get deeper into the pockets of existing customers than to get new customers. This is the business case for the project.
The most common implementation hurdle for teams is the necessity of modeling the domain. Domain modeling reduces risk and enhances the requirements discovery process. If the domain can be modeled in 10% of the allotted project time then the scope is correct. A project that has 1000 features in the final version typically has 300 of these features discovered in design. Just because you know an object oriented language does not make one a modeler. I look for musicians to model. Database people typically do not make good modelers. Some social scientist should pursue what makes a good modeler and get a PHD.
What entices firms to adopt FDD is "frequent, tangible, working results. Current agile methodologies are not nearly as structured as FDD and offer far less predictable results. There is no daily stand up meeting; everyone knows what tasks he is working on and on what feature is being produced. As a FDD project manager I can give you an accurate reports as to where you project is in percentage terms. This contrasts to terminally being stuck at 90% done and” we should be finished in about two more weeks - give or take a few days."
Wyeth in Cambridge Mass. has an incredible FDD team. This team really has delivered on the promises of FDD. Several team members have joined and exited this team over the years. There should be a talent pool of modelers and disciplined process folks floating around.
Once you adopt FDD I strongly suggest that you implement a knowledge management program to spread the methodology and improve your execution. You can measure the improvement from project to project. The key metric is the feature.
I hope this helps,
Bob
size
The largest development project currently using FDD is Wells Fargo Bank.
I'm currently running an FDD project in the USA that is bigger than the Singapore lending project. But who knows what others there might be out there that are even bigger.
FDD - pragmatic agile that works
Hi Ron,
I've been an FDD proponent for some time. You can read a little about my experience using FDD in real-world applications here [http://www.looselycoupled.com/stories/2003/agile-dev0710.html].
I had experience with more traditional System Development Life Cycle (SDLC) methodologies, including spiral (iterative) methodologies before I found FDD, but upon finding it I was immediately impressed with 1) FDD's simplicity; and 2) FDD's boldness. FDD is the only methodology I've encountered that's bold enough to provide reference guidelines to an estimated level of effort for the different activities that take place, and even provides some high-level naming templates that can help teams new to FDD get started. I've also found the uptake on FDD to be less challenging and confusing than it can be with other agile methodologies (I'm a ScrumMaster, and like Steve use the Scrum framework when it's appropriate). FDD is simple and familiar enough (to legacy SDLC methodologies) that it can be conveyed and put into effect quickly and naturally; something that can be more challenging when you have teams with limited experience, and with all the experience that they do have -- including related lecturing at school -- focusing on non-agile methodologies.
Regarding community, I echo what Jeff and Steve have already said. The impact of FDD is broad, with the concepts being adopted in various other agile practices. Actually, I find the entire agile community to be open and receptive to each other's ideas, and it's not uncommon to find teams which use combinations of FDD, Scrum, and XP. I'm sure you've already noted how open minded Jeff is about methodology. Every time I hear (or read) him speaking about methodology, he encourages people to use what works. If they're already using something that works, he advises they stick with it. For many of us who have tried various things, FDD works!
While the forums here may not appear too active, I think you'll find if you have questions you'll get quick responses, from people who use FDD in the trenches.
If you're looking for something that is clear, concise, and works, I would encourage you to give FDD a try.
Thanks,
Vernon
Jump in! The Water's Fine
Ron, depending on your org's culture and how much you have to sell an idea... i found great success by merely doing now, and asking forgiveness later. much easier than asking for permission
though one might expect that sentence to be followed by one of those "In all seriousness..." paragraphs, I am serious.
besides, you can always bend any process to sound like another -- if you squint hard enough. i can do waterfall... every 3 weeks
my personal style done over the past decade on many successful projects is a blend of FDD, XP, and Scrum. Varies based on project, team, culture. I never even say what the process is. Other than "agile." I just do it. the team just does it. the companies are happy -- if a bit uncomfortable to start.
so, if possible, just jump in and start...
-- jon
http://technicaldebt.com
FDD still relevant?
Reiterating points above I have now used significant parts of FDD in three different organisations. I agree that the key is customising and tweaking any method to fit an organisation. What I have found especially important is that people need to feel that they have some input into the method. They want to own it. I am not sure if this is peculiar to just New Zealand, where I am working.
So rule number one - every project starts with the colour domain model. If you don't have the people or the knowledge to do the modelling you are not ready to start a significant project. If that is the only piece of the FDD jigsaw you use you have set your project off with more chance of success than any project that doesn't analyse their domain in a similar fashion. The obvious and not so-obvious benefits that stem from using colour modelling up front in a project are worthy of an article, and possibly a book all on their own.
Breaking the project down into features (or stories) comes next and is significantly easier with the model (and hence the scope) defined. From then on their are bits and pieces of other FDD pieces that I use. But again I am also using parts of XP and Scrum to produce a method that fits the organisation. While the parking-lot concept is also another large differentiator I have found the set-up and maintenance is cumbersome so in my current organisation we are using Rally. Simple out of the box tracking / reporting and charting.
The heavy marketing of Scrum and the recognition of the Scrum-Master certification is certainly helping it gain traction. But I also see experienced Agile project managers extending it to use FDD principles.
Julien Thomas
books/articles
You are right about that and this is a book that I really would like to write. I do have a book project and I have written about 60 pages, but that project has been stale for about a year due to heavy work commitments. Basically, the book is about application architecture. It will cover color modeling, but also the process for doing it (never documented before) and also cover the various aspects UI-PD-SI and separation, packaging, persistence (use a tool), and so on.
Something else I'd really like to write about is build and scm. It is so fundamental and so poorly understood and implemented.
Jeff
Colour modelling up-front
Here are some of the benefits that I have personally experienced with modelling workshops up-front (in no particular order):
- Colour modelling workshops are a fantastic team-building activity which also serves to highlight team personalities (and issues), and some strengths and weaknesses
- The domain becomes a shared language between business and IT and amongst project team members
- A common and deep understanding of the business domain, processes and business requirements is gained by participants
- Bridges the transition from requirements into design and build; enables the team to move rapidly from analysis activities into build activities
- The model is directly implementable in (object-oriented) code; code can be generated from the model
- Modelling confirms scope or where there are scope decisions to be made
- Modelling confirms business requirements (for the business domain; not for the UI and other areas not in 'model' scope) and highlights where requirements are poor or business domain knowledge is lacking
- Encourages business decisions to be made
- Gives an indication of overall project size; focusses on progress by putting 'ratholes' - other areas that need to be addressed - to one side
- Encourages participation from all team members in the project process
- The modelling workshop is a major milestone and reference point for the project
- The colour model conveys a huge amount of high-quality information and becomes a reference model for project members (not just developers but business folk as well) that is used to facilitate high-quality discussions of the domain and requirements; there is shared ownership of the model
- Model notes capture essential information about the business domain which can be transferred into code comments for the domain classes
- Modelling workshops encourage direct participation in the project by business stakeholders and SMEs - they get to know the technical team and in doing so learn some of the complexities of software development projects, which in turn leads to more realistic project goals. Technical team members get to see the world outside of their IDE.
- If modelling directly involves business SMEs there can be less laborious requirements gathering and documentation phase by other business proxies (I mean BA's), with less errors and time consumed by the technical team translating the requirements documentation
- The team get to understand consensus and how the team as a whole is more important to the success of the project than any given individual. Other team norms are established that tend to be adhered to throughout the project lifespan
- Discourages speculation about the requirements or technical team members inventing requirements
Modelling comes with a few gotchas of course, but these are far outweighed by the benefits.
There is a lot more to be said about approaches or techniques for colour modelling and the workshops. I'm looking forward to the book Jeff
Hugh Beveridge
FDD is more than a methodology...
I've been using FDD since 2003, after reading Steve's and Mac Felsing's "Practical Guide to FDD". Since then, my whole Software Engineering and Project Management universes have changed! :)
It's so pervasive in my thinking and practice that I don't regard it only as a "methodology", but as a philosophy and a meta-process. It drives my thinking and I use it to build other processes. As an example, I used much of FDD principles and concepts to manage a project to map and model business processes, not even remotely close to a software environment!
Having tried XP, RUP and other approaches before, FDD answered much of my questions and is a perfect match to my style. I also attended a CSM class, but didn't see much use of Scrum in an FDD project. I only use Scrum to introduce Agile thinking to FDD-unaware audiences, but as soon as possible, I make sure my clients get a good understanding of FDD science.
Some other things I use to empower FDD even more:
* TOC (Theory of Constraints) as a complement to build strategies, conflict resolution, retrospectives, collective thinking, and much more. FDD systemic approach is a perfect fit with TOC.
* BPM (Business Process Modeling) using some lean notation, such as EPC/VAC (IDS Scheer Aris, SAP R/3, Visio, etc.), particularly on or before process #1. It helps on requirements discovery, domain walkthroughs and modeling in color.
* Mind Mapping to capture and communicate domain knowledge in the SME walkthroughs in processes #1 and #4.
Also, for organizations seeking CMMI, particularly maturity level 3, FDD is the quickest and best alternative I've ever seen!
Here, in Brazil, I'm the major promoter of FDD through workshops, articles, presentations, consulting, coaching and mentoring, but there are other people talking about and teaching it as well. The interest is growing fast and we have a good number of users (we have our own Yahoo group in Portuguese).
Regarding FDD lack of popularity, I'm not worried about it. In my opinion, there is much noise about XP and Scrum, many people claiming that are using them, but few are really doing them right and completely. FDD, on the contrary, is less talked about, but its users are very happy and bold!
My advise to those who are "worried" about using FDD or not, is this: competitive advantage is not mandatory, it's an option. FDD doesn't need defenders, it's solid enough to stand for itself. ;)
All the best,
Adail Muniz Retamal
www.heptagon.com.br
FDD - is it relevant
Anyone who has taken a serious look at FDD will know that FDD has a lot to offer the Agile community. I don't want to get into a philosophical debate about Agile processes, but I've had exposure to XP, Scrum and FDD and my preference will always be FDD. IMO what FDD lacks is the sort of awareness and marketing that other Agile processes have had, and continue to get. I could draw some analogies between the popularity of operating systems here (for arguments sake, let's take Windows vs Mac), but that would be trite
Let's face it, FDD is not marketed as good as it could be. Jeff may not like playing the evangelist, but he's definitely the man to do it (attend one of his workshops and you'll know what I mean). I don't deny there's serious effort involved doing this, but the fact that we see a question like this posted on the FDD website indicates we're probably not doing enough to keep FDD up there with more actively marketed processes (however tempting it may be to blame it all on Jeff 
).
So, is FDD still relevant? More than ever. And there's a decent community of active supporters and users willing to help and offer advice. My best advice is to get yourself and a bunch of developers onto a FDD training workshop and give it a go.
Cheers
Jason
FDD is certainly popular in Melbourne...
Local projects often don't start out using FDD. This is usually because project managers do not have any genuine exposure to agile project approaches or have allegiances to legacy project methods sponsored by global consulting organisations.
However, when the pressure starts to build and folks start to get focused on delivering software it is FDD that is most frequently selected.
we're all individuals; no we're not!
Hi Jason, that's a fair cop and mea culpa.
So what do we all do? I will gladly steward if there are activities to steward, but I can't be the sole driver. If people simply start writing here, that little snowball will start rolling and get bigger...
Quite, and very
Hi Ron,
The question of popularity is a tricky one. As Jeff has already pointed out, there doesn't seem to have been any good surveys done on this recently (which would make an excellent Software Engineering paper), so it is difficult to quantify exactly. FDD does appear to be up there among the better known approaches, so it appears to be 'quite' popular. But the most popular isn't always the best, and you really need to choose what is most appropriate for your situation.
FDD probably doesn't have quite the mindshare that XP does (just to pick a random example) because it doesn't have quite the same evangelical culture, or a figurehead focused on the book publishing and conference/speaking circuit (trying not to sound too cynical). FDD practitioners seem to be more of the get-on-and-do-it rather than get-out-and-talk-about-it types
but you'll probably find plenty of people who, when asked, are happy to talk about it.
I can say without hesitation that FDD is every bit as relevant now as it was when it was first named. You can think of it as a collection of "best practices" that have been honed and refined with years of experience, and they are not specific to any technology or time. FDD is practical and pragmatic, not dogmatic. And there are now many success stories out there in industry.
As for visible activity, the forums here seem to have bursts of conversations, and invariably result in very high quality discussions, with lots of interesting perspectives. So any lack in quantity is made up for in quality.
I have used FDD very successfully on several of my own small projects in the past, as well as having worked on two large projects with Jeff. I'm in the process of slowly introducing its practices where I work now. Change can be a slow process, but already we've seen some very positive outcomes.
I encourage you to give it a try, and come back and discuss your project and bounce around ideas with the community here.
Best regards -
:: Gavin Baker - http://antonym.org/
FDD is very relevant
Hi Ron,
I think that rather than look at each individual practice and discuss the pros and cons, what you need to do is be clear on what is it you want from a new development practice and then assess which of the available practices is best suited to the needs of your organization. It’s not about whether scrum or xp is better than FDD it’s about which process best meets your needs.
I can’t speak for many of the development practices as my experiences are based heavily on FDD, but what I can do is tell you what my experiences have been.
It was circa 2000 and I was the Development Manager for a large web development firm (approx 200 staff) and it was at the tail end of the dotcom boom. The company had grown rapidly over the previous year and the processes hadn’t grown to match it’s size. Getting things done became more and more complex as more overheads were involved, politics started to get in the way, the focus on getting the work done seemed to have become second place to whatever career games people were playing. Not to mention the fact that many of the people employed didn’t have the right skills. There was no consistent approach to any project in terms of people, process or technology. Each project was unique, the only thing projects had in common is that most of them were in trouble.
In short, things were a mess. We had unclear changing requirements, constant scope creep, unrealistic deadlines and low morale. It wasn’t a fun place to be. (Note: I’m now playing the role of senior project manager in a different web firm and although it’s 8 years later, the situation isn’t that much different).
My gut told me things didn’t have to be this way and on that point I was right, the question was how to bring about improvements? Given my authority was related to development, I started there. Some problems I wasn’t going to be able to address directly, eg. Unrealistic deadlines were the result of the account managers selling a project with a timeline that wasn’t agreed to by the project team. What I could do is work on finding a consistent way of developing projects that made sense and felt right.
The key terms here are “made sense” and “felt right”. When I use the term “made sense” it means that the process had to be practical and pragmatic, not academic or theoretical. It had to be derived from actual practices, not the musings of some professor of software engineering. Something that had been proven to work time and time again. The second term “felt right” is also important. It’s easy to underestimate the role of the organisation’s culture. The culture I was in was very “dotcom” and we had the usual pool tables, bean bags, dyed hair, hawian shirts of the day. Trying to bring in a process that was highly methodical wasn’t going to take, it would be rejected before even getting to step 1. There was also the fact that a lot of people in the industry (and my organization) lacked a strong understanding of the SDLC, many people couldn’t even tell you what it stands for. Ironically, that’s still the case where I work now. So, to cut a long story short, we needed a set of evaluation criteria that would help us to pick a practice that would fit with our culture. This is what I came up with.
Complexity
Too complex and people will have trouble using it
This not because back in 2000 people weren’t very experienced, it’s simply a part of human nature, the more things we need to deal with, the harder it is. The more complex the instructions, the harder it is to learn. That’s why the iPod has been so successful, it’s so simple.
Size
Too big and people won’t even try it
This is a part of the challenge of trying to institute change in any organization. It’s very difficult to implement large changes across the board and it’s not advisable to try. Keep it contained and you stand a better chance of it succeeding. In this case, I didn’t want to try to tackle the entire life cycle from sales through to support. I wanted to focus purely on the development process.
Cost
Don’t want to break the bank
In my case, even though the company had money, it wasn’t about to spend any on new practices. It just wasn’t that type of company. They were happy to “wing it” and work things out as we went along. They didn’t see the need to invest in process improvement in order to become more efficient and therefore more profitbable. Once again, that’s same situation I face at my current workplace.
Pragmatic
Derived from practice, not theory without successful practical application
As I mentioned earlier, and this is probable a reflection on my mindset, I wanted something that I knew already worked and had been proven to work. I’d read enough about different theories of how to do things but what was lacking were real world examples. I didn’t want to try anything that someone hadn’t already tried and was successful with.
Risk
Chances of successful adoption of a large methodogy was low, best start with something achievable.
This is common sense, a large methodology wasn’t needed, our projects weren’t that large, from 4 to 8 months. I didn’t need a solution for $1mil+ budget projects, we just didn’t have to deal with that.
So, now that I had my assessment criteria, I went about researching different practices. I had a number of vendors present and I also spoke to all my developers to get their experiences. Together, myself and my development team looked at all the available options. Back then, there were no agile practices so we were stuck with RUP, Process Mentor and a number of in-house practices that my developers had learned from their previous jobs.
We were still searching when I came across FDD. It was actually by chance. Jeff Deluca was doing a presentation on a round trip modeling tool to my development team. At the end of the presentation he still had 15mins left so gave a quick talk on FDD. I’d pretty much ignored the presentation to that point given I wasn’t that technical but when Jeff started talking about FDD I sat up immediately and paid great attention.
In that fifteen minutes, Jeff walked through the 5 steps of FDD. I got it, and the rest of the team got it. On the surface it seemed to match the evaluation criteria perfectly. But, I wanted to be sure before doing anything. So, I asked Jeff to return and give another, more detailed presentation on FDD. It was after that presentation that I met with my development team and we decided that of all the practices we had looked at, this was the most appropriate and we were willing to give it a go.
The next step was training. I organized for Jeff to run a 5 day training course. At that course I had representatives from all the main disciplines of the company, project management, business analysis, design, development and testing. At the end of the training, the feeling was even stronger that FDD offered a way forward that we badly needed.
FDD was not complex, large or expensive. (it’s only 5 pages)
It’s from the field and easy to understand. (based on 18 years of experience)
It felt right and made sense (fun, understandable, AND, it works)
Ofcourse, that didn’t mean FDD was the be all and end all. That just doesn’t exist. After the training, we conducted a workshop to establish what we liked, what concerned us and what we were actually going to do. This is what we agreed on.
What did we like about FDD as a software development process?
Note: I think what is interesting here is that the “best parts” of FDD actually had little to do with development and far more to do with project management.
What did we dislike about FDD?
What can we successfully use from FDD in our work?
How ?
Of all the “How” tasks we identified, we actually followed through on all of them except for the colour modeling training. We found that just having worked together on process improvement improved morale. We didn’t get FDD established as the “only” way of doing projects across the business as in less than a year, the dotcom crash was upon us and the company pretty much imploded.
Since then, I started my own small business (http://www.designit.com.au) and for the past 7 years have been using a form of FDD to run my projects. I don’t follow the process to the letter as not all aspects of FDD are appropriate to my projects (I focus on implementing content management systems) but the overall principles still stand true.
I recently sold my business to a larger organization and have found a similar set of symptoms that I experienced 8 years ago and am working on getting them to think more in an FDD way. Not because I think FDD is the only way to manage things, I don’t but I also haven’t come across anything better in all that time. I’ve made adjustments and refinements to how I use FDD but the basic principles still apply and I can’t see that changing for another 8 years.
Hope this helps.
Cheers,
Marty
Martin Bauer
Senior Project Manager
http://www.martinbauer.com
Not very well known
Hi,
for Germany I can say that FDD is simply not very well known. But when I present an agile landscape in companies, a lot of companies like the basic ideas of FDD. And therefore I would say that we have slowly growing interest in Germany in FDD.
Stefan
Relevant only if you plan on using people.
My short answer is yes, it is relevant. Some great reasons have already been given. I’d like to add something I didn’t see here.
We’ve just started to implement FDD on a large project. We had numerous problems with our approach before; way too many to mention in a post. Some core issues were a lack of understanding the business need, and an inability to get numerous people marching in the same direction. In some ways this all comes down to good communication.
One of the things FDD brings to the table is a process that facilitates focused and purposeful communication. The modeling phase is designed to transfer business knowledge to the team. The model itself is used as a tool to facilitate communication, and to illustrate (communicate) the agreed upon scope of the project. The construction phase has checkpoints built in to communicate the intent of a construction effort (workpackages, design inspection) and to check the quality of that construction (code inspections (conversations)). The project management tools measure and communicate the progress of the team. The KMS helps communicate internally and externally to the team.
At the end of the day building software is about getting people that have varying skills to work together in “harmony”. It’s about building a team to build a product. My opinion is that other methodologies hyper focus on the inputs and outputs (what do I do and how do I measure I did it). What FDD brings to the table are best practices for getting a team to work well. There’s psychology in FDD. Unless you’re planning on building the application with robots, you need a bit of psychology. Unfortunately some of this goes into the realm of things that Jeff (or others) should really write down.
I would also like to echo something that was suggested earlier; get some experienced help. We are benefiting greatly from working with an experienced team of people. I would recommend reading Mr. Palmer’s book as a primer.
I'd also like to mention is that we've had much more success getting buy in from our business representatives using this process. The process really resonates with them. I've been most suprised with the affect the color modeling has had on our organization.
Jay
FDD - the way to go
Hi Ron
We have used FDD in four transport management related software projects here in Sydney involving from 5 - 15 people on a team. Three of the projects were of a soft real-time nature. As an approach FDD has been instrumental in the ability to ensure communication between all stakeholders. This was the main reason for selecting the process in the first place. In the first project our implementation of FDD was instrumental in getting a model that everyone understood and features that could be scheduled, tracked and traded so that the final hard deadline could be attained. While there were a few sceptics the results have been taken on board and all projects in the department are now asked to follow FDD as standard.
The key things we want and mostly get from FDD now are:
1) understanding of the domain by up-front modelling
2) software structuring using features
3) tracking of the project deliverables using parking lots and feature completion graphs
4) ability to present the project information at all levels using simple web pages or wikis (better tools would help though).
From my point of the view the system's approach embodied in FDD and the feedback from short deliver cycles are fundamental in delivering software that works - so from our point of view FDD is still very relevant.
TOP FIVE REASONS PEOPLE USE FDD:
TOP FIVE REASONS PEOPLE USE FDD:
1. Because you model your project up-front, you budget your project more effectively.
2. Because you get a truly holistic view of your project, you know exactly how far away you really are from being finished.
3. Because your team, SMEs and upper management participate and collaborate together, you end up building what they asked for.
4. Because you work hip-to-hip with your SME, your team and the SME share a common language.
5. Because your development team works iteratively and collaboratively together in phases 4 and 5 of the FDD process, you have a more effective, more satisfied a team.
This is probably why Jeff gets many calls to train teams on FDD, lead application development as well as rescue sinking projects.
Simply put, after I implemented the 1st FDD project back on 2002 on a mission critical application, there were no point of return but to continue to use FDD. FDD helped me retain talented individuals. My team said that the FDD process has changed their life and the way they manage, architect and develop application.
FDD changed the way we develop and manage software applications. FDD transformed us into an action- and results-oriented team that delivers on time within budget.
I would say try it -- you'll like it.
Munther Baara
Director, Clinical BSP
Wyeth