MVP or Minimum Viable Product
Minimum Viable Product or MVP is a strategy used for fast and quantitative market testing of a product or product feature, popularized by Eric Ries.
Minimum Viable Product allows a business to get into the market as rapidly as possible and maximize the value of the finite finances. We build just enough of the core of a product that will allow users to garner feedback – and possibly earn some revenue.
This is one of the very basic rules of Agile to keep features from drifting out of control and also gives quick feedback on the new features being developed. We usually do one-‐week sprints (development cycle). Larger features are broken down into one-‐week long pieces thereby increasing focus and minimizing risks.
Kanban is a concept related to lean software development methodology. It is no longer an inventory control system. Rather, it is a scheduling system that tells you what to produce, when to produce it, and how much to produce. In Agile software development, it has become a common practice to visualize and share project status by posting cards on a wall of the project room. Kanban can be described as a typical notice board. On the board, engineering tasks are represented by cards (Post-It Notes), and the statuses are indicated by posting them to separate areas on the board labeled “ToDo”, “Doing”, and “Done”. Such Kanban Boards helps visually signal tasks and limit WIP (Work In Progress). For each iteration, tasks are newly identified by breaking down user stories into tasks and these tasks that are posted onto the ToDo area.
Test driven development
“Test-driven development (TDD), is an evolutionary approach to software development which combines test- first development where you write a test before you write just enough production code to fulfill that test and refactoring”
Our engineering team writes the unit tests first for every feature we implement which fails at first and then we code the feature-‐in to pass the tests. The discipline of writing a failing test and then writing the feature code to make it pass ensures complete code-‐coverage and thereby creates a very reliable product.
Point-‐based system for story estimation
For story/requirement estimations, we use a simple point based system where the points are measured using relative complexity. We believe that our engineers are much better at understanding the complexity of a problem when they are estimating the time it takes in solving it.
“Velocity” of a project is the measure of the number of points a team can finish in a sprint and this becomes very predictable after the first two or three weeks of engagement. This gives our clients a very early indication as to how long a given set of features might take to build and also gives the visibility to make informed decisions on what features holds the highest priority.
Sprint planning and daily huddles with the team
“The Daily Huddle” is arguably one of the greatest productivity and efficiency booster off-shoring industry has ever experienced.
The Daily Huddle is a group meeting with every individual who is working on the project. Daily huddle is a chance for everyone to “check-in” with their plan for the day and it’s also an opportunity to point your team in the right direction and get a flavor for the day ahead. It is a chance to see who is prepared and who is not. Each team holds Daily Huddle meetings in Skype (group conversation) with their client where they answer 3 questions each day:
a. What have you done since last Daily Huddle/ scrum?
b. What will you do before the next Daily Huddle/ scrum?
c. What obstacles are impeding your work?
Huddle aims at giving answers to what has been done, what is to be done and what is blocking the team from completing their tasks. Team Leaders will post the Huddle updates in our Confluence project management system every day.
Retrospective meetings with engineering team
The retrospective meeting is a special meeting where the team gathers after completing an increment amount of work to inspect and adapt their methods and teamwork. In contrast to traditional post mortems or project reviews, retrospectives focus not only on the engineering process but also on the team and the issues faced by them.
During this meeting, we consider three things: what went well, what didn’t, and what improvements could be made in the next phase?