Which Software Development Methodology do you use ?

Firms have been using a variety of software development methodologies as they try to bring software development into the fold of engineering and science and have it be less of an art.

At the same time, expert practitioners have put forward a variety of formal methodologies to guide project teams though the software development process.

For the most part, these methods fall into two camps - the Predictive/Watefall category or the Iterative/Adaptive category.

Predictive/Waterfall approach

This is the traditional approach to software development where the team progresses sequentially through the various development phases - planning, requirements, design, coding , testing and implementation. The key aspect here is that there is no going back/revisiting once a phase is complete.  A fixed scope with no feedback loop is the biggest drawback of this process. 

Iterative/Adaptive approach

This approach has seen the most activity in terms of new methods with the Agile family of methods being the most recent and popular. The basic principle is to use shorter delivery cycles to deliver the end product/software quickly by constantly taking in feedback from the end users.

Typical methods falling under the agile umbrella include Feature driven development, Lean development, Xtreme Programming (XP) and the Dynamic systems development method.

While each of the above iterative methods have their own rules and method of operation , they are more common than they are different. In my experience I found that you don’t actually take up one specific method and follow it to the ‘T’.  It is more realistic and useful to evaluate your current situation and organizational environment and pick the aspects that work in each method to build your own process.  In real life, projects end up looking like they have followed  a mix of the above methods as each project team evolves and modifies its process as they execute projects. This happens naturally rather than by design.

How do teams pick their development methodology

I have found that the following have an impact on what development process a team ultimately gravitates to:

• Size of the technology eco system the project team is in. Is the team a part of a large technology organization ?
• How many different application teams are typically impacted by projects. Are applications very much inter-connected in an enterprise environment?
• Are all members of a project team present at the same location
• Are the end users of the software co-located with the development team
• Nature of the application - Web based Vs a thick client
• Criticality of ‘time to market’ for the organization
• Capability of key developers and management’s trust in their ability to execute independently
• Whether the project is  Product development or internal enterprise application systems enhancement
• The industry the project team’s firm belongs to

Here are a few practical examples of different flavors of software development methodologies that have been adopted by various firms that I have been associated with and also a few pointers to why they have adopted those :

A large global financial organization

- Goal is to build and enhance Enterprise application systems
- Uses Waterfall methodology with clearly defined phases for planning, requirements, design, coding , testing and implementation
- Scope change needs are addressed through a Change control process
- Co-ordinated testing and Implementation is required across applications leading to a pre-defined and common release calendar
            - A single project typically spans a lot of applications
            - Each application is impacted by multiple projects
- Large number of users who need to be formally trained. This limits the capacity/appetite for frequent releases.

An analytics products development firm
- Web based Product development
- Software used as a service by internal users as well as external clients
- Users co-located with key development staff
- Iterative development to release features quickly
- Internal professional services users can educate clients on incremental feature upgrades leading to a smooth absorption of new functionality
- Software hosted on internal servers that enables quick and seamless delivery of new features in small incerements
- Shades of Dynamic systems development method
                 - Timebox development effort to come up with a release every 2-3 months with a fixed set of resources
                 - When features involve fundamental / core changes that take longer, the time box elongates.
- Shades of feature driven development
                - When the timebox is longer,there are iterations within the release to design,build and test features incrementally. There isn’t a wait to build all features and only then test them.
- Shades of XP
                - Refactoring of code/design included along with other features during iterations

A provider of software as a service

- Revenue model - Software as a service through web based applications
- Short release cycles (<2 months)
- Iterative UI design through HTML Prototyping
- Shades of lean development
             - Build a minimal feature set to begin with for each application
             - Start selling the service
              - Add features iteratively as needed

A Technology products development firm
- Shrink wrap product development. Products are ‘installed’ by users
- End user Product release cycles are long - 6 months to a year
- Large number of iterations internally till the product is considered to have enough features to warrant a release
 - Shades of feature driven development
             - Features distributed amongst developers who built one set and then went to the next
 - Shades of XP
             - Design, coding and testing done together  
 - Emphasis on building working software and not so much on documentation
             - A working build is available each day with the latest changes.
             - Management, other developers and sales and marketing teams can watch the software being built and provide input and plan their own activities
 

An experimental stock portfolio

I have recently created a portfolio with my stock picks. The intent like most mutual funds out there is to beat the indices - particularly the S&P 500.  Specifically in this case, the intent is to come out ahead of the S&P 500 by a decent margin by the end of 2009.

As an experiment, I have posted the portfolio holdings and its NAV (Net Asset Value) on this website under  ”My Stock Portfolio“. I will be updating the holdings and the NAV on a monthly basis.  Readers of this blog will have a chance to track the portfolio performance and make decisions for their own portfolios.

Note that this is an experiment and may be discontinued if personal or other situations  demand it.