Starting with the Startup - Selecting Processes

In the previous post about Starting with the Startup I explained that as our first step we have decided to choose processes. Of course one of the most important decisions to make is to choose right management methodology (framework). The product owner (managing director) was coming from the company with the strong full life cycle (waterfall if you prefer this way) process. He had no idea about any other processes and he was used to work in that way. Even all the next steps he planned were in that direction. There was plan to hire external consultant that will more or less write "book with the boxes" that we will implement. And that will be our solutions.

The good thing is that although he didn't know for something else than waterfall methodology he didn't like waterfall approach.

So as you may guess it was not hard to explain him what is agile, what is scrum and what are advantages of the agile approach compared to waterfall approach.

For those who don't know difference just shortly: in waterfall you define and plan the whole project in advance and then just implement what was planned. No changes are allowed or complex change request processes are defined to introduce new requirements. In agile style you create vision and rough plan of your project and then implement your project in increments and iterations. You allow project to grow and change in the way according you new discoveries or business needs.

Selecting agile approach out of the box would be mistake because for any decision you should have a good reasons. So let analyze situation we have.

• We are startup company with small number of developers.
• We have rough idea what is our goal
• Our main focus are desktop and mobile web applications
• The market where we are moving is changing rapidly
• We are not sure and not aware of all the features we will need in our applications

Possibility 1: Waterfall (or similar strong processes) - if we choose this path it means that we need to define all the features of our applications. Oops, we are still not sure how many applications we will have. Not to talk about features of those applications. Ok, but if we analyze problem carefully maybe we would be able to define all the features in all the applications. But the next problem is: market is changing rapidly. Are we sure we want to create detailed plans too far in the future knowing that market will change in the mean time. Decision: this is not the way we should go.

Possibility 2: Agile (Scrum) - I would say this is the direct hit. Agile approach is good to use if you have clear vision but not clear plan. If you have small (up to 9 persons) collocated team. If you requirements can change fast according to new discoveries and you need to adjust your goals according to market changes. Well if you check the list above agile is covering situation we have.

Decision: So actually it was not so hard to make the decision. We have decided to take agile approach implemented with Scrum.