Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


Articles
Lifecycle
Design
Programming
Soapbox
Reviews
Cthulhu

Check out our ageing Reviews Section


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:



ICONIX/Sparx Public Classes to Come to London

ICONIX is planning a series of open- enrollment public classes entitled Hands-On Enterprise Architect for Power Users in collaboration with Sparx Systems.




Design

ICONIX Process + Agile Practices == Agile ICONIX

 

ICONIX Process is an open, free-to-use object modeling process. It's minimal, use case driven, and - when combined with the practices described here - extremely agile.

 

ICONIX Process is intensely feedback-driven, fueled by the firm belief that to be "agile" we needn't sacrifice up-front requirements analysis and design: we just need to do them more effectively.

Agile ICONIX Process
Click image for a larger version

 

The process uses a core subset of UML diagrams. These can be combined with a core subset of agile techniques, as shown in the diagram above (this combination is often referred to as "Agile ICONIX"). The combined process is extremely pragmatic as it addresses the most common reasons why projects fail (top of our list is vague, ambiguous requirements). We describe the process in detail (including how to "disambiguate" your requirements) in the book Agile Development with ICONIX Process - and it's all illustrated with a real-world example.

Your customer's requirements will inevitably change during and after development, so you need a process which makes it easier to procure change at any stage. However, requirements often change simply because the team got the details wrong early on through a lack of understanding of the business domain, or because the customer was asked the wrong questions (or misunderstood their replies). So your development process should at least help to reduce requirements churn in the areas where these issues can be addressed.

In the above diagram, the two practices to the left (Agile Planning, and Frequent Small Releases) are global to the whole process; the other practices either relate to Requirements/Design, or provide feedback between the two stages. In addition, practices in the Requirements stage provide input into the Design, and the Design practices provide feedback into the Requirements.

 

Why Define a Core Subset of Agile Practices?

There's a huge number of agile processes available: XP, Scrum, FDD, ASD, the Crystal series, and DSDM to name but a few. Typically, each process is defined in books and on many different websites, newsgroups and so forth.

However, it's our experience that teams rarely address any single agile process: they tend to take the "best bits" from process A, combine them with a practice from process B, and add a light sprinkling of their own home-grown practices to boot. Similarly when a team first decides to adopt a new agile process, they might attempt just a few practices at a time, rather than going "all-out extremo agile" in the first week.

To decide which agile practices to apply to your own projects first, it seems prudent to begin with a core subset: the bare minimum set of practices that you can apply to achieve the agile goals. We've left out a multitude of practices from this core set. This doesn't necessarily mean those other practices aren't as good or are in some way invalid; what we've done is simply put together a collection of practices (from various methodologies) that work well with each other (and, in particular, which work well with the ICONIX Process, a collaborative, "agile-friendly", feedback-driven analysis & design process).

 

The Goals of Agility

Not everyone might agree, but we see the goals of software agility (i.e. the reason you'd want to make your project more agile) as follows:

Respond to changing requirements in a robust and timely manner.
Improve the design and architecture without massively impacting the schedule.
Give the customer(s) exactly what they want from this project for the dollars they have to invest.
Do all this without burning out your staff to get the job done.

This could be further summed up as:

Give the customer(s) what they want within a reasonable time frame without messing it up.

 

The Agile ICONIX Practices

This list gives a little more detail about the practices shown in the above diagram. These practices are also listed in a suitable adoption order (i.e. adopt Practice 1, then practice 2 and so on). So in a sense this list doubles as an "adoption roadmap":

ICONIX Process Practices

These practices cover ICONIX Process analysis & design, plus interaction design, which is a useful way of controlling change by reducing requirements churn.

1.
Requirements analysis and disambiguation
Reduce requirements churn using a variety of techniques (including robustness analysis and domain analysis - see the next practice).
2.

Domain analysis
Capture a common language that can be shared by everyone involved in the project, including the customer and users.

3.

Interaction design (insert your favorite interaction design technique here)
Interaction design, performed as early in the project life cycle as possible, can have a profound effect on the team’s understanding of the problem domain. Take the time to understand the user's needs (e.g. by interviewing actual end-users), and to balance their needs in the context of the customer's business requirements.

This in turn reduces requirements churn and therefore also reduces the expense incurred from responding to changing requirements

4.

Prefactoring/model-driven refactoring
Apply the right design practices (as described in the Agile ICONIX book) to get the design as "on the nose" as possible up front. We've coined the term "prefactoring" to mean:

Using up-front design modeling to refactor and improve the design before writing the code.

Agile Practices

The remaining practices can be thought of as "traditional" agile practices.

5.
Aggressive testing
As we describe in the Agile ICONIX book, Test Driven Development (TDD) can be adapted to become a very effective form of design review ("micro-tests" are driven by the controllers and boundary objects in your UML diagrams). This process is particularly good for exploring all of the "rainy day scenarios" in your use cases. Additionally, if further code refactoring needs to be done, then it's important to have a set of unit tests in place.
6.

Frequent small releases
It pays to release the product to the customer often, so that you can get feedback as early as possible on whether the product’s heading in the right direction. Note that a "release" isn't necessarily a "full customer ship"; it may be a prototype release, a proof-of-concept, a QA testing release etc.

7.
Frequent integration
(aka very-nearly-continuous integration): integrating all production code at frequent intervals. We also view it as essential to have a dedicated build PC which gets all the latest code, builds it and runs all the automated tests, ideally once per hour.
8.
Synchronizing model and code after each release
With this practice we're enabling the next bout of work ("enabling the next effort" to describe it in Agile Modeling terms). After each release, pause briefly to bring the code and the design back in sync. But only update what you need to - if a diagram is no longer needed, discard it (or to keep the managers happy, banish it to the bowels of your version control system).
9.
Agile planning
An agile project is one that is planning driven rather than plan driven. In the book, we give a chapter over to various agile planning techniques.
10.
Responsible ownership/collective responsibility
This practice is deliberately left open to interpretation because you'll need to tailor it according to the personalities, abilities and politics of the individuals on your team. The practice ranges from "extreme" collective ownership to the other extreme, individual ownership (aka specialization).
11.

Optimizing team communication
This practice primarily means looking at the way your team is currently organized and moving team members around (both physically and in terms of their responsibilities) to improve the level and quality of communication.

You'd aim to address this practice quite late in the adoption roadmap, once the other practices are in place and you've got more of a feel for the dynamics going on in the team, and in the interrelated practices.

12.

Short iterations
For planning purposes; dividing a release into fixed-size iterations.

A project often finds a natural rhythm. For example, each week on Monday morning, you might have a team progress meeting to discuss issues from last week and sort out what each person will do this week. It pays to make the planning process follow the same rhythm, by dividing the project into fixed-size planning iterations of 1 week each. As with the other practices, this practice should be tailored to suit your own project's "natural rhythm".

 

Note that several of these practices mention up-front design. For the purposes of defining these practices, our definition of "up-front design" is simply "design performed prior to coding", which can be broken down into fine-grained iterations. "Up-front design" isn't the same as "Big Design Up-Front" (BDUF). BDUF could mean 6+ months of up-front design without a single line of source code -- in other words, a very bad thing!

In the book Agile Development with ICONIX Process we describe the above practices in more detail (including the motivations behind each practice, e.g. why these particular practices work so well together as a core subset). We also describe the various analysis and design techniques which we've mentioned in describing the practices: including persona analysis, agile planning, use case driven object modeling, and test driven development (and use case driven object modeling combined with test driven development).

>> More info about the book

(And here's a chapter outline)

 

<< Back to Design

<< Back to Software Reality

 

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.