Software development process is all about the ways teams of people work together and interact with all the other interested parties in developing a piece of software.
The key phrase in the previous sentence is 'teams of people'. Jeff De Luca says his first law of information technology is, "IT is 80% psychology and 20% technology. Many other respected people within the industry have said similar things including Tom De Marco , Fred Brooks, Gerald Weinberg, Richard Fairley and Luke Hohmann.
This means, whether we like it or not, the greater part of enterprise software development is learning to communicate and work with other people.
The Four C's of Software Development Management
When talking about software development projects, project managers often talk about managing four variables: schedule, scope, budget, and quality. With the exception of quality, these are relatively easy to track and measure, and the true management challenge on a non-trivial software development effort involves managing the four C's of:
Ok, so it should be three C's and a Q but four C's sounds so much better, is easier to remember, and I confess to enjoying the irony of misspelling quality. If these four C's are under control on a project then the other classic management variables of schedule, budget, and scope are much more likely to remain under control.
Any software development process that wants to be successful must address the handling of these four C's.
The software industry has invented, proposed, and debated, refined, celebrated, and criticised so many different processes, methods and approaches to team-based software development over the last forty years. During the 1970's and 1980's so-called waterfall processes and structured methods reigned supreme. These were superseded in the 1990's by slightly more incremental and iterative processes using formal use-case and object-oriented analysis and design techniques. All of these approaches emphasized comprehensive initial analysis and design phases that produced large, detailed, beautifully formatted, requirements, analysis and design specification documents.
While many traditional process proponents were focusing on the millennium bug towards the end of the last century, a wave of new lighter, more informal approaches to software development started to appear including Kent Beck's eXtreme Programming (XP), Ken Schwaber and Jeff Sutherland's Scrum, and Jeff De Luca's Feature-Driven Development (FDD). These were quickly joined by the Poppendiecks' Lean Software Development and later by David Anderson's Kanban among others.
With rapidly increasing interest in these new emerging approaches to software development, a number of the key people involved established the agilemanifesto in 2001 that lists a set of values and principles that all of these self-styled agile approaches are supposed to subscribe to.
People and Processes
Despite all the innovation, hard work, and debate around different software development processes, methods, and approaches, none of them has been able to replace the importance of building a great team of good people. No process, method, or approach, agile or otherwise, can make up for a fundamental lack of ability, experience, or character within a team.
Over the years I have worked with all kinds of software development processes including traditional waterfall, incremental waterfall, use case driven, RUP-like, Feature-Driven Development (FDD), eXtreme Programming, and Scrum. My personal favourite to date is Feature-Driven Development (FDD) but I firmly believe that assigning the right people to a project is far more important than the particular process used.
Corporations spend vast amounts of money, time, and effort each year debating and trying to improve process. I am convinced that in 80% of cases, if this was channeled instead into improving the thinking and ability of both developers and managers, the increases of productivity and quality would be dramatically higher.
The Purpose of Process
Assuming we have a good team of people, what does a good process look like?
The following mission statement for a process is adapted from a brainstorming session in a meeting room of the Courtyard Marriott, Raleigh, NC, USA in 2000 with Jeff De Luca and Peter Coad:
A good software development process enables and enforces the repeatable delivery of high quality, working software in a timely and cost-effective manner, supplying accurate and meaningful information to all key roles inside and outside a project while imposing the minimum of administrative overhead on the development team members.
When a process emphasizes only enforcement, it stifles creativity and innovation and causes frustration among developers. Conversely, when a process emphasizes only enabling, and creativity and innovation are not channeled to useful areas, then individual team members simply do as they think best. This can mean results do not integrate, or the software does not truly reflect the client's requirements, or the quality of the software is inconsistent. This can be highly frustrating for team leads and managers. A good process must balance enablement with enforcement.
A good process also helps deliver high quality, working software in a timely and cost-effective manner. In the final assessment,repeated delivery of large Microsoft Word documents or PowerPoint slide shows describing the software being built is not what counts. Neither is repeated delivery of demonstration-only quality versions of the software. Even repeated delivery of software that is ready for production is not necessarily enough. If executing the process takes too long, costs too much, or results in poor quality software being delivered, repeated delivery is of limited benefit.
Of course, knowing what is meant by 'too long', 'too costly', or 'poor quality' is information needed by a development team's leadership and managers. To be able to intelligently steer a development team, its various levels of leadership need to know the status and progress of the development. If the appropriate information is not readily available when needed, is inaccurate, or is at the wrong level of detail, then the team's leadership may not be able to make appropriate decisions, or worse, may be persuaded to make inappropriate decisions about the development's future.
Progress information is of importance to the leadership of a development project but other information needs to be available to other people on the team. Clarification of requirements, design decisions, coding standards and conventions, environment settings, etc, all need to be communicated effectively. A good process, therefore, supplies accurate and meaningful information to all key roles inside and outside a project.
However, if supplying this information takes up large amounts of each team members' time then 'following the process' frequently becomes too expensive and team members are tempted to take short cuts undermining the quality of the information communicated. Therefore, the process needs to supply accurate and meaningful information to all key roles while imposing the minimum of administrative overhead on the development team members.
Finally, to maintain its effectiveness, any process needs to be monitored, reviewed and modified when necessary to maintain its value to the organization.
Coad, LeFebvre, De Luca, Java Modeling in Color with UML, 1999
Traditional waterfall-style processes are characterized by well-defined phases and
quality checkpoints or gateways. Unfortunately, projects following waterfall-style processes regularly exhibit
a number of problems.
Common goals of agile processes include minimising wasted effort especially early in a
project, and better absorbing the inevitable changes in requirements as they happen throughout the life of a
project. They aim to do this without compromising the quality of the software produced or the ability to
The development of significant software systems and products is a team sport, and it comes in a large variety of
shapes and sizes. The same can be said of the various sports called
FDD is an agile, pragmatic, model-centric, client-valued-requirements-driven approach to developing software. It is designed from the ground up to be more applicable to larger project teams than generally recommended for other agile processes like Scrum, Kanban and eXtreme Programming.
I was the development manager on the very successful, complex commercial lending system project in Singapore thatJeff De Luca originally developed FDD for; Jeff De Luca was the project manager and Peter Coad was the main external consultant on the project.Proven again and again on complex enterprise software development projects across the world since then, FDD also combines very nicely with Peter Coad's highly effective and seriously underrated 'modeling in color' technique./p>
In 2001, Peter Coad asked Mac Felsing and myself to write a book for his Coad Series called A Practical Guide to Feature-Driven Development. The book was to be part of a set of three books including one called A Practical Guide to eXtreme Programming written by Randy Miller, Dave Astels, and Miro Novak, and similarly titled one on the Unified Process that was never completed. Published in 2002, the book is over ten years old now but unfortunately remains the only book devoted to applying FDD. This is a shame because FDD still has much to offer those wanting to move beyond what Scrum and eXtreme Programming offer 'out of the box'.
In fact, as agile grows up, it seems more and more of the ideas from the FDD are gaining wider acceptance either directly or through others coming to similar conclusions independently. For example, an adaptation of the FDD Parking Lot Chart appears in Mike Cohn's book, Agile Estimating and Planning. In addition, it is not that surprising to find many Kanban boards bearing a strong resemblance to FDD's feature milestones. After all, Kanban's David Anderson was the User Interface Designer on the original FDD project in Singapore. Eric Evan's Domain-Driven Design puts a living, pragmatic domain model back at the heart of development similar to the way FDD does, and Ken Schwaber's, The Enterprise and Scrum, organizes product backlogs into shallow hierarchies not dissimilar to the organization of FDD's feature list. ...
FDD is formally documented as five processes, each
described on no more than
one double-sided letter-sized piece of paper. The basic ETVX
(Entry, Tasks, Verification, eXit) template
used was suggested by M. A. Rajashima and the layout inspired by Edward
The first three processes describe initial,
project-wide activities that create a conceptual and management
framework for the project. Within this framework, the highly-iterative,
development engine room described by the other two processes repeatedly delivers
completed, client-valued features, or 'frequent, tangible, working
results' as Peter Coad often used to say.
With agile processes
and the latest development tools, has more modern software development
practice outgrown the need for formal inspections? eXtreme
Programming mandates pair programming as a replacement for inspections
and peer reviews. Scrum and Kanban are silent on the topic, but Feature-Driven
Development mandates peer reviews of both design and code believing
them to be essential to producing the high-quality results desired by
the customer and needed by the project team if they are to continue to
deliver completed new features every few days.