Programming Throwdown - Agile Thinking With ZenHub

Episode Date: January 21, 2020

One of the most exciting but also overwhelming feelings in software engineering is starting a new project. Staring at an empty main.py file is intimidating for everyone. A great way to keep motivated and stay on course is to start by making a list of tasks. This is the first step to project management, and Agile is a set of methodologies for great project management. In this episode, we talk with Aaron Upright, cofounder of ZenHub, about Agile and project management. ZenHub is a quick and easy platform for Agile development that integrates seamlessly with GitHub. If this interview piques your interest and you are a GitHub user, grab a copy of ZenHub and check it out! In case you missed our last promotion with Educative, it's still possible to get 10% off if you sign up for one of their courses now! Try them out for free! educative.io/ProgrammingThrowdown Show notes: https://www.programmingthrowdown.com/2020/01/episode-98-agile-thinking-with-zenhub.html ★ Support this podcast on Patreon ★

programming throwdown episode 98 agile thinking with zen hub take it away jason hey everyone so we're here with aaron upright who's a co-founder at ZenHub. And, you know, I know agile is a really common term. I remember even hearing it in university before even taking any software architecture or software engineering courses. I just become very ubiquitous. But a lot of people don't know, you know, really what that means, what it entails. And so we have Aaron here who's founded a company that part of its core mission revolves around Agile to kind of dive deep with us and kind of explain what Agile is all about. Yeah, thank you guys. Thank you guys so much for having me. I'm really excited to be on the show

today. Cool, cool. So why don't you tell us a bit about your background? Like what kind of led you to the path that got you here? Yeah, so I work on the go to market side of our business, which kind of captures everything from marketing, sales, success, basically following customers from kind of when they come to Zenhub and when they're kind of first interested to using the tool to how we kind of really make them successful. And my background actually isn't really typical for a founder of a developer tool company. I did a year of engineering when I was in university, but actually I dropped out of that program and completely switched what my focus was from an academic perspective. For whatever reason, I just found that academically engineering, being in an engineering program

was a little bit isolating for know, isolating for me. And I really like the competitive aspect of having to compete against my classmates. But I love the concept of building things and making things. And I was always really fascinated with technology. And so academically, that led me down the path of actually going to business school where I finished my degree. And that's how I got involved in a lot of the go-to-market sides of Zen Hub. But when I graduated, I was looking for what is a way that I can apply this in a way that kind of really naturally fits with where my passions are and really naturally fits with technology. And so the answer for me at that point in time was saying, hey, can I join a really small startup

or could I join something in the technical space to try to apply what I had learned in university with kind of what my passions were. I actually ended up in Vancouver, Canada, at a company called Axiom Zen. The idea, the hubris for Axiom Zen was a startup, you could say, that builds other startups, or almost a venture studio model. At the time, there were a couple of people that were working on an internal project called Zen Hub, really to address and fix a lot of the gaps that we saw in our own software development process at Axiom Zen. And kind of when I first found out about that, it was a very internal project, very kind of small scale thing,

but I immediately knew that I wanted to get involved in that. And so that's a little bit kind of of my background and how I came to be is one of kind of the core founding team members of what now today is the product we know as Zenhub. It's really interesting. I always thought, and I've never been to business school. You've been in both, so you'd be the authority here, but I always imagined business school as being really competitive. Yeah. I think it's interesting. It's competitive in different ways. What I was really craving, I think, in my education was the opportunity to collaborate and work on things with people. And it's kind of funny that I say that because so much of software development and so much of what we're going to talk about with Agile is all about how you collaborate and communicate better and come together to deliver products and to ship software.

But, you know, in the first year of engineering that I took it, I found it was a lot of assignment work, a lot of individual work on things. What I mean by competitive is that you're competing for the ability to specialize in a program at the end of the year, at least for the school that I went to. You'd be talking with your classmates and trying to work together on things and collaborate, and a lot of people that were in that program weren't really open to doing that. I'm painting a really broad brush here on engineering programs as a whole, because I know that not everyone is like that. And at the end of your program,

you can get some really interesting things with capstone projects and things like that. But I was just craving for kind of more of that project work, I guess, throughout my undergraduate degree. And, you know, that's kind of where I found that. That totally makes sense. I think, I think that that is a really big issue. I took one course that really changed my life, kind of changed my PhD dissertation, like changed everything. And I think one of the reasons that that course was so impactful was the whole thing was just a set of projects. Yeah. And I feel like that is a really strong way to go. But it's, it's, it's an intense, it's intense on the, on the, on the professor. Yeah, for sure. I think that's one of the reasons why they don't do it.

But I totally agree with you. I think that it's, it's a shame that some people do all of this. It's like they know how to invert a binary tree and they know how to do a lot of these things really well, you know, as an individual, but then maybe they haven't taken courses on working as a team. Yeah, for sure. And I think that teamwork component of it and learning how to work with other people

is one of the most valuable experiences you can build because you're going to have to immediately do that when you kind of step out of school or step out of university or college program and then enter the workforce so and actually i remember one of my favorite courses i think probably the favorite course i had of our undergrad degree actually or my undergrad degree was um where we we actually had a course that overlapped with computing science and so half the course or half the classroom was business students half the classroom was computer students, half the classroom was computer science students.

It was actually an elective for them and kind of a core course for us. But it was really cool because the whole kind of point of this course, and it was 100% project work, no exams, no finals, no midterms, was to come together and kind of build this website that was powered by a SQL database and all these different kinds of things. Obviously, we were able to work with students from CS, so they had more of a technical background. But the idea was that as business students, we were supposed to gather the customer requirements and do a lot of that ideating. That was actually the first time, too, that, funny enough, I was actually exposed to GitHub.

There's a funny story about that, too, because I think if you look on, you know, our team at Zen Hub, one of the things that we do sometimes is, you know, when new people come on board, you know, we look at like, well, how long have you been signed up for GitHub? How long have you been using it? And I actually have one of the oldest profiles on the team, despite not being a technical founder or between being a software engineer, because I signed up for this thing when I was in school to be able to work and collaborate with, with the rest of my classmates that were working on that project. So. That's awesome. So, so the yeah, I have a buddy who just happened to be as in the same university as, as Mark Zuckerberg. And I think he, his degree was in philosophy or something, but he has, he has like the eighth account on Facebook or something crazy like that. Maybe it's the 30th

account. And so his, his Facebook ID is like 20. Whereas for the rest of us, it's, you know, in the billions. That's funny. Yeah. It just sounds very serendipitous. Yeah, for sure. Cool. So, yeah, kind of walk people through sort of like what Agile is, especially, you know,

we have a lot of folks who are even in high school, maybe folks even younger than that. And they might have never worked on a team before, a team of software engineers. So how could you explain sort of Agile? Like, what is the value of that? And sort of how does it work? Yeah, I think it's a really interesting question. And I would kind of answer, I guess, in two parts of what is Agile then what does it mean to be agile? And I think a lot of the content, a lot of the writing out there, a lot of what you can go and find on agile tends to focus across all these different Agile terms, you're almost immediately kind of jumping into the deep end through that. I like to think about it, though, through the lens of what Agile means for our customers and for our end users. Because I think at the end of the day, we're all building and shipping software. And Agile offers frameworks in which to do that, in which to organize these.

But really the value of Agile, I think, is what it means for the customer. And ideally, for all of us, that's getting software to market faster, getting software to market that's higher quality, that aligns with the value proposition behind our project. And really, I think what Agile comes down to, as opposed to maybe more traditional ways of working that I kind of grew up with in school and kind of learned about is really delivering value to our end users and our customers in smaller increments. I also think the idea of value is a really important one to think about in agile because if you're not delivering value, it doesn't really matter how you're working. You can come together and organize yourself in any way you want. But at the end of the day, if what you're

building isn't valuable to your customer or value to potential customers, you don't really have a project or a business. And I keep using the word customers, but I mean, that can be anything from people who use your open source project, that use your software in an unpaid or either a commercial standpoint. And yeah, I think about agile is the whole point of it is to deliver more value sooner to is to deliver more value sooner to our customers, more value sooner to our constituents. And I think at the end of the day, I would argue if you can do that and find ways to do that, irrespective of how you organize, you know, then you're working in an agile

and iterative way. Yeah, that makes sense. So is this related to, you know, we just had a show on continuous integration and they talked about continuous deployment. So you do a push, it passed some tests and then right away, your customer gets it maybe within an hour. So that would be an example. You're moving to continuous deployment would be, that would be an agile endeavor. Exactly. There's under the, under the kind of broad strokes of agile, there's a lot of different ways that it gets physically implemented at companies. And like you said, CI, CD is one of those.

And I think for a lot of people listening to this, you know, it's important to kind of recognize where we kind of came from and where we are now in terms of our software development process. And not so long ago, and believe me, there's still companies out there. We get a look at this kind of still pretty frequently that are used to very kind of waterfall centric ways of shipping. And what I mean by that is these kind of really steep drop offs of like, all right, for the first three months of this project, you know, we're going to focus on the design phase. And once we're done with the design phase, it's permanently done, we're never going to come back and update those designs, those are locked in, we're moving on to the next phase, which is development, that's going to last another three months. And you know And we're going to be working on the

designs that we built from the last phase and working to actually codify those and to actually create those. And then once we're done with that development phase, it's permanently done. We move on to testing and so on and so forth in this very kind of waterfall-centric way where you have these kind of multiple step points. And that used to be the way that a lot of teams would come together, especially in large companies, and really develop software with these very phased approaches. And really what we've moved to more recently is these really short cycles and almost circular iterations where we design, develop, QA. That could generate feedback, though, that ends up changing the design somehow. And so we don't have to wait until the next version of the software, the next big iteration that we push out to actually make those changes. We can do that in a much more iterative way on the fly. And when you talk

about CICD, that's definitely a huge part of it because as you think about shorter cycles of design, development, testing, deployment, we need to be able to get software out way faster and make sure that it still goes through the same kind of passesmonth project that we deliver once and then it's in the hands of our customers and they use it for however long they use it for, CICD really came about so we can enable teams to ship a lot faster while still upholding a lot of the quality components that you need when you're producing software. Yeah, that makes sense. So what about for folks who are sort of pegged to a longer release cycle, how can they be agile? That's a really good question. I think it comes back to thinking about maybe some of the frameworks that you can start to implement around that. And I talked a lot about value and the core kind of principle of agile being, hey, let's figure out ways to deliver value to customers sooner. I think it's a little bit silly, though, not to acknowledge that there's a lot of really academic ways about thinking about Agile, too, and so much content that's been written about it, and so many, you know, so many essentially ways of working that have been documented,

certifications, accreditations that you can get. So I guess to answer the question, for teams that are kind of used to that more waterfall centric way of working, there's a lot of, you know, frameworks that you can look to, to start to integrate and implement kind of components of agile across your different software, you know, your software development lifecycle, I guess, your software development process. And, you know, I can start with something small. That's, you know, an idea that we kind of recommend the teams, whether it's a new way of working, or it's a new process that you're implementing or maybe a new system to try to get to one of those end goals that you essentially have. Rather than having to go through this massive cultural

transformation of saying, we're no longer developing software like that. Everyone's got to work and organize in this way. I've seen that firsthand. It can be a very painful thing for an organization to have to go through. And so I guess to answer that question more directly, I would say, you know, start really with what your goals are in mind. And if you're switching from a way of working that is more waterfall centric to in wanting to be more agile, you know, really, what are you hoping to get out of that? And what does success look like for your team? And then find those frameworks or those processes that can overlap and get you closer towards that goal that feel comfortable for the team, that aren't necessarily transforming your entire process overnight or creating really confusing paradigm

shifts for people in the organization to have to go through. Yeah, that totally makes sense. Yeah. I mean, Patrick has a lot more experience on hardware- related things than I do, but I would imagine no matter what someone's working on, after a day of coding, there almost has to be some way to show that, even if it's just the person sitting next to you. And so in almost any environment, you can find that audience where you can get that immediate feedback. And then even if it's sort of just within your team or within your company or organization, you can be agile and then make those big strides when it gets pushed out to the

customer. For sure. Yeah. And I think, again, just kind of coming back to the idea of focusing on what your goals and what success looks like is a really important thing to think about as you're transitioning from any way of working to another way of working. I think if you only focus on the processes or the ways of working or the frameworks, you know, without really having any goal in mind, you just get disconnected from really what the purpose is behind agile and why it came to be kind of in the first place and why we move faster as organizations and why it matters to our customers. That, that makes sense. So, so, you know, folks who, so I guess, okay, so I'll ask kind of an initial question. Zenhub, do you, you provide this platform,

but I'm assuming you also do a bit of sort of consulting if there's some, some folks who, who want to sort of improve their methodology in addition to using software. Yeah. So, oh, go ahead. No, I was just going to say, I spend a lot of my time on that. So it's, it's something that I'm pretty close to in the business. Oh, cool. So what do you find sort of changes when, when folks sort of adopt this, this methodology, like what,

what sort of like what's the impact of that? Yeah. I mean, hopefully the, the impact is, you know, that we're able to actually deliver value to customers sooner. Hopefully the whole team can be thinking through that lens rather than, okay, how do we just adopt the next thing? How do we ride that next wave of technology or that next wave of systems and process kind of thinking? Because, like I mentioned, at the core of it, we're really trying to deliver that value, you know, sooner. So what we typically see that, you know, teams go through these, these transformations, you know, is that the quality of what they're producing tends to

increase the time, the market tends to decrease. The conceptualization of what a project is, or, you know, what a product is, tends to be much more of a minimum viable product and much more iterative. What I mean by that is instead of thinking, we have to ship the perfect product day one and get it right from the moment that it lands in our customers' hands, we can take a more iterative approach here because we're working in an agile way. We know that once we deliver something, we're not done. We have to come back to that. We have to get feedback on what we built. We build that back into the product. We look for opportunities to optimize in that. And so I think teams that are kind of going through those agile transformations or thinking about agile tend to think more in

those ways rather than here's a big project I have to deliver. This is the target delivery date for this. It has to be absolutely right from day one. And every feature has to be available in it from day one. You know, it can create these runaway projects where scope just increases and increases and increases. And you have this massive scope creep that happens versus people that are thinking in more agile ways, I think are naturally more attuned to saying, what is the maximum value that I can deliver in a first iteration, follow it up with, you know, subsequent iterations that keep on adding value to that product. And it's a pretty big mindset, mindset shift, depending on kind of where you're coming from. So yeah, that totally makes sense. So yeah, you have, you're in this

sort of really unique position where you can, you, you literally are observing, let's say, split tests and back tests. So in other words, you have folks that switched from whatever they were doing, maybe it was something ad hoc or maybe it was a waterfall model to Agile. And you could also, if you're working with one part of a company and it's a larger company that has other software engineering teams, you can also split test and you can see what it's doing firsthand, which is really cool. I think it really gives you a unique perspective on Agile.

For sure. And I think one of the interesting things about that is that when companies, large organizations typically go through these transformations, it's typically not a, like you mentioned, a all or nothing approach where suddenly everyone wakes up one morning, there's an email in your inbox and it says, hey, we're now an agile shop and we're working in agile ways. You know, I mean, I hope it's not that, but there's, yeah. But typically there's teams that are piloting these new processes and piloting these new approaches and piloting the new tools and systems that come along with that. And more often than not, what we find within these large organizations is that it's not a mandate being pushed down from the CIO or from leadership saying, hey, you have to convert to an agile way of working.

Oftentimes within the organization, and funny enough, it's teams that are looking at the parts of the organization that adopted Agile and saying, holy, man, are they moving faster than we are? Or, wow, look at how much better they're able to build and deliver software. We need to start working like that. And so that groundswell of adoption tends to come more bottoms up, I think, than you'd expect in a lot of organizations because people see the results and people see the dynamic and the change that actually happens when you start working in agile ways. And that's been really fun to see as well, because you can start with a really small team, you know, that's adopting your solution. And then before you know it, you have people knocking on your

door saying, we want to use this thing because we want to be more like that other team, or we see the value in doing this, like let us in. So I think that's a really cool aspect of it, too. That's super cool. One thing is a bit of a bit of a tangent. But I've noticed a lot of it's very hard to build things for engineers because because they tend to want to build everything themselves. It's like, this only solves 99.69% of the problem. I need to build it from scratch. Right. And so, and so, you know, but GitHub runs counter to that. I mean, GitHub is amazing and Zen Hub runs counter to that. And so how, how are you able to, you know, kind of get, get folks to adopt Zen Hub instead of hacking something together and pick any web framework

they want? Yeah, I think it's an interesting question. There's a couple of ways that we think about that. One is kind of extensibility and flexibility of our product. And so we've been very intentional in saying, we don't want to take the most opinionated approach in the market and say, here's our tool, you have to use it, then the engineers get upset and they go, well, we have to customize it and it's not fit for our purpose. So we're going to have to rewrite another one or we're going to have to rebuild this whole thing from scratch. We actually try to provide enough flexibility within our product that if you're used to a certain way of working or you want to try other ways of working, it's easy to actually customize

and configure the product for that. And so hopefully that alleviates the need for engineers to feel like they need to go off and create a separate system themselves to do that. The other thing is that we do provide a pretty extensible API around our product as well. So there aren't features or things that you can do inside of Zen Hub. We try to create a really accessible way to get that information either outside of the system or to put that information into the system. So hopefully, if it's not a use case that we've thought of or something that we've kind of built into the product, you can actually go and build that yourself. And I feel like a lot of engineers actually appreciate that approach. And that kind

of alleviates, I think, a little bit of that feeling to be like, well, this tool isn't what I need, so I need to go off and build it. The other thing I would say, too, is just culturally reminding teams of what your mission is, and even individual developers. Publicly, we can talk about a customer we work with. It's a really exciting use case. It's the Jet Propulsion Labs team that's part of NASA that actually uses our product. You know, when you're a developer there, your mission is to, you know, be putting spacecraft on the moon and be putting spacecraft on Mars. And that's what incentivized you to go and work

for Jet Propulsion Labs of all the cool things that you need to do, not building tooling and infrastructure, you know, to solve the problems in the organization. So there's that constant kind of reminder sometimes for people too, in terms of, Hey, like, you know, we need your feedback and be open and vocal about it because your mission and your job, your mission actually quite literally is to, to go off and do this, you know, space related thing, not to build the best in class project management tool. So let us take that on, give us your feedback, tell us, you know, what you need in the product. We'll do our best to build it in.

And if we can't, we'll make our experience extensible enough, hopefully, so that you can build it yourself. Yeah, that totally, totally makes sense. And so did that, was that realized on day one? So on day, like early in Zen Hub, did you say, you know, we're, this product is for engineers, it needs to have a really solid API, or is that something you kind of learned along the way? I think it's definitely something we learned along the way. Um, the origin story for Zenhub is, is a really different one. And it doesn't really follow the typical narrative of starting a company where, you know, there was, uh, two engineers at Google that were frustrated by X and they went out and got built it. And then

we raised funding for it. And now, you know, we're, you know, kind of taking over the world. We really just noticed, and this was back when I was working at Axiom Zen, that kind of parent company of Zen Hub, that the way we were building software was just fundamentally broken in a couple of really important ways. And we noticed that our developers were constantly spending, you know, all of their time almost inside of github and that was the environment where they were most comfortable with it was the environment where they felt most at home but we were constantly forcing them outside of that to go and update these different project management tools because as a business we needed to know where we were at

you know we were working with customers and clients at the time, and we needed to have that lens into these different software development efforts. I just had this crazy sort of out-of-body experience because I'm literally going through that right now where we spend almost all of our time in GitHub, but our project management is using Google Docs. Yeah. And it's such a high friction experience, right? Yeah, totally. Developers who are used to that environment, you're saying once a day or multiple times a day, come out of that environment where you're most comfortable into this other project management tool to update what you're working on simply so that we can report that to someone else

or have an accurate view of the project. And what tends to happen more often than not, and I'm not sure if this has been your experience too, is that developers don't do it. You know, they have other important things to do and it's an extra added hassle and kind of headache at the end of the day to have to remember that. The challenge there though is no one really wants to make developers' lives more difficult. It's the fact that project managers need access to that information, hopefully in an accurate way to actually provide visibility and transparency further up. And when they don't have a system that's up to date, they ultimately don't have accurate information. So that's really the problem that we were trying to solve. And what was broken with

our process is that whenever you'd ask a project manager how this particular project was doing, no one really had a clue because we were using systems that our developers wouldn't really keep up to date. And so that really led us down that path of saying, what if we just built this thing over top of the source code layer? What if we just integrated as deeply as possible as we could with where developers are already spending their time? And so you talk about, what would you guys think about APIs and think about extensibility upfront. Literally the first version of Zen Hub was a hacky Chrome extension that actually manipulated the GitHub DOM. I'm not sure how we even made it past those early days sometimes too, because we were literally injecting code into GitHub's website, but to inject this tab where you could actually have a task board to manage all your issues and pull requests. And that was kind of the MVP of the product and just being kind of that

very physical experience inside of GitHub. Not a lot of automation in that, fairly manual, but we noticed in using it that our process really just changed completely overnight. And as we started to get more traction and get more developers on the product, that's when we started really thinking about, okay, well, how do we build this in a way that kind of, I guess, best fits with that? And I still think it's a pretty core differentiator for us today because what we always come back to,

you know, is we're looking at new features and looking at new things we can build and taking in customer feedback is what is the developer experience and how is that going to impact that? And that developer love i think that we have in the product today so uh the initial version you said sort of like did some you know uh dom injection but uh how do you how do you what do you do now it seems like that's necessary right if you're going to integrate with someone else's website yeah well i mean, that totally became the model, right?

And at first, like I said, it was just like, well, how do we physically stay inside of the GitHub UI? Because that's where people are comfortable with. And we want to be able to work from github.com. We don't want to have to manage a separate platform and have to manage separate logins and authentications for a lot of that. And so half of that, I think, was made from the choice of,

this is literally the best experience for the developers. Half of that was like, half of that, I think, was made from the choice of, this is literally the best experience for the developers. Half of that was like, here are some freebies we can get by integrating with GitHub OAuth and integrating into their platform. It's still fairly core to our strategy today, but I would say the one thing that changed, and this is something I think for anyone listening that is a fairly typical situation, is that software development, especially for commercial projects, but also in open source and also larger projects,

it truly does become a team sport at some level. And it's not just about developers off working on code and building things. It's the coordination that needs to happen around that and the surfacing of that visibility to the rest of the organization. And so that's when we also started to think about the experience from the perspective of the other personas that are involved in building software, whether it's a design team that's actually creating the design spec for what is going to be built, whether it's a product team that's coordinating and gathering requirements, whether it's a project manager that's organizing the work into sprints, whether it's a QA manager that's actively kind of testing and doing a lot of QA on the work.

And so that's when we really started to think about our experience, at least from the perspective of different personas that would come into contact with that. And we've actually built outside of the extension and started to kind of layer different areas or different value into different areas of the product since then. But yeah, it's evolved a lot from just that initial way of thinking at initial product. So yeah, that totally makes sense. Totally makes sense. Like you don't, it's sort of the same issue in reverse. You don't want the project manager now to have to live in GitHub. You have sort of a separate user experience and they share like a common backend. Exactly. Yeah. And believe me, we found that out very quickly that project managers are

not necessarily at home inside of GitHub. And that was kind of that moment of realization of like, well, we built an awesome tool here that has an amazing developer experience, but man, now there's a lot of other people that are coming into contact with this. We need to give them that information in a venue and in a place where they feel comfortable as well. So we actually built our own web app container with Zenhub as well. It tends to be that if you're a developer, you're using GitHub, you love to stay inside

that view, you'll download our extension and actually use Zenhub inside the GitHub platform. As a project manager or product owner, maybe you're using the web app which is available kind of on any browser regardless of whether or not extensions are supported it's available on any device and so just much more of a home for that persona but yeah it was it was kind of funny going through that realization of being like we have fantastic traction with developers they love using the tool and then it was started getting a lot of pushback fairly quickly from people being like, so I signed up for GitHub the other day and couldn't figure out where I was supposed to go. And it's like, I don't know the last time you guys went through the onboarding for GitHub, but it's so developer focused. And it's like, create your first PR.

And project managers would be like, why? That seems like a dangerous thing to do, actually. And we were like, yeah, that is actually a dangerous thing to do. Don't go off and create PRs against the repos where you've been given access to these stuff. Yeah, right. Totally. Very cool. And I guess there's maybe even like a leadership. That might be part of the app, I guess. So leaders can see the breakdown of many different agile teams. Yeah, that's kind of been the next part in the journey for us. And I think we think about where we go as a company a lot through the lens of these personas.

I think it's a useful way for anyone that's actually listening to this and either building software or thinking about building software to think about your product vision and to think about how you actually set vision for where you want to go is to think about the personas and jobs to be done of the people who are interacting with your product. Obviously, I think we provide a best-in-class experience for developers. We integrate to the source code layer. We get out of your way. We provide just enough value at the right time for the project manager.

One of the personas that we're kind of focusing on now is, how do we present a lot of this insight, and a lot of what's happening in the software development organization, up to leadership? And take what's being done by the developers organization up to leadership and take what's being done by the developers and start to connect that back to what the business actually cares about and where we're ultimately going as a company. So if we're calling out these big initiatives that we're going through, these new products we want to build, these new features within products that we want to build, connecting

the work that developers are doing inside of GitHub to those major projects I think is a pretty big gap that not a lot of organizations have a great answer for. And being able to do that with what's actually happening in the source code is so powerful because ultimately the view that you're seeing into your projects is coming directly from the changes that are happening in your code base rather than people manually updating them. So we actually launched a brand new feature just at the beginning of November, actually, called Zen Hub Roadmaps to essentially allow teams to build product roadmaps directly inside of Zen Hub.

And then for the items in that roadmap to be connected back down to the individual issues and pull requests that are being worked on by different teams. And it's been a really cool layer of visibility. And like you said, we see a lot of teams use that to really surface what is happening in the engineering organization to the rest of the business and to leadership as well. That's awesome. Yeah, that totally makes sense. Hey, guys, I'm going to jump in for a minute here with a word from this episode's sponsor. We're happy again to have Educative.io uh an online learning resource and since the last time we

came to you talking about them they've changed things up a little they have a brand new option instead of buying courses one by one and selecting what you want they now offer they still offer that but they also offer the ability to get a subscription where you can for the length of your subscription access any of the courses so all the same courses we talked about before you can now access for sort of a flat monthly or you know per time period fee and because of their sponsorship they've agreed to give us at educative.io slash programming throwdown 10 off either a single month's purchase or the subscription that's right you get 10 off pretty much anything in the store so so i was looking at the courses after we talked last time and um a couple things that i i guess i missed and which is one is they

have a number of courses that are actually just completely free if you want to try them. So they have free previews, you know, little parts of many of their courses, but they also have a number of languages from scratch. So C++ and Python from scratch. And those courses are actually free. So not only are they a great way to learn or advance your knowledge in those languages, but it's a great way to actually check out the platform first because spending any money, I mean, I don't like spending money. So not spending money and still being able to check something out

always alleviates a little bit of the sort of nervousness around doing it. And this is a great way to check out the platform, these from scratch courses. And there's also another course I found on here that's the practicing for programming interviews. So Jason, you do interviews at your company. Do you recommend people practice programming before they show up to your interview? Yeah, totally. The cool thing about this is,

is, you know, when you're kind of writing in this sort of environment, they kind of give you some, they kind of give you some setup, and then you you some setup and then you write some code and then you can even kind of, you know, validate that you've done the right thing. And that's that kind of loop of, you know, writing something, especially, you know, in this case, if you're, unless you're sort of using an editor and then coming back, but if you're, but if you're writing it in the editor, you know, you, you're kind of writing that as if you're writing it on a whiteboard. And then you're getting this instant feedback like, OK, you got it right. You need to try again. And that's really going to kind of give you that muscle memory that you need so that when you go to a whiteboard interview, you kind of are a little bit more prepared. I think that the from scratch

courses are really solid. And the other part of it is, you know, it's, it's a different way to learn, you know, there, there might be some folks out there who can do sort of the lecture thing. For me, it's, it's, it never really resonated with me. Something like this where it's hands-on is, is, is really good for, for people like me. And it's, it's, it's awesome that they have this free course. So even if you're you know a python guru um but but you think this might be a good way to learn something else uh you know you could dive through the python course you could pick a different language and dive through that uh totally for free and then if that looks like the kind of you know learning model that's really going to work for you um you

know that you kind of know that without having to spend any money they didn't really i was trying to think about it i guess when i was learning a program i mostly did it from like books before even really like getting on the internet or there being internet i mean i guess there probably was but we didn't really use it um so the closest i could think of this was did you ever do vim tutor no i didn't oh so if you ever you know have accessed vim one of the things that will reckon or I guess VI is the same thing. I'm not really good about the difference between the two. So if you open them, sometimes the bottom would be like, I forget there's some command you can type and it will basically walk you through like a document, which also tells

you like how to edit and you like move up and down in the document. And it's sort of almost like kind of like interactive fiction about learning how to use vim oh yeah emacs has something similar oh okay uh and i was thinking like actually this kind of is like that but you know of course like a hundred times better or whatever but yeah you know when you originally said that i thought you were thinking about um they actually used to have these um i keep wanting to say choose your own adventure. They're about the same form factor as those choose your own adventure books. But it's not, you read it, you know, left to right. But you get to a point and there's basically like a little puzzle. And, you know, you're supposed to like solve the puzzle.

And then somehow there's some way to like validate you got it right. And then you keep reading and so the idea is you have to it's kind of on the honor system but but you would um you'd be reading this is just like a paperback book and then it would be like oh put in this basic code and then and then edit it to solve the puzzle and that's basically how i got started yeah so i mean i think this you know format is you know obviously catching on in a lot of different places. And it's really awesome to see. This is a learning resource, I think is really resonate with people, the ability to be able to be almost anywhere and be able to interactively, you know, read, write the code, not necessarily just like listening to a lecture and trying to figure out like, how do I make it go 50% faster? How fast can I go before I can't understand the person anymore? Not that I've ever done that before. But yeah, I think this is a great forum for learning. Yeah, this is awesome, guys. Check it out. Educative.io slash programming throwdown. That's going to get you a 10% discount.

That's also going to let them know that, you know, that this was a good slot for them, that they were a good sponsor for us. So that helps us out. It also helps you out. And check it out. Also, let us know. Send us comments. Send us email. Let us know what you think of the courses. And we can relay that back to the folks at Educative and give them feedback so they can keep improving.

All right. Thanks for the sponsorship. And let's get back to interviewing. All right. Spiraling back up a bit. So yeah, you know, if someone just wants to get started with agile, I mean, actually, this is something that agile took me personally a long time to get into. And I think it's because when you search for agile, what you find is just a lot of different names of processes. And actually, you know, it reminds me a lot of the, like, Lean Six Sigma. You know, like the black belt. Yeah, I remember that.

Yeah. So it's kind of, it's kind of, it's pretty nebulous. You know, you don't, when you search for, you know, agile programming, you don't get, you just get all the information at once. Yeah. So if someone wants to, let's say someone's a, you know, a student, maybe they're a PhD student and they have pretty long projects, you know, projects that could take years, but they're working, let's say by themselves or with a couple of people you know what is something

that that that they can do um that would sort of you know get them get them the right mental model yeah that they can dive into agile i think it's really funny you mentioned like lean six sigma because i i remember and i just have this like flashback of of uh you know me in high school and and uh was actually like trying to understand and like read about that. I thought it would be something that would be like really big. And then, like you said, you go out and you search all this, not to say that it isn't big and isn't well adopted, but, um, you go out and you search for like all of this to try to figure out like, this is a topic I've heard a lot about, or I've read a lot about, or keeps on coming up. And then everything talks about supply chain management logistics. And you're like, I don't

know supply chain management logistics. Like I'm in high school. I just want to know how to do things more efficiently. And like, you know, it seems like a cool area and field to kind of study. And agile is kind of the same way, right? Where you search it, like you said, and then you're seeing all this stuff around, like the methodologies, the frameworks and the tools and like, and then you get into really complicated parts of it too, like safe, which is scaled agile framework. And it's like the release train

and program increments. And you're like, stop, I am done. Like I can't, I can't learn this anymore. And so if you're completely new to agile, if you're a student, you know, in high school, or if you're doing your undergrad, or if you're doing your PhD, you know, what I would recommend is starting with some of the basics to familiarize yourself with that. There's three resources I think that come to mind that I can call out that I think are pretty powerful for that. The first is starting with the Agile Manifesto. This was written a while ago, but if you're not familiar with what it is, it really spells out a lot of the core tenets of what it means to be agile and really why this way of thinking kind of came about and what it was trying to kind of work against. And I think it's really a good read. It's a short one too.

And there's just kind of four core points and then I think 12 points on the actual manifesto itself. But it's a good read to create perspective around the intentions behind agile. And when these people kind of came together and developed this way of thinking what it was kind of meant to address um and i think you know most people that are going to go back and read it for the first time will probably realize that it's it's kind of out of date um for example like there's a really heavy emphasis in the agile manifesto on co-location and face-to-face collaboration over tools and processes and you can tell it was like clearly written before slack zoom and like webex were like big things because it was like clearly written before Slack, Zoom, and like WebEx were like big things because it was like,

no, we gotta get people in the same room. And like, that's how they collaborate. It's like, well, reality of the situation today is that that's not necessarily the case. But it's a really good read, I think, to get behind the driving forces of Agile, behind the intentions, and really understand the tenants.

Another resource that really kind of helped me in the early days is a book called The Agile Samurai. And I think it's kind of a quintessential read when it comes to understanding agile. And I like it because it does a lot of compare and contrast between agile and waterfall ways of working too. And so it compares what we're aiming at and trying to get to with Agile and kind of what used to be with waterfall ways of working. And if you're coming from that waterfall way of working, or that's what you're used to, or that's what you're being taught in school, or that's kind of what you know and imagine

project management to be, it helps paint that picture. It's a little bit contrary to that. I also really love it too, because to your point, it doesn't assume as a reader that you know anything. It explains like every single concept in the book from, you know, CICD to agile to the different ways of working, it gives really good analogies. And it's not that assumptive kind of read of like, all right, you know, 50% of this, we're going to teach you the next 50%. It's like, you know, you know, nothing about it. How do we get you off the ground and start comparing this to things and making analogies that are really easy to grasp versus all of this assumed knowledge that we think you might have?

And then the third resource that I can't recommend this one enough, it's a book called The Phoenix Project. Maybe you guys have heard of it or maybe you've read it. No, it sounds awesome. Okay. Take a note. Basically, it presents like a picture of an organization that's working in a very waterfall-centric way that is in major disarray after one of their projects that they were supposed to launch to transform the business and bring them into the new modern era basically fails and goes way over budget, way over time, and basically flops. And it's all about – it's this hypothetical kind of picture they paint as a company. The company is called Parts Unlimited, and so it's not like, you know, any specific company they're targeting out of. It's all fictional. But it's all about how these different characters in the book kind of adapt their ways of working

and go through this agile and DevOps transformation, ultimately, and come up the other side as a completely different organization. And the cool thing about this book, too, is that there's characters in it, there's character development, and people have different roles. And it keeps on coming back to the same people as opposed to, you know, just being this high level academic kind of read. It's actually a little bit more fun, because it puts it into practice. And it's funny, too, because I think you can see a lot of similarities between like some of the characters in the book, and probably some of the people that you'll end up working with, just in terms of their personalities, and, and all the things like that. So those are those are

the resources that I really love., again, to your point, they don't have this like assumptive, they don't have this, they're not assumptive in saying like, oh, you already know about Agile or you develop software in a multinational organization and you're used to working this way, so you should know this. We're going to teach you something else. Yeah, that totally makes sense. So I think, does it make sense to sort of pull out one component, like maybe just

the two week sprint methodology and just say, you know, try this first. Like, so if someone comes to you, um, and, and they want to adopt agile, is there sort of, is it incremental like that? Or, or is it really just a deconstruction of what they're doing now? I think it should be. I mean, we get this question all the time. And because I'm involved on our go-to-market team, you know, I spend most of my day working with our customers that are using our product. And by far, the number one question that we get is, you know, how do we get started with Agile or what framework do we adopt? We're starting from a place

where we're not very Agile today. We kind of organize work a little bit. Tell me, you must have all the answers. You see a bunch of different teams. Is it Scrum? Is it Kanban? Give me the real deal here. What do I just need to adopt so that I can stay on Agile

and kind of get to the point of Agile working? So we encounter this all the time. And I think there's a few big things when you step back that I always recommend to teams when they're thinking about how to get started with agile. And the first thing is to think about what success looks like for you and your team, kind of where you're at today. And what does that picture of like success look like in terms of where you'd like to be six months from now, a year from now, 18 months from now? Don't think about tools and processes just yet. Define success because that ultimately allows, I think, the organization to take a progressive approach that balances speed, visibility, predictability, and really change management within the organization.

And so thinking about success, I feel like, is a really good first step in terms of thinking about what flavor of agile you want to ultimately adopt. I'm also a really big fan of teams easing into a new process and building those good habits along the way, as opposed to going through this culture shock of suddenly adopting a new way of working and not knowing how to do it. And when teams are adopting agile, you know, methodologies, whether it's Scrum or Kanban or anything in between, I don't think it should be an all or nothing approach. You know, that suddenly you're working in this new way of working. You mentioned like Scrum, for example. So if you want to deconstruct that one and focus on that, you know, just to connect that to the, what I just kind of mentioned,

like we've seen teams who are like, well, we ultimately want to end up working in a very Scrum style way. We think that's kind of core to our success, but you know, maybe they start with certain elements of that framework. So they still, for example, organize work into two week sprints, but they're not yet at the point where they're able to estimate or where they're able to understand their velocity. And that's okay. Software estimation is like one of the hardest things I think to do when you're building software and knowing how long things are going to take and how complex things they are. And probably if you started estimating from day one, that would

actually slow your team down and create more friction in adopting that new process. And so that's where, you know, I really, I think an iterative approach is important, where you're like, we're gonna, you know, adopt certain parts of this, of this methodology, not all the parts, because they may not make sense, kind of given where we're at today. And this is where we want to get to over time. But you know, this is kind of where we're going to start. So yeah, that sense yeah i think um yeah to your point i mean if you haven't broken things down into two-week chunks there's no way you're going to predict what you can do in two weeks exactly it's impossible right and so and so um yeah the first step i think is yeah getting that methodology and and um maybe even similar to like a shadow, shadow database type thing. You know,

if your project manager really needs to stay on top of things, you can have this sort of transition period where, you know, it's a little painful, but you do things in, in your current project management flow and you do things in, let's say Zen hub just maybe for a quarter to sort of, you know, you know, make that shift. Exactly, yeah. I think maybe organizations can be a little heavy-handed at times

in enforcing agile ways of working. Typically, when we see that, it's a big predictor of organizations not being as successful with agile when people are really, really heavy-handed on the ways of working. But for most people that are adopting agile, there's no agile police force out there that if you're not using all the different parts of a methodology, they're going to come by and arrest you at your desk kind of thing. It's like, ease into it. No one's enforcing this kind of stuff. Do what works for the team, figure it out yourself, and eventually you'll get to the

state that you want to be at. But upfront you know, upfront, there's, there's no point in investing in every single part of it. If you know that, like you said, uh, we've never organized work into two weeks before. So how are we possibly going to know how long, how much we can do in that timeframe? Right. Yeah. Yeah. Totally makes sense. So, um, so Zen hub is, um, in terms of Zen Hub itself as a product, if folks want to use it, is there a thing for students or is it free for open source projects or how can somebody try it out? Yeah. So if you're working on a commercial project today,

it's a paid license for Zen Hub. And because of our proximity with GitHub and how closely we are integrated, we've tried really closely to follow their pricing model for it. So licensing on a per seat basis with just options for teams to go monthly or annual,

depending on what their kind of use case is and where they're trying to get to. For students and open source teams though, those are communities that I think are really important to us and really near and dear. So we actually offer the product for free for students if you're in an academic program and open source teams that are working on open source initiatives or open source software.

I mean, I was a student once, we all were, and on the bottom of your list is paying money to purchase tools for software development of all the things that you could spend your money on in college or in high school. So we find most students don't really have the ability to pay anyways. But what I think has been really interesting actually is if you can get more students on your platform and get more people using your product, they take those tools with them into organization. That's right. platform and get more people using your product, they take those tools with them into organization.

We end up recouping that cost when a student that was using our product in high school or using it in college ends up bringing it to an organization. We actually have this with a major customer that's a consumer bank up in Canada. They're using Zenhub because one of their interns over the summer actually was like, using this for a mechanical engineering course that I'm working on, you know, we're building a formula car basically for this project. And I want to be able to use it here too. And they were like, well, let's try it out kind of thing. And it's actually resulted in a pretty big customer, pretty nice logo for us. So it's pretty cool. Just the synergies that can come from that. But yeah, we're completely free for students and open source teams. So for those of you who are listening and want to try it out on your project, best way to get started is just to go to zenhub.com, sign up, download the extension or

access the web app. And then once you actually authorize Zenhub, you're going to be able to see that board overlay and the reports over top of your existing GitHub repos. So super easy, super frictionless to get started with as well. That sounds awesome. So this is a bit of a meta question, but I don't know why I just got curious about it. So for students, you probably are looking for like a.edu email address when they register, correct? Yeah. So that's typically how we ask students to reach out. Or we might ask for some information just about, you know, their project or what they're working on just to kind of make sure that there is like a use case behind it.

I mean, if you're a commercial project out there trying to game the tool space by signing up with an EDU email, you've gone to a lot of effort to do that, you know. Yeah, no. We're not trying to actively police that. I think we're just trying to make it as easy for students as possible. So, yeah, we look for a.edu email or, you know, if students are coming in from a personal email, because that's what's connected to their GitHub account. Sometimes, you know, we just ask them like the name of the course and if they can shoot that back to us in an email, I mean, that's more than enough. It's a very low burden of proof, I think. And how do you and GitHub handle the per seat? Like, is that also kind of, you know, on the honor system in a sense that you're, you know,

because it's, I would imagine, like, I don't really know how you would build a website that has a per seat charge, right? Yeah. So it kind of maps back both for GitHub and for ZenHub to the actual license. And in our kind of licensing governance, I think that we've built into our product, and I'm sure GitHub has done the actual license. And in our kind of licensing governance, I think that we've built into our product, and I'm sure GitHub has done the same too, there is that concept of this organization

has paid for 10 licenses. So when that 11th person from that organization tries to come in, they're going to be kind of directed to go and ask their team for another license on top of that. So the seats are, there's one-to-one mapping between seats and GitHub accounts. Exactly, yeah. Oh, yeah, that makes so much sense.

Two users can't use the same seat at any given time. Like I said, when that 11th person comes in, then we ask them to go and request a license from their administrator. And usually, you know, there's a valid use case for that person or that individual kind of joining the rest of the team. And so more often than not, it just kind of goes through. Yeah, that makes sense. Yeah, the reason why I ask is just kind of random.

I was talking to somebody the other day about how they used to have, I used to do, I have a minor in digital media. So we used to use this program called 3D Studio Max that was, I don't know, thousands of dollars at the time. Now it's probably an open source version, but they actually had a hardware dongle that you had to plug in. I don't know if it was USB, I don't quite remember, but it might've even been PS2 port, but you have to plug in this hardware dongle, otherwise the software wouldn't start. And it just, I don't actually know uh i think nowadays it's all basically tied to your identity and so so most sites you know most most most companies are not going to tell three employees to use the same identity just to save uh yeah so that works out well it's it's kind of crazy just on that point too to think about like what software used to be like before subscription services and sas was really a

big thing yeah and i mean i even remember like uh uh you know i probably should publicly say but like downloading like uh pirated copies of like the adobe software in university oh yeah i'm not gonna buy like okay we'll find them cat's out of the bag on this one um well now they have a good model for students where you can pay. I think maybe I kind of stole it under here, but you can pay something like $10 a month. Exactly, yeah. For free or something. You know, and it's like I can't imagine a world where we'd actually bundle our software up, put it in a box, send it to a customer, charge them $1,000 a license of thing and then and that's that um it's just crazy to think about like the delivery involved in that is so complicated and like getting your product

into your hands of your customers and stuff like that it's just like it's a completely different way of thinking but yeah that makes sense how do you um um so there's a there's a per seat license but then if if if someone's at a bigger company and they want you know your help or they want they want someone's help from zen Hub, how does that work? Is that handled on sort of more of a case-by-case basis? Yeah, so we actually offer through our pricing page a couple different ways to actually, I guess a couple different tiers. So one is our growth plan, and that's a little bit more self-service. It tends to be used by kind of smaller teams that come in and say, hey, we think this tool is going to be a great fit for our workflow and we want to leverage this and use it, but

we maybe don't need a lot of help. We're fairly comfortable with that concept. We may have support questions from time to time or we're a small team. We can figure things out for ourselves. Then we actually have an enterprise tier and that involves a lot more of the priority support, having a customer success person that's dedicated to working with your team. And then we get to do a lot of just the mechanics around like actually purchasing and procuring too, where it's, you know, we can do invoice billing

and stuff like that. That's kind of less interesting. But the success piece is really, I think that core differentiator there. And we find that a lot of larger teams really opt into that because they want to be able to have someone answer those questions for them and help apply the tool to their ways of working or help suggest new ways of working. And that all comes back to those conversations we had about working with teams to help them kind of adopt

Agile and iterate on their approach to Agile and give them those suggestions on how to best do that, check in with them frequently to make sure that things are working. A lot of, like I said, larger teams really value that. Even though they have support for that within their organization anyways, they may have dedicated resources to that. I think it helps to have someone who is a lot more connected to maybe the tool that they're using as well because they can say, okay, well, our mandate is this, how do we kind of fit that mandate into the tool? And, you know, maybe we say that you can't, sometimes we need to go back and see if we can not change that

mandate, but adapt that, or here's how you can do it and give customers that lens. Yeah, that makes sense. So what about, is it, is, is ZenHub integrated, like, let's say, Outlook? What are sort of really useful? I mean, I imagine it's integrated with Slack. So at the end of a sprint, maybe there's a Slack post. Yeah, we did. That was the second integration that we actually built was into Slack. And obviously, because so many teams are working through there and so much work and conversation

and even collaboration passes through Slack at some point in the project, that was a really important integration for us to try to build that point where we could take some of the data from Zenhub and kind of present it in that view. I think that also speaks a little bit back to that persona as well. And we talked about this a little bit earlier on, but the personas that are spending most time in Slack are probably their project managers, your product owners, the people that are having active conversations around that. Some of the things that we do, for example, are showing teams when things have changed

on their board or when pipeline transitions have happened for certain issues on their board so they don't necessarily need to see all of that inside the product. Transitions have happened, pipeline transitions have happened for certain issues on their board. So they don't necessarily need to see all of that inside the product. They can actually use Slack to keep apprised on those different updates that are actually happening. Yeah, that totally makes sense. So you mentioned pipelines. Can you go over just a real quick kind of glossary of various terms? So I think we mentioned sprints, I think, just to recap, sprints are basically these two week chunks where you set something in advance. So at the end of two weeks, we want the customer

experience to look like this. And then you see you can measure that and pace yourself. And then sprints are part of Scrum, if I remember correctly? Yes, sprints are kind of a very Scrum-centric term. Got it. And so what are pipelines then? Yeah, it's a good question. So pipelines, at least the way that we talk about them, there's a very familiar concept in a lot of agile methodologies and a lot of agile ways of working that kind of anchors around the different phases, I guess you could say, or the different kind of swim lanes within your software development process. And so ideally,

you have a pipeline for each different stage that a work item would have to go through before it's actually delivered to the customer. So one of those could be a backlog. One of those could be a pipeline that says in progress. One of those could be a pipeline that says in progress. One of those could be a pipeline that says testing. One of those could be a pipeline that says QA, ready for deployment, and then maybe like closed or completed work. And so essentially what the pipelines help do is they help to actually ascribe a physical state to where that issue or where that work item actually lives within your overall workflow. And so you're able to see and kind of trace work through the different stages

of your software development process or the different stages that, you know, work needs to go through before it's actually delivered. Now, if you're thinking about Agile for the first time and you're really just, you know, going to be using it on a personal project or maybe an open source project or a school project, you know, the classic columns are kind of like to do, doing, done, right? With a backlog of like, well, this is all the stuff I have to do. I want to prioritize it. Here's all the stuff I'm currently doing that's in progress. Here's all the stuff I've done. So at least I can look back and we can measure what we've done over the past, you know, however long we want to measure that for, what my current focus is on, and do I have way too many things in that or not enough things in that? And then this is eventually the to-do list of all the items that I have to check off.

And so it's that very, like, systems way of kind of thinking. where the software development life cycle is much more complex. And you see boards with maybe 10, 15 pipelines on them of all the different stages that work actually needs to go through before it can be delivered or put in a system where it can be delivered to the customer. So that's what we refer to as pipelines as it applies to kind of, I guess, a task board or kind of a workspace. And that's something that's pretty popular, not just in Zen Hub, and it's not really something we, a paradigm we invented, but

you'll see it in all the other project management tools or all the other agile planning tools out there as well, whether it's Trello or Jira or any of the other ones you're familiar with. That makes sense. And so the pipeline kind of handles your sort of dependencies. So if something has to go through two weeks of QA and it's, it's due in 10 days, you have, you have a big, and you haven't finished coding, you have a big problem and you already know it. You don't have to wait nine days and then say, Oh, we have a problem because you've, so you know, that that pipeline, there's, there's some fixed costs there. And there's some variable costs in terms of time in

that. Yeah. And I think about it from a visibility perspective too, in terms of, you know, number one thing that organizing work in that way gives you is the two important concepts both start with a P. So they're easy to remember. It's priority and progress, right? So is this the most important thing that I can work on? Is it prioritized at the top of our column? Is it kind of down below and in terms of things that we really, you know, aren't super priority for us? And the other one is progress. So where is it at any given point in my workflow? And understanding those two things even, it gives a fundamentally different lens to a project than like, here's a list of things that I have, and maybe some of them are being worked on,

maybe some of them aren't being worked on. I don't necessarily know what are these things are most important, what we need to do first to your point, like what are the dependencies in this? So that's where we're boards can really kind of help with the organization information. Yeah, totally makes sense. So, so what about actually, so how many engineers work at Zen Hub? Yeah, we have a team is 34. We have 14 engineers. Got it. And so what is a typical day for an engineer? So actually, is Zed Hub distributed or is it mostly in Vancouver? Yeah, that's a good question. So our product and engineering teams are mostly up in Vancouver. Our go-to-market team tends to be a little bit more located where our customers are. So we have people in the Bay Area. We have

a few folks in Seattle. And so a little bit more distributed to give us some coverage and to be a little bit closer to our customers. On the kind of remote aspect of things, though, you know, we started out as a very co-located team. And it was because everyone that was working on Zenhub at the time was based up in Vancouver. But, you know, we saw an opportunity to bring talent into the team as we grew the company and it wasn't necessarily just based here and to draw from some of the biggest talent markets in the world, like the Bay Area and like Seattle, because there's some fantastic, you know, talent there on the development side and fantastic talent on the go-to-market side there. And so that was

kind of one of our initial kind of forays into thinking about building, I wouldn't say a truly distributed company, but having remote people working at the company. And then while our engineering and product teams are actually based in Vancouver, there also are now some engineers that are actually working remotely. And this isn't necessarily something that we sat down and planned out and said, you know, we're going to shift from being all in one office to being distributed over the next year, is more a matter of, I think, circumstance for some of these people that they could no longer work in Vancouver or could no longer be in Vancouver for personal or for family reasons or

whatever have that be. And it offered us kind of a good opportunity, though, to kind of test aspects of that remote culture with people that we really knew and that we trusted. So rather than like hiring someone, you know, and having them off in a province or a state that, you know, and having never met that person in person, you know, it was people that were in this office that kind of knew and understood the culture that then through, you know, circumstances had to be remote, that we kind of let go and do that. And so it gave us kind of this interesting way to kind of adapt in almost into a remote working culture. And honestly, it's been it's been really easy, I think, to adapt to. And most people I think you'd ask at Zenhub would say the same thing in terms of doesn't create any more friction, you know, these people are still reachable and

accessible and easy to work with. And most people are happy, obviously, because, you know, I think they get to, obviously, you know, be in a circumstance that's kind of comfortable for them. But there's also a lot of ways that we make ourselves accessible to those people as well, to make sure that you don't have that degraded experience or poor experience, because you happen to be working in a different time zone or happen to be working, you know, the world so yeah that makes sense probably a lot of communication um you know a lot of zoom a lot of slack exactly same players that you'd expect those those are our products that we use religiously um and then obviously a lot of collaboration too and inside of github issues and a lot of commenting back and forth on issues using zen hub to kind of

synchronize that as well so um, you know, it's kind of a cool story of, yeah, we didn't really start with those intentions in mind. We slowly became remote, but it's been working really well for us. And it's given us a new way of thinking about things to the point where I think now we're feeling a lot more comfortable maybe making some hires and stepping outside of that comfort zone and saying, we actually are fine with having people in different geographies and different areas of the world. So long as you know, they're willing to spend some time in the office up front, at least to get a feel for the culture and for the people that work here. And yeah, yeah, makes sense. So kind of walk us through like a day in the life of a Zen Hub engineer.

So what are they doing kind of day to day? For sure. I'm probably not the best person to comment on that because I'm not an engineer myself, but I see a lot of what our engineers are working on. And there's, I think, some interesting takeaways, at least that I can share there. So I would say that the first thing is that we've actually organized,

and this is motivated from the Spotify way of working. You should probably add that to the resource list if people are interested in learning and understanding Agile. Spotify, actually, of all organizations, has done some fantastic writing on Agile and how you organize teams around Agile, particularly within organizations. Cool. We'll add that to the notes. Yeah.

We adopted some of those core tenets from that way of working where we actually spun up what we call squads or engineering pods within our company. Even across all of those engineers, we don't have them all just working on the same thing at once and with the exact same focus at the same time. We actually have three different squads internally. Each one of them has a slightly separate focus. We have a back-end pod or squad. We have two front- end pods or squads,

and they'll be working on, you know, different features or different parts of the product at any given time, depending on, you know, what's important to us and what we're kind of prioritizing. And within a certain kind of range or a certain kind of balance, we try to give these pods autonomy to work in the way that makes the most sense for them. So there's certain things that are kind of a must and that we fix. We don't want every team using a different communication tool. It all has to happen in Slack, for example. Nor do we want teams using different project management tools.

All of that is driven through GitHub and Zen Hub. So there's that kind of core set of tools and systems, but we give them autonomy in terms of working in a way that makes most sense and organizing in a way that makes most sense for them as a team. And most of us just from our history as a company have ended up working in a very scrum centric way. But for one of the last features that we actually built, one of the teams was actually testing out more of a Kanban centric way of working. And for those who are listening that don't necessarily know what that is, it's a little bit more of a continuous flow of work rather than organizing work into two-week sprints or increments.

It's essentially just pulling from a backlog and saying, you know, I'm going to work on this and then this next and then this next kind of thing. And we're not going to have any of these be defined in terms of two-week sprints. We're just going to start picking them up as we have capacity and as we have time. Oh, interesting. Yeah. So it's a little bit more rapid pace of development. There's a lot less downtime between certain cycles and things like that. You also don't get as many strong KPIs, I think, in terms of like velocity and that predictability. But we tried that, I think, because we were trying to move very fast on something. That isn't to say you can't move fast with Scrum, but it's just a slightly different

way of working at things. It's pretty cool to see that they were even open to trying out new ways of working and things like that. For the default, though, most of our teams, like I said, end up working in very Scrum-centric ways. We think about the day-to-day of our engineers. A lot of them are participating actively in those Ag agile rituals and ceremonies that come around these methodologies. For Scrum, a lot of that is sprint planning.

You can think about sprint planning as, well, you have a two-week period and you want to get done X at the end of that two weeks. That's your goal for the sprint. Sprint planning is what work we're actually going to bring into those two weeks. How many issues? What are those issues going to be. It's based on obviously prioritization and the needs of the business, but that's actually a physical meeting where we sit down and we plan out what work we're going to be doing over the next two weeks before we actually start executing on it. Another really popular thing in sprints

is the idea of a retrospective. So coming together at the end of that, spending some time as a team and saying, what went really well? What do we want to improve? You know, what do we want to start doing? What do we want to stop doing? You kind of ask those meta questions of the team. And those hopefully really lead to opportunities for process change and process improvement. So our engineers are spending time in those two types of meetings. Like a lot of our engineers are also spending time on the creation and kind of scoping of new features. So one of the things, and this isn't necessarily connected to Agile,

but one of the ways of working that we found really effective is what we call a three-in-the-box model. And I say we because, you know, I shouldn't say we, we actually stole it from a customer, but it was really effective. So we use it. But a three-in-the-box model essentially is product, one representative from product,

one representative from engineering, one representative from design, and all three of those stakeholders come together at the beginning of a new feature or a new product in order to participate in some high-level estimation and scoping around things. And what that helps us do is avoid those situations where design has gone through something with product. You know, you spit out this, this project to your development team and they say, yeah, it's not going to happen. And you're like, what do you mean? We spent months doing this design and all of this work that went into this. And they're like, well, I can tell you right now that it's not feasible, right? Like technically there's this blocker or this is going to be a

huge hurdle that no one's thought of. And so we try to bring all those stakeholders together early and often in the product design process, the feature design process, so that we can get that input. And that's really just like a, you know, finger in the wind estimate at that point. We're not actually committing anyone to that, but it just helps us know when things aren't going to be possible or when we need to readjust our thinking about things. So our engineers are, you know, actively participating in a lot of those meetings as well. Um, and then, yeah, the rest of the time I think is, you know, spent, uh, spent, you know, actively doing work, actively coding, actively pair programming and working with each other on

things. So that makes sense. So when you're in that, in that sprint, uh, planning phase, um, does this sort of, is there sort of one person in the room who has Zen Hub open and they're basically taking notes in a sense, but they're setting that up? Or is it a thing where everyone has their laptops out with Zen Hub and they're all adding to some skeleton of the next sprint? How does that integrate with the product? It's a timely question because we're actually building a new feature in Zenhub to make that process a lot easier and make it a lot more efficient for teams.

So I'm glad you asked that. But today, really what happens is we typically are sitting around a table. Someone will put our Zenhub board up on a screen that's in the room, like a large TV screen or something like that. We'll open up our board. We'll go to our backlog pipeline. Hopefully, that has been groomed so that it reflects kind of the most up-to-date priorities of what the business is, meaning that the highest priority items are to the top of that. And then for teams that are working in a very sprint-centric or scrum-centric way, they typically know what their relative velocity is.

And when I say velocity, it's how many issues can they take on in that two-week time span. And we go through that backlog and we say, this is what we're going to commit to essentially and try to align that with the goals of what our sprint is. Now, one of the interesting things is that we actually maintain a global backlog of work. And so teams are kind of pulling out the pieces that are a little bit more relevant to them. So we go from that global backlog into maybe specific team or team specific sprints. But yeah, there's a lot of collaboration where usually it's someone from our product team that's kind of driving that conversation. But certainly the engineers are getting a lot of feedback in terms of like, well, I think this would be a really important issue to tackle in this sprint. And this issue is actually dependency for this other issue here. So

we have to do this one first. So we may as well prioritize it in this sprint so that we can work on the subsequent issues in the next sprint. Sometimes people are coming to the table and saying, hey, it's really important for this particular sprint that we include some type of work items or some type of issues that actually address technical debt. We don't want to get too far behind where we're just accruing and accruing and accruing technical debt that we have to pay off later, so let's involve some of this work in it. Sometimes it's developers that work with our customers too that are advocating for bug fixes and customer facing issues as well.

So people will be in that room and they'll say, hey, I was just on a call with X customer and this was pretty painful for them or we discovered this bug. We need to prioritize this within the sprint and be able to deliver this back to the customer kind of thing. So they advocate on the customer's behalf as well. Cool. That totally makes sense.

Yeah, I think this is something everyone should try. Every team should try, especially if you're just using Google Docs. This sounds way better. At the end of the day, yeah, I think one of the most important parts of Agile ways of working is visibility and transparency and for people on the team to be able to see what's actively being worked on. And there's obviously a lot of parts that come beyond that in terms of reporting board and understand what the priorities are that we're going to be working on and to be organizing work in that way through the lens of what's the highest priority of the business. Again, I've done a lot of talking today from a commercial sense, but

you're working on an open source project. What should be feedback from your contributors as a maintainer you need to prioritize in that project in order to get more people using it or in order to better the experience for everyone that could be using that. It's a really useful exercise to actually go through. Yeah, actually, quick interjection there. So if you're working on an open source project, you typically would want to expose your project plan. So this is actually something I maintain a project called Eternal Terminal. And someone actually created an issue. It's been a while, maybe about a year ago. They created an issue basically saying, what are you doing next? Can you tell me what to expect

in version N plus one? And so if someone's using Zen Hub, is there a way they can sort of export something to a markdown file that just sits in the repo. So other folks who don't have Zen Hub installed can still see the roadmap. Yeah, that's a big thing that we're working on right now, bringing that visibility to teams and the individuals that may not have a need to directly authorize Zen Hub or integrate with Zen Hub. Today, the best course of action, I think,

would be for that user to actually go to our web app because you don't actually have to download something into your browser and physically have a plug-in in order to see that. You can just do it in a really nice web app wrapper. But that would be the best way I would think to do that in the product in the way that it's least most supported today. But just touching on this topic because I think it's a really interesting one. This has been something I've been writing a lot about and I think there's been a lot

of reading that I've done on this topic as well where you know people look at really those core tenets of agile and say like well this doesn't really jive with how open source projects work and there's this like interesting at odds of agile and open source in some ways where I actually think a lot of open source projects would really benefit from more agile ways of working primarily from a visibility and transparency standpoint of what's going to be worked on. What I mean by that is, if you go look back on the Agile manifesto, it has this emphasis on individuals and interactions over process and tools, and working software over comprehensive

documentation. That's fine, right? I mean, like, you know, whether or not you want to be distributed or whether or not you want to be co-located is, you know, maybe a core consideration when it comes to agile. But how many open source projects have you seen that are, you know, where people are collaborating face to face? Like they're almost all distributed. It's not going to happen. That's actually one of the benefits of it.

You can work from anywhere in the world with anyone in the world and to produce something really cool and amazing. And then this concept of like working software over comprehensive documentation, like if you're not going to document what you're doing in an open source project, I think anyone's going to contribute to it. Like it's just going to be a mess of trying to find out where to add value and what to work on next. And I think people see those things and are like, well, because those concepts are at odds, you know, open source projects can't be agile. And I think that's just like a really shallow way to look at things, because I think open source can really benefit from adopting agile ways of working, you know,

helping to establish a process and common way of working so that everyone that wants to make a contribution to that project understands how to do that in the best way possible. Helping contributors know which issues are priority, for example. You know, how many times... That's hugely important. Right? I mean, you're gracious of any input that you get in an open source project. You're never going to be like, well, thanks.

I mean, that wasn't a priority issue, but I guess it's okay that you contributed. Like, you're always appreciative people are contributing and stuff like that. But what if people knew the top issues to work on are the highest value things that they could actually work on? People crave that, too. They're coming to a project and they're being like, I really want to add value here. I want to work on something important that actually pushes this open source project along. And being able to organize work in a task board, I think, and surface what those priorities are can be really important to people.

And the last thing, which directly maps back to what you mentioned, is providing visibility and surfacing updates to the community. Showing people what those next things are that we're going to be working on as a project. maps back to what you mentioned, is providing visibility and surfacing updates to the community. Showing people what those next things are that we're going to be working on as a project. Organizing work into epics, for example, that can be tracked so that you can visualize that in Zenhub at least on a roadmap view. That's been a really interesting use case for this new feature that we launched, the roadmap view, where we had a lot of open source maintainers come back to us and say, Hey, this is amazing for being able to show where we're going next in our project, because how else do you do that? Like in a wiki and a readme, like people are trying to

parse through a bunch of different texts and like read about the history of the project, but then where you're going next, there's no really solved way to do that. And so people using roadmaps for that and Zed have has been a really cool, really cool way to do that. And so people using roadmaps for that and Zen Hub has been a really cool way to give the community visibility of what's being worked on next. Yeah, that makes sense. Also, I imagine there's some integration with GitHub proper,

like in a sense, like GitHub has the tags. And so Zen Hub, I'm assuming, can sort of push high priority tags, push low priority tags. And so even if someone doesn't have Zen Hub installed, they're still going to get some rough information. Yeah, and that's kind of the beauty of the model too with integrating into GitHub.

It's like you pick up all the, essentially like the freebies of their product. And like milestones, for example, we repurpose for sprints. So if you know about GitHub milestones, you use them, we actually use that as the construct by which we help teams for sprints. So if you know about GitHub milestones, we use them. We actually use that as the construct by which we help teams build sprints. So even if you're not looking at a, you know, a Zen Hub board, you can still see the work that you've included in a milestone. We really heavily use, well, assignees, obviously, but labels as well. So if you're creating labels

inside of GitHub for like high priority, urgent, bug, won't fix, good first issue, stuff like that. Those are all labels that you can see on the Zen Hub cards on your board. But also, you know, if you're not using the Zen Hub board, you're not even using the product, you're still attaching labels to them. You can come and you can look at the issue list inside of GitHub, get a general sense for kind of where the priority issues are and what's being worked on by the team. So yeah, that totally makes sense. Yeah, there's there's a number of issues that I have in my open source project, right? Basically, I told the person, you know, submit the PR will help you, but, but, you know, we just we can't prioritize building this ourselves, right? And so, and so

that's, that's perfect example, we're having, you know, sort of marking that as, you know, looking for help, basically. That's an invitation to anyone who wants to get started in open source. Yeah, for sure. Cool. So is Zenhub hiring and do you do internships or just full time? Always looking for great engineers and great folks to join our team, even if you're not in engineering. Like I said, our engineering and product organizations are primarily based in Vancouver. So I think for most intranet chips, we tend to want to have people physically in the office because I think in a short amount of time, that's where you can benefit the most from being close to the team. We do those as well, though. And so if you're a co-op student and you're looking for your next co-op placement, the team and to kind of contribute in moving the mission along. And so a couple of different ways, if anyone listening is kind of interested, you can check out our careers page on our website. If you see an open role that you like, by all means, apply for it.

Feel free to mention my name or mention the podcast. Or if there is no open role, feel free to send me an email as well. If you mention the podcast, you get a 20% discount on your salary. 20% increase or I get a 20% discount. That's funny. Yeah. But if there isn't any open roles too, you can feel free to send me an email. It's my first name, Aaron at Zenhub.com. So yeah. Cool. So Aaron at Zenhub.com is your your email if folks want to apply for jobs, internships, ask you

sort of like one-on-one questions. And then do you have any social media? Are you on like Twitter or any of those platforms? Yeah. So best way to get in touch with me I think is through Twitter. And on Twitter, I'm at I'm Aaron Upright. First name, last name, I'm Aaron Upright. We can probably put a link to that

or actually add that to the show as well if people want to connect there. But yeah, we'd love to kind of chat with anyone there. We're pretty active in a lot of the discussions and Twitter feuds sometimes around agile because it tends to be a pretty polarizing concept. And so I'm always looking to get involved and get in touch with people there too. Cool. Awesome. Yeah. I can imagine it's from the little bit that I've like kind of read and pieced together. I've also been on Agile team. It sounds like one of these tabs versus spaces kind of things where, yeah, it starts these huge wars. But I think the important thing is not whether you use tabs or spaces, but that you sort of write a bunch of code, right? And in this case, the important thing is that you adopt, you know, one of these policies and you can sort of regulate and scope.

And you end up not with way too many people with nothing to do and also not with completely swamped. You can kind of plan ahead of it. Yeah. And hopefully at the end of the day too, like I said, you know, better working software for your customers or, you know, contributors on your projects or people who are taking advantage of it. And that's, I think, always a great goal to have in mind. And maybe a final kind of statement to leave on is the more that you can think through that lens about, you know, how is what we're doing and how we're organizing and how we're working adding value versus just another way to work. That's going to go away and be

replaced with something in two to three years. That's always a really helpful mindset to think through. Yeah. Yeah, totally. Cool. Thank you so much. I think this is what you were able to really do is take something that seemed almost like a, like a philosophy, like this very abstract thing, and break it down into components. And I think this will definitely motivate a lot of people. And if you want to try out Agile methods, you can just integrate with ZenHub. If you're using GitHub, you can integrate with ZenHub and try it out totally for free.

Is there a free trial for subscriptions or no? Yeah, there is. So for any project, even on a commercial sense, we give teams either a 14-day or a 30-day trial, depending on if you're using a growth plan or an enterprise plan. So definitely a period of try before you buy it. Cool. Yeah. So definitely try this out and get off just writing Google Docs. Trust me. I think I'm going to try it out myself. I think it sounds awesome. Awesome.

Guys, well, thanks so much for having me. I really appreciate it. This is fantastic. Cool. Thanks, Aaron. Have a good one. Okay. The intro music is Axo by Binar Pilot.

Programming Throwdown is distributed under a Creative Commons Attribution Share Alike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide attribution to Patrick and I and share alike in kind.