Iteration

See “Sprint”

Posted in i | 1 Comment

Iteration Burn Down

See Burn Down Chart.

Posted in i | Leave a comment

Iteration Demo

See Demo.

Posted in i | Leave a comment

Iteration Review

See Demo.

Posted in i | Leave a comment

Iterative Development

Related terms: Incremental Delivery, Evolutionary Development, Timeboxing

A project life-cycle strategy used to reduce risk of project failure by dividing projects into smaller, more manageable pieces of “potentially shippable” product delivered over the course of a series of brief iterations, or sprints. Iterative development  processes afford teams the ability to “inspect and adapt” their processes between iterations, leading to continuous improvement. The concept of iterative development stands in contrast to the traditional, waterfall method of “big design up front” followed by development and testing in strict sequence.

The concept of iterative development is central to all agile frameworks and is regarded as an essential part of agile development. Extreme Programming recommends that teams make frequent, small releases, working in iterations of one to four weeks, with one week being the preferred interval. Scrum also recommends regular cycles, called sprints, of one to four weeks.

Background of the Term

The concept of iterative software development was described by Tom Gilb in his 1988 book, Principles of Software Engineering Management, where he referred to it as Evolutionary Development. It has gone on to permeate all agile frameworks.

Currently, iterative development is strongly associated with incremental development, but historically that was not always the case. See, for example, Barry Boehm‘s paper A Spiral Model of Software Development and Enhancement in which the model is iterative but not necessarily incremental.

Further Learning

Iterative Development – Agile Alliance – glossary entry
Iterative and incremental development – Wikipedia

Posted in i | 3 Comments

McGregor’s X-Y Theory

McGregor’s X-Y Theory is a management theory that turns the established management philosophy on its head. It also supports agile.

Theory X

This theory looks at the conventional idea that management is top-down. It is considered the authoritarian way of managing that was common in many companies before introducing the agile way of working and is still prevalent in some cultures. This form of leadership is characterized by words like controlling, micromanaging, and non-innovative. Often in this culture, employees are not encouraged to speak up with new ideas and do not feel empowered to do so.

Theory Y

This theory focuses on staff control. It encourages innovation, empowerment, and team responsibility. Management supports the team and lets them develop new ideas, supports change, and continuous improvement. Agile principles support this style and are pulling companies into the Y management style.

Background Of The Term

McGregor’s X-Y Theory was proposed in his 1960 book “The Human Side of Enterprise” (McGraw-Hill, 1960)

Further Learning

Managing the Unmanageable, Rules, Tools, and Insights For Managing Software, People And Teams, Second Edition, Mantle and Lichty (Addison-Wesley 2020)

Posted in m | Leave a comment

On Site Customer

See Product Owner.

Posted in o | Leave a comment

Persona

Also: User Persona

A fictional character with individual needs, goals and habits, created by an Agile team as a representative user, to serve as a reference-point for usability during product development. Agile teams may refer back to a set of personas (the convention is to use the English plural rather than the latin personae) as they develop a product, to test whether or not the product meets these users’ needs and desires.

Etymology

The concept of using actual characters to represent “typical users” dates back to advertising giant Ogilvy, which included the concept in their “knowledge management system” in 1997. Agilist Alan Cooper took the concept one step further in his 1999 book The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity suggesting that the idea of “typical” needed to be dropped, and teams should design a product for an individual persona.

References

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper

Personas, Profiles, Actors, & Roles: Modeling users to target successful product design an interactive presentation by Jeff Patton

Posted in p | Leave a comment

Planning Poker

An estimating tool in Agile, Planning Poker is a structured game used to reach group consensus while estimating tasks. It is called poker because it does indeed involve a deck of cards.

Game Play: Each card in the deck is inscribed with a number in the Fibonacci sequence, in which each number is equal to the sum of the previous two: 1, 2, 3, 5, 8, 13, 21, etc. Team members each choose a card that represents their best guess as to the difficulty level of the task, and everyone turns over their cards at once. The high and low cards get the floor to argue their cases, and after that, the game is repeated, the theory being that the players’ estimates will converge through rounds of structured discussion. A Project Manager or Scrum Master may serve as moderator.

Etymology

The game was first created by Agile consultant James Grenning, an original signator to the Agile Manifesto, in 2002, while working with an XP Team. It was later popularized by Agile consultant and Certified Scrum Trainer Mike Cohn, in his book, Agile Estimating and Planning.

Posted in p | Leave a comment

Principles

Also: Agile Principles

The Agile Principles, like the Agile Values, were first stated by a group of independent software development pundits who gathered at the Snowbird resort in Utah in 2001 in order to codify the their shared philosophy. The result was an Agile Manifesto, the signatories to which formed the basis of the Agile Alliance. The Manifesto consisted of a set of Values, and their supporting principles. The twelve principles are listed below:

  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.

Etymology

The Agile Principles were originally stated in the Agile Manifesto.

Posted in p | Leave a comment