My Extreme Programming / Agile career journey

Logo of the University of Calgary above an Extreme Programming process diagram. Arrow pointing right to a ThoughtWorks logo and another arrow after that pointing to a Spotify logo.
Jason’s career journey

The journey starts with Extreme Programming

A fellow student, Eric had pointed me to an article by Ron Jeffries on, probably the original version of this one. It was quite shocking as it challenged what we had previously learned about how generally engineering projects were run and what we were learning specifically about software engineering (I believe at the time we were being introduced to the Personal Software Process). This led to a lot of discussions on UseNet (comp.object, and Ward’s Wiki (aka The Portland Pattern Repository aka the first wiki), and personal experimentation with TDD and simple design.

In 2000, my advisor Dr. Giancarlo Succi and his colleague Dr. Michele Marchesi at the University of Cagliari organised the first Extreme Programming Conference XP2000 which I attended. Martin Fowler has a nice summary of the conference here.

The ThoughtWorks Era

After about a year in ThoughtWorks Chicago, I transferred to ThoughtWorks Calgary. After about a year in Calgary, there was an opportunity to do a 2-week engagement in Melbourne, Australia which I signed up for. That engagement extended again and again, and I ended up transferring to ThoughtWorks Australia, mostly based in Sydney.

Most of my particular style of Agile is influenced by what I learned at ThoughtWorks. The main themes that come to mind:

  • Automated builds, configuration management/version control, continuous integration. This was pre-Maven times so we were doing custom Ant builds. Git didn’t exist. I was mainly using CVS and eventually Subversion as counters to ClearCase. I also became a committer on CruiseControl, the first Open Source continuous integration server.
  • Java, OOP, TDD, simple design;
  • Basic rituals: daily stand-ups, planning, retrospectives, and what we called “showcases”. I tried to capture all my daily standup experiences in this article;
  • Patterns of Enterprise Application Architecture / Enterprise Integration Patterns. I think these books are a pretty good summary of the kinds of custom development we were involved in back then.
  • Inception (aka Quickstart) (aka how to rapidly kick-off new projects while still having sufficiently coherent goals and context). Jonathan Rasmussen has a simple version of an Inception Deck here (and in his Agile Samurai book) which is pretty close to an older version that Rob Gibson originally created at ThoughtWorks Australia. Later on, we shifted to using a set of Inception Method Cards (inspired by IDEO’s Method Cards) to select and dynamically shuffle-in activities as relevant. Watching Luke Barett during an Inception is where I initially learned the technique that Jeff Patton later called User Story Mapping.
  • Agile / digital transformation using role model teams. Co-source a team or set of teams (50% ThoughtWorks, 50% local) on a reasonably significant delivery to demonstrate what good looks like. Use the role model team(s) as an incubator to create even more role model teams and expand from there, including addressing broader organizational constraints that inevitably pop up. This is essentially the “model line” concept that the Lean community talks about.

I helped run a couple of XP / Agile / Lean / Kanban user groups in Sydney: The Sydney XP Activity Club (SyXPAC) (originally started by Dr. Neil Roodyn) and later on the Sydney Limited WIP Society.

During all of this, I was helping to review XP / Agile books, probably from requests via the Extreme Programming mailing list (originally on Yahoo! Groups). You might find me in the acknowledgement sections for 2000s-era Agile books.

Also, during all of this, I was blogging a lot. Initially on JRoller, then Blogger.

The Spotify Era

The main themes that come to mind about my time at Spotify:

  • Hypergrowth → aligned autonomy. On average, the area I was working with doubled every year and there was on average some level of re-organization required every 6 months or so. This led to me thinking that stable identity needed to be at a higher level, the Tribe, rather than Squads that were more volatile. Aligned autonomy seemed to be the consistent theme over the years.
  • Structure should follow strategy → BAPO. Hoke introduced me to the BAPO model which is now my go-to way to approach organisational design.
  • OKRs → strategy deployment → persistent models. Recognizing OKRs as a translation of hoshin kanri (aka strategy deployment) and that strategy (aka a more persistent model) should obviously come before strategy deployment. I wrote down some of my thoughts on OKRs and my issues with cascading goals.

I also presented 3 insights from 4 years at Spotify at YOW! back in 2019 which covers some of this.

To be continued…



Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl