|
The Agile Development Model
|
|
|
|
|
|
|
|
The Agile Development Model
The Agile Development Model Overview
Agile development "started"
in February 2001 with a meeting at the Snowbird ski lodge in Salt
Lake City, Utah. During that meeting, the
Agile Manifesto was
chartered and signed. In 2005,
Alistair Cockburn and
Jim Highsmith gathered another group of people and wrote an addendum known as
the
PM Declaration of Interdependence.
Despite being characterized as "revolutionary," agile is really an organized
collection of practices that were used here and there throughout the history of
software development. The
Agile Manifesto has
become the banner of the agile software developer's creed.
Several flavors of agile exist. The most popular are Scrum,
and XP. Scrum seems to have a higher retention rate than XP, but
many organizations that implore Agile borrow techniques from both.
Agile Development is streamlined for software development models where
requirements change frequently, and a quality system is not
required. Most teams that employ Agile are only able to
reach CMMI level 2. Microsoft has published a study detailing a
level 3 CMMI Agile implementation. You can read about it
here.
Agile also purports to be able to deliver customer value sooner. This
characterization comes from the frequent gathering of software stakeholders,
users, and development teams to show-off the latest build of software, and have
discussions about what to program into it next.
For even more about Agile Development, please see the
Agile Alliance website,
or visit
Alistair Cockburn's
website.
Agile Software Estimation Techniques
Agile software development is best used on projects with a fair amount of
uncertainty as to future market changes or future customer need changes.
Consequently, estimating the time needed to complete a software program produced
using the Agile Development Model can be tricky.
The best approach is to begin the estimation process just after you have
completed your initial list of user-stories.
-
Pick a single, simple user-story, give it a unit value of 1.
-
Assign the other user stories a corresponding unit value, representing how much
more complex they are than the initial user story.
-
Complete the initial user-story, and track how much time it has taken the team
to complete it.
-
Multiply that time by the complexity factor listed for the other user-stories.
-
Add up all the estimates, and you have your first estimate.
Remember, that software estimation is a re-occurring process. As you begin
to complete your user-stories, re-estimate about every 20% so your latter
estimates become even more accurate.
For further information,
Steve McConnell has
an excellent
document on
software estimation.
Agile and EVM (Earned Value Management)
A great reporting technique for listing software development project
progress is to track the project's Earned Value progress.
A proper Earned Value progress chart tracks the predicted timeline,
predicted cost, and the actual progress altogether on the same chart.
This chart tells a story. You can see that the predicted value is the dark
baseline, comprising a start date and a predictable duration of cost and
time. This represents the 'perfect' project.
Actual Cost follows the predictable baseline for the first three weeks, but then
levels off for the next three weeks. This implies the programmers were
taken off the project for some reason during this time. When they
re-engaged, their cost was steeper, implying more programmers were put on the
project, or overtime was worked.
Finally, the Earned Value indicator shows the actual real amount of progress,
prorated against cost, that has occurred.
Based on the indicators, this chart shows that the project is not completed
yet, and still has about 20% of work until the Earned Value equals 100%.
This will occur when the Earned Value indicator finally intersects the
Predicted Value indicator.
You can see how Earned Value Management is an effective tool for project
tracking. In reality, this is more effective than the traditional Gantt
chart, for showing the baseline estimate, the real progress, the
cost-to-date, and the time-to-completion.
With the Agile Development Model, another popular chart called a Burndown
chart is a popular way to track project workload progress.
Burndown charts list the Project Workload progress made, across sprints.
The idea is that over time, one can predict how many sprints will be needed to
complete all of the project work units listed on the project backlog.
Although not as informative as the Earned Value Chart above, these charts
provide a good means for estimating the project completion date.
Getting Started with Agile Development
To get started with Agile Development, call us for a consultation. We can
be reached at (801) 916-5516.
Agile Development Model Procedure Templates
Agile Development Model Project Plan Templates
Agile Project Backlog Templates, Project Burndown Chart
Recent Posts on the Agile Development Model...
The Three P’s of a Quality Management System (3/28/2008)
A Quality Management System, sometimes referred to as a Total Quality Management (TQM) System, is a simple concept that will dramatically improve software production quality over time.
Companies that don’t have a quality system are commonly reacting to production and support issues due to omissive events.
A simple rule of thumb is to ask yourself how many fires your development team has put out this [...]
The Bat-Phone (3/28/2008)
Do you have one of those executives that harasses you with status updates to projects, yet never attends the status update meetings?
Perhaps they call you, email you, stop in to your office, and want to know what the latest on project X is?
Is the behavior effecient? What suggestions do you have about how to convey [...]
Book Review: The 360 Degree Leader (1/22/2008)
John C. Maxwell’s book, The 360 Degree Leader, is an excellent field-guide for navigating the challenges of leadership at all levels of an organization.
Maxwell starts his book by dispelling many common dysfunctional myths that are found at line-level, or middle-level management. Ideas such as “When I get to the top, I’ll be in control,” and “If I were on top, [...]
Book Review: Under Pressure and On Time (12/6/2007)
Ed Sullivan’s book, Under Pressure And On Time, is a no-nonsense guide for delivering software products to market in a timely manner.
In this industry where the average software project is late, over budget, or a complete failure, there are so many books written about what not to do. It’s refreshing to read a software development book that [...]
Book Review: Software Project Survival Guide (11/29/2007)
In Steve McConnell’s book, Software Project Survival Guide, he describes the foundation and procedures for managing a successful software development project.
Researching from NASA, IEEE, and some other industry giants like Grady Booch and Tom Demarco, McConnell summarizes software development into six stages:
Planning
Design
Construction
Testing
Release
Wrap-up
McConnell also offers some great ideas like keeping a project history to record lessons learned [...]
Book Review: Product Development for the Lean Enterprise (11/23/2007)
I finished reading Product Development for the Lean Enterprise: Why Toyota’s System Is Four Times More Productive and How You Can Implement It, by Michael N. Kennedy. This book explains why Toyota’s internal product development process has enabled them to surpass the Detroit auto manufacturers production in both volume and quality.
If you haven’t heard already, Toyota now [...]
Book Review: Confessions of an UnManager (11/22/2007)
Recently I read Debra Boggan & Anna VerSteeg’s book titled Confessions Of An Unmanager: Ten Steps To Jump Start Company Performance By Getting Others To Accept Accountability.
This is an interesting book that speaks to the great “divide” in corporate America. The divide, they say, is the distinction between how management conducts themselves in relation to their teams [...]
Book Review: Integrating Agile Development in the Real World (11/15/2007)
Hooray, another book on Agile Development!
In Integrating Agile Development in the Real World, Peter Schuh explains in depth how to get your team to adopt the Agile Development Model.
Schuh covers several Agile Metholodogies including the problems to watch out for during the process.
I do have to say, this book seemed like a “whole bunch of everything” and so [...]
Agile Development and Government Contracts (11/14/2007)
So I attended our SLC-based agile development forum yesterday. Alistair Cockburn was there, along with some other associates from around the valley.
We discussed various successes and challenges with using the Agile Development Model for software development. One particular topic that became a main discussion point was how to get government agencies to accept Agile Development [...]
Meetings? We don’t need no stinkin’ meetings? (11/8/2007)
There seems to be no set standard for development meetings. Some groups complain about being ‘meetinged to death,’ while others complain about a lack of communication, direction, or group cohesion. Given the two options, it is generally agreed that overcommunication is much better than undercommunication.
One of the more innovative approaches to cutting down on meeting [...]
| Related Seminars |
Date |
Register |
|
|
|
|
|
|