Since 2014, SenseGrow has been providing software that allows their customers to connect their products to the Internet of Things. We spoke with Co-Founder and CEO Atindra Chandel about productivity, shaping agile processes to work best for his team, and their evaluation matrix.
SenseGrow is an enterprise SaaS company committed to providing the best possible Internet of Things (IoT) products to our customers. Our product helps enterprises to build IoT solutions faster and get more value from their connected devices. Some of the leading enterprises use our products to build their IoT solutions.
Our product philosophy is, “Simple is beautiful and scalable.” The platform allows you to do rapid solution prototyping and piloting with ease. Once you have solved and demonstrated the technology puzzle, it becomes easy for managers to justify and predict business impact more definitively. Some of the leading companies today are using our products to build and launch smart, connected products or integrate their device data into their enterprise applications.
We’re an 18-person company with a seven-person development team. We also outsource some of the development work. Access to capital and hiring people who have the right startup mindset are the greatest challenges that we face. IoT is a relatively new field and the market is still shaping up, which puts a lot of iteration demand on the technology team as we develop new understanding about the market.
We’ve always believed in small agile teams that require minimal management overhead. We’ve been using agile since we started the product development in 2012, when the co-founders were the only members of the development team. The market was nascent and since we developed our IoT platform from the ground up, the product required continuous iterations based on initial customer and sales team feedback. Agile turned out to be a good choice and helped us in creating a product that has hundreds of paying customers.
Yes, we’ve made some deviations. For starters, we have a long-term overall product roadmap and we follow this plan. We rigorously evaluate feature requests that don’t fit in this plan against an evaluation matrix we have built. Secondly, we create and maintain documentation of some complex portion of the product. This is useful when new team members join the project. Lastly, we use time tracking for external developers that we hire. This helps us understand where they are spending their time. This helps us understand the time cost of the work outsourced.
The matrix involves scoring a story on a scale of 0–5 based on these aspects:
Usability (U)—Will this feature improve the ease of use of our product?
Scalability (S)—Will this help make the product more scalable?
Revenue (R)—Will this feature increase revenue from existing customers or by serving new customer segments?
Retention (RE)—Will this feature help us retain our current customers?
We then use an equation (0.3R+0.1S+0.3U+0.3RE) to come out with a weighted score for the story that helps us prioritize. We move stories that score higher up in the Icebox. We also take into account the effort required and the relative dependency of the story on other stories when picking up stories in a given sprint.
We use the Tracker point system to fix deadlines and product launches. The number of points assigned to a story depends on who’s working on it. The same story done by a relatively less-experienced developer might have 3 points, whereas it might just translate to 1 point for an experienced developer. The points equate to the amount of effort put in by the individual. This makes timeline predictions quite accurate.
From our historical records in Tracker, we have closely estimated the number of points a team member can deliver. We aggregate this individual score to come to the team score x. We target a minimum number of x points in a given release or sprint. We try to keep the release dates non-negotiable while keeping the number of points negotiable. This means if a release is due next week and we realize we will not be able to deliver a few stories, we move them to the next release cycle. We also keep a close watch on the velocity of the project.
Since we are a small team, productivity is important but managing it is easier compared to larger teams. We only monitor two parameters to assess productivity—the number of points delivered and variance from individual self-rated performance (i.e., points he or she can deliver in a 15-day release cycle).
If you are a product company and developing a product in a nascent industry from the ground up, agile is one of the best methodologies. But there are things you should keep close track of. For example, you should prioritize and select features based on an evaluation matrix and not just on the whims and fancies of individuals or customers. You should plan and select features so that the product moves on the overall product roadmap. It's important to break the product into epics. These epics are the key modules or value proposition of the product. Put every story in an epic by tagging it. After every few iterations, check on the Iteration report (which shows the work distribution across these epics) and ensure overall product development in all key areas. Lastly, keep the documentation to a minimum, but maintain documentation of key concepts or areas so that transitioning to new developers is easier.
Internally we have a very clear vision and five-year goals trajectory for what we hope to achieve, a larger vision of what we are working for. We’re growing methodically.
I personally started Tracker somewhere around 2009–10. I was impressed with the ease of using it and it became a natural choice when we founded SenseGrow. The experience has been good and it requires minimum administration. In all these years, we have spent hardly any time training people to use or administer the tool. Tracker is a great tool for startups that are still iterating to find the right product-market mix.
It’s easy to use and administer, which is a really a good thing for a small team. Tracker has a zero learning curve; it never throws complexity or over configuration at you. It defines a workflow for beginners, and then as you start improving your process, it allows you to change the process. We learned agile the Pivotal Tracker way and I think it was a good decision.
For a startup, agile is not just a methodology—it is their only competitive advantage against bigger rivals. It is important to manage productivity and have insights into the product launches. Tracker has helped us keep the team productive and agile without having to worry about setting up complex workflows. It keeps us on our product roadmap and helps us give customers more definite launch dates on certain feature releases.
Go through the quick start videos. Don’t be stuck with creating a perfect workflow on day one; start minimally and improve the workflow iteratively over time.
