As on today, I am working with Appster as an Agile Coach and Senior Project Manager. Here’s what I have to say about the process we are following at Appster.
In order to build a great product, you need to have a greater process. A process that is simple yet flexible. A process that lays emphasis on quality yet allows change as you go. Agile emerged as an answer to this need. It is a software development framework suited to humans – people cannot predict the future accurately and would like changes to be accommodated in their plans; humans can focus only one or two items at the same time and not the whole gamut. A quick look at the Agile Manifesto assures one to the flexibility inherent in an Agile development environment.
At Appster, we are trying to imbibe the spirit of Agile in its purest form. It all begins with the signing of an Agile contract with the client. The client is not bound into an iron-clad contract (reminiscent of the Waterfall model of software development) but allowed to make changes to it as long as the primary constraint (scope / time / cost) is unaffected.
The client’s requirements are captured not in an exhaustive document covering reams of paper but into high level User Stories (called as Epics). Epics allow the client to express the desired functionality easily while leaving enough room for change / discussions.
Then the dev team breaks down these epics into smaller User Stories that are the right size for development and planning. The entire development is broken down into two-week long iterations called Sprints. At the beginning of each Sprint, the highest priority User Stories are discussed in detail and planned to be completed during that Sprint. The design, development, and testing for each User Story is encompassed within the Sprint only. This is in sharp contrast to Waterfall development wherein each of these was a phase in itself. At the end of the Sprint, the client is presented with working software in the form of a build. While the client does User Acceptance Testing of the build, the team retrospects about how it performed in the last Sprint and what improvements it can include in future Sprints.
During the development, the client is welcome to change any requirement for which work hasn’t started already. The client is free to make changes inline with the scope / timeline agreed upon. The team approaches client interaction with a mindset of collaboration rather than contract negotiation. Even changes that are beyond the contract are acceptable if both the parties are willing.
The above process allows the dev team to deliver working software frequently and in increments. It allows the client to be deeply involved with the development process and see his app take shape and grow like a tree. It also allows (and even welcomes) changes to the application that make it relevant to the current situation of the market and competition.