How to start an agile project
During the recent panel debate in Colombo Agile Meetup my colleague Lasantha Bandara asked the following question:
How do you start an agile project and ensure room for future enhancements? How can we achieve flexibity at the beginning?
This is my answer:
Flexibility is about having an acceptable cost of change. Sometimes, the best cost of change is to create something and throw it away early to try something else if it doesn’t work out.
The first technical decision I make on projects is what I call the deployment model. That is: How will the users access the application and where will the data reside. The most common categories of deployment model include web, disconnected client, rich client with server, and mobile client. There are other less common as well, for example an email responder. A mobile web client could also be considered a category of its own and so may perhaps a rich JavaScript web application.
As Sabri Sawaad said during in the panel: You must make decisions, but consider the cost of changing them.
You have to choose a deployment model and client-server communication protocol before you write any code that you can demo. Often, the project comes with an assumed deployment model, but it’s not always set in stone. For example, a project where the customer was aiming for a traditional web application, we suggested a JavaScript application due to the skillset of the developers. In another project, we challenged the customer to try a rich client instead of a web application, but after the first sprint, we discarded the code and did the web application instead. In a final example, discussing the requirements further with the client it turned out that a web client was more appropriate than the initial idea of a mobile application, so we had to replace team members to get the correct skillset.
As an architect, it’s part of your job to help the customer find a deployment model that matches the requirements of the users and the skillset of the team.
On the panel, Subuki Shihabdeen and Buddhima Wickramasinghe both pointed out the importance of early feedback. In my opinion, this implies that the beginning of a project is a bad time to learn new technologies. When you know the deployment model, use the technologies and frameworks you are familiar with to quickly show something to the customer. If this means delaying using a database, as Hasith Yaga suggested in the panel, do this. If it means using Entity Framework and SQL Server, because the team is familiar with this, do that. But as Sabri said: Invest in strategies to minimize the cost of changing these decisions, such as encapsulating the data layer.
In order to quickly choose and roll out a first demo, the only think I’ve found to work is to practice. I’ve created applications repeatedly from scratch in many frameworks and languages for practice. Each time I do it faster.
So here is my process, summarized:
- Spend time to practice technologies so you can choose good options with confidence
- Help the customer choose an appropriate deployment model based on the user needs and developer skills (including your own)
- Put something in front of the customer quickly by using your existing skills
- Invest to reduce the cost of changing decisions on frameworks and technologies
- Change course if you find a better technology or even deployment model
Comments:
[Dumindra] - Apr 9, 2013
Great explanation..
[Kasun Chaturanga Gajamange] - Apr 9, 2013
A great , short and a simple answer. Thanks for this summarized article.. :)
Lasantha Bandara - Apr 9, 2013
Great! this is an answer that I was seeking for. Thank you very much for addressing it from developers point of view. I’m impressed with these ideas, while adapting to your process. * Spend time to practice technologies so you can choose good options with confidence * Choose an appropriate deployment model at the beginning * Reduce the cost of changing decisions on frameworks and technologies