Increasing Business and Technology Throughput

I recently updated a template on my website that I frequently use when either leading iterative development projects or coaching project managers on effective iterative development techniques called the Iteration RouteMap.  The word 'routemap' comes from a South African colleague who used the 'king's english' and insisted that the term routemap was more appropriate than roadmap, the name's stuck ever since!

As far as templates go this one is really quite lightweight, however, there are several key concepts that are important when managing projects in general and iterative projects in particular.  The first is using a mechanism to determine how to size effort.  I typically look at this from the perspective of size and complexity (which is usually a good indication of risk).  Large and complex work items should be started early in the project lifecycle.  I also estimate using Perfect Engineering Days (PEDs), this illustrates how long something should take without interuptions, well defined requirements and all of the other components that can impact how long it actually takes.  A Load Factor is then used to convert PEDs into a realistic estimate.  The Load Factor reflects the productivity of the project and is typically between '2' and '5'.  A '5' reflects a programming language that is either new to the development team or difficult to work with (such as Visual Basic 4/5 within an object oriented development environment).  2 is usually only achieved when the development team has been working on a project for an extended period of time, usually near the latter iterations of the project (when development complexity should be lower). It should be noted that as you actually get some iterations completed you can start substituting the Velocity of your development for the Load Factor. 

The final item is to recognize that there are different Types of functionality/value that will be completed during an iteration.  The logical work items are user stories that represent tangible units of business value that stakeholders can identify and provide feedback on.  However, often these stories need to be supported by 'Infrastructure' stories which ensure a well designed system which can support its non-functional requirements.  In addition, the User Interface (UI) necessary for the story can also be decoupled from the story iteself and is often represented as a separate work item. 

Hopefully this template will be useful to both those just starting their agile/iterative development initiatives as well as those who have been doing this type of rowkr for awhile.  As usual, please feel free to email me with comments.

Posted by Bryan Campbell at 10:01 AM | Permalink | Comments (2) | TrackBacks (0)

One of the most important aspects of the Unified Process and what I emphasize when managing complex software development projects is to focus on an 'architecture-centric' approach to building a system.  The best way to accomplish this from my perspective is to ensure a prioritization of user stories/use cases based on not only business value but architectural significance.  It's also important to remember that building architecturally significant components can still demonstrate business value at the completion of an iteration.  A simple UI showing how data can be entered, stored and retrieved (even if it's not editable) shows a business stakeholder that the 'tiers' and 'layers' that exist behind the scenes are adding value.  One way to ensure a balance between business needs and architectural requirements is to establish a troika of the Product Owner, Architect and Project Manager to review and assess the Release Plan and its prioritization.

The Design Discipline

• Balancing the amount of effort applied to formal Design:  Agile Modeling (AM)

• Designing for Future Change: Service-oriented Architectures (SOA)

A Service-oriented Architecture is one in which all functions, or services, are defined using a description language and have invokable interfaces that are called to perform steps in business processes.  Each such service must have unambiguous semantics (see Design By Contract), and should preferably be idempotent (repeatable without side effects).  Larman’s expedited UP leads smoothly to the definition of such architectures since it promotes the definition of system or component-level operations with well-defined semantics (contracts). Although this requires a degree of maturity within a development organization its benefits are significant.

• Realizing the Full Benefits of Reuse:  Product Line Architectures  

Adopting some form of Product Line Process is indispensable to the achievement of true asset reuse across a range of projects and products.  The earlier model of “if we build a component repository, they will come” simply does not work.  To realize reuse benefits the enterprise must combine an application engineering process with a domain engineering process.  A standard recommendation is to adopt this two-level approach wherever and whenever feasible.  Using commonality/variability analysis together with a full repertoire of variation point management techniques (model management and refactoring, model-driven architecture, management of variable configurations, design patterns, framework development, polymorphism and AOSD) in order to achieve this well-defined relationship between the domain engineering and application engineering processes.  (Of course, one of the reasons software development has moved towards OO technologies is that they contribute importantly to this repertoire.).

• Design by Contract (DBC)

  Design by Contract is a simple but powerful discipline for writing specifications of use cases, services, system operations, component operations and class methods.  It uses the concepts of pre conditions, post conditions and invariants to achieve a full separation of “what” from “how”. The benefits of so doing are enormous, and include:

  • Precision,
  • Lack of ambiguity,
  • Testability, and
  • The ability to write short specifications even for complex implementations.
    

Posted by Bryan Campbell at 10:39 AM | Permalink | TrackBacks (0)