Customer Story: Guild Education

Guild Education is helping companies provide education as a benefit for their employees.

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.

Guild team photo

Thank you for talking with us. How would you describe Guild?

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.

Excellent. Is there a type of education that they’re hoping to provide their community?

Michael Madura: 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.

What are the major hurdles you’re facing, as far as growth and other challenges?

Michael Madura: 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 startup, 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.

“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.”

What changed when Jessica joined the team?

Michael Madura: 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.

Sign at the Guild office

Madeline Ford: We’d just manually count up points every time to figure it out.

Jessica Rusin: Yeah. There was some manual counting going on. There are some plugins, but they weren’t useful.

Madeline Ford: Plus, it was cluttered.

Jessica Rusin: 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.”

How agile was the team before you came on board?

Jessica Rusin: 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.

Was it difficult to move to a pointing system based on complexity instead of hours?

Jessica Rusin: 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.”

How easy or difficult was it to adopt Tracker?

Madeline Ford: 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.

Oh, that’s good to hear. What would you say Tracker does best for your team these days?

Jessica Rusin: 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 Ford: 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.

Guild team working

You also mentioned, Jessica, that sometimes people would forget to update their Trello card. Tracker does have a workflow. Do you find that people are more on top of it then? That the data you get may be more accurate now?

Jessica Rusin: 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.

There’s a certain element of gamification where you’re trying to hit your velocity number or monitor your volatility. Does that play a part in the team being more “on it”—for a lack of a better word—as far as being involved with Tracker?

Jessica Rusin: 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 Ford: 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.

What advice would you give to someone like yourself who is new to Tracker?

Jessica Rusin: 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 Ford: 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 Rusin: 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.