Software development process is all about the way a team of people works together and interacts with all the other interested parties and other teams in developing a piece of software.

The key phrase to remember in the previous sentence is 'a team of people'. Jeff De Luca says his first law of information technology is, "IT is 80% psychology and 20% technology"and many other respected people within the industry including Tom De Marco, Fred Brooks, Gerald Weinberg, Richard Fairley and Luke Hohmann have said similar things over the years.

This means, whether we like it or not, the greater part of the majority of software development is learning to communicate and work with other people.

The software industry has invented, proposed, debated, refined, celebrated, criticized, and derided numerous different processes, methods and approaches to team-based software development over the last forty years. After the waterfall processes and structured methods reigned supreme in the 1970's and 1980's, formal use-case and object-oriented analysis and design approaches dominated the 1990's. All of these  approaches emphasized comprehensive initial analysis, and design phases that produced large, detailed, beautifully formatted, requirements, analysis and design specification documents.

Then, at the turn of the century, Kent Beck's eXtreme Programming was the first of a revolutionary wave of more informal, self-styled agile approaches to become widely popular. Agile processes seek to minimize wasted effort especially early in a project, and better absorb the inevitable changes in requirements as they happen. They aim to do this without compromising the quality of the software produced or the ability to maintain it. Agile processes subscribe to a set of values and principles defined in the agile manifesto established in 2001.

In the last few years, eXtreme Programming's popularity has declined dramatically and Ken Schwaber and Jeff Sutherland's Scrum has become the de facto starting point for teams wanting to adopt a more agile approach to software development. Jeff De Luca's Feature-Driven Development (FDD) is cited in some studies as the third most used agile approach despite far less publicity surrounding it. In practice, most teams starting with Scrum, inevitably end up incorporating ideas and practices from both eXtreme Programming and FDD, and frequently from the Poppendiecks' Lean Software Development and David Anderson's Kanban too.

However, despite all this 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.

Read More about People and Process...

So, given a good team of people, what makes for a good process? The following mission statement for a process is adapted from 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 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 enough. If executing the process takes too long, costs too much, or delivers poor quality software, 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.

The Four C's of Software Development Process

The true management challenge on any non-trivial software development effort are the four Cs:

• Complexity
• Communication
• Change
• Cwality

Ok, so it should be 3 Cs and a Q but 4Cs sounds much better and is easier to remember! I also like the irony of misspelling quality. Anyway, if these four C's are under control on a project then the other classic management variables of schedule, budget and resources will almost look after themselves.

Feature-Driven Development (FDD)
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 that Jeff De Luca originally developed FDD for; Jeff 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. 

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 Interaction 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.
Read more...

FDD Processes
FDD is 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 Tufte's Envisioning Information .
Read more...

Developer Ailments
Developers. You got to love them ... or else they leave you ... with a half-coded system and no documentation!
Read the full article...

Design and Code Inspections
With agile processes and the latest development tools, has more modern software development practice outgrown the need for formal inspections?
Read the full article...

The BAT Blog
My contributions to the old Borland Agile Transformation Blog: "Contributors to this blog are passionate about the impact that great teams and good software can have on an organization’s bottom line. They bring decades of experience designing, developing and delivering great software, and each is playing a critical role in Borland’s own transformation."
Read more...