Software Development Research and Best Practices

  Phone: (801) 930-7551 
Questions@RedRockResearch.com  

Software development research and best practices

Software Development Research and Best Practices

Read our Blog!

The Agile Development Model  


The Agile Development Model



    
     
Corporate Strategy
      Portfolio Management
      Project Management
        -Agile Development Model
        -SDLC Development Model
      Product Management
      Quality Management
      Configuration Management
      Team Management
      Software Development Manager
      Development Organization

eErosion - Free Server Health Monitoring Jasper - download our free Function Point counter utility Book Reviews

        

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 the Scrum methodology, 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 strict quality management 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. 

  1. Pick a single, simple user-story, give it a unit value of 1.
  2. Assign the other user stories a corresponding unit value, representing how much more complex they are than the initial user story.
  3. Complete the initial user-story, and track how much time it has taken the team to complete it.
  4. Multiply that time by the complexity factor listed for the other user-stories.
  5. 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) 636-0043.

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...

Software Development Best Practices - Software Requirements Management (7/18/2009)
I recently hosted Red Rock Research’s second weekly software development best practices seminar for the general public.  Our topic was Software Requirements Management. Requirements Management is perhaps the most controversial topic in software development.  Everyone seems to have their own technque.  It is also the most important skill-set–statistically more important than development skills–to the overall success of a software [...]

Book Review: The Book of Five Rings (7/14/2009)
Recently, while attending the ‘09 Agile Roots conference in Salt Lake City, UT, Alistair Cockburn–the keynote speaker–referenced Miyamoto Musashi’s 16th-century book called The Book of Five Rings.  I like Asian philosophy (and swords and such) so I picked up the book and read it.  The book was written in 1643 by an undefeated Japanese samurai master who was so effective [...]

Two Days with Alistair Cockburn (7/11/2009)
I recently attended an Agile Development Product Owner class taught by Alistair Cockburn.  The content was excellent.  He taught us about the proper perspectives an Agile Product Owner needs to successfully interact with the project sponsors, users, and the development team. Alistair Cockburn has authored several books on Agile Development, and is one of the original signers of [...]

How to compute % defects removed from release candidate code (6/28/2009)
Recently someone on StackOverflow.com asked me to explain how to compute the defect removal rate for release candidate software.  There are two methods for producing this number and I teach both in several of my seminars, but I’ll explain the simpler method in this post… Lawrence Putnam presented this model in his 1992 Book titled Measures for [...]

Excellence over Heroics (11/13/2008)
I value Excellence over Heroics.  ‘Excellence’ can be defined as “the crisp execution of established procedures.”  Think about that for a minute. Do you know of a software development shop where several prominent developers often stay up late into the night, or come in regularly over the weekend to solve high-profile problems, or put out urgent mission-critical fires? The thrill of delivering when [...]

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

     

www.RedRockResearch.com