Discovering XP: A Tale of Two Startups
Discovering XP: A Tale of Two Startups
By
By Heidi Helfand
on •
Sep 7, 2023
“Are you ready to push the reset button?” That’s what Klaus Schauser, cofounder of AppFolio asked me when I joined him and others at his second startup, AppFolio. Klaus cofounded this startup with Jon Walker in 2006. I was the 10th employee and left at around 600 people. Appfolio went public in 2015 and is traded on the NASDAQ. I have always thought about Klaus’s “reset button” comment throughout the years. That reset button brought us a fresh start and an opportunity to do things differently from the first startup. Here’s how.
At the first company, we worked in component based teams, which later integrated and performed quality testing. You would build something, get a code review, and iterate back and forth. Integration with the other components followed, according to a schedule, and it would go off to testing, where you would iterate back and forth with testing and new builds. This process took months, something I experienced firsthand as one of the technical project managers who wrote the integration schedules.
Furthermore, developers would experience a lot of context switching. They’d work on something, send it off to code review and later to the manual testing force, and then start the next thing on their list. The problem was that oftentimes, once they were well on their way with the second thing, the first thing would have quality issues, and they would be pulled back to work on it for days or weeks. When that was finalized they’d go back to the second thing, and it would take a lot of time to get back into the flow of it due to the context switch. This is not a great developer experience.
Pushing the reset button at the second startup meant that we could avoid repeating this multi cycle process. We would work differently this time. We were on a quest for shorter feedback loops and a better lifestyle for our teams.
Our founders knew they needed to move quality earlier in the cycle, have robust automated test coverage, and continuous (not delayed) integration. They wanted much shorter feedback loops from idea to customer. They wanted to bring in expert software engineers to teach us how to work differently so we could easily shake off the old ways of working from the previous startup. This is where Ross Hale, now the CEO and founder of Artium, entered the scene.
Ross and other key engineers he brought along taught our early team extreme programming (XP), test-driven development, and continuous integration. This was a big change from the weeks or months-long integration we lived through at the first startup.
I was responsible for onboarding engineers in these early days and the cool thing was that Ross and the other consultants seamlessly joined into our team and our work, as opposed to taking us into a conference room or something to sit through multiple day-long workshops. We didn’t have time for any kind of abstract workshop that we’d have to figure out how to apply later. The clock had started ticking, and we needed to ship the first version of AppFolio Property Manager, and fast.
So Ross and friends joined our team, where they built the software together with us while at the same time teaching us better and more modern ways of building software. For example, we’d have one AppFolio engineer at work with Ross and another AppFolio engineer with another consultant. They pair programmed. This brought individualized learning on how to write robust software with tests, earlier detection of defects, and a collaborative, human approach to working. Every few days, all engineers would switch pairs. This switching ensured that the knowledge was spread amongst the team and everyone had a chance to work with our XP mentors.
In addition, Ross and his friends worked with our engineers and set up continuous integration systems so that when building the product, we would also write automated tests. For instance, when you developed something and checked it in, you could see if the automated tests passed (green build) or failed (red build). We would aim to always have a green build that we could give to customers for testing. And that’s what we did. We began to know the customers by name. This was the ultimate reset button as compared to the sometimes yearly cycles at the first startup, where customers felt like they were a world away.
At some point, Ross and the other senior engineers with him left our teams. It was after several months. I don’t recall exactly since it was all so natural and seamless. We didn’t need them anymore. We were releasing to our growing customer base very frequently, and kept pairing and switching pairs as we grew from one to twenty-five teams, the point at which I left AppFolio to pursue other opportunities.
It’s years later, and I’m thrilled to be reunited with Ross and working with the awesome team members at Artium. I’ve lived through what this client experience is like. As a former VP of Engineering, I understand the challenges and pressures associated with building a thriving team experience while at the same time meeting sometimes quite challenging deadlines. If you’d like to learn more, reach out, and we can have a call - linkedin.com/in/heidihelfand
In my next post, I’ll share my experience with scaling XP through Dynamic Reteaming, the title of the book I wrote, published by O’Reilly. That details many of the XP practices and team change patterns that we experienced at AppFolio as well as at other very successful software companies.
by Heidi Helfand,
SVP of Strategy and Innovation at Artium
“Are you ready to push the reset button?” That’s what Klaus Schauser, cofounder of AppFolio asked me when I joined him and others at his second startup, AppFolio. Klaus cofounded this startup with Jon Walker in 2006. I was the 10th employee and left at around 600 people. Appfolio went public in 2015 and is traded on the NASDAQ. I have always thought about Klaus’s “reset button” comment throughout the years. That reset button brought us a fresh start and an opportunity to do things differently from the first startup. Here’s how.
At the first company, we worked in component based teams, which later integrated and performed quality testing. You would build something, get a code review, and iterate back and forth. Integration with the other components followed, according to a schedule, and it would go off to testing, where you would iterate back and forth with testing and new builds. This process took months, something I experienced firsthand as one of the technical project managers who wrote the integration schedules.
Furthermore, developers would experience a lot of context switching. They’d work on something, send it off to code review and later to the manual testing force, and then start the next thing on their list. The problem was that oftentimes, once they were well on their way with the second thing, the first thing would have quality issues, and they would be pulled back to work on it for days or weeks. When that was finalized they’d go back to the second thing, and it would take a lot of time to get back into the flow of it due to the context switch. This is not a great developer experience.
Pushing the reset button at the second startup meant that we could avoid repeating this multi cycle process. We would work differently this time. We were on a quest for shorter feedback loops and a better lifestyle for our teams.
Our founders knew they needed to move quality earlier in the cycle, have robust automated test coverage, and continuous (not delayed) integration. They wanted much shorter feedback loops from idea to customer. They wanted to bring in expert software engineers to teach us how to work differently so we could easily shake off the old ways of working from the previous startup. This is where Ross Hale, now the CEO and founder of Artium, entered the scene.
Ross and other key engineers he brought along taught our early team extreme programming (XP), test-driven development, and continuous integration. This was a big change from the weeks or months-long integration we lived through at the first startup.
I was responsible for onboarding engineers in these early days and the cool thing was that Ross and the other consultants seamlessly joined into our team and our work, as opposed to taking us into a conference room or something to sit through multiple day-long workshops. We didn’t have time for any kind of abstract workshop that we’d have to figure out how to apply later. The clock had started ticking, and we needed to ship the first version of AppFolio Property Manager, and fast.
So Ross and friends joined our team, where they built the software together with us while at the same time teaching us better and more modern ways of building software. For example, we’d have one AppFolio engineer at work with Ross and another AppFolio engineer with another consultant. They pair programmed. This brought individualized learning on how to write robust software with tests, earlier detection of defects, and a collaborative, human approach to working. Every few days, all engineers would switch pairs. This switching ensured that the knowledge was spread amongst the team and everyone had a chance to work with our XP mentors.
In addition, Ross and his friends worked with our engineers and set up continuous integration systems so that when building the product, we would also write automated tests. For instance, when you developed something and checked it in, you could see if the automated tests passed (green build) or failed (red build). We would aim to always have a green build that we could give to customers for testing. And that’s what we did. We began to know the customers by name. This was the ultimate reset button as compared to the sometimes yearly cycles at the first startup, where customers felt like they were a world away.
At some point, Ross and the other senior engineers with him left our teams. It was after several months. I don’t recall exactly since it was all so natural and seamless. We didn’t need them anymore. We were releasing to our growing customer base very frequently, and kept pairing and switching pairs as we grew from one to twenty-five teams, the point at which I left AppFolio to pursue other opportunities.
It’s years later, and I’m thrilled to be reunited with Ross and working with the awesome team members at Artium. I’ve lived through what this client experience is like. As a former VP of Engineering, I understand the challenges and pressures associated with building a thriving team experience while at the same time meeting sometimes quite challenging deadlines. If you’d like to learn more, reach out, and we can have a call - linkedin.com/in/heidihelfand
In my next post, I’ll share my experience with scaling XP through Dynamic Reteaming, the title of the book I wrote, published by O’Reilly. That details many of the XP practices and team change patterns that we experienced at AppFolio as well as at other very successful software companies.
by Heidi Helfand,
SVP of Strategy and Innovation at Artium
“Are you ready to push the reset button?” That’s what Klaus Schauser, cofounder of AppFolio asked me when I joined him and others at his second startup, AppFolio. Klaus cofounded this startup with Jon Walker in 2006. I was the 10th employee and left at around 600 people. Appfolio went public in 2015 and is traded on the NASDAQ. I have always thought about Klaus’s “reset button” comment throughout the years. That reset button brought us a fresh start and an opportunity to do things differently from the first startup. Here’s how.
At the first company, we worked in component based teams, which later integrated and performed quality testing. You would build something, get a code review, and iterate back and forth. Integration with the other components followed, according to a schedule, and it would go off to testing, where you would iterate back and forth with testing and new builds. This process took months, something I experienced firsthand as one of the technical project managers who wrote the integration schedules.
Furthermore, developers would experience a lot of context switching. They’d work on something, send it off to code review and later to the manual testing force, and then start the next thing on their list. The problem was that oftentimes, once they were well on their way with the second thing, the first thing would have quality issues, and they would be pulled back to work on it for days or weeks. When that was finalized they’d go back to the second thing, and it would take a lot of time to get back into the flow of it due to the context switch. This is not a great developer experience.
Pushing the reset button at the second startup meant that we could avoid repeating this multi cycle process. We would work differently this time. We were on a quest for shorter feedback loops and a better lifestyle for our teams.
Our founders knew they needed to move quality earlier in the cycle, have robust automated test coverage, and continuous (not delayed) integration. They wanted much shorter feedback loops from idea to customer. They wanted to bring in expert software engineers to teach us how to work differently so we could easily shake off the old ways of working from the previous startup. This is where Ross Hale, now the CEO and founder of Artium, entered the scene.
Ross and other key engineers he brought along taught our early team extreme programming (XP), test-driven development, and continuous integration. This was a big change from the weeks or months-long integration we lived through at the first startup.
I was responsible for onboarding engineers in these early days and the cool thing was that Ross and the other consultants seamlessly joined into our team and our work, as opposed to taking us into a conference room or something to sit through multiple day-long workshops. We didn’t have time for any kind of abstract workshop that we’d have to figure out how to apply later. The clock had started ticking, and we needed to ship the first version of AppFolio Property Manager, and fast.
So Ross and friends joined our team, where they built the software together with us while at the same time teaching us better and more modern ways of building software. For example, we’d have one AppFolio engineer at work with Ross and another AppFolio engineer with another consultant. They pair programmed. This brought individualized learning on how to write robust software with tests, earlier detection of defects, and a collaborative, human approach to working. Every few days, all engineers would switch pairs. This switching ensured that the knowledge was spread amongst the team and everyone had a chance to work with our XP mentors.
In addition, Ross and his friends worked with our engineers and set up continuous integration systems so that when building the product, we would also write automated tests. For instance, when you developed something and checked it in, you could see if the automated tests passed (green build) or failed (red build). We would aim to always have a green build that we could give to customers for testing. And that’s what we did. We began to know the customers by name. This was the ultimate reset button as compared to the sometimes yearly cycles at the first startup, where customers felt like they were a world away.
At some point, Ross and the other senior engineers with him left our teams. It was after several months. I don’t recall exactly since it was all so natural and seamless. We didn’t need them anymore. We were releasing to our growing customer base very frequently, and kept pairing and switching pairs as we grew from one to twenty-five teams, the point at which I left AppFolio to pursue other opportunities.
It’s years later, and I’m thrilled to be reunited with Ross and working with the awesome team members at Artium. I’ve lived through what this client experience is like. As a former VP of Engineering, I understand the challenges and pressures associated with building a thriving team experience while at the same time meeting sometimes quite challenging deadlines. If you’d like to learn more, reach out, and we can have a call - linkedin.com/in/heidihelfand
In my next post, I’ll share my experience with scaling XP through Dynamic Reteaming, the title of the book I wrote, published by O’Reilly. That details many of the XP practices and team change patterns that we experienced at AppFolio as well as at other very successful software companies.
by Heidi Helfand,
SVP of Strategy and Innovation at Artium