Agile Software Development using Feature Driven Development (FDD)
The manifesto for Agile Software Development says that while there is value in the items on the right, we value the items on the left more.
It is very easy to quickly react to these four simple statements. "How can following a plan be less important?" or "do we not even plan?" or "I believe and know that good documentation is key, how can that be less important?" and so on.
It is easy to label Agile as immature and lacking, or even hacking, but that is to completely misunderstand it. In fact, it takes great maturity to understand what these four value statements are really saying.
The fourth statement isn't saying you shouldn't plan. It is saying that responding to change is more valuable than following a plan. FDD plans and considers the plan a required part of any project. However, slavishly following a plan without being able to adapt and respond to change is a pattern for failure, not a pattern for success.
The second statement isn't saying you shouldn't document. FDD considers good documentation a required part of any project. However, toiling over documentation without producing any working software is a pattern for failure, not a pattern for success.
Agility requires great maturity to understand the balance between these items and what it really means to say we value the items on the left more.
Patterns of Difficulty
It is well documented that software development projects often don't deliver on time, or within budget or with the function that was agreed when they started.
We need to delve a bit deeper than just "they often fail or under-deliver." What are the patterns of difficulty that many projects have? It's often hard to know how to deal with users and integrate them into software development . As IT professionals, it can be hard when their language is so different from ours or when they aren't as accessible as we need them to be.
Capturing requirements is difficult and there's no agreed way to do so. (How often have you heard the question "what level of granularity should a use case be?"). Requirements are rarely as accurate as we want them to be.
After three months of project work, the persistence layer is done, the messaging subsystem is in place, the database schema and accessors are done and this is all important and significant work - except to those that commissioned the building of the software system. It's hard for a project manager to report and track progress in terms that aren't meaningful to the client and the sponsors.
Some things are best delegated to the correct project role and other things should be specified or bounded in advance. It's hard to know in complex systems what to do for which and to predict in advance how changing the detailed rules of individual interactions will affect the overall behaviour of the project (the system).
In the study of complex systems, the idea of emergence is used to indicate the arising of patterns, structures, or properties that do not seem adequately explained by referring only to the system's pre-existing components and their interaction. (Bechtel & Richardson, 1993)
"Complexity refers to the condition of the universe which is integrated and yet too rich and varied for us to understand in simple, mechanistic or linear ways. We can understand many parts of the universe in these ways but the larger and more intricately related phenomena can only be understood by principles and patterns -- not in detail. Complexity deals with the nature of emergence, innovation, learning and adaptation." (Sherman).
If there was just one message from Professor Fred Brooks in "The Mythical Man Month" it would be that "...it's not linear."
"By understanding industries as complex systems, managers can improve decision making and search for innovative solutions. ... Chaos [complexity] theory is a promising framework that accounts for the dynamic evolution of industries and the complex interactions among industry actors. By conceptualizing industries as chaotic systems, a number of managerial implications can be developed. Long-term forecasting is almost impossible for chaotic systems, and dramatic change can occur unexpectedly; as a result, flexibility and adaptiveness are essential for organizations to survive. Nevertheless, chaotic systems exhibit a degree of order, enabling short-term forecasting to be undertaken and underlying patterns can be discerned. Chaos [complexity] theory also points to the importance of developing guidelines and decision rules to cope with complexity, and of searching for non-obvious and indirect means to achieving goals." (Levy, 1994)
In project or development management the system we are building is the project. It is the project that will create the software system. Software development projects are complex systems. Software programs themselves are complex. Complex systems contain patterns that can be discerned and used.
"We cannot predict where a chess game will go, but we can learn patterns of play that bring success." (Highsmith 2000).
FDD was developed by Nebulon's Jeff De Luca over his years of extensive IT and project management experience. It incorporates several ideas and practices from the last 30 years of the industry. These include Harlan Mill's surgical teams, Fred Brooks' on scaling projects whilst maintaining the conceptual integrity of the whole, Jerry Weinberg's on software construction as a human activity, Tom DeMarco's on what a project is, Michael Fagan's inspections, Peter Coad who in 1997 introduced the notion of a feature to Jeff, and so on.
Jeff De Luca has blended these various ideas and concepts with those from his own experiences to create a 'recipe' for simplified, enhanced and measurable project management: patterns of play that bring success.
His Feature-Driven Development is a new, valuable and flexible tool that enables people - the essence of any project, IT or otherwise - to work in an efficient and productive way with a minimum of fuss for a maximum of output.
Patterns of Play that Bring Success
FDD understands, embraces, and accepts software construction as a human activity. Process is needed, as is technology, but it is the knowing of where to specify what should be done and where not to. That is, the essence of a well-bounded process is the recognition of people and their role in software construction projects, and knowing what needs to be written down (as a process) versus what is simply delegated to the right role. The patterns of play that bring success.
FDD is model-driven and it uses a breadth, not depth, modelling exercise at the start of a project as a knowledge transfer and requirements analysis activity that makes the rest of the processes work as well as they do. One of the keys to good object modelling is to model the domain - this is the very essence of object oriented. Since we are modelling the domain, and doing it with the users, the language used therefore must be the same. It has to be one of the outcomes of the modelling exercise that we are now all speaking the same language.
For a project manager, having an accurate baseline to track against is not only desirable but often a necessity in today's corporate world. To get an accurate baseline, there has to be some form of informational or analytical activity in order to derive the baseline. The modelling in FDD process #1 is that activity.
For a project manager, tracking and reporting progress to the client and sponsors in terms that are meaningful makes your job much easier. If all of the work in a project is expressed in client-valued terms, it also facilitates easier discussions regarding changes, scope creep and so on. Finally, it better focuses the project team as all they are doing is expressed in the language of the domain rather than the technologies in use.
There are only five processes in FDD of 1-2 pages each. The patterns of play that bring success to "on time, on budget with agreed function" delivery are captured in these processes. However, there is much more to a project than just this. Furthermore, there are elements of detail unspecified in the FDD processes. This is well-bounded, and the recognition of people and their roles, in action. FDD says you must design and code inspect. It does not say how. Your Chief Programmers (a role) will know how to do this, or will know to get a mentor in to show the team how at the start. (If they don't know how and they don't ask for help, then you've got people problems. Process is not a substitue for synaptic activity).
Over-specifying process, that is attempting to specify all steps and all tasks and all details, completely fails as an aid to software development. These are optimising cultures. They value stability and predictability and often, sadly, are blindly followed to the point where process pride completely overtakes the production of working, tangible results. (How often have you seen a Gantt chart with all or most of the bars being of equal length - from project start to project finish? Not useful at all, but it's a tick in a box of a rigorous process).
Agility is often equated to XP (extreme programming). This is only partially correct. There are several processes under the "Agile" umbrella and this in itself speaks volumes about the merits of the four Agile Manifesto value statements.
FDD subscribes to those four statements and it isn't the same as all other Agile methods. For example, FDD values design over "the code is the design." FDD values design first. The unit of development and thus an increment in an FDD project - a feature - is tiny; more granular than the iterations in other processes. Features (tiny, granular pieces of client-valued function) are being completed every week in an FDD project - and completed is a terrific word to get used in a project.
There are many other points of difference - and that's great!
Bechtel, William, & Richardson, Robert, 1993, "Discovering Complexity: Decomposition and Localization as Strategies in Scientific Research." Princeton: Princeton University Press.
Highsmith, James A. III, 2000, "Adaptive Software Development: A Collaborative Approach to Managing Complex Systems." Dorset House Publishing.
Levy, D., 1994, "Chaos theory and strategy: Theory, application and managerial implications," Strategic Management Journal, 15 (Summer), 167-178.
Sherman, Robert, private correspondence to Lissack, Michael R.