Agile

The Agile Movement
(http://agilemethodology.org/)

What Is Agile?
Not a methodology! The Agile movement seeks alternatives to traditional project management. Agile approaches help teams respond to unpredictability through incremental, iterative work cadences, known as sprints. Agile methodologies are an alternative to waterfall, or traditional sequential development.

What is Scrum?
Scrum is the most popular way of introducing Agility due to its simplicity and flexibility. Because of this popularity, many organizations claim to be “doing Scrum” but aren’t doing anything close to Scrum’s actual definition. Scrum emphasizes empirical feedback, team self management, and striving to build properly tested product increments within short iterations. Doing Scrum as it’s actually defined usually comes into conflict with existing habits at established non-Agile organizations.

Scrum has only three roles: Product Owner, Team, and Scrum Master. These are described in detail by the Scrum Training Series by Michael James. The responsibilities of the traditional project manager role are split up among these three Scrum roles. Scrum has five meetings: Backlog Grooming (aka Backlog Refinement), Sprint Planning, Daily Scrum (aka 15-minute standup), the Sprint Review Meeting, and the Sprint Retrospective Meeting.

Many books and classes are available from a variety of competing sources of varying accuracy and quality.  One place to start would be the Scrum Training Series, which uses an entertaining approach to cover the most popular way of introducing Agile to teams. You can also download the 6-page illustrated Scrum Reference Card.

Where Did Agile Come From?
In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which criticized sequential development. He asserted that software should not be developed like an automobile on an assembly line, in which each piece is added in sequential phases. In such sequential phases, every phase of the project must be completed before the next phase can begin. Dr. Royce recommended against the phase based approach in which developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce specifically objected to this approach due to the lack of communication between the specialized groups that complete each phase of work.

It’s easy to see how the “waterfall” methodology is far from optimized compared to agile methodology. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?

Why Agile?
Agile development methodology provides opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.

The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. Agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to continuously replan their release to optimize its value throughout development, allowing them to be as competitive as possible in the marketplace. Development using an agile methodology preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

Agile software development
(https://en.wikipedia.org/wiki/Agile_software_development)

Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. Agile itself has never defined any specific methods to achieve this, but many have grown up as a result and have been recognized as being ‘Agile’.

The Manifesto for Agile Software Development, also known as the Agile Manifesto, was first proclaimed in 2001, after “agile methodology” was originally introduced in the late 1980s and early 1990s. The manifesto came out of the DSDM Consortium in 1994, although its roots go back to the mid 1980s at DuPont and texts by James Martin and James Kerr et al.

Manifesto for Agile Software Development
(http://agilemanifesto.org/)

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Twelve Principles of Agile Software

Principles behind the Agile Manifesto
We follow these principles: Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Agile AllianceAgile Alliance
(https://www.agilealliance.org/agile101/what-is-agile/)

Agile Alliance is a nonprofit organization with global membership, committed to advancing Agile development principles and practices.

What is Agile?
(https://www.agilealliance.org/agile101/what-is-agile/)

The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.

Agile Software Development is an umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto.

Solutions evolve through collaboration between self-organizing, cross-functional teams utilizing the appropriate practices for their context.

Manifesto for Agile Software Development
(https://www.agilealliance.org/agile101/the-agile-manifesto/)

The Agile Manifesto was written in February of 2001 by seventeen independent-minded software practitioners . While the participants didn’t agree about much, they found consensus around four main values.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

12 Principles Behind the Agile Manifesto
(https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/)

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What is Agile Software Development?
(https://www.agilealliance.org/agile101/what-is-agile/)

Agile Software Development is an umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto.

Solutions evolve through collaboration between self-organizing, cross-functional teams utilizing the appropriate practices for their context.

n the late 1990’s, several methodologies began to gain increasing public attention, each having a different combination of old and new ideas. These methodologies emphasized close collaboration between the development team and business stakeholders; frequent delivery of business value, tight, self-organizing teams; and smart ways to craft, confirm, and deliver code.

The term “Agile” was applied to this collection of methodologies in early 2001 when 17 software development practitioners gathered in Snowbird, Utah to discuss their shared ideas and various approaches to software development. This joint collection of values and principles was expressed in the Manifesto for Agile Software Development and the corresponding twelve principles.

The Agile Alliance was formed shortly after this gathering to encourage practitioners to further explore and share ideas and experiences.

Practices Timeline
(https://www.agilealliance.org/agile101/guide-to-agile/practices-timeline/)

Trace the history and evolution of Agile from its roots in 1968, and learn how it has evolved through the years.

 1968: “Conway’s Law”
“Conway’s Law” is coined and summarized as follows: “Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.” It has long had the status of folklore rather than of well-supported scientific result, though recent studies have lent it some academic support. (The social aspects of software development remained largely ignored by academic software engineering until the mid-90’s.)

1970s:
Barry Boehm proposes “Wideband Delphi”, a forerunner of Planning Poker

1976:
A series of articles by D. Panzl describing tools with features closely resembling those of JUnit attest to the long history of automated unit testing.

1976:
Publication of Software Reliability by Glenford Myers, which states as an “axiom” that “a developer should never test their own code” (Dark Ages of Developer Testing).

1977:
Creation of the “make” tool for Unix systems – the principle of automating software builds is not a new idea.

1980:
Substantial discussion of incremental development in IBM’s Federal Systems Division can be found in a volume edited by Harlan Mills, ”Principles of software engineering”, specifically an article by Dyer, which recommends organizing “each increment to maximize the separation of its function(s) from function(s) in other increments”; however, the idea is still very much that of a scheduled, phased approach rather than one responsive to change.

1980:
The notion of “visual control” originating in the Toyota Production System is an anticipation of “information radiators”.

1983:
A wide range of “human factors testing” techniques foreshadowing usability testing, used at the Xerox PARC during the design of the Xerox Star, are described in the CHI conference proceedings.

1984:
An early empirical study by Barry Boehm of projects using prototyping, by essence an iterative strategy, suggests that iterative approaches first started receiving serious attention around that time, most probably driven by factors such as the rise of personal computers and graphical user interfaces.

1984:
The notion of “factoring”, an anticipation of refactoring, is described in Brodie’s “Thinking Forth”, where it is presented as “organizing code into useful fragments” which “occurs during detailed design and implementation”.

1984:
While criticisms of the “waterfall” sequential approach have started much earlier, formulations of alternative incremental approaches are becoming more pointed; a good example is an early paper on ”Knowledge-based communication processes in software engineering” advocating incremental development for the specific reason that “complete and stable specifications are not available”.

1985:
Perhaps the first explicitly named, incremental alternative to the “waterfall” approach is Tom Gilb’s Evolutionary Delivery Model, nicknamed “Evo”.

1986:
In a well-known paper, Barry Boehm presents ”A Spiral model of software development and enhancement”, an iterative model geared to identifying and reducing risks through any appropriate approaches (though the “typical” example presented is based on prototyping).

1986:
The term “Scrum” appears in an article by Takeuchi and Nonaka ”The New New Product Development Game”, often cited as an inspiration for Scrum, the framework; however, it only appears once (in the title of a section: “Moving the scrum downfield”) and does not at this point refer to any sort of meeting.

1988-1990:
The rise of event-driven GUI software and their specific testing challenges create an opportunity for “capture and replay” test automation tools provided by companies such as Segue or Mercury; this type of tool dominates the market for the next decade.

1988:
The “timebox” is described as a cornerstone of Scott Schultz’s “Rapid Iterative Production Prototyping” approach in use at a Du Pont spin-off, Information Engineering Associates.

1988:
Though the idea of reasoning through design issues by anthropomorphizing objects, as in the CRC technique, may seem quite natural, it has had some formidable detractors, for instance this artlce by Dijsktra ”On the cruelty of really teaching computing science”, which appears just as object-oriented is hitting the mainstream: “in computing science the anthropomorphic metaphor should be banned”.

1989:
Ward Cunningham describes the CRC technique in a joint article with Kent Beck; the specific format used for the cards derives from an application designed by Cunningham to store design documentation as a Hypercard stack.

1990:
Bill Opdyke coins the term “refactoring” in an ACM SIGPLAN paper with Ralph Johnson, “Refactoring: An aid in designing application frameworks and evolving object-oriented systems”

1990:
Rebecca Wirfs-Brock describes the conceptual aspects of CRC, which she invented while she and Cunningham were working at Tektronix, in her book ”Designing object-oriented software”.

1990:
Testing discipline dominated by “black box” techniques, in particular in the form of “capture and replay” testing tools.

1990’s:
Owing to the rise in popularity of RAD tools and IDEs, “make” type tools acquire a mixed reputation.

1991:
RAD, possibly the first approach in which timeboxing and “iterations” in the looser sense of “one repetition of the entire software development process” are closely combined, is described by James Martin in his ”Rapid Application Development”. This book also describes the details of the timebox in one of its chapters.

1991:
Independent creation of a testing framework at Taligent with striking similarities to SUnit (source)

1992:
“Dynamic Duo” is the term coined by Larry Constantine, reporting on a visit to Whitesmiths Inc., a compiler vendor started by P.J. Plauger, one of the implementors of C: “At each terminal were two programmers! Of course, only one programmer was actually cutting code at each keyboard, but the others were peering over their shoulders.” Whitesmiths existed from 1978 to 1988.

1992:
A comprehensive description of “refactoring” is presented in Opdyke’s thesis, “Refactoring object-oriented frameworks”

1993:
“The benefits of collaboration for student programmers” by Wilson et al. is one early empirical study indicating benefits of pairing for programming tasks specifically. Posterior studies are more abundant and driven by the desire to “validate” pair programming after it had already gained popularity through Extreme Programming.

1993:

The phrase “continuous integration” is already in use and thus predates what will later be known as Agile processes, for instance an article written this year contrasts it with “scheduled” integration, and recommends the latter, citing “lack of thorough testing” as one issue with continuous integration; this helps explain why the automated testing favored by Agile teams is an enabler for continuous integration.

1994:
Jim Coplien, describing his observations of the “hyperprodutive” Borland Quattro Pro team, notes their reliance on almost daily meetings: “the project was made more of meetings than anything else”; this article is also cited as a strong influence on Scrum

1994:

Kent Beck writes the SUnit testing framework for Smalltalk (source)

1995:
Coplien names the “Code Ownership” pattern in Pattern Languages of Program Design, in an early version of his “Organizational Patterns”, a work influential in the later development of Agile discourse. However, he endorses exclusive individual code ownership, and cautions against collective ownership which he equates to no ownership at all. Coplien admits that objections against individual ownership exist, but argues that other of his patterns mitigate those problems.

1995:
An article by Alistair Cockburn, ”Growth of human factors in application development”, suggests one major reason why iterative approaches gradually gain acceptance: the bottleneck in software development is shifting to (individual and organizational) learning, and human learning is intrinsically an iterative, trial and error process.

1995:
Based on the same inspiration as CRC cards, Ward Cunningham develops the concept of a Wiki, which will later become the ancestor of Wikipedia and undoubtedly one of the most influential ideas in the history of the World Wide Web.

1995:
The earliest writings on Scrum introduce the notion of the “sprint” as iteration, although its duration is variable.

1995:
The pattern “Developing in Pairs” is given a brief description, in Alexandrian pattern form, in Jim Coplien’s chapter “A Generative Development-Process Pattern Language” from the first patterns book, “Pattern Languages of Program Design”.

1996:
Steve McConnell describes the “Daily Build and Smoke Test” technique, used at Microsoft for Windows NT 3.0 during the 1990’s; the emphasis is not so much on the automation as on the frequency, the daily cycle being at that time considered “extreme”.

 

1996:
Automated tests are a practice of Extreme Programming, without much emphasis on the distinction between unit and acceptance testing, and with no particular notation or tool recommended.

1997:
Ken Schwaber describes the “daily scrum” (which does not appear in his earlier writings, such as the 1995 article “SCRUM Development Process”), this is later recast in pattern form by Mike Beedle.

1997:
In ”Surviving Object-Oriented Projects”, Alistair Cockburn describes several projects (dating as far back as 1993) informally using the practice, but does not give it a label; he summarizes it as “Work in increments, focus after each”.

1997:
The testing tool JUnit is written by Beck and Gamma, inspired by Beck’s earlier work on SUnit; its growing popularity over the next few years marks the end of the “capture and replay” era.

1998 to 2002:
“Test First” is elaborated into “Test Driven”, in particular on the C2.com Wiki.

1998:
Continuous integration and the “daily stand-up” are listed among the core practices of Extreme Programming.

 

1998:
The earliest article about Extreme Programming, “Chrysler goes to Extremes”, describes several XP practices such as self-chosen tasks, test first, three week iterations, collective code ownership, and pair programming.

1999:

Early on in the elaboration of Extreme Programming, the “System Metaphor” practice is proposed to address the issues of business-technical translation and cognitive friction, however the practice is poorly understood and fails to catch on.

1999:

In an article for the C++ Report, Robert C. Martin gives what is perhaps the earliest description of the Agile sense of the terms “iterative” and “incremental”.

1999:

Personas are first described in one chapter of Alan Cooper’s “The Inmates are Running the Asylum”, building on prior work in “Goal-Directed design”.

1999:

The “rules of simple design” are described for the first time in an IEEE Computer article by Kent Beck, “Embracing Change with Extreme Programming”, summarizing earlier discussions on the OTUG mailing list.

1999:

The practice of “refactoring”, incorporated a few years earlier into Extreme Programming, is popularized by Martin Fowler’s book of the same name.

 

1999:

The term “Big Visible Chart” is coined by Kent Beck in “Extreme Programming Explained”, though later attributed by Beck to Martin Fowler.

1999:

The unit “Gummi Bears”, an alternative to “story points” for estimating user stories, is first mentioned by Ron Jeffries (later attributed to an XP project led by Joseph Pelrine).

 

2000,ca:

The “three questions” of Scrum’s daily meeting format are largely adopted by Extreme Programming teams.

2000 (or earlier):

The roles of Driver and Navigator are introduced to help explain pair programming; the earliest known reference is a mailing list posting; note however that the reality of these roles has been disputed, for instance Sallyann Bryant’s article ”Pair programming and the mysterious role of the navigator”.

 

2000:

An article by Martin Fowler provides perhaps the most complete description of the continuous integration practice available at that time.

2000:

The “mock objects” testing technique is described by Freeman, McKinnon and Craig in their article ”Endo-Testing: Unit Testing with Mock Objects”, an allusion to the “Mock Turtle” character in Lewis Carroll

 

2000:

The burndown chart is first described by Ken Schwaber, who invents it while working at Fidelity Investments in an attempt to provide Scrum teams with a simple tool kit; he describes it formally on his Web site.

2000:

The term “velocity” is a relatively late addition to Extreme Programming, replacing a previous notion of “load factor” deemed overly complex.

 

2000’s:

Even though the practice is far from new, nor limited to Agile teams, it is partly due to Agile practices that a revival of “make” type build automation takes place.

2001:

Mary Poppendieck’s article, ”Lean Programming”, draws attention to the structural parallels between Agile and the ideas known as Lean or the “Toyota Production System”.

 

2001:

Cruise Control, the first “continuous integration server”, is published under an open source license; it automates monitoring of the source code repository, triggering the build and test process, notifications of the results to the developers, and archival of the test reports; the period 2001-2007 sees a large number of similar tools appear, leading perhaps to an excessive focus on tools over practice.

2001:

Among the visualizations described in Norm Kerth’s “Project Retrospectives”, the “Energy Seismograph” can perhaps be seen as a forerunner of the niko-niko calendar.

 

2001:

An article by Bill Wake points out two distinct flavors of estimation in use among Agile teams, relative and absolute estimation.

2001:

An avowed member of the “context-driven” school of software testing, Brian Marick participates in the Snowbird event leading to the publication of the Agile Manifesto; he has often described himself as the “token tester” of the group, bringing some awareness of practices within exploratory testing to the Agile community.

 

2001:

Refactoring “crosses the Rubicon”, an expression of Martin Fowler describing the wide availability of automated aids to refactoring in IDEs for the language Java.

2001:

Regular retrospectives are one of the principles of the Agile Manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”, though not necessarily yet common practice.

 

2001:

Some techniques of exploratory technique, together with a first mention of the “context driven school of software testing”, are introduced in Kaner, Bach and Pettichord’s ”Lessons Learned in Software Testing”.

2001:

The “quick design session” is described in ”Extreme Programming Installed”.

 

2001:

The “role-feature-reason” format for expressing user stories is invented at Connextra in the UK.

2001:

The Scrum of Scrums is first described (summarizing experiences at IDX) in an article by Jeff Sutherland, Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies.

 

2001:

The XP community endorses retrospectives early on, by way of a paper at XP2001 on ”Adaptation: XP Style”

2001:

The Card, Conversation, Confirmation model is proposed by Ron Jeffries to distinguish “social” user stories from “documentary” requirements practices such as use cases

 

2001:

The article which will later come to largely define project chartering as an agile practice is published:“Immunizing Against Predictable Project Failure”

2001:

The first description of a “reflection workshop” in the context of an Agile project appears in Alistair Cockburn’s ”Agile Software Development”

 

2001:

The term “Project Retrospectives” is introduced in Norm Kerth’s book of the same name

2001:

The term “information radiator” is coined by Alistair Cockburn, part of an extended metaphor which equates the movement of information with the dispersion of heat and gas

 

2002:

”Pair Programming Illuminated”, by Laurie Williams and Robert Kessler, is the first book devoted exclusively to the practice and discusses its theory, practice and the various studies up to that date

2002:

Ward Cunningham, one of the inventors of Extreme Programming, publishes Fit, a tool for acceptance testing based on a tabular, Excel-like notation

 

2002:

An early article by Bill Wake calls attention to the possible inconsistencies arising from terms commonly used within teams, such as “done”

2002:

An early practitioner’s report discusses personas within the broader context: Jeff Patton’s “Hitting the Target: Adding Interaction Design to Agile Software Development” is perhaps the first formal description in an Agile context, although the topic has been discussed informally on mailing lists since at least 2000

 

2002:

In early (unpublished) discussions of applying Lean ideas to software, seeing undeployed features as “inventory”, Kent Beck mentions continuous deployment at LifeWare and “several others”; it will take several years, however, for the idea to be refined and codified

2002:

The Scrum community picks up the practice of measuring “velocity”

 

2002:

The burndown gains popularity among the Scrum community, as well as alternatives such as the “burnup” which merely inverts the vertical direction, or the more sophisticated ”Cumulative Flow Diagram”, which most closely resembles a burnup but appears to be an independent invention

2002:

The current form of Planning Poker is set out in an article by James Grenning

 

2003 to 2004:

Driven by the popularity of Fit/FitNesse ATDD becomes accepted practice in spite of Beck’s objections

2003 to 2006:

For some time the Fit/FitNesse combo eclipses most other tools and becomes the mainstream model for Agile acceptance testing

 

2003:

Joshua Kerievsky at Industrial Logic publishes ”Industrial XP”, a set of proposed extensions to Extreme Programming which includes the Project Chartering activity, essentially as defined by the 2001 article

2003:

Kent Beck briefly mentions ATDD in the book “Test Driven Development: By Example” but dismisses it as impractical

 

2003:

AgileDox, the ancestor of BDD, is a tool generating technical documentation automatically from JUnit tests, written by Chris Stevenson

2003:

Adoption of Fit, which has remained marginal, booms when Bob Martin combines Fit with Wikis (another invention of Cunningham’s), creating FitNesse

 

2003:

An anonymous article on the C2 Wiki describes Ping-Pong Programming, a moderately popular variant which marries pairing with test-driven development

2003:

Early Scrum training materials hint at the future importance of the “Definition of Done”, initially only in the form of a slide title: “The story of Done”

 

2003:

Expanding on their earlier work on Lean Programming, Mary and Tom Poppendieck’s book ”Lean Software Development” describes the Agile task board as a “software kanban system”

2003:

Publication of “Test Driven Development: By Example” by Kent Beck

 

2003:

Thanks in good part to sessions at the XP Day cycle of conferences, more teams start practicing project and iteration retrospectives

2003:

The INVEST checklist for quickly evaluating user stories originates in an article by Bill Wake, which also repurposed the acronym SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) for tasks resulting from the technical decomposition of user stories.

 

2003:

The five-column task board format is described by Mike Cohn on his Web site; at the time, as this photo gallery collected by Bill Wake shows, very diverse variants still abound.

2003:

The term “Nebulous Units of Time” or NUTs is coined by Joshua Kerievsky as an alternative to “story points”

 

2003:

The term “domain driven design” is coined by Eric Evans and described in a book of the same name, eventually emerging as a viable alternative to the “System Metaphor”

2004 to 2006:

The daily meeting is generalized as a core Agile practice, and with widespread use of task boards gains one final key guideline, “hold the daily meeting near the task board” (described for instance by Tobias Mayer)

 

2004:

Kent Beck proposes “Whole Team” as the new denomination for the practice previously known as “On Site Customer”

2004:

An article by Alberto Savoia proposes “Extreme Feedback Devices” such as lava lamps or dedicated monitors, to display the results of the most recent integration, an important innovation in CI

 

2004:

In order to test his hypotheses about de-emphasizing “test” terminology in favor of “behavior”, Dan North releases JBehave

2004:

The INVEST acronym is among the techniques recommended in Mike Cohn’s ”User Stories applied”, which discusses it at length in Chapter 2.

 

2005:

The Planning Poker technique is popularized in the Scrum community, as are a number of planning techniques, by Mike Cohn’s “Agile Estimating and Planning”

2005:

The earliest recorded use of the term “backlog grooming” is from Mike Cohn on the Scrum development mailing list; it will be several years before the practice is described more formally

 

2005:

The first exercises inviting Scrum trainees to reflect on their (local) “definition of done” appear in later iterations of Scrum training materials

2005:

Without giving it that name, Jeff Patton formulates the concepts of story mapping in “It’s All in How You Slice It”.

 

2006 to 2009:

Several new tools are released confirming the community’s investment in BDD, such as RSpec or more recently, Cucumber and GivWenZen

2006:

Jean Tabaka’s book ”Collaboration Explained” references project chartering as one of the key practices for effective collaboration; though she explicitly cites Industrial XP her presentation differs in several respects from the 2001 article, indicating a synthesis influenced by other sources

 

2006:

In collaboration with Chris Matts, North proposes the given-when-then canvas to expand the scope of BDD to business analysis and documents the approach in “Introducing BDD”

2006:

More recently, tools inspired by the BDD approach have renewed competition in the acceptance testing area

 

2006:

Niko-niko calendars are first described by Akinori Sakata in this article

2006:

The first conference article describing the core of continuous deployment, ”The Deployment Production Line” by Jez Humble, Chris Read and Dan North is published in the proceedings of Agile2006, a codification of the practices of several Thoughtworks UK teams

 

2006:

The publication of Esther Derby and Diana Larsen’s ”Agile Retrospectives” brings to a close the codification of heartbeat retrospectives

2007:

By that point the “Definition of Done” as a full-fledged practice, and as a textual checklist displayed in the team room, has become widespread.

 

2007:

The ”kanbandev” mailing list is formed to provide a venue for discussion of kanban-inspired Agile planning practices

2007:

The first few experience reports from teams using the specific set of alterations known as “kanban” (no iterations, no estimates, continuous task boards with WIP limits) are published, including reports from Corbis (David Anderson) and BueTech (Arlo Belshee)

 

2007:

The simplified three-column task board format (“To Do”, “In Progress”, “Done”) becomes, around that time, more popular and more standard than the original five-column version

2008:

Alan Cooper’s keynote at Agile 2008 marked a formal reconciliation, of sorts, between Agile discourse and interaction design, which had long been perceived to be at odds; invited by “the Agile leadership” as an “outsider”, Cooper came to be perceived over the following year as very much an “insider”

 

2008:

An emerging definition of exploratory testing is given by Cem Kaner, reflecting the continuing refinement of this approach to testing

2008:

One of the first formal descriptions of “backlog grooming” is given by Kane Mar, under the name “Story Time”, and recommending it as a regular meeting

 

2008:

The Agile 2008 conference features a stage dedicated to discussion of “User Experience” practices, such as usability testing, personas or paper prototyping

2008:

The story mapping practice is described and abundantly illustrated in Jeff Patton’s “The new user story backlog is a map”

 

2008:

While the first few allusions to teams using a “definition of ready” date to the beginning of that year, the first formal description seems to be from october, and is incorporated into “official” Scrum training material shortly thereafter

2009:

The practice of continuous deployment has become well established, though still somewhat controversial as a much commented upon article, ”Continuous Deployment at IMVU” by Timothy Fitz attests; it has become important not only in Agile but also as a core element of more specialized, recent strategies such as Lean Startup or DevOps

 

2009:

Two entities dedicated to exploring the kanban approach are formed, one addressing business concerns, the LSSC and a more informal one aimed at giving the community more visibility: the Limited WIP Society

2010:

A comprehensive description of integrating mock objects, TDD and OO design is provided in Freeman and Pryce’s ”Growing Object-Oriented Software Guided by Tests”

 

2011:

The practice of “backlog grooming” is promoted to an “official” element of Scrum with its inclusion in the Scrum Guide

What Is Agile? (10 Key Principles of Agile)
(http://www.allaboutagile.com/what-is-agile-10-key-principles/)

What is agile?  Agile is one of the big buzzwords of the IT development industry. But exactly what is agile development?

Put simply, agile development is a different way of managing IT development teams and projects.

The use of the word agile in this context derives from the agile manifesto.  A small group of people got together in 2001 to discuss their feelings that the traditional approach to managing software development projects was failing far too often, and there had to be a better way.  They came up with the agile manifesto, which describes 4 important values that are as relevant today as they were then.  It says, “we value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.”

Ever since then, the use of methods that support these values has become increasingly popular.

From my use of various agile methods, I have written about 10 key principles of agile.  These are characteristics that are common to all agile methods, and the things that I think make agile fundamentally different to a more traditional waterfall approach to software development.  They are:

1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential

There are various methodologies that are collectively known as agile, as they promote the values of the agile manifesto and they are consistent with the above principles.  The most popular ones are:

DSDM is probably the original agile development method. DSDM was around before the term ‘agile’ was even invented, but is absolutely based on all the principles we’ve come to know as agile.  DSDM seems to be much less well-known outside of the UK.

Scrum is also an agile development method, which concentrates particularly on how to manage tasks within a team-based development environment.  Scrum is the most popular and widely adopted agile method – I think because it is relatively simple to implement and addresses many of the management issues that have plagued IT development teams for decades.

XP (Extreme Programming) is a more radical agile methodology, focusing more on the software engineering process and addressing the analysis, development and test phases with novel approaches that make a substantial difference to the quality of the end product.

DSDM is probably the most complete agile methodology, whereas Scrum and XP are easier to implement and complementary because they tackle different aspects of software development projects and are both founded on very similar concepts.

Over the last 10 years, there is an ever-increasing volume of success stories, where companies have dramatically improved the success and performance of their IT development teams and projects.  This has caused agile to be widely adopted across a variety of industries, including media and technology, large corporates, and even government.

In reality, though, agile is not a magic bullet for all software development issues.  The real trick is to know lots of techniques from various waterfall and agile development methods, and to select a mixture of the best approaches that are most appropriate for any given situation.  To do this reliably with any degree of success really requires a lot of experience and skill.

In agile software projects, project management takes a slightly different form, relying far more on the project manager’s skills in communication, facilitation, coordination, and emphasising far less on planning and control.

Agile development can be a very exciting and invigorating approach, although some projects suit agile more than others.  The collaboration and visibility can provide a much richer and more rewarding experience for teams to develop great software products. Agile development can be a lot more enjoyable than the waterfall approach, which requires lots more documentation and is less flexible by its nature. And when people enjoy their work, it’s amazing what they can achieve!

Agile in a Nutshell
(http://www.agilenutshell.com/)

What is Agile?

Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.

agile in a nutshell
It works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations.

agile in a nutshell

VersionOne’€™s Agile 101
(https://www.versionone.com/agile-101/)

Are you wondering “What is Agile?” or brushing up on your Agile knowledge?
Welcome to VersionOne’€™s Agile 101

What Is Agile Methodology?
(https://www.versionone.com/agile-101/agile-methodologies/)

The various agile Scrum methodologies share much of the same philosophy, as well as many of the same characteristics and practices. But from an implementation standpoint, each has its own recipe of practices, terminology, and tactics. Here we have summarized a few of the main agile software development methodology contenders:

 

agile101-software-dev

Agile Scrum Methodology

Scrum is a lightweight agile project management framework with broad applicability for managing and controlling iterative and incremental projects of all types. Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed significantly to the evolution of Scrum over the last decade. Scrum has garnered increasing popularity in the agile software development community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.

With Scrum methodology, the “Product Owner” works closely with the team to identify and prioritize system functionality in form of a “Product Backlog”. The Product Backlog consists of features, bug fixes, non-functional requirements, etc. – whatever needs to be done in order to successfully deliver a working software system. With priorities driven by the Product Owner, cross-functional teams estimate and sign-up to deliver “potentially shippable increments” of software during successive Sprints, typically lasting 30 days. Once a Sprint’s Product Backlog is committed, no additional functionality can be added to the Sprint except by the team. Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized, if necessary, and the next set of functionality is selected for the next Sprint.

Scrum methodology has been proven to scale to multiple teams across very large organizations with 800+ people. See how VersionOne supports Scrum Sprint Planning by making it easier to manage your Product Backlog.

Lean and Kanban Software Development

Lean Software Development is an iterative agile methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement, and the practices of companies like Toyota. Lean Software Development focuses the team on delivering Value to the customer, and on the efficiency of the “Value Stream,” the mechanisms that deliver that Value. The main principles of Lean methodology include:

  • Eliminating Waste
  • Amplifying Learning
  • Deciding as Late as Possible
  • Delivering as Fast as Possible
  • Empowering the Team
  • Building Integrity In
  • Seeing the Whole

Lean methodology eliminates waste through such practices as selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers. Lean uses the idea of work product being “pulled” via customer request. It focuses decision-making authority and ability on individuals and small teams, since research shows this to be faster and more efficient than hierarchical flow of control. Lean also concentrates on the efficiency of the use of team resources, trying to ensure that everyone is productive as much of the time as possible. It concentrates on concurrent work and the fewest possible intra-team workflow dependencies. Lean also strongly recommends that automated unit tests be written at the same time the code is written.

The Kanban Method is used by organizations to manage the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.

Kanban is based on 3 basic principles:

  • Visualize what you do today (workflow): seeing all the items in context of each other can be very informative
  • Limit the amount of work in progress (WIP): this helps balance the flow-based approach so teams don ‘t start and commit to too much work at once
  • Enhance flow: when something is finished, the next highest thing from the backlog is pulled into play

Kanban promotes continuous collaboration and encourages active, ongoing learning and improving by defining the best possible team workflow. See how VersionOne supports Kanban software development.

Extreme Programming (XP)

XP, originally described by Kent Beck, has emerged as one of the most popular and controversial agile methodologies. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values €“ simplicity, communication, feedback, and courage €“ and twelve supporting practices:

  • Planning Game
  • Small Releases
  • Customer Acceptance Tests
  • Simple Design
  • Pair Programming
  • Test-Driven Development
  • Refactoring
  • Continuous Integration
  • Collective Code Ownership
  • Coding Standards
  • Metaphor
  • Sustainable Pace

Don Wells has depicted the XP process in a popular diagram.

In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as “User Stories”. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration-by-iteration basis. In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.

Crystal

The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others, whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project ‘s unique characteristics.
Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile process methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions. Alistair Cockburn, the originator of Crystal, has released a book, Crystal Clear: A Human-Powered Methodology for Small Teams.

Dynamic Systems Development Method (DSDM)

DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990 ‘s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994 with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile process and iterative software development projects.

DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:

M €“ Must have requirements
S €“ Should have if at all possible
C €“ Could have but not critical
W – Won ‘t have this time, but potentially later

All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.
The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as Extreme Programming and the Rational Unified Process.

Feature-Driven Development (FDD)

The FDD variant of agile methodology was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week “design by feature, build by feature” iterations. The features are small, “useful in the eyes of the client” results. FDD designs the rest of the development process around feature delivery using the following eight practices:

  • Domain Object Modeling
  • Developing by Feature
  • Component/Class Ownership
  • Feature Teams
  • Inspections
  • Configuration Management
  • Regular Builds
  • Visibility of progress and results

FDD recommends specific programmer practices such as “Regular Builds” and “Component/Class Ownership”. FDD’s proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other agile methods, FDD describes specific, very short phases of work, which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.

The notion of “Domain Object Modeling” is increasingly interesting outside the FDD community, following the success of Eric Evans’ book Domain-Driven Design.

VersionOneVersionOneVersionOneVersionOne
(https://www.versionone.com/)

The VersionOne® Enterprise Agile Platform
VersionOne is an all-in-one enterprise agile solution for software organizations scaling agile.
From discovery to delivery, VersionOne uniquely scales to any number of organizational levels and supports methodologies such as the Scaled Agile Framework® (SAFe®), Enterprise Scrum, Kanban, DAD, LeSS, or a Hybrid approach.