In November 2007, StoneHenge Partners integrated 10 of the 12
principles of Agile software development into our Nimble℠
Method. How did we do that? Why not all twelve? What else did we
include in the Nimble℠ Method? All good questions; let's take
them one at a time.
Below is a list of the ten Agile principles we adopted and a
brief explanation of how we apply each of them.
| Agile Manifesto |
Nimble Method |
| Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software. |
Our methodology includes iterative development and delivery
of working code. |
| Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive
advantage. |
Our methodology is designed to facilitate change and to
keep our Client informed as to its impact. |
| Deliver working software frequently, from a couple of weeks to
a couple of months, with a preference to the shorter
timescale. |
We work with our Client to define the functionality to be
delivered in each 2 to 4 week iteration. |
| Business people and developers must work together daily
throughout the project. |
Our initial requirements document creates a functional
framework which must be further defined through additional face to
face review with the SME, as it becomes time to create
it. |
| The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation. |
We conduct a daily development team face-to face scrum
meeting, which includes the Client, as well. |
| Working software is the primary measure of progress. |
This is our primary measure of progress, not how many hours
have been charged to the project. |
| Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely. |
Our development team overtime has been significantly
reduced. |
| Continuous attention to technical excellence and good design
enhances agility. |
Our initial and on-going review of the system's functional
component diagram, allows us to quickly identify change and
adjust. |
| Simplicity--the art of maximizing the amount of work not
done--is essential. |
We believe in working smart not hard. Two collaborative
tools we use to help us accomplish this are Enterprise Architect
for documenting requirements and designs in a modeling framework
and Mantis for documenting defects so we may learn from our
mistakes. |
| At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly. |
The development team conducts a project review before
starting the next iteration to insure we have learned from our
experiences with previous iterations in an effort to prevent future
defects. |
But there are two Agile principles we did not adopt. Here is a
brief explanation why.
| Agile Mainfesto |
Nimble Method |
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
|
We build projects around the functional components required
by the Client through Function Point Analysis. It
allows us to identify the system's functional components. Next we
build our project team with motivated individuals. Then we work
with our Client and the development team to define the iteration
development plan.
|
The best architectures, requirements, and designs emerge from
self-organizing teams.
|
We use the Function Point Analysis
methodology to insure that we thoroughly and consistently discover
the User's functional requirements.
For example, one technique we use to define the boundary of
the application is called a functional component diagram. This
diagram is similar to a logical data model and it allows us to
bridge the communication gap between business users and
developers.
This process also allows us to consistently size projects so
we may price them and assist our Clients in their project planning
process through ROI analysis or the sizing of phases. |
Two additional non-Agile components are included in our
Nimble℠ Method. They are:
- We create an upfront high level functional requirements
document for the entire project, via our Function Point Analysis
methodology, so we may size and plan our projects. This is similar
to the classic Waterfall methodology, except it does not include
Use Cases. On the other hand, we require the development team to
work with the client to further define their needs as it becomes
time to create each component of the system.
- We use Function Point Analysis (FPA) to size, plan and track
projects. FPA is the only ISO approved methodology to consistently
size software development projects. Simply put it is a method that
allows you to divide a system's User's requirements into one of
five different functional components so they may be better
understood and analyzed.
This methodology was created by IBM in the late 1970's. Today
the methodology and certification of counters is the responsibility
of the International Function Point
User's Group. There are approximately 1,200 certified counters
in over 20 countries.
At StoneHenge Partners, we believe in Agile development and we
have had nothing but great results since making the change. Based
on the above, hopefully you too will agree that Nimble℠ is
working with Agility.