Like every start-up the engineering at Sokrati has evolved over the years. Many inclusions are ideas within and ideas adapted through monitoring others'. No process definition can be complete & straight-forward. Life at Sokrati started just like any other start-up: bootstrapping, being scrappy, ensuring survival while delivering quality, followed by growth and now we are a midst growth and expansion.
By the close of 2011, we realized the importance of re-hauling the current adhoc process in engineering. Why is it that we are constantly fixing code or constantly playing a catch-up with scale or are constantly involved with addressing client issues? We were managing over a million transactions per day and couldn't sustain any down-time. Software that used to run on one mighty server now is housed upon 126 commodity servers and the count is only growing. Our Systems Engineering team comprising of 2 manages 63 servers per person! And yes the system never sleeps! As a matter of fact if you are responsible for managing the advertising budget of prominent Internet players, it cannot sleep.
Now Sokrati has hit a very fast paced symbiotic eco-system. We now deliver high-quality software, with super high-quality support & maintenance along with feature roll-outs that happen every 2 weeks and yet keeping our cost on a minimal. Here is an attempt in detailing how the entire engineering unit works towards pursuing and achieving quality. If you are thinking of adopting a unique process or gathering upon ideas I hope this would be of help.
The product planning happens 2 months before the development team is involved. During the product planning the Product Manager plays a crucial role in gathering the requirements for the features to come and works with UX in crystallizing rough mockups and pencil sketches. The fully functional mockups generated by UX is then run by the clients, business owners & dev leads to achieve a common ground. These features are lined up to be delivered to the clients over the course of next 3 months. The features are enumerated in the form of user-stories and with the help of the dev team, the Product Manager details stories that should be delivered in 2 week stints.
We follow the agile model @ Sokrati and hence a week before the sprints for the 3 month development effort start the sprint planning takes place. The sprints are 2 weeks long with a goal to deliver the feature at the end of the sprint, fully tested & deployed to production. The sprint planning week is owned by the lead of the dev team. He/she takes care of doing the necessary research work and laying out the tech spec minimizing unknowns so as to adhere to the commitments. Once the sprint starts every effort is made to not bring any requirements or change any existing ones unless it is business critical.
The team comprises of atleast 3 members whose roles are pretty much diverse and ever changing true to our culture. There needs to be atleast 1 developer, 1 QA & 1 Operational Rotation. At the start of a new cycle since there is no operational rotation the sprint starts with 2 Devs and 1 QA. The devs plan the implementation while the QA plans breaking the code. The QA is a rotational as well who is also a developer. But in this role he plays the devil's advocate. Once the sprint ends the QA who has signed off the release goes on to becoming the operational hand-off for the next 2 weeks. Where he/she trains the operations team to manage the feature being rolled out. He/she also ensures complete documentation to facilitate support and bug fixing that arises. The sprint is planned such that the devs have enough time to fix the bugs being pointed by the QA. All efforts are taken to roll atleast 1 feature every 2 weeks!
A week before the end of current sprint starts the sprint planning for next sprint. Here again the dev lead is involved in articulating the deliverables for the next release. By the close of sprint planning, since active QA current sprint is happening, the lead also gets to know about the bugs that arose in the current sprint. If it is blocking the release of the feature the lead may choose to prioritize the bug in the next sprint cutting down upon a feature. These become feedback notes to the dev and the dev-lead as well, to fix any loop-holes in their tech spec or development effort. The next sprint now starts with a new QA rotational and a possible new developer.
This iteration happens over the next 3 months. By the close of the third month the new features and requirements are formulated by the PM for the ensuing 3 months. As one can see the development effort is very fast paced. Due to this there may be certain compromises in quality of code or good to have design patterns. After the 3 months of development effort the team takes a 1 month cool-off period where the goal is to retrospect and fix the past. This is also a buffer period to plan for contingencies and to freshen up as the next 3 months are going to start pretty soon! In this period we also aim at shrinking the code by 30%. Thus addressing any design compromises that had taken place. Yes we delete code in this phase.
Hope it helps. This system works best if the development teams are small and have all the required skill-sets to minimize external dependencies. If your team needs to roll-out UI features I am sure it would include doing some back-end work as well. In such a case don't create 2 teams, instead have one team (albeit small) of the required skills to ensure delivery of the entire feature.
In my next blog I will go over the various roles and various team structures to demonstrate case-studies. If you would like me to substantiate on anything please let me know.
No comments:
Post a Comment