Agile Development

As you have read by now, the usual process of software development involves making detailed plans about whats going to be built and when. And once the ground work to develop the system is done, we’ll be ready to start developing more advanced features.

The specifications gives us a list of things to do and we proceed to complete them in the order of implementation or urgency mentioned by the client.

But Plans Change..

and surely for the better. This only means that you are thinking about the app and trying to make it better.  You may have realized a feature developed and published faster is in your interest or your client has given a new requirement superseding current work in priority. The development schedule must allow changes and be ready to adapt to it. –  Agile Development.

Plan to be flexible

Agile Development is about being able to adapt to changing plans and focusing on delivering a working application in the least amount of time. This still needs us to have specifications and development requirements as with anything else. What changes is how my team and  I go about building what’s been selected to be delivered by the end of this milestone. That’s right you get to choose what goes in to the current milestone if you wish to.

Start with tiny steps. Plan, build and test tiny steps. This yields a bug free, ship ready working application in the shortest time. The improvements are also in tiny steps.

Having an adaptive development process should make you stay competitive and respond to changes to the product variables. Be it early release, prioritize, budget cuts etc.

Know you is know how

Know Your Business

Can’t build a ship without knowing the ocean.

If its a niche application or an enterprise application, it helps a lot to know the native working environment of the application. i.e the domain and the work the app is going to be used in. Helps to know about other similar apps as well.

If it’s an in-house or an intranet application, we’d want to know how your work. By that I mean your typical and atypical operations and corner cases. We especially want to know the workings of a typical organisation going to use the app and the problems you currently face that may have potentially led you to this idea. The problem we want to eliminate.

Typical use cases and environment the app is used in is what we are after.

This is a way to do justice to your idea. The result of this exercise makes the application that’s more tailored and make sense to that user.