How to Start an Agile Project
How do you start an agile project and ensure room for future enhancements? How can we achieve flexibility 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.
As Sabri Sawaad said during in the panal: You must make decisions, but consider the cost of changing them.
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 familar 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
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)