(Guest blogger and Rally user Erine Gray is the founder of Aunt Bertha, a software platform that makes it easy for people to find and apply for food, health, housing and education programs in the U.S.)
This is the story of how Aunt Bertha used Rally to get our team organized, communicate better, and start loving each other again. It was kind of like group therapy.
I’m only sort of joking. Our team doubled in size this year and there are now more people writing code. There’s more knowledge to be transferred. There’s more testing that needs to be done. There’s more that can go wrong. And things did go wrong; like any relationship, communication is key.
We had a new customer, Critical Mass, who wanted its users to be able to know if they qualified for a local cancer program using rules common in the cancer program space: current age, age at diagnosis, type of cancer, and current stage of cancer. We’ve always had ways of determining whether someone qualified for a program based on their income, but we didn’t have an easy way to extend this qualification to other eligibility rules, like these.
Ideally, a cancer survivor should be able to see—with the click of a button—whether or not they qualify for a cancer program, and why. They should be able to see something like this:
Since Aunt Bertha’s mission is to make program information accessible, we were excited to build this feature into our product. However, we had a problem.
Teamwork and Knowledge Transfer
When we first started using Rally at Aunt Bertha, we had two new programmers on the team. I was the lead developer, and I was terrible at knowledge transfer. Release after release would go by and features were not delivered on time. And it was my fault.
I had no doubt in my mind this feature should be built, and I knew how I was going to do it. I had a vision of what it was supposed to look like and a rough idea of how the algorithm would work, since I’d written most of the search code over the last three years.
The trouble was that building this feature was going to be a significant amount of work, and I didn’t have time to build it. Programmers are typically optimistic about how long it takes to do stuff, but we have short memories. It’s kind of like golf: we only remember those great drives that lay up perfectly on the fairway; we don’t remember the time we spent digging through the weeds to find our ball (or the late nights spent debugging only to find out we put a semicolon in the wrong place.)
Aunt Bertha was also in a growth phase. I didn’t need to be the lead programmer anymore. I had to delegate, but I was afraid because I knew that this feature would touch hundreds of lines of code that only I understood.
Around this time our product manager, Ruby, started implementing Rally for our software development process. Prior to Rally, we had used Github as a code repository and for issue tracking. It was a nice, lightweight way of keeping track of issues and milestones, but now we had more developers and staying organized was a real challenge. We needed more rigor and structure.
I didn’t know much about agile software development. Ruby implemented a bi-weekly sprint planning meeting, and gave us all homework. Our job was to look at all of our stories, and break them down into digestible tasks.
I took the Critical Mass eligibility rule story and began to break it down. In the past I would typically jump into a feature, only to discover later just how complex it was. Breaking down a feature into stories and tasks really forced me to think about the problem in small chunks. That was when the light bulb went off in my head: I could indeed delegate some of these tasks to our new developers. I didn’t have to be the one to do it all; I just had to coach them along.
I’m happy to report we built a pretty amazing feature that’s making it easier for cancer survivors to navigate the myriad programs out there. Our developers can now dig into the most complex code, and I can now concentrate on getting new customers and setting the longer-term vision for the product.
Rally helped us communicate better, and set deadlines that we could actually make. Rally helped us understand that big problems are nothing but a series of small problems.
Making It Fun
One of my favorite views in Rally is the Story Estimation screen.
After we’ve developed our stories and added the requisite tasks, our next step is to estimate about how long a story (or feature) will take to build. This screen allows you to easily drop in a story by the estimated size. We size ours based on the size of our dogs (we’re a dog friendly office.)
A small story is a “Cinco.” A “Rosie” (that’s my dog) is a medium-sized story. A “Beowolf” (Chris’ dog) is a big story.
Cinco, Rosie, and Beowolf represent small, medium, and large story sizes
It may seem silly to estimate your workload this way, but the truth is that sizing is relative. What matters is how many Beowolfs, Rosies, or Cincos you can accomplish in a two-week sprint.
Why We Chose Rally
We considered plenty of options: we could have just stayed with Github, and we looked at Rally competitors. But we ended up going with Rally for a couple of reasons. One reason was that Rally offers its products at a discount for fellow B Corporations (Aunt Bertha has been a B Corporation since 2011.) The primary reason, however, was an encounter I had with Rally’s founder, Ryan Martens.
Ryan was a mentor at Boulder’s Unreasonable Institute, and when Aunt Bertha went through the 2012 Unreasonable Institute in Boulder, I had a chance to interact with Ryan. During that summer the team would spend most evenings with mentors: getting our questions answered, hearing about their experiences, or just sharing stories. I distinctly remember one of Ryan’s comments on business and ethics: the passion of his delivery and his desire for our success made me a fan immediately. Simply put, he seemed like a guy I wanted to be like, someday. And Rally is a company we want to be like someday.