Go to the profile of brighterlink.io
brighterlink.io
R&D group for brighterlink.io, part of Brightergy, a KC based energy startup. Our tech pub is here https://medium.com/brightergy-engineering

Sprint 3 finished, on to the home stretch

We are slightly delinquent on this post as we ended our Sprint 3 on Monday (4/25/16). However, we’ve been busy hooking everything up. As mentioned in our Sprint 2 retro, we’re starting to put the pieces together and every week that goes by, we’re more and more production ready, which in turn means we need a bit of process. There’s a misconception that if we’re “fly by the seat of the pants” type of agile team, we can’t have process, but that couldn’t be further from the truth. We need to put the rules in place to make sure we’re doing it fast and doing it right. This is the true test of a well functioning agile team. Anyways, on to our Sprint 3 accomplishments :

  • Completed UI -> Backend <- Device authentication using JWT/Auth0
  • Settled on an authorization strategy (using the JWT JSON Payload)
  • Built Authentication into our Websockets
  • Built out Intercom.io integration, so we can receive chats and emails from customers
  • Rebuilt our backend digi to use websockets and authenticate properly
  • Merged our various frontend code into a single one, settling on ReactJS
  • Automation to configure hundreds of Schneider thermostats
  • Parser to read existing product (Brighterlink 1.0) usage information
  • Starting to incorporate “Design thinking” via customer personas

We didn’t quite get all the items we wanted done on our milestone list, with the part being UI communications with the devices. But that’s ok, the idea of the milestone was to be a guide post, and we got pretty close. It’s important to celebrate those victories as the team accomplished a lot. But as always, we found places to improve and our retro yielded these nuggets:

When to use Trello vs GitHub Issues

We’ve been using Trello exclusively for our todos, but really wanted to integrate GitHub issues into the mix. The question became, when do we use one over the other? We came to the conclusion that we’d use the Trello board to have an overview of the Sprint, and be able to group high level things, but tasks, refactors and the “stories” for the cards would be tracked in GitHub. We haven’t hooked up GitHub -> Trello, but for now its been working. We also said that each PR should have a GitHub issue # associated with it, whereas Trello cards could cross repos and issues. GitHub also has the concepts of Labels and Milestones, so we’re using that to track things like “bug, enhancement, devops, refactor” etc.

Too many Lists, Todos

We started building up a lot of Lists, and having to clean them up every Sprint became a pain. On top of that, we were also building up too many “Todos” for a sprint. So, we ditched the concept of a “board per Sprint” and just had a single “Main Board”. Then, we’d just have sprint specific completed/milestone/retro lists, that we can send to our Completed board after each sprint. We also consolidated a few of our lists and created Backlog list, that had a few sprints worth of stuff, and then had a single “This Sprint” list to mark things we wanted to do or were in progress. This, combined with the GitHub issues usage has significantly cleaned up our board.

Tools Overload

We’ve started accumulating a bunch of tools that do specific things from our user management, to log aggregation, to exception handling, to customer interaction and more. On one hand, we are able to really get “best of breed” SaaS products that do specific things really well, but on the other hand, there’s a bit of management overhead associated with it. What we really need is a single “Operations Dashboard” that can aggregate the information into one place, and tell us “what’s the state” of the service, and then we can drill down to get the details. This also allows us to build metrics that we care about, and find ways to pull them together. Tools like Geckoboard would help us create these dashboards, and make it much easier to see a high level overview. We found that we needed this for our business metrics as well, so being able to see how many customers were using specific applications, and the size of the customers and data consumption would be important.

Final Thoughts

A lot of this is overwhelming, and can seem like the things just keep on piling up, so keeping a level head and making sure we’re really taking things a day at a time, and not trying to solve for too much will help us keep sane. We’re really hoping to have internal user and customer feedback on our next Sprint, and then the real fun begins. We see this as all an “audition” to the show, as the fun really starts when we start getting customer usage and a really good dev -> customer cycle going. This is why we are continuing to hone in our development process, and make sure we can maintain stability even while we’re doing a continuous delivery model.