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.
Jim Highsmith, InformIT Article, 2002
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.
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.
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.