Joseph Michael Pesch
VP Programming

Agile Development

by 18. November 2008 15:39


Neudesic - Microsoft - Agile Training (4.59 mb)

William Salazar – Development Contact for all development technologies including Visual Studio.


Infrastructure Optimization (IO)


Grady Booch - Object Solutions: Managing the object oriented project, 1996

People are more important than any process. Good people with a good process will outperform good people with no process every time.


Alistar Cockburn - Agile Software Development, 2002

I found no interesting correlation in the projects that I studied among process, language or tools and process success.  A well functioning team of adequate people will complete a project almost regardless of process, or technology they are asked to use.


A big process with heavy "Ceremonies and Artifacts" will not improve the likelihood of a successful project.  Having good people, with "enough" process provides the best likelihood of a successful project.


Repeatability vs. Invention

“Repeatability” of end product must have deviation of less than 3%.

“Invention” is process of defining new product (i.e. larger deviation from existing product), often involves a lot of research in addition to normal design and development (research time can be especially hard to estimate).


Extreme innovation, Sydney opera house, original estimate 3 years and 7 Million dollars, actually took 7 years and 100 Million dollars.  Construction keeps incredible statistics on building process estimations; as opposed to Software development which has no statistics to look at.  This points out the significant challenge that Software development faces specifically in the realm of estimation.


Statistically, small and medium size projects experience 25% change from conception to completion, large projects experience 35% change.


Responding to Change

·         “Loading the boat” vs. “Packing light”

·         Predicatively planned projejcts typically waste time on unneeded scope.


“Scope Bloat” – Example, winning year’s worth of groceries:

·         Style 1:  List everything you will need for the year (once and only once)

·         Style 2:  Request items as needed throughout the year

·         NOTE: With style 1 you will inevitably forget some things and request others you may not really need, just to be safe.


1988 study by the Standish Group:

·         45%  of features built are never used

·         19% are rarely used

·         16% sometimes

·         13% often

·         7% regularly


Predictive vs. Adaptive – Game of chess:  As complicated as chess is from a perspective of number of possible moves, building software is even more complicated.  We can invest heavily in an illusion of predictability in software development; however, that is all it is “an illusion”.


Command and Control vs. Empowered Teams – “Walk to your car and get me a pen”:  Stand up, turn left, 10 steps forward, turn left 20 steps forward, etc.  Most likely, he will get off track somewhere along the way, if he deviates from the plan and fails it will be his fault, if he sticks to the bad plan he will fail but at least it will be the planners fault rather than his.  The alternative is to just request a pen and let the capable person improvise and find a pen by his own means.


< Adaptive   Preditive >
Agile Iterative Waterfall

MSF 4.0 for Agile 2006 **

MSF 4.0 2006 **

MSF 4.0 for CMM 2006 **

Scrum 1993

MSF 1994 **



CMM 1991 *

CMM 1991 *


Rational Unified Process 1981


* CMM (Capacity Maturity Model) – Not necessarily a process; however, it is typically misused as a label that you are CMM Level X… (Example of correct use: Scrum is a CMM Level III process).** Not a specific/rigid methodology; but rather, a framework for creation/adaptation into a custom methodology of your own.*** Other Agile Methods: Crystal Clear 2005, Lean, Adaptive (ASD) 2003, Feature Driven (FDD) 2000, Extreme Programming 1999, DSDM 1995, Test Driven Development (TDD). 

Agile Software Development Manifesto (

“We are uncovering better ways of developing software by doing it and helping others do it.”

Through this work we have come to value:

·         Individuals and interactions over processes and tools

·         Working software over comprehensive documentation

·         Customer collaboration over contract negotiation

·         Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.


Not “No Documentation”; but rather, what is the minimally sufficient level of documentation.


With all projects seeing an average of 25-35% change, why fight change, need to embrace it and work with it.  Need to be on same side of table (i.e. “our problem” vs. “their problem”) with the customer.


“Some problems are just hard, some people are just difficult, and processes cannot solve these issues.”

  Key Principals of Agile

·         Deliver actual working software (not demo software)

·         Harness change vs. fighting change

·         Start with teams of motivated people

·         Continuous open communication (identifying and solving issues, not getting into “blame game”)

·         “Empowered teams” over “command and control”

·         Time-boxed iterations in weeks

·         Strive for “sustainable page”

·         Team motivation, vs. individual motivation

Key stumbling block is horizontal development (e.g. UI developer waiting on DBA, etc.), need to work on “unblocking” self (e.g. define your interfaces as needed if the source developer is not available to do so).

 What agile feels like

·         Committed to “DONE” software list

·         People help each other and interact face-to-face

·         People don’t wait a day to communicate

·         Team members know to “give and take”

·         Team members remove roadblocks that other can’t or won’t

·         Non-team members “help” remove roadblocks, and avoid becoming roadblocks

·         Team members willing to “wear multiple hats”

·         Team members pull their weight

·         Team members help each other to pull more weight

·         “I know and trust that we are doing what will best move the project forward today.”


The Agile Toolkit Podcast


Avoid “Velocity Pressure” which can create “Code Debt”, that is, pressure to meet unrealistic goal may result in short-cuts taken that will need to be cleaned up at some later point.


Fibinachi sequence (1, 2, 3, 5, 8, 13) plus epics 20, 40, 100 (where epics represent big features not yet broken down e.g. report generator).


Relative estimates (e.g. how complex/large one task is compared to another), should remain constant across team member abilities; whereas, velocity estimation is unique to peoples skills, ability, motivation/performance, environment, tools, team makeup, etc.  Good velocity planning is really only achievable after one or two sprints at which point you can apply the actual history of velocity against remaining tasks.





Comments are closed