Starting with Startup - Tools and Technologies Reasoning

For those that read 'Starting with Startup' posts I want to apologize for not writing recently but last months we have been working a lot. You know how it is in startups :)

In the previous posts I have explained processes and tools we have decided to use. There were some comments and questions why this and not that technology and similar.

When you start with the startup everything is completely new. The following list captures the most important new things that each member of the startup team meet:

• team members
• project
• processes (you cannot expect that each team member will have experience with the process you select)
  
• technologies (you cannot expect that each team member will have experience with all technologies you select)

As we all know it is much easier to predict result if there is minimum of unknowns. And in the startup company more or less everything is unknown - from the project to the project acceptance from final users. So what you try is to minimize unknowns. And to do that you have to carefully select each aspect of the technology and process.

I would say that selection of agile and Scrum is more or less straight-forward. You want to be able to adapt to each new situation that will come up and what gives you more possibilities for that than agile development.

How to minimize unknowns in the project will be topic of further posts.

And at the end comes technology. And here is reasoning similar. You select what suites the best for the team and the project that is in front of you. And that is reason why we didn't select some upcoming technologies like GIT. We have created list of tools we need and then selected those that are the most known to all of us. And the result of selections are in details explained in the previous post.

Starting with the Startup - Setting Up Development Environment

After we have set basics for using Scrum we can start with our first sprints. Our first sprints were devoted to choosing and setting up development environment.

So let explore what do we know so far about the project (of course I knew much more than I can write in this post).

* Our main focus are desktop and mobile web applications

* Our core business is in the field of affiliate networks

* We will use agile process or to be more specific Scrum

So I will jump directly into decisions we had to make and what have we decided:

Web development framework

Basically we have been deciding between two choices: Grails and Wicket. Who is reading my blog from time to time probably already knows answer to this. We have decided for Grails.

Build process

Although Grails have nice build commands we needed something that is easier to integrate with the builds of other projects. Basically we have been deciding between maven and ivy. As Grails supports ivy much better than maven we have decided for ivy.

Continuous build process

More or less we have not been thinking too much here. We have decided for Hudson. Hudson is easy to install, has great front-end for management and number of very useful plugins. One note: although Hudson has Grails plugin we are not using it. We are using ivy in the Hudson to build the Grails projects.

Bug tracker

Although we would be happy not to have bugs that is not reality. So we needed bug tracker. As most of us had experience with Mantis we have decided that our bug tracking tool will be Mantis

Libraries repository

We will be depending on some external libraries. As we don't want to have them stored on Internet we needed some tool that handles dependencies. We have decided for Nexus.

Source code control

Although there are new source code control system like git we have decided to use probably the most common one Subversion

Mobile web development framework

After lot of investigation you find out that the market with the mobile web application frameworks is quite poor. The only available and really useful open source solution is: WALL NG. Luckily we have managed to almost fully integrate WALL NG with the Grails.

IDE Tool

Although we didn't have any experience with InteliJ Idea as this is currently only tool with good support for groovy/grails we have decided that our IDE tool of selection is InteliJ Idea.

In-house Grails plugin repository

As Grails has number of useful plugins and we knew we will be using them. This leads that we need local Grails plugin repository. Grails repository is set in the Subversion.

Having setup like the one mentioned above should give you fluent build process that is easy to repeat in the any moment. Additionally Hudson will ensure that your build is in the fit condition because it will report all build and test breaks.

Starting with the Startup - Start Using Scrum

After Scrum has been selected as process and the team have been educated about agile and Scrum we can start with setting up development environment. Very important thing to notice is that we can start using Scrum right away. Yes, Scrum can be used for tasks where you need to make decisions, investigation, setup of development environment and similar tasks.

As quite often those tasks are not too much time consuming and you want to review current status more often it is best to start with short sprints. E.g. we decided to make one week sprints. This means that you can review your progress, adapt to new findings and adjust your directions on the weekly basis. When you are deciding about length of the sprint you should ask question: For what time period can we be sure that we will not change our minds?

The first thing we did was not part of the sprint but we did that with the purpose. We wanted to select some Scrum tool.

More or less there are two basic options:

* Using excel for product backlog and sprint backlog
* Using some of existing (commercial or open sourced) Scrum tools

We have decided to use ScrumWorks basic edition with the addition of the big pin-board.

ScrumWorks enables you to have product backlog, sprint backlog with the burndown chart, and some advance reporting options. Pin-board is used for user story cards. Idea is to split the pin-board in columns (e.g. todo, progress, testing, done) so everybody can see the status of the current sprint by simply looking onto it. If you are asking: isn't Scrum tool enough, I would say no. The reason is that if you are not part of the team, to check the status of the sprint it is enough to check the pin-board. Without pin-board you would had to open Scrum tool and this is already enough to give it up on checking status of the sprint.

One of the most important features of the agile and Scrum is transparency. We want to be aware of the real situation in each moment. If the project or sprint is late we want to find it out as soon as possible.

So we have prepared our Scrum tools and now we are ready to start sprint(s) for setting up development environment.

So how we set up development environment will be described in the next post.

Starting with the Startup - Educating the Team

In the previous post I have explained why we have choose agile approach or more directly Scrum. But before you start using agile approach it is very important to explain what is agile and Scrum to the whole team and of course to the management.

In our case we are lucky because we have full support from the management. It means there are no "artificial" obstacles in implementing Scrum. The only real obstacle are we. So before going on I made presentation about Scrum, team members did some reading and then we discussed about the whole approach.

So when you are educating team do not forget to explain to them:

• Cores of the agile and the Scrum

And especially take care to explain:

• Why everything in Scrum is time-boxed
• What is user story and what are the differences between user story and use case
• What means DONE
• What is goal of the sprint
• What is velocity and why it gives better estimation when things will be done than "classical" approaches
• Why testing is so important in the agile approach
• What is burndown chart and how it helps the whole team

It may be clear why these points are important but I will shortly explain why I think it is important to take care there is full understanding of them.

Time-boxing - very often developers are used to implement some tasks as long as they want. Even after deadlines. In Scrum everything is time-boxed because this way everybody have to be focused that features have to be finished in proposed time. So it is not possible to change architecture forever. In one moment you have to decide and do implementation.

User story - in lot of companies and even in schools developers are used to thing in use cases. While use cases are good very often they put limitation that need not to be set in given moment. Classical examples are: then user clicks the button.... How the use case knows there is .... button. User story explains functionality that user wants to achieve without too much details.

Done - Done must mean: I am confident that feature implemented can go online. It is tested, written in good quality and I believe there are no bugs. This should be approach for all features that are marked done. You should not return back to this feature.

Goal of the sprint - you have to set goal if you want to have good feeling at the end of sprint. How could you know if your sprint was success or failure without clear goal?

Velocity - velocity is number that based on the experience (yesterday's weather) tells you how much team can implement in the given period of time. Velocity is better than "classical" approaches because it covers meetings, phone calls, unexpected bugs and everything that is happening more or less regulary.

Testing - if there are no tests how can you change the code and be sure that you didn't break any of the existing functionality. Well you cannot and you have to check everything after each change. If you have lot of tests you just run them and find out immediately if you have broke some existing functionality.

Burndown - is great tool that tells you without mercy you current status. It will tell you if you are doing good or if you are doing bad. Just have it in front of eyes.

Conclusion: If you have decided to take agile approach do not forget to educate developers what is agile. It is better to do it at the beginning then fixing problems in the middle.

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.

Starting with the Startup

Few months ago (October last year) I have joined the startup company. An what is the real luck I have joined them really at the beginning. So when I came on my first working day there was server room prepared, tables with computers and few developers that joined the company a month before me. The core business of the company is (will be) affiliate networks and mobile web applications. It is quite young and very innovating area of the current industry trends. If you don't believe me Google it :)

The great thing in joining startup right from the beginning is that you have big influence on the whole process. It is never boring and commonly it is taken care that the team is created from great people and developers. And of course it does not mean that big and small companies do not have great people and great developers.

So when the team is established, servers are prepared and there is rough idea what needs to be implemented you can jump right away into development. You install Eclipse, and start writing code. And doing it this way you will fail in a few months :)

First steps to be done are to establish some basic processes. As my part is mainly considered to development processes I will go through development processes and development environment setup.

Well our decisions I will explain in the coming posts.

New feature on spend day with kids

For those who are using spend day with kids site or find it interesting or useful just to let you know that I have added some new features. Now it is possible to search for indoor and outdoor places to go with kids. So for example now it is possible to search for indoor places to go with kids in the range of 50 kms from London or outdoor things to do with kids in the range of 20 kms from New York.

As I have recently changed my job position my free time become really limited so it is really hard to work on pet projects. Even this small change would be almost impossible if there would not be Grails. Thanks to it it's quite easy to add new features. Actually implementation took only few hours and updating all over 1400 places to visit took much more time.

I hope that in the coming days I will be able to write some posts about my experience with Grails in the startup company. We had lot of interesting points that deserves blogs posts.