"The structure of a software system will reflect the communication structure of the team that built it."
R. E. Fairley


"Man will occasionally stumble over the truth, but most times he will pick himself up and carry on."
Winston Churchill


"If you can't explain it simply, you don't understand it well enough."
Albert Einstein


"It usually takes more than three weeks to prepare a good impromptu speech."
Mark Twain


"Use models to find out how things work or to find solutions to puzzling dilemmas. Create models to communicate ideas and understand things you can’t see. Recognize models and the countless ways models are used for working, playing, teaching and explaining. Assess models for what they do and don't tell you about the real thing and how useful they are"
Boston Science Museum


"chaos often results when a project's complexity is greater than its managers' ability to direct meaningful progress toward a goal."
Ken Schwaber, Agile Project Management with Scrum, 2004


"The complexity of software is an essential property, not an accidental one. ... Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size."
Frederick P. Brooks, The Mythical Man-Month, 1995


"Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the program."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992


"As the number of people increases, the ways they can interact tend to multiply faster than you can control them."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992


"When people are factored in, nothing is simple. The complexity of individuals and individuals working in teams raises the noise level for all projects."
Ken Schwaber, Mike Beedle, Agile Software Development with Scrum, 2002


"Simplicity is the final achievement. After one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art."
Frederic Chopin


"We apply the analytic procedure in order to create a conceptual framework within which we can draw conclusions about the means by which a system solves its tasks. Indeed, we do this with the express purpose of establishing a solid foundation from which we can carry out a subsequent synthesis. This synthesis, in turn, acts to verify the conceptual model as an explanation. The process is an iterative one."
Tom Ritchey, Refactoring, 1991,


Notes on different approaches to team-based software development.

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.

Process Shapes

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.

Read More about People and Process...

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.

No amount of process over-specification will make up for bad people. Far better: Staff your project with good people, do whatever it takes to keep them happy, and use simple, well-bounded processes to guide them along the way.
Coad, LeFebvre, De Luca, Java Modeling in Color with UML, 1999

Waterfall Processes

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

Agile Development

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 maintain it.
Read more...

Process and Football

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

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

FDD Processes

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

Design and Code Inspections

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.
Read the full article...

Follow me on Twitter...