Archive for the ‘Introduction’ Category

Agile Introduction For Dummies – Part II

January 7, 2008

This is a continuation of Agile Introduction For Dummies – Part I

While, having much in common e.g. what they value, Agile Methods also differ in practices they suggest, such as, Extreme Programming, Scrum, Crystal Methods, Feature Driven Development, Lean Development, and Dynamic Systems Development Methodology.


And, Extreme Programming is undoubtedly the hottest Agile Method to emerge in recent years.  XP owes much of its popularity to developers disenchanted with traditional methods and looking for something new, something extreme. The 12-rules of Extreme Programming, true to the nature of the method itself, are concise and to the point.

  • The planning game: Each iteration begins with customers, managers, and developers fleshing out, estimating, and prioritizing requirements or ‘user stories’ for the next release, capturing it in a language that everyone can understand.
  • Small releases: An initial version of the system is put into production after the first few iterations.  Subsequently, working versions are put into production anywhere from every few days to every few weeks.
  •  Metaphor: Customers, managers, and developers construct a metaphor, or set of metaphors after which to model the system.·         Simple design: Developers are urged to keep design as simple as possible, say everything once and only once.
  • Tests: Developers write acceptance tests for their code before they write the code itself, while customers write functional tests for each iteration, with tests being run at the end of each iteration.
  • Re-factoring: As developers work, the design evolves and is kept as simple as possible.
  • Pair programming: Two developers sit together at the same machine to write the code.
  • Continuous integration: Developers integrate new code into the system, as often as possible and all functional tests must be passed code integration, or else the new code is discarded.
  • Collective ownership: The code is owned by all developers, and they may make changes anywhere in the code at anytime they feel necessary.
  • On-site customer: A customer works with the development team at all times to answer questions, perform acceptance tests, and ensure that development is progressing as expected.


Scrum, along with XP, is one of the more widely used Agile Methods, it is a process that accepts the development process is unpredictable and formalising the do what it takes mentality has found success with numerous independent software vendors.  Scrum projects are split into iterations (sprints) consisting of the following:

  1. Pre-sprint planning: All system work is kept in ‘release backlog’.  During pre-sprint planning, features and functionality are selected from the release backlog and placed into the ‘sprint backlog’, or a prioritized collection of tasks to be completed during the next sprint.
  2. Sprint: Upon completion of pre-sprint planning, teams are handed their sprint backlog and told to sprint to achieve their objectives.  The sprint backlog is frozen and remains unchangeable for the duration of the sprint. Team members choose the tasks they want to work on and begin development.  Short daily meetings are critical to the success of Scrum.  Scrum meetings are held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.
  3. Post-sprint meeting: After every sprint, a post-sprint meeting is held to analyze project progress and demonstrate the current system.


Crystal methods focus on people, inter-action, community, skills, talents, and communication as first order effects on performance.  Process remains important, but secondary.  All Crystal methods begin with a core set of roles, work products, techniques, and notations, and this initial set is expanded as the team grows or the method hardens.


The Feature Driven Development method comprises of the following core values:

  1. Putting in place a system for building systems is necessary for successful scaling of larger projects.
  2. Putting together a simple, well-defined process that works best.
  3. Ensuring process steps are logical.
  4. Get rid of ‘Process pride’ as it keeps the real work from happening.
  5. Good processes are moved to the background to allow team members to focus on results.
  6. Short, iterative, feature-driven life cycles are considered the best.

 And, feature driven development begins by:

1.      Building a features list.

2.      Planning feature by feature.

3.      Designing by feature and building by feature.

LEAN DEVELOPMENTThe Lean Development Agile method focuses on twelve management strategies, as follows:

1.      Customer satisfaction is the highest priority.

2.      Always provide the best value for the money.

3.      Success depends on active customer participation.

4.      Every Lean Development project is a team effort.

5.      Everything is changeable.

6.      Domain is not the point, however solutions are.

7.      Complete, do not construct.

8.      An 80% solution today, instead of a 100% solution tomorrow.

9.      Minimalism is essential.

10.  Needs determine technology.

11.  Product growth is feature growth, not size growth.

12.  Never push Lean Development beyond its limits.


Dynamic Systems Development Method (DSDM) is not so much a method as it is a framework with a six stage life cycle.

  1. Pre-project: The pre-project phase establishes that the project is ready to begin, funding is available, and everything is in place to commence a successful project.
  2. Feasibility study: DSDM stresses that the feasibility study should be short, no more than a few weeks.  And along with the usual feasibility activities, this phase should determine whether DSDM is the right approach for the project.
  3. Business study: The business study phase is strongly collaborative, using a series of facilitated workshops attended by knowledgeable staff, who are quickly able to pool their know-how and gain consensus regarding development priorities. This phase results in a Business Area Definition, identifying users, markets, and business processes affected by the system.
  4. Functional model iteration: Functional model iteration aims to build on high-level requirements identified in the business study.  The DSDM framework works by building a number of proto-types based on risk, evolving these prototypes into the complete system.  This phase and design and build phases have a common process:
    • Identify what is to be produced.
    • Agree how and when to do it.
    • Create the product.
    • Check it has been correctly produced (by reviewing documents, demonstrating a proto-type or testing part of the system).
  5. Design and build iteration: The prototypes from the functional model iteration are completed, combined, and tested and a working system delivered to users.
  6. Implementation: During implementation, the system is transitioned into use by creating an Increment Review Document that discusses the state of the system.  Either the system meets all requirements and is considered complete, or there is a missing functionality (due to omission or time concerns).  If, there is still work to be done on the system, the functional model design, build, and implementation phases are repeated until the system is complete.
  7. Post-project: This phase includes normal post-project clean-up, as well as on going maintenance. And so, Agile Methods proving popular are here to stay.  As seen, there are many Agile Methods to select from, but before an organization selects and implements an Agile Method, it should decide whether it is ready to go agile or not.

Agile Introduction For Dummies – Part I

January 7, 2008

In my previous post I wrote about Waterfall vs. Agile.  This post is all about introducing Agile Methods to people who know zilch about them.

Creating a buzz in the software development community, Agile Methods have drawn their fair share of advocates and opponents, with some considering agile methods to be the best thing to happen, while others are not so kind. Agile Methods are a reaction to traditional ways of developing software and acknowledging the “need for an alternative to documentation driven, heavyweight software development processes”.  Traditional methods begin work by eliciting and documenting a ‘complete’ set of requirements, followed by architectural and high-level design, development, and inspection.  Frustrating, as fast moving industry and technology requirements ‘change at rates that swamp traditional methods’, and customers are unable to state their needs even while, they expect more from their software.  As a result, several independent Agile methods and practices have been developed, methods that are actually a collection of different techniques (or practices) that share the same values and basic principles. As the development world changed and it became more and more obvious that traditional methods did not always work as intended, new people-oriented and flexible practices became necessary to cope with the changing requirements, such as:

  • Customer satisfaction takes precedence over conforming to original plans.
  • Change happens, instead of preventing it, far better to cope and reduce the cost of change throughout the development process.
  •  Change elimination means unresponsiveness to business conditions, quite simply it can spell business failure.
  • The market demands and expects innovative, high quality software that meets its needs, and meets them sooner rather than later. Thus, a discussion of new software developments methods saw the emergence of Agile methodology with representatives of Extreme Programming (XP), SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others convening and putting together an Agile Manifesto dedicated to uncovering better ways of developing software through valuing:
  • Individuals and interaction over process and tools:  Traditional software engineering lays too much emphasis on process, while it is already a known fact that people matter more than process.
  • Working software over comprehensive documentation: While documentation is important, building software is the ultimate goal.
  • Customer collaboration over contract negotiation: Contracts are important, however, customer collaboration is more so, and without which nothing goes well.
  • Responding to change over following a plan: Customers and users do not always know what they want at the outset of a software project, therefore it is essential they remain open to change during project execution. 

Agile Methods aim at allowing organizations to deliver quickly, change quickly and change often.  While, Agile techniques vary in practice and emphasis, they share common characteristics, including iterative development and a focus on inter-action and communication.  Maintaining regularity allows development teams adapt rapidly to changing requirements, and working in close proximity, focusing on communication, means teams can make decisions and act on them immediately, rather than wait on correspondence.  It is also important to reduce non-value adding intermediate artefacts to allow more resources to be devoted to product development for early completion. 

Agile movement is all about programmers that add maneuoverability to the process, so that an Agile project can identify and respond to changes more quickly than one using a traditional approach.  Agile Methods are not about practices used, but about recognising people to be primary drivers behind project success, coupled with intense focus on effective maneuverability.  True agility is not just a collection of practices; but also a frame of mind, and while other processes may look Agile, they do not feel Agile.

 To be continued in Part II