"Perhaps the worst software technology of all time was the use of physical lines of code [for metrics]. Continued use of this approach, in the author’s opinion, should be considered professional malpractice."
Capers Jones, Applied Software Measurement

"Information Technology is 80% psychology and 20% technology "
Jeff De Luca, www.nebulon.com

"Kanban is the science of not trying to do too much at once"
Stephen Palmer, 2012

"I guess that as you go along you try to fill your tool-box, so that when you face these circumstances you have more options to choose from"
Jonny Wilkinson, Tom Fordyce's Blog, 2009

"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,

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

"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

"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

"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

"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

"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

"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

"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

"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

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

"Speech is conveniently located midway between thought and action, where it often substitutes for both."
John Andrew Holmes

"We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process"
Glenford Myers (via jJeff De Luca)

"Deliver frequent, tangible, working results"
Peter Coad

"Agile software development is about iteration not oscillation"
Jim Highsmith (paraphrased), Agile 2009

Notes on agile approaches to team-based software development.

Towards the end of the last century, a wave of new, revolutionary, more informal approaches to software development started to appear. Kent Beck's eXtreme Programming was the first of these light-weight approaches to break onto the beach of general popularity.

eXtreme Programming dispensed with long upfront requirements and design activities, advocated small project teams, programming in pairs, automated unit testing, collective ownership of code, and continuous integration. It repeatedly delivered small amounts of finished software of tangible value to the customer at the end of short, fixed-length intervals of time that it called development iterations.

In more recent years, eXtreme Programming's popularity has declined and Ken Schwaber and Jeff Sutherland's Scrum, developed at around the same time, has become the de facto starting point for teams wanting to adopt a more agile approach to software development. Like eXtreme Programming, Scrum uses small teams and short development iterations that it call sprints. Scrum defines the way a team manages, selects and validates the work for each sprint but deliberately does not dictate how the development team is to do the work. The team is expected to organize itself to best complete the work committed to in each sprint.

Despite far less publicity and hype surrounding it, a number of studies cited, Jeff De Luca's Feature-Driven Development (FDD) as the third agile approach used most during the 'noughties' (2000-2009). Although first used around the same time as eXtreme Programming and Scrum, FDD differs from them in a number of ways. For example, FDD defines some initial but significant analysis, design, and planning work at the start of a project, and is designed to cater for much larger projects and project teams. Nevertheless, similar ideas of delivering frequent increments of customer-valued, high-quality, working software are as central to FDD as they are to Scrum or eXtreme Programming.

Most teams starting with Scrum today, 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.

In 2001, with rapidly increasing interest in these new emerging approaches to software development, a number of the key people involved established the agile manifesto that lists a set of values and principles that all these approaches aspire to.

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.

Well over a decade after the original penning of the Agile Manifesto, interest in the evolution of these self-styled agile approaches remains strong, especially the challenge scaling Scrum and eXtreme Programming success to larger development projets and programmes. Here, Feature-Driven Development (FDD) with its dynamically-formed feature teams, pragmatic code ownership, and domain model centric analysis and design, has a significant contribution still to make.

FDD is not the only approach to push a more domain-centric or domain-driven approach. Eric Evan's Domain-Driven Design puts the domain model at the heart of the software development process. But as in FDD, the domain model is not a static set of diagrams drawn by modeling specialists during a lengthy analsyis and high-level design phase of a waterfall-style approach, but a living, conceptual framework on which developers build feature by feature, or user story by user story.

Dean Leffingwell's Scaled Agile Framework is one of the more recent attempts to blend a cohesive approach out of a number of different techniques for scaling Scrum and eXtreme Programming beyond a handful of largely independent teams of developers. While it remains to see just how agile the overall approach generally proves to be at the portfolio and programme levels, it provides a solid starting point for process improvement in areas such as demand management where many organisations have nothing better than adhoc, disjointed processes.

Simple designs don't mean less work, they mean more thinking.
Jim Highsmith, InformIT Article, 2002

Agile Project Management Tools

Personally, I do not think there is anything more irritating during a release or iteration planning session than watching a non-typist editing user stories and tasks in a web-based product.

Agile and Lazy Loading

Lazy loading (or 'loading on demand' or 'deferred instantiation' if you prefer) is a popular performance optimization technique. It distributes work that would be done 'upfront' over a longer duration. In some ways it is similar to the way agile approaches distribute analysis and design work throughout the duration of a project.

eXtreme Programming

The premise behind eXtreme Programming is that the cost of making changes to software does not need to grow exponentially more expensive throughout a project or product development life-cycle. That the cost of change does increase exponentially over-time is attributed to unnecessary complexity added early in the project/ product life-cycle; complexity that provides the flexibility to address all the changes that might be asked for in the future.


Scrum splits a project into a number of fixed length time boxes or iterations called sprints. At the beginning of each sprint the project team meets to select a subset of items from a priortised to-do list known as the product backlog. The subset of items chosen from the product backlog are the items that provide the most business value for the customer and which the team believe they can complete by the end of the sprint. This selection process is known as Sprint Planning.

Feature-Driven Development

FDD combines key advantages of other agile approaches with model-centric techniques and fluid team organisation. This means that FDD easily scales to much larger teams and projects than generally recommended for other agile approaches. FDD is also characterised by an emphasis on quality throughout the process, and timely, accurate, meaningful status reporting and progress tracking for all levels of leadership.

Follow me on Twitter...