//
you're reading...
Software Development

From Pseudo-Agile to Waterfall – The path of a small and new software company

It seems to me like most software companies which start-up “in a garage” (the typical start-up place) begin with a pseudo agile approach to software development and then migrate to waterfall as the company grows.

It all starts with the sales team which is usually made up of one person who is also the business analyst and possibly a member of the development team going out to win business.  A deal is sealed which is followed by a meeting with the client (Product Owner) to extract more details about the product to be developed. On getting back to the office (garage), he meets with his co-workers to develop a strategy to deliver the product. They all (The Team) work together to analyse, design, implement and test the product.

Products are usually broken down into little chunks which are implemented and demoed  to the product owner periodically. Product owners are allowed to make lots of changes during the development process even if they completely signed off on a set of initial requirements. This of course is because the software house is new in the market and will do almost anything to keep its clients. The development team is usually a collaborative and self-organising team which develop products in an iterative manner using minimal paper work. A similar scenario to what happens in an agile development environment. A remarkable outcome of this is a highly creative and motivated team. Everyone is allowed to give their inputs and feel valued which breeds good team spirit.

However, as the company grows and makes a name for itself, it acquires new clients with larger and more complex projects. In order to execute these projects, the company hires more staff. At this point, developing products using the pseudo agile approach becomes almost impossible. This calls for a structured way of handling product development. Most companies head down the route of the traditional waterfall software development approach.

Product owners are compelled to stick to initial signed-off product requirements and their involvement during the development cycle is significantly reduced. The teams work towards becoming more effective and as such, engage in less of the collaborative meetings while moving over to more electronic means of communication like using documents, emails and discussions over the phone. Hierarchy sets in. Some team members become extensions of the hands and mind of their superiors; bringing no contribution to the decisions made. Team motivation and creativity begins to drop as well as the quality of the products developed. Clients begin to get finished products that meet their initial requirements but probably do not really meet their needs which may have changed during the development cycle.

Does all this sound familiar to anyone?

In the beginning was agile!

Just a thought…

About these ads

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: