Tag: appster

Agile

Are You There?

Are You There

At Appster, we practice Scrum as our software development methodology. The upside of this incremental and iterative philosophy is that we can deliver working software very frequently (every week) and yet be open to change during the course of the project. The downside is that it requires active involvement of the client. Clients who could sit back and relax after the heavy exercise of requirements gathering during Waterfall days find this challenging and, sometime, even revolting.

The team requires client presence (physical or over video conference) during Sprint Planning Meetings. This is the time when the team needs clarity from the client on the high priority user stories that can be picked from the top of the backlog as Sprint Backlog. The team might require client involvement during the course of the Sprint when it is faced with a priority decision (which stories to complete in the remaining time available) or maybe some clarification on an existing story or maybe a decision on the multiple options possible for implementation of a story. And finally the team requires the client to do User Acceptance Testing (UAT) of the build that the team generates at the end of the Sprint. This part is of key importance. UAT actually generates feedback for the team on how did it deliver against the requirements of the client. Even if it was spot on, the client might get “aha” moments during the UAT and might suggest changes (which are welcome in Agile) that would go on to improve the product.

While clients are available during Sprint Planning (actively or passively through a PO), it is hard to get them to do a thorough UAT. Maybe because they also have a day job or maybe because they are busy in other aspects of their business as an entrepreneur. Whatever the reason be, the lack of timely UAT hurts the project and demoralises the team. The team feels sad when it don’t get timely feedback as it feels that it is working on something not important enough for the project sponsor. It feels orphaned. The project suffers because the team might go off-course for lack of a corrective action that the UAT could have spawned.

As a result of delayed / improper feedback, client feedback accumulates towards the end of the project. At this point, two opposing forces come into action – the client who is giving feedback (which might have lost relevance due to lost time) and wants all his points to be considered; and the team which is wanting to wrap up the project and is inclined to ignore those points that the client is suggesting. This force completely dries up the agility that was intended into the project. The client is welcome to add more to the project provided he takes out an equivalent amount of work from the plan or allows more time to the project. The above scenario keeps the deadline but tries to add more work which might be relevant (for example bugs in the application discovered by the client).

For a successful project release and happy stakeholders (development team and the client), it is imperative that the client does timely UAT and provide feedback that can be fed back into the product backlog and the product can be developed with a sharp focus on the market. The team should not have the chance to ask the client, “Are you there?”.

Agile

Agility @ Appster

Appster Logo

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.