What is your workflow? (Startups | Engineering)
by Aarjav Trivedi
We recently re-engineered our workflow as a team, to fix some problems. Here’s the email I sent out about it that says pretty much everything. We are still new to agile-ish planning, so I am sure we could do some things better. Please leave a comment with your suggestions if you would!
What is your workflow? Why?
NB: Credit for all good things in this post (and our process) to the rest of the RideCell team (Arun, Ram, Derek, Kartik, Darren, JJ, Bhumi and Venkat) and to to my friend Sujoy Gupta who leads the awesome engineering team at www.topprospect.com. Blame for all the mistakes almost certainly rests with me!
Aarjav Trivedi
[Going out to everyone at RideCell]
Riders,
As we discussed today in office, we have redesigned our approach to defining, prioritizing, measuring and shipping what we do at RideCell. These are major changes, so please read this email carefully.
Our core measurable goals as a company are:
1) Increase customers: Sell to new Fleets: Universities, Public Transit and Private
2) Increase users and usage: Users are riders, dispatchers, drivers and managers. Recruit new users at existing customers via word of mouth, training, marketing, network effects. Get more of them to be active. Increase happiness of active users.
3) Increase performance: Performance is customer performance, internal technology performance, and internal human performance. Customer performance is core metrics customers care about such as automation %, average time, no shows, cancels, etc. Technology performance is increased by reducing exceptions, optimizing code for quality and speed, getting more performance out of fewer resources. Human performance is optimized by better tools, better co-ordination, helping each other and working together more effectively.
Our trac workflow made it harder to achieve the above goals because, with it:
1) Company goals are not linked to daily tasks: Individual tickets are not linked to any of the above goals directly. They are linked to features and releases that we hope will affect the above in positive way, but that we cannot measure. I think that as a developer you should know exactly how the ticket you are working on will help the company, and if you feel that it is based on a faulty assumption, you should be able to challenge it.
2) Progress cannot be measured for an individual or for us as a group: Because our task estimation happens “offline” and is an arbitrary guess made by the “owner” of the ticket with his inherent bias. There is no “feedback loop” other than one off comments. We seem work in fits and starts and are driven by project deadlines.
3) Ticket assignment creates lack of shared ownership and wastes time: We spend 2-3 hours each week assigning tickets to everyone while everyone else is present. Most people are bored when we discuss other people’s tickets because when the week rolls by they are going to look only at their own tickets for 5 days. This also creates silos that discourages people from getting broader knowledge.
4) There is no forum to regularly discuss items that are causing people to be happy (good news), unhappy (bad news) or confused.
5) There are no predictable schedules for anyone causing whatever general organization system we build to breakdown from time to time.
We are going to incorporate the following changes to address this:
(1) Groups that own metrics: We form 3 groups in the company, each responsible for the 3 goals listed at the top. Above all, their performance will be rated on how effectively we achieve those goals.
Group membership will be based on expertise and job profile (JJ and I, as sales guys, will be part of “Increase Customers” group by default) and/or interest (Ram will be part of increase sales group if he has an express interest in it).
(2) Use of a Pivotal as a Master task list. You have been sent an invite to pivotal, please sign up and log in. Here is our pivotal workflow:
It is explained in more detail below:
For each iteration of 1 week, each group meets and identifies the most important/urgent things they think need to be done to meet their goal that week. They will add these new stories to an “IceBox” list which is a master list of all tasks that need to be done for that goal. They will then prioritize the icebox. The group will take a vote on how many hours each task should take and mark it based on the majority opinion. Only people who have some knowledge of the task should vote. Majority wins. This will help us recalibrate ourselves. No story should be a task that would take longer than 4 hours. 6/8 hour tasks are allowed but discouraged.
Once the groups have sorted their goals, for each iteration, I will take the IceBox list for each group, and, with help from someone in the group if needed, put some of the tasks from the icebox into a “Backlog” which is a Universal prioritized task list for that iteration shared by the whole team across groups. Backlog will contain tickets worth X + n points where X is the expected velocity of our team based on past performance and n is the number of team members. This means that if we got 40 points worth of work done last week as a team, we will have 46 points of work assigned this week, adding 1 point per customer. We will naturally identify our plateau and stabilize there.
Each day, each developer will finish his story at hand and pick a story from the top of the “Backlog” list. So, no “assigning” of tickets, people take ownership themselves and also know what others will be working on that day.
Completed stories will be marked by developer as “finished” and assigned for review to one or more reviewers when they commit their code and use “[fixes #12345] to reviewer1,reviewer2″ in the commit message. One of the reviewers will review the code and mark it as submitted in reviewboard and as delivered in Pivotal if it looks good. If not, they will mark it as rejected and the developer will have to restart the ticket.
Weekly testers will take delivered tickets and mark them as “accepted” or “rejected” based on whether the y test ok. Tickets rejected by testers will have to be restarted
If bugs are filed during the week, Critical (core functionality not working or crash type) bugs will be put on top of Backlog queue. All other bugs, when urgent will go to back of Backlog queue. If not urgent, they will go to the Icebox in the appropriate group, usually “Increase performance”
(3) We will have the following short meetings to create our “Feedback loop” and continuously improve as a company:
a) IceBox filling: Groups meet separately to add new stories to their icebox, prioritize stories in their icebox based on importance and urgency and assign points to stories
Aarjav will move stuff from IceBox -> Backlog: Usually Aarjav only + Group expert (if required) move things to Backlog and prioritize them across groups
b) Retrospective -> End of week meeting to discuss our stats associated with each group including velocity that week. Also discuss things we love, hate and are confused about as a company. [ the ":) :$ 
" meeting ]
c) Standup emails and meeting: By 10.30 a.m. everyday, everyone should send out a scrum email letting everyone know what they plan to work on that day based on the top backlog tickets, and any critical items they want others to know about. A’s email will include a list of part time people who are not working that day. At 11:00 am A, D and whoever else is working that day will do a quick 15 minute standup meeting to discuss scrum emails.
We will practice this work flow on Monday and all this week. Please please email me or talk to me, R or A in person if you have questions or doubts or concerns.
Sincerely,
Aarjav
