Risk based selection for agile iterative lifecycle methods

This overview helps project management and teams in selecting the best iterative method(s) for their projects, based on the major risks they want to tackle. The overview highlights the focus of the different methods, ie. which risks are mainly addressed. This is not a detailed course on all the methods, but references to literature are provided.

During the last decade agile software development methods and lifecycles (SDLC) became very successful and as such a lot of hype was created around them. The abundance of methods that have been developed looks scaring at first sight: agile, incremental, iterative, evolutionary, lean and extreme are some of the terms used. It is not easy to select the right method for the problem at hand.

As a project team your focus is on tackling your project's risk. Choosing the right iterative development method is an important activity early in your development lifecycle.

Compared to the waterfall approach all iterative methods have in common that their main deliverable in (almost) every iteration is an integrated, tested, executable system. All development processes (requirements, analysis and design, coding, integration and test) are performed in every iteration.

Differences between the methods lie in the kind of risks where they put the focus on, the length of iterations, the amount of documentation, the importance of modeling.

What follows is an overview of the best-known methods, their focus, and main references. Use this overview to make an educated selection for your projects.

Spiral Model (Boehm 1985)

Although not the first application of iterative development, Barry Boehm was the first to explain why iteration matters. The spiral model has explicit activities to identify risks, tackle them via prototyping and evaluate them before going to the next iteration.

A Spiral Model of Software Development and Enhancement, by Barry Boehm, IEEE Computer, May 1988

Incremental Development

Often used together with iterative development. The main focus is on a staged integration. The major risk of a big bang integration near the end of development is tackled. In traditional waterfall oriented organisation, incremental development has the advantage that you can work in an iterative way only at the backend of your lifecycle activities (coding, integration, testing) and do the front part activities (requirements, analysis & design) in a waterfall way. No difficult cultural and organisational change is needed with your business partners. A disadvantage of this approach is that you remain inflexible to requirements changes. With a fully iterative process you also do your requirements activities with every iteration, and you can cope with requirements changes, but it also requires more involvement from your customer.

Rational Unified Process (RUP)

An iterative incremental development process by IBM-Rational which is widely accepted by industry. The process is architecture driven, use case driven, and risk driven, in right balance. Compared to the agile methods there is more emphasis on documentation and visual modelling. IBM-Rational provides a whole toolsuite and web-based process asset library to support the process. RUP is highly tailorable and scalable, although the tailoring can be a challenge for somewhat smaller projects.

The Rational Unified Process: An Introduction, Philippe Kruchten,

eXtreme Programming (XP)

XP is the best known of the agile methods. The aim is on coping with unstable requirements. Emphasis is put on communication, simplicity, early deliveries and testing. The method is based on a set of core practices: test-driven development, continuous integration, pair programming, small releases, customer tests, simple design, refactoring, metaphor, collective ownership, coding standard, planning game, whole team and sustainable pace. XP works very effective and is largely productive for small highly skilled teams. The method is rather difficult to scale to large distributed teams. It can also be difficult to use in traditional development organisations.

www.xprogramming.com (Ron Jeffries)
eXtreme programming - a gentle introduction
Extreme Programming Explained, Kent Beck

SCRUM

A method which emphasizes on project management and team work, with less focus on the engineering practices. Iterations are defined as 30 days sprints. Daily 15 minute meetings (scrums) help the team stay on track and make fast progress. Customer prioritised features are kept in a backlog. The method is widely applicable, both on new projects and on maintenance, at the team level (which might be part of a larger organisation).

www.controlchaos.com/
Agile Project Management with Scrum, by Ken Schwaber, Microsoft Press

Dynamic Systems Development Method (DSDM)

When staying within the deadline and the budget (time-box principle) is your main concern you might have a look at DSDM which focusses on these risks. The process framework is based on Rapid Application Development (RAD). There are similarities with RUP, but there is less focus on tools and techniques.

DSDM Consortium


Crystal Methods (Alistar Cockburn)

XP like method, but more focus on documentation. Emphasis on tailoring for project sizes between 6 and 60 developers, and for criticality. Attention is given on versioning and configuration management.

Crystal Clear: A Human-Powered Methodology for Small Teams, by Alistair Cockburn

Feature-Driven Development (FDD, Peter Coad)

Combines agile methods with model driven techniques. The focus is on features: plan by, design by, build by, and report by feature. The domain modelling is mostly done upfront. Iterations are defined as feature sets. A feature is developed in a waterfall way. Due to the emphasis on domain modelling this methods scales good to larger teams.

A Practical Guide to Feature-Driven Development (The Coad Series),

Test-Driven Development (TDD)

Focuses on testable requirements and test automation. The development cycle is turned around: start with a test case and a failing unit test before implementing the code. Use unit test tools and build a regression testsuite on the go. This is one of the XP practices that seems to be more difficult to adopt in traditional development environments.

Test Driven Development: A Practical Guide, by Dave Astels
Test Driven Development: By Example, by Kent Beck
Introduction to TDD, by S.Ambler


Component Based Development (CBD)

CBD is about building software systems by assembling and integrating software components, rather than about coding. The focus is reducing development cost and rapid system assembly. Activities include: component qualification (suitability testing), component adaptation, assembling components into systems and system evolution.

Component-Based Software Development / COTS Integration


Lean Software Development (LSD, M.Poppendieck)

Based on "lean thinking" in manufacturing, logistics and product development. The focus is on efficiency and the elimination of waste. Also related to "lean six sigma".

Lean Software Development: An Agile Toolkit for Software Development Managers
Lean Software Development. Deliver Value Quickly, Efficiently, Reliably - Every Time


Waterfall lifecycle

A waterfall lifecycle is only suitable for easy projects with well known requirements and known solutions. These kind of project are rather rare those days. Or as Fred Brooks explained in his
‘95 ICSE keynote and in his famous “Mythical Man-Month”: “The waterfall model is wrong!”.

General literature on agile and iterative development:
Manifesto for Agile Development
Agile and Iterative Development: A Manager's Guide, by Craig Larman
Agile Project Management: Creating Innovative Products, by Jim Highsmith
Agile Software Development, by Alistair Cockburn
Unified Project Management, by Walker Royce
Balancing Agility and Discipline, A Guide for the Perplexed, by Barry Boehm, Richard Turner

Conclusion

An iterative development lifecycle is the obvious choice in todays flexible software business. Choosing the right variant of iterative development should be based on the risks you want to tackle in your project. This overview gives you a first guideline.

Digg it! | Add to del.icio.us

Pair Programming Benefits and Rules

Pair programming is one of the more successfull technique from the agile movement. However it may require a cultural change in traditional software shops. Paying attention to explain the benefits and giving some guidance will help:

General benefits:

• Produces better code coverage. By switching pairs, developers understand more of the system.
• Minimizes dependencies upon personnel.
• Results in a more evenly paced, sustainable development rhythm.
• Can produce solutions more rapidly.
• Moves all team members to a higher level of skills and system understanding.
• Helps build a true team.

Specific benefits from a management standpoint:

• Reduces risk
• Shorter learning curve for new hires
• Can be used as interviewing criteria ("can we work with this guy?")
• Problems are far less hidden
• Helps ensure adherence to standards
• Cross-pollination/resource fluidity.

Specific benefits from an employee perspective:

• Awareness of other parts of the system
• Resume building
• Decreases time spent in review meetings
• Continuous education. Learn new things every day from even the most junior programmers.
• Provides the ability to move between teams.
• More rapid learning as a new hire.

Rules:

1. all production code must be developed by a pair.
2. it's not one person doing all the work and another watching.
3. switch keyboards several times an hour. The person without the keyboard should be thinking about the bigger picture and should be providing strategic direction.
4. don't pair more than 75% of your work day. Make sure you take breaks! Get up and walk around for a few minutes at least once an hour.
5. switch pairs frequently, at least once a day.

Read the complete article with good advice in 'Pair Programming Observations, by Jeff Langr, StickyMinds.com'.

For more in-depth knowledge of cost and benefits read:
Pair Programming Illuminated - by Laurie Williams, Robert Kessler

Most Useful Requirements Processes

Understand and communicate requirements that align yout IT priorities
with your business needs.

No process is more fundamental than the process of defining and managing business and technical requirements. It's no surprise that studies cite inaccurate, incomplete, and mismanaged requirements as the primary reason for project failure.

The Requirements-engineering process consists of two major domains: definition and management.

Best practices:

Elicit Requiremements:

• Define the vision and project scope.
• Identify the appropriate stakeholders.
• Select champions (Voice of the customer).
• Choose elicitation techniques (workshops, questionnaires, surveys, individual interviews).
• Explore user scenarios.

Analyse Requirements: verify they are complete and achievable

• Create analysis models.
• Build and evaluate prototypes.
• Prioritize requirements.

Specify Requirements:

• Look for ambiguities.
• Store requirements in a database.
• Trace requirements into design, code, and tests.

Validate Requirements:

• Review the requirements through a formal peer review.
• Create test cases from requirements.

Manage Requirements:

• Manage versions.
• Adopt a change control process.
• Perform requirements change impact analysis.
• Store requirements attributes.
• Track the status of each requirement.

Applying requirements best practices lead to higher satisfaction for your customers.

These are highlights from Matts Klassen's article: Achieve Useful Requirements Processes.