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
 

Game Theory , Google and Project Management

At first glance the title seems to club disciplines which have nothing to do with each other.  Read further and you may change your mind.

Game theory is a discipline in mathematics that studies interactive decision-making, where the outcome for each participant or “player” in a game depends on the actions of all.

If you are a player in such a game, when choosing your course of action or “strategy”, you must take into account the choices of others. But in thinking about their choices, you must recognize that they are thinking about yours, and in turn trying to take into account your thinking about their thinking, and so on.

Take the example of a three person fight among A, B and C where each has to shoot the other two to survive. A and B have a 90% hit rate of hitting targets whereas C has a hit rate of only 30%.

Who do you think will survive ?

The answer is C! A and B’s best option is to fire against each other to eliminate the most dangerous opponent which leads to them killing each other while C survives.

Mathematician John Nash (of ’The beautiful mind’) fame had theorized what is called a ‘Nash equilibrium’ where if each participant in a game knows the options and their value for the rest of the participants, there is only one logical choice each participant will make. Any other choice will be less productive.

There have been further advances in this science including a Nobel prize in 2005 for work in this field.

A fresh example of how Game theory is being used in business is infact playing out in front of us.  The FCC bid to open up the 700MHz wireless spectrum for auction has Google, the FCC and the Telecom companies (AT&T etc) all employing game theroists to figure out what their opponents will do and how to strategize.

Interestingly enough, game theory type moves have already taken place without the auction even starting (auction  starts Jan 2008) . Google has lobbied for a rule that the winner has to allow devices free access to connect to the network (like the internet) - this is unlike the closed network policy of current wireless service providers. Google has also indicated it would step into the bidding process. FCC has agreed to the rule but with a catch, the minimum bid has to be $4 billion. This ensures Google doesn’t just pretend it will make a bid , but does so in reality.  AT&T in the meantime has said it will open up its existing network next year.

Lets evaluate  google’s options ?

a. Not bid – not a good option . Bids may come in lower than $4 billion and AT&T may not open its current network

b. Bid to win – again not a good option. It does not want to run the network, just build applications that use it

c. Bid higher than $4 billion but only just, so that it loses. This is the best option. It does not need to shell out any money but will get what it wants – a free network

Now, coming to Project Management . Game theory seems good for auctions, but how does it apply or help in project management.

The answer is pretty straightforward. On a day-to-day basis project managers need to resolve issues, put out fires so that the project stays on track. This involves mostly dealing with people , negotiating with them and arriving at a solution that keeps the project moving forward. The negotiation aspect of the above process is where game theory comes in.

Here are some things you can consider in your negotiation process :

What is the issue?  What decision are you trying to make?
Who are the players? Which players will have an impact on the success of your decision?
Develop a list of options for each player.
What are the goals of each player?  Always assume their goals and actions will be rational from their point of view.
What are the sources of gain?  Mutual gain is possible if players have different preferences, priorities, capacities, risk profile or beliefs.  Where mutual gain is likely, a negotiated outcome is possible.
Who can make credible commitments that might affect the game?
What is the time line?  Who is in a hurry, who can afford to delay?  Will players choose simultaneously, or sequentially?  Is this a one-time situation, or one of many repeated such decisions?
Who knows what?

(Mis)Economics of the Departmental Bell Curve rating of employees

Some companies use the bell curve rating method within each department during employee performance evaluation. The methodology involves dividing employees into ‘Under performers’ , ‘Acceptable performers’ and ‘Over achievers’ by matching the % of employees in each category to the shape of the bell curve and then making employee level HR decisions based on the category they fall into.

In a typical application of this method, 80% of the employees fall within the ‘Acceptable performers’ bucket with 10% each falling into the ‘Under performers’ and ‘Over achievers’ buckets. A company may choose to drop / terminate the bottom 10% employees while bestowing above average bonuses on the top 10%.

The following are the problems with this aproach

Lopping off the bottom 10% in each department

- You hemorrage good departments of good people while keeping questionable folks from the bad departments. Result is that good departments will be unnecessarily spending money/effort on hiring on a continuous basis while it impacts on-going business.

Restricting outperformers to 10% in each department

- This marks the return to communism if you will. If the rating is relative and not absolute why would the rest of the 80-90% of folks need to bother how hard / good they work as the result would be the same.

Assumptions

1. Not all departments are equal. Some departments can have people who are on an average very good and some departments quite the opposite (positively mediocre/bad)

2. An employee needs to be judged by his output vis-a-vis his job requirement and not by the output of his neighbour/colleague