From their offices in Denver, CO, Guild Education partners with companies nationwide to expand the educational opportunities offered as part of their benefits package. Working with nonprofit universities that specialize in supporting working adults, Guild offers classes, programs, and degrees intended to help employees grow in their career.
We spoke with Jessica Rusin and Madeline Ford from the Engineering team, and Michael Madura from the Salesforce team, about the challenges of rapid growth and how an agile mindset has helped mitigate them.
Michael Madura: What we do is kind of a new concept: “Education as a Benefit.” We’ve built this platform that enables employers to offer continuing education and align business goals, like talent development and retention, with affordable education programs that employees love. We have a network of nonprofit universities and learning providers that create this consortium of classes, programs, and college degrees.
Michael: Yeah, absolutely. Even in the era of bootcamps and Massive Open Online Courses, we believe that a college degree still matters. At the same time, we understand that working adults can’t drop everything and head back to school—nor can they trade on-the-job training for traditional college courses. So at Guild, we work with our university partners to articulate employee training for college credit. Even our Guild courses, like management bootcamp, allow students to earn college credit while gaining valuable skills that they can implement immediately at work. We’ve created a pretty cool pathway to a college degree.
Michael: If you picture an engineering department with a design team, a product team, and a development team…you can think of it as a giant roundtable. We have team members coming up with product, team members keeping all of our development and online needs in order. We have a team working on just Salesforce—that’s my team. We’re growing exponentially.
But from the start, the things that have been coming up are: how fast do we need to ramp up our business? What velocity do we need to hit the targets that we need to hit?
Obviously we’re a start-up, so we’re still in that phase of ramp-up, but looking at our trajectory and how fast we’re moving, it’s pretty slick to watch. If we didn’t have a product like Tracker, we wouldn’t have it. We’d need more staff, we’d need 10 different PMs, you know, all kinds of stuff. That’s kind of it in a nutshell.
Michael: When Jess was hired, and we went all in with Tracker, the velocity increased tremendously. The entire team started using the Agile framework, running sprints and things like that. The things that we’ve been able to build in six months are incredible.
Jessica Rusin: We started out with a really small team. There were just two technical people in April; now, our team is close to 10. We had a lot of growth. When we first started out, we were using Trello, which when you just have a couple developers on the team works out OK. As the team grew, we grew into different areas. We have Salesforce developers and Ruby developers, and we have data and BI folks and designers on our team. We had different areas that we needed to track with different projects. We wanted to use agile for all areas of the product and development side of this company.
If people forgot to move things into a particular Trello lane, it would just sit there and get lost. It became pretty apparent that we needed to pick a better tool for the process. I had used Pivotal Tracker in the past, but I didn’t want to influence my team and tell them they had to use it. So I kicked off an initiative with Madeline and some other folks on the team who looked at the other tools out there. They made a matrix of all the different tools between Trello, JIRA, Asana, and Pivotal Tracker.
We looked at all those tools and Tracker really checked a lot of the boxes for us, which I was happy about. Then I divulged to them, “Well, actually that was my favorite one. I was kind of hoping you would pick that one.”
So we instituted Tracker. One of the troublesome areas in Trello was that we weren’t able to see sprint by sprint what our burndown was, how many stories were finished, how quickly things were getting accepted, and things like that.
That’s all really important to the process, moving and streamlining it as we scale. That was one of the immediate benefits I saw when we moved to Pivotal Tracker. I am now able to say, “Hey, here’s how many points we did and we have a problem with acceptance. We’re accepting way late in the sprint. We need to get to a better place where acceptance is happening throughout the sprint so we’re not bottlenecked at the end of the sprint.” Things like that. We could actually see that visually, whereas we couldn’t before.
“When we went all in with Tracker, the velocity increased tremendously. The entire team started using the Agile framework, running sprints and things like that. The things that we’ve been able to build in six months are incredible.”
Madeline Ford: We’d just manually count up points every time to figure it out.
Jessica: Yeah. There was some manual counting going on. There are some plugins, but they weren’t useful.
Madeline: Plus, it was cluttered.
Jessica: It was pretty cluttered. Once we moved to Tracker, we could actually see what our progress looked like sprint after sprint, how we could build a more sustainable cycle. We’re seeing one sprint where we do a bunch of points and then the next sprint we wouldn’t do that many. We wanted to try to even that out. The only way to do that was to be able to prove to the business that this is how things were running.
I can take these reports to my leadership team and say, “Here’s our velocity. Our velocity went up these weeks, which is in line with what we’re doing as a business.” It provides a lot more visibility into what the development team is doing. Prior to that, people just had no clue. They saw this big Trello board and were like, “Oh, I guess you’re doing a bunch of stuff.”
Jessica: We were using a handful of agile practices. It was interesting because we were a six-person startup in April. The founders and the technical people and everybody were just getting stuff done. We had our daily stand-ups and retrospectives and planning sessions. What happened, though, was that our team grew too big and not everyone across the company would participate. We actually split out and made our stand-ups a little more formalized. Our planning and prioritization works now just with pointing, whereas prior to that it was all based on hours. We moved to a pointing system that is better for development in general.
Jessica: Yeah. I think it was tough on the business leaders who were expecting to know exactly when something was going to get done from an hours perspective to know that we were now pointing things based on both time and complexity. It was a bit of a transition, though not so much for the developers because I think they got it.
I think it was tougher for the business side to understand if you don’t know if it’s going to be four or eight hours, or it’s going to be done on Friday instead of Thursday. But that’s kind of the point—we aren’t tracking day by day anymore; we’re tracking sprint by sprint. We’re committing to things based on our sprint, not necessarily based on the hours or the exact day.
Although we have some things that are time sensitive, like if we have a client request or something that has to get out the door. I think they’ve gotten used to the idea that these are the points that are pulled into this sprint and usually we end up getting through most of those points. They’ve also gotten used to the idea that there are tradeoffs when things come in to a sprint. They can actually see the tradeoffs more visibly now, too, which I think helped a little bit.
“Once we moved to Tracker, we could actually see what our progress looked like sprint after sprint, how we could build a more sustainable cycle.”
Madeline: I guess there’s sort of two parts. One was getting up and running on Tracker, and the second is using it once it’s up and running. I think using it has been pretty smooth. There are a few different things in our workflow, just in terms of how we were pointing and what the actual flow was from Start to Finish to Deliver, and what all those meant because it was new terminology for a lot of the folks on our team. I feel like once it was up and running, it has run pretty smoothly.
Getting everything ported over from Trello was a little bit complicated, but for the most part our team was sort of OK with leaving stuff behind in Trello, some of the bigger things that have been hanging out there for a while. We just exported all of the parts that were in Trello, matched up the information that we could, imported it into Tracker, and then made some manual changes. Those pain points only lasted for a sprint or two as we were still referencing Tracker and Trello for a few weeks. Now that we’ve been in it for a while, it’s been pretty smooth.
Jessica: I think the organization and what status stories are in is key. It was really tough in Trello to see if the story was ready for code review. Had it been accepted? Those little things were all being tracked by just labels. They didn’t have actual statuses. In Tracker, having the status with the color-coded buttons is the visual indicator that something’s been delivered versus something that’s still in progress.
Madeline: It’s good to keep you on track during the sprint so you can see at a glance, “Oh, most of the cards are in Accept/Reject at this point, or we still have a lot of things at Start.” Being able to get that brief snapshot at the beginning of every day is really good for keeping a barometer on where we are in the sprint.
Jessica: Yes, it’s much more accurate because they know what card they’re working on. They can go into the card and just update the status. Whereas before it was all tags or you had to actually go find the lane. Sometimes the lane would be three lanes down, across the page. They couldn’t drag it. It got randomly dropped into another lane, and you couldn’t find it.
Jessica: A little bit. I think it really helps with planning. We use more of a Scrum model and when we’re on that planning day and predicting what the trade-offs are and what could we pull in, knowing our previous velocity and being pretty solid on that allows us to more easily say, “Yeah, this stuff is going to get in this sprint,” versus, “No, it’s probably not going to get in until the next sprint.” Being able to talk about it as a business or with product to say, “Hey, here’s what you’re trading off: this five-point story versus these two- or three-point ones, or we could hit these one-pointers off really easily versus these larger ones right now.” It’s really given us the ability to be able to plan better.
Madeline: For me, the gamification comes in less when looking at the velocity at different points throughout the sprint and more when it comes to moving things through the workflow. It’s very satisfying when something’s at Accept/Reject and it’s off of your plate and things turn green. I think that has definitely been a good motivation for people to actually get stuff into the right state and then bug the necessary people to move it along.
Jessica: I would really highly recommend it for a lot of development managers mainly because I’ve used a lot of tools like Rally and JIRA. Those are great tools, but they’re large and complex. What I like about Tracker is that it’s kind of an in-between tool that’s pretty simple to use, but which has enough tracking and reporting to really make it useful. I recommend it for other managers who want to keep things fairly simple, but who also want to have some level of accountability with their teams and make sure that things are getting done on time and moving through the workflow as they should be.
Madeline: For me, on a more micro level in terms of advice, I would say to make sure every team member is crystal clear on what each part of the workflow means. We have so many different projects and so many different people that see the data—Salesforce, design, etc. The Start > Finish > Deliver > Accept/Reject workflow was a little bit wishy-washy at first. It wasn’t totally clear when I should click this button versus when I should click that button. It took a little bit to get clear on what the workflow meant for each team. Really defining that upfront I think would be really useful.
Jessica: Yeah. One other thing is I encourage people to use the GitHub integration because there are a lot of times when you have to reference code changes from months prior. It’s so much easier to search Tracker than to go into GitHub and try to look through your stuff. If you have the integration, you can search the story and then link right into the code change, which is pretty neat.
There are many different variables that make up software teams, but no matter the size or industry, we share a lot of the same challenges. And while Tracker is only a small part of the equation, we’ve begun collecting these stories with the hope that we can all learn from them. See the other case studies here. Want to share your story with us? Get in touch.
Tags: Case Studies