Changes between Version 14 and Version 15 of WhitePaper

Show
Ignore:
Author:
anonymous (IP: 96.234.165.66)
Timestamp:
01/13/08 21:58:20 (3 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • WhitePaper

    v14 v15  
    1 = Real World Agile Development: = 
    2 = The Promise, The Problems, and The Practice =    
    3  
    4 == An SW Complete Perspective, January 2008 == 
    5  
    6 ---- 
    7  
    8 == The Promise of Agile Development == 
    9  
    10 Agile Development has received considerable attention lately because of the 
    11 promise to deliver greater responsiveness, reliability, and customer 
    12 satisfaction.  Unlike more traditional methodologies, the emphasis of Agile 
    13 Development is on: 
    14  
    15  - self-organized teams of trusted, motivated individuals, 
    16  
    17  - frequent delivery of usable software, 
    18  
    19  - continuous testing, and 
    20  
    21  - direct interaction between developers, management, and customers. 
    22  
    23 These are accompanied by a corresponding de-emphasis of: 
    24  
    25  - rigid and unrealistic schedules, 
    26   
    27  - cumbersome and inflexible processes, and 
    28  
    29  - burdensome and unnecessary documentation. 
    30  
    31  
    32 SW Complete's experience with Agile Development has convinced us that this is 
    33 not just hype.  Agile Development techniques free talented developers to do what 
    34 they do best, while providing management and customers the feedback to know the 
    35 effort is succeeding.  We have been able to use an Agile Development approach to 
    36 jump start new development efforts, and rescue projects that were trapped by 
    37 antiquated processes, aging code bases, and stifling bureaucracies. 
    38  
    39 The basic principles of Agile Development are readily comprehensible, easily 
    40 adopted, and immediately justifiable via concrete results.  There are several 
    41 variations on the Agile Development theme to choose from, including: Scrum, 
    42 Extreme Programming, and Feature Driven Development.  Each shares common 
    43 characteristics and has provided real world success stories, and yet Agile 
    44 Development has not achieved wide-spread acceptance in the software industry. 
    45 In fact, it receives criticism from many respected authorities. 
    46  
    47 So what's the problem?  
    48  
    49  
    50 ---- 
    51  
    52 == The Problems with Agile Development == 
    53  
    54 While we agree with the Agile Development philosophy in principle, the 
    55 implementation typically encounters several problems.  These include: 
    56  
    57  - '''Acceptance.'''  Experienced developers, managers, and customers aren't 
    58    blank slates to simply be reprogrammed, and Agile Development is likely not 
    59    the first new approach to be sold as a panacea.  To be accepted by 
    60    developers, it can't be imposed as a rigid methodology.  Moreover, there are 
    61    numerous other stakeholders (acquisition managers, program managers, testers, 
    62    field support personnel, and end users), each with different goals and 
    63    agendas. The case for Agile Development may be easily made to developers, but 
    64    the benefits to other stakeholders are perhaps not so readily apparent. 
    65  
    66  - '''Coordination.''' Agile Development's assumption of small development teams 
    67    in close contact with management and customers is often wishful thinking. 
    68    Management and customers often lack the required availability through no 
    69    fault of their own.  Development efforts rarely exist in isolation, but are 
    70    part of larger programs with overarching schedules, budgets, milestones, and 
    71    other constraints.  This requires associated development efforts to be 
    72    distributed across multiple teams, sites, and functional areas.  The direct, 
    73    informal communication defined by Agile Development does not automatically 
    74    scale well across diverse environments.  Additionally, access to subject 
    75    matter experts or integration test environments may be severely limited, 
    76    requiring more formalized coordination. 
    77  
    78  - '''Commitment.'''  Any paradigm shift is a long term commitment.  Like trying 
    79    to diet or to quit smoking, it is easy to fall off the wagon.  Due to past 
    80    frustrations, the trust and patience of management and customers may already 
    81    be in short supply.  The necessary developer training and code refactoring 
    82    require time and funding that are either limited or are contractually 
    83    inaccessible.  And it is hard to overcome the sense that tomorrow's fix can't 
    84    get in the way of today's fire drill. 
    85  
    86  - '''Instability.'''  Despite its stated tolerance of requirements changes, 
    87    Agile Development requires a relatively stable external environment. 
    88    Enterprise-wide direction changes can easily derail small projects. 
    89    Deployment platform or integration framework changes can cause substantial 
    90    rewrites that are disruptive to users who are preoccupied with evolving 
    91    missions and site-specific needs.  Within the project team, personnel 
    92    turnover results in loss of project history and the need for developer 
    93    retraining.  A self-organized team is only productive when its membership is 
    94    stable.  Likewise, turnover in management or domain experts may result in 
    95    completely redefined processes or requirements, respectively. 
    96  
    97  - '''Inertia.'''  Big organizations, legacy deployments, monolithic 
    98    organizational infrastructure, and long funding cycles tend to produce a very 
    99    persistent status quo.  Fielded versions of applications must be maintained 
    100    indefinitely.  Familiar, ingrained formats for management data and 
    101    communication cannot be abandoned overnight.  Incentives created in 
    102    conjunction with existing processes are often institutionalized.  If the 
    103    benefits of a new approach are not quantified, they will be overshadowed by 
    104    the perceived costs, and no change will be accepted. 
    105  
    106 ---- 
    107  
    108 == The Practice of Agile Development == 
    109  
    110 In order to address the problems listed above, the successful practice of Agile 
    111 Development begins with acknowledging these simple truths: 
    112  
    113  - Every perceived problem cannot be fixed at the same time, and some will never 
    114    be fixed. 
    115   
    116  - You can't manage what you can't measure. 
    117  
    118  - If it isn't accessible or understandable, it won't be used or maintained. 
    119  
    120  - Relying on clairvoyance and telepathy is never a safe bet. 
    121  
    122  
    123 These truths are implied in the criteria we use to judge all project activities 
    124 and decisions: 
    125  
    126  - '''Impact.'''  The backlog of features and tasks are prioritized based on the 
    127    positive and negative impacts on users, code stability, funding, and 
    128    milestones.  The "bang for the buck" and "no free lunch" cliches live here. 
    129  
    130  - '''Validation.'''  In a test-driven approach, requirements are defined in 
    131    terms of the tests required to validate the end products.  Code that is 
    132    designed to pass those tests will inevitably provide more traceability and 
    133    reliability. 
    134  
    135  - '''Clarity.'''  Making requirements, design, and code simple, transparent, 
    136    and self-explanatory is a primary goal, not an afterthought.  Traditional 
    137    methodologies rely on strictly formatted documentation that is superimposed 
    138    on the development process.  Agile Development, in contrast, relies on the 
    139    natural artifacts of the process and tools.  Thus, the focus is on clarity of 
    140    the work products, not the volume of documents. 
    141  
    142  - '''Flexibility.'''  Tasking and decisions must serve a purpose; however, that 
    143    purpose involves not only the immediate usefulness but also an ability to 
    144    adapt to future needs.  This implies a focus on the big picture and an effort 
    145    to anticipate.  Flexibility is often favored over short term, small-scope 
    146    optimality.  While it may be impossible to predict the future in detail, 
    147    trends and probable scenarios should be taken into account when prioritizing 
    148    tasks and defining features. 
    149  
    150 It should be obvious that these criteria are not in conflict with Agile 
    151 Development.  It is important to note Agile Development is not a methodology in 
    152 the traditional sense.  Its concepts can be implemented as heuristics and 
    153 tactical process improvements rather than rigid prescriptions.  Thus, Agile 
    154 Development is adaptable to existing processes and other methodologies.  This is 
    155 good news in that we are often not in control of those choices. 
    156  
    157 The SW Complete version of Agile Development, known as HighTest, comprises the 
    158 following practices: 
    159  
    160  - '''Testing''' is the central, focal activity.  Requirements are defined by 
    161    tests.  Designs are defined in terms of passing the tests.  Coding is not 
    162    considered complete without passing the associated tests.  Testing, in this 
    163    sense, refers not only to unit test code but also to other forms of 
    164    validation, including user acceptance criteria and project performance 
    165    metrics. 
    166  
    167  - '''Composability''' of the software is a primary goal.  The overall 
    168    application model is not domain-specific but aimed at facilitating the 
    169    composition of domain-specific components and platform-specific services. 
    170    This allows the model to remain intact as the domain and mission evolve. 
    171    Pluggable components can be retooled or replaced to keep pace with changing 
    172    requirements and advancing services.  When done right, composable code 
    173    becomes a direct representation of the requirements, and reuse of generic 
    174    services is promoted.  Clarity and flexibility are simultaneously increased. 
    175  
    176  - '''Configurability''' increases flexability, responsiveness, and applicability. 
    177    The more configurable the software, the better.  Specific components 
    178    assembled via generic models lend themselves to configurability. 
    179    Configurable software can be tailored to individual site requirements without 
    180    negatively impacting version control or deployment activities. 
    181  
    182  - '''Automation''' is both a source and a measure of productivity. Tests, 
    183    analysis, and documentation that are automated are repeatable, painless, and 
    184    another source of self-documenting transparency and metrics.  If you're going 
    185    to do something a second time, try to automate it.  Development and 
    186    management tools, though never a substitute for good practices, enhance and 
    187    simplify the software process.  For almost every proven practice, recommended 
    188    activity, or repeated task, there will be a tool to make it more efficient, 
    189    effective and simple. This is certainly true for testing, tracking, 
    190    documentation, and configuration management. 
    191  
    192  - '''Incremental development''' reduces both cost and risk.  In conjunction 
    193    with continual testing, it leads to software that is always deliverable and 
    194    demonstrable.  The backlog of requirements becomes more manageable.  Small 
    195    increments provide the flexibility to adjust to an evolving mission. 
    196  
    197  - '''Incremental process improvement''' allows Agile Development to be mixed 
    198    into existing processes with minimal impact or resistance.  Tools, 
    199    automation, and better practices are added in small steps, and can be adapted 
    200    for use with legacy projects.  Task tracking and unit testing are 
    201    particularly easy to add incrementally. 
    202  
    203 ---- 
    204  
    205 == Benefits == 
    206  
    207  - '''Acceptance.'''  Increased understanding and measurable success are the 
    208    keys to acceptance.  Automation and testing yield metrics to validate 
    209    performance and insure requirements are met.  Incremental process 
    210    improvements reduce resistance from all stakeholders by reducing costs, 
    211    risks, and schedule impacts.  Tools for testing and task tracking produce 
    212    natural, comprehensible artifacts instead of laborious documents. 
    213  
    214  - '''Coordination.'''  Composable software facilitates distributed development 
    215    while minimizing the impact of infrastructure churn.  Explicit validation 
    216    criteria provided early and maintained continuously provide the focal point 
    217    for coordinating stakeholders even as mission and priorities evolve.  Metrics 
    218    from testing and tracking tools provide the basis and justification for 
    219    schedule and requirements changes.  Incremental improvements to software 
    220    within controlled test environments promote continuous feedback from users. 
    221  
    222  - '''Commitment.'''  Incremental improvements to application code and 
    223    development processes require minimal commitment from management or customers 
    224    while also promoting confidence.  Automated tests help to insure that quick 
    225    responses to requirements changes result in working code, thereby reducing 
    226    the tendency to stray from best practices when quick turnaround is demanded. 
    227    Generic composability models help to reduce the need for both user and 
    228    developer training by providing a common look and feel and a natural containment  
    229    of complexity. 
    230  
    231  - '''Stability.'''  Composable models are naturally service-oriented. 
    232    Configurable interfaces are manageable interfaces that reduce the cost and 
    233    risk associated with even large modifications to enterprise infrastructures. 
    234    When automated testing is included in configuration management, the result is 
    235    a regression test capability.  This, along with the project history provided 
    236    by task and requirements tracking tools, reduces the impact of turnover. 
    237  
    238  - '''Agility.'''  In a discussion of something called "Agile Development", the 
    239    word "agility" had better show up eventually.  Agility is the ability to 
    240    succeed in the face of evolving mission, infrastructure churn, and 
    241    heterogeneous user requirements.  Following the principles and practices 
    242    described here can provide the necessary flexibility without sacrificing 
    243    clarity of purpose or confidence in results.  While we have succeeded in 
    244    rescuing projects through the incremental adoption of these practices, Agile 
    245    Development works best when it is promoted throughout the enterprise 
    246    beginning with the planning and acquisition phases, and incentives of all 
    247    stakeholders are aligned with these principles. 
     1 - [AgileDevelopmentWhitePaper Agile Development White Paper]