Agile Zone is brought to you in partnership with:

Programmer, solution architect, user group and conference organizer, conference speaker and traveling fun code evangelist. Johannes tries to apply Agile principles to large software projects, but what he's really passionate about is sharing the experience of more fun programming with other coders around the world. Johannes is a DZone MVB and is not an employee of DZone and has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

How to Start an Agile Project

04.08.2013
| 2601 views |
  • submit to reddit
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 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.

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 panal: 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 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:

  1. Spend time to practice technologies so you can choose good options with confidence
  2. Help the customer choose an appropriate deployment model based on the user needs and developer skills (including your own)
  3. Put something in front of the customer quickly by using your existing skills
  4. Invest to reduce the cost of changing decisions on frameworks and technologies
  5. Change course if you find a better technology or even deployment model
Published at DZone with permission of Johannes Brodwall, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)