Getting started with the Spotify iOS SDK

How to make the Spotify Model Work for you

https://codingsans.com/blog/spotify-model

Here is a link to my interview with the podcast Level Up Engineering on how to make the Spotify Model work for you and your company.

The Spotify Playbook

Update: This article has been turned into a book titled – Competing With Unicorns. Check it out if you would like to learn more about Spotify and how they work.

===

Three years ago, I packed up my family, moved halfway around world to Stockholm, Sweden, to join a then relatively unknown music streaming service called Spotify. Since then, I have left Spotify, returned to the world of corporate IT, and am amazed at the differences in how we work.

At first I chalked this up to Spotify been a cool hip tech startup – which would naturally tilt it more towards a Silicon Valley way. Except that Spotify has moved beyond being a small startup, while somehow maintaining the speed and agility you’d never expect from company of it’s size.

In this essay I would like to explain how Spotify works, why it is different, and why I believe its style of work will continue to grow in popularity. Because as software continues to eat the world, the advantage is going to those who how to make it. And right now Spotify, and other tech companies, is winning this hyper competitive war for talent; in to no small part due to it’s culture, management practices, and the way it works.

Empowerment and trust

If I had to pick two words to describe how Spotify is different it would be these: empowerment and trust. Spotify empowers and trusts its people to an extent I have never seen a company do before.

It’s small things – like having administrative access on your computer and being able to book your own travel. To big things – like choosing how you and your team would like to work, as well as having access to the all company’s financials.

Why so much empowerment and trust? Because Spotify believes that:

The more information we share with our people, the better decisions they are going to make.

But it goes beyond that. Spotify doesn’t only do this purely for better decision making purposes. It empowers and trusts its people because it believes that is how you attract the best talent. And the people it needs enjoy working this way.

Some of this is Swedish culture (Swedes are big on consensus building and moving cohesively as one). But it’s also a style of work and that has deep roots here in the Nordics. The Scandinavians believe that the best work comes from those who get to make their own decisions. Management does play a big role – but it’s mostly by removing barriers and then getting out of the way. Which is why the Nordic countries were among the first to adopt Agile. For them it was just a very natural way to work.

That captures the spirit of how Spotify likes to work. But it still doesn’t explain the how. Let’s dive a little deeper now and look at how some of the practices that Spotify uses to empower teams build trust in the organization.

Small self directed teams

Pretty much everything in Spotify revolves around the small self directed team. Or as we like to call them – squads.

• Spotify teams
• Sit together
• Get their own squad areas
• Set their own goals and priorities
• Decide how they would like to work
• And are 100% responsible for the work they produce

You can think of squads more or less as typical cross functional Agile teams. Except we don’t use Scrum Masters or Project Managers. The team creates and manages the work themselves – sometimes with the help of an Agile Coach.

And the way squads know what to work on, is that each squad is given a mission.

Missions and Teams over Projects and Budgets

Spotify empowers their teams by giving them missions. What’s a mission? A mission is a long term goal, aspiration, or belief. That if we only did this one thing, we could really make the world a better place for our customers.

For example, if you were on my old team, Delorean, our mission would have been to make the world of music a better place in the car. Or if you were on the the TV Platform team, it might be enriching gaming experience by bringing music to TVs and consoles.

Missions are different than traditional projects in several key ways.

For one, missions are longer term. Unlike projects, missions don’t have a definite beginning nor an end. They simply continue until the mission is met, or no longer important.

Missions based teams also stay together. Why break up the team at the end of a project just when they’ve started to figure things out?

The third big difference is hand-offs. Spotify teams don’t hand off their work to someone else for maintenance. They own it. Which means if something goes wrong in the middle of the night, they know they are the ones who are going to be paged.

So those are some differences in terms of time horizons and incentives.

Project	Mission
Short term	Long term
Clear beginning and an end	Continues as long as required
Team disbands upon completion	Team stays together
Hands off their work to others	Maintains and supports their work themselves
Has a budget	The team is the budget
Has a project manager	Has no project manager
Schedule is primary	Schedule may, or may not, be primary
The focus is the plan	The focus is the work

• There is always a budget. It’s just annual. Not tracked at the project level.

But what really separates missions from projects are budgets. Or lack thereof.

Spotify doesn’t allocate budgets to missions in same way traditional companies do to projects. The team is the budget at Spotify. That’s all they track. Head count. Whereas the budget is what gets tracked, and is the focus, on traditional projects. One invests and supports the team and mission (long term). The other is more focused on the budget and the project (short term).

By eliminating the drama that comes with traditional project budget, mission based teams are better able to focus. By not constantly having to look over their shoulder, and report and track, they can instead focus on their missions, and think of better ways of serving their customers.

One is a distraction. The other other is not.

This is big reason why Spotify, and tech companies, execute circles around their more traditional counterparts. They have fewer distractions and are better able to focus purely on the work.

No doubt, Agile has come a long way with regards to helping companies ignoring traditional project management maxims.

But Spotify, and these other tech companies, take things a step further. By eliminating the project and budget all together, and by focusing purely on the mission and the team, they enable their teams to go much much faster. While simultaneously empowering and trusting the team.

Which is why startups value impact over plans.

Impact over plans

To understand why no one cares if your project is plus or minus 10% at a tech company, you need to understand what startups value, and how this affects their budgeting.

Money to a startup is like fuel. It’s there to be spent. Startups need to exit the earth’s orbit, and demonstrate that what they have built is so great, that it is worth giving them another round of financing to get to the next level. And once they get that round they are set. They have their money. They have their runway. It’s off to the races.

So when it comes to measuring performance, they don’t focus on minutia of a six month project. They measure the impact instead.

How many signups did our last release get
How many more active users this month are using the product
How much more music are people listening to in the car

Now, obviously, traditional companies value speed and impact too. But if you watch their actions, you’ll see they value something more. Something called meeting expectations.

It all starts at the top. The CEO has to set, and hopefully meet, expectations every quarter around corporate earnings. To meet these earnings the company then creates an annual budget. From this annual budget flow the projects. And from these projects flow your budget. And that’s your plan.

Now because the expectations have been set, the one thing you never want to do is blow your budget. That’s pretty much all that counts.

So while it’s nice that you’ve solved world peace, cured cancer, and discovered some wonderful new innovative product, I am sorry. Your project will still be seen as a failure. You exceeded the budget and failed to follow the plan.

I am exaggerating a bit here. But not by much. This is what traditional companies value. This is what they measure. And this is what they track. Which is why being plus or minus 10% on your traditional project is such a big deal at a traditional company, while no one at a startup will care.

Tech lead

For most of its history, Spotify has been a tech, product, and design lead company. That means people from engineering, design, and product are in leadership positions at the company. And you feel it almost immediately when you join the company.

For one, you don’t have to fight for good computers or machines. Engineers know what a difference a good monitor and computer can make. So they don’t skimp. No more bad equipment.

Secondly, there is no more crappy enterprise software. Because the leaders of the company have technical backgrounds, they aren’t sold by the slick marketing and sales teams from the commercial vendors. Instead, you get to use the same tools you would use if you were working on an open source project at home.

You also see way more investment in internal systems and infrastructure. Spotify, Facebook, and Google all invest in countless internal systems to make the lives of their teams easier. These squads, focused on developer productivity, take on many of the hard technical challenges we as engineers on squads would love to solve, but never seem to have the time.

Bets

One challenge with a whole bunch of teams working independently on missions is that periodically you need to coordinate and do something bigger. Something that involves multiple teams. For that, Spotify uses the bets.

Bets are big, prioritized, cross cutting company initiatives that require multiple parts of the company to get things done. Usually numbering no more than 10-15 at a time, the rule of thumb is that someone comes to you working on a bet, you pause your work and help them out. If two groups come to you with different bets, the higher priority one wins.

It’s not a perfect system, but it’s fast and flexible. Teams usually know in advance who needs help and when. It gives them the flexibility to plan and work on longer term missions, while simultaneously helping the company out. And some teams just work on bets continuously. Because there is always another hill to climb.

Big trust

We already touched on how Spotify issues a lot of trust to their small empowered teams through missions and squads. But here are a few other examples of how Spotify moves quickly while not sweating the small stuff.

Self serve kiosks
If you need a new keyboard, mouse, adapter, phone cable, or thumb drive, Spotify lets you help yourself. There are all available, 24/7, via self serve kiosks that are continuously stacked with this stuff. No need to fill all the that paper work out. Just take what you need. And don’t be wasteful.

Booking travel
Need to travel for work? Can’t seem to get the flight you’d like? No worries. Book it yourself. We trust you. They are rules of thumb around when you can and can not book business class. But basically we want you to be happy. So book whatever makes sense and take the flight you want.

Access to data
If you ever want know how many monthly active users we have, or how many iPhone installations we have versus Android, that information is available to you.
If you can’t find it on one of our many dashboards, we will help you find the right person to ask. You basically have access to all the information in the company. Just ask and you will most likely receive.

Default to open

By default, Spotify is open with its ideas, leadership, and data. While this can be overwhelming at first, it’s refreshing to see how transparent a company can be with its information.

For example, Spotify was the first place I had been where the leaders sent all the material and notes they used for their offsites, to the entire company after. They even videoed the whole thing.

This was amazing. Because now as a rank and file employee, you had access to all the same information your boss was getting from the CEO. You could also see the same presentations and discussions leaders were having at the highest level. That was empowering.

I am sure not everyone watched all these videos but I did. And they made me feel very included and a part of the company in a way that I had never felt before.

This happens for all sorts of things: management meetings, townhalls, and weekly check-ins. You name it. You always knew what was going on, because when it came to information sharing the default was always open.

Swedish based

I could write a book on Swedish culture. Suffice it to say it’s different then what we practice here in North America.

Being a Swedish based company, culture affects Spotify in several interesting ways. For one, it is very much a consensus building culture. Spotify emphasizes hearing everyone’s voice, not rushing decisions, and getting group buy in. That doesn’t mean it is slow. Decisions do get made. It’s just in more of a consensus based style, with less direction coming from a single individual or leader on the team. Spotify really values diversity in decision making.

You also can’t really tell people what to do in Sweden – especially if you are the boss. This drives non-Swedes mad who are used to more command and control styles of structure. In Sweden, the relationship between the employee and the boss isn’t as top town as it is in North America. Servant leadership is a real thing at Spotify, and as a manager you are expected to serve your team and help people out.

Swedes also value above all things bra stämning or good working environment. Team cohesiveness is very important in the Swedish workplace. So there are many cultural norms like fika (structured coffee breaks), eating together (smörgåsbord), and generally hanging out and getting to know one another. This informal bonding helps create a good workplace and environment for the team.

But it’s not all about being nice and not getting work done. People at Spotify work hard. Not necessarily in the way of longer hours like we do in North America. But more in terms of responsibility. Spotify works hard to take away every excuse you and your team have for not doing your best work. And with that comes an expectation that you are your team will deliver. That’s really their secret sauce. Because once all the barriers are removed, it’s really just you and the work. No excuses left.

Needless to say, it’s very different than in North America where there is often a single decision maker, decisions come from the top, and you often have little say or control in how you work.

Summary

So those are some high-level thoughts about what work is like at Spotify, and some of the things they do that are different. We’ve only scratched the surface, and it still doesn’t fully capture what it’s like working there, and how much easier, and more fun it is to work there.

All I know is that empowering and trusting your people is hugely liberating. I took a 50% pay cut to work at Spotify, and I would gladly do so again because I had such a good time working there.

And coming from someone like me, an author, full time dad and husband, who religiously guards his time, that is a pretty neat trick. Spotify was able to get more out of me than any other company had before. And this essay is my attempt at explaining how they did that.

And all I know is it has something to do with how they work. And if we can tap more of that, we all might just enjoy work and life a little bit better.

Launching iMessage on Spotify

This week, a project me and my friends here in San Francisco have been working on finally went live. The Spotify iMessage App Extension.

This app extension let’s you search for songs, send them to friends, and then play short 30 sec clips.

I know it doesn’t look like much – but it was a lot of work! You’ve got just the basic functionality of the App itself. You’ve got error handling. How to handle going off line. Analytics. Authorization. The expand and collapse interaction of iMessage. Nasty bugs. And the requirement to support both portrait and landscape orientations too (thank you UIStackView).

You don’t launch something like this without a lot of help. And I want to thank:

• Saurabh Verma
• Samuel Kohonen
• David Ehrmann
• Matt Montag
• Sonny Chen
• Jon Yeo
• Kevin Mindeguia
• Kristian Lindwall
• Jacob Schulman
• Lisa_Kleinsorge
• Kevin Hutchinson
• Alva
• Daniel Persson
• Dan Flemming

And my partner in crime, with whom this all started as a Spotify hackweek project, Joseph Baena.

Without them none of this would have worked.
So thank you team.
Onwards and upwards.
Looking forward to iterating more on this great platform!

Oh. And we are hiring! So if you are a mobile iOS or Android engineer, and have always wanted to work a great team in the great San Francisco Bay area, go checkout our job listings here and see if you’d like to join the band.

Links

• TechCrunch – Spotify launches an iMessage app for texting songs to friends
• Engadget – Spotify’s iMessage app shares clips of your favorite songs
• The Verge – Spotify’s new iMessage app lets you share 30-second song previews with friends
• The Next Web – Spotify finally lands in the iMessage App Store
• Macrumors –
  Spotify Introduces iMessage App With Search Function for Sharing Music With Friends
• Billboard – Spotify iMessage App Allows Users to Share Songs Without Leaving the Conversation
• Product Hunt

XP Days at Spotify

Today I had the pleasure of hosting the second day of a two day XP style workshop with some incredible developers at Spotify. Here’s what we did.

Build something fast!

We kick things off by asking the class to build a Reverse Polish Notation (RPN) style calculator. In 10 minutes.

We do this partially by design – to create a little stress. But it’s also an ice breaker. Just to verify everyone’s machine is up and running. As well as gauge the experience level of the class.

We then have a discussion about what some of the challenges are when building software. As well as what quality means, and how we can shoot for that in our software.

The birth of XP

This then segues into the birth of XP. Here I share Kent and Ward’s original vision of what XP was. Talk a little about the C3 project. And basically explain the XP attitudes behind if certain things are hard, we are going to continuously do them, all the time. Testing, integration, pairing, design, etc.

I also draw the cost of change curve and share how Kent wanted a way to develop software, such that the cost didn’t increase exponentially over time.

Elephant Carpaccio

Partly because smaller stories are a good idea, and partly because it helps them with the project they do on day two, we then do an Elephant Carpaccio story slicing exercise.

https://docs.google.com/document/u/1/d/1TCuuu-8Mm14oxsOnlk8DqfZAA1cvtYu9WGv67Yj_sSk/pub

This is great because it reminds people about what makes stories valuable in the first place, while also giving advice on how to slice. Basics, but really good stuff for people who may not have read or had any story training.

TDD together

This is where we formally introduce TDD, and revisit the RPN calculator we built at the beginning of the course.

As a class, I start with one other person, showing them the mechanics behind writing the test first, making it pass, and then … sometimes refactoring. Sometimes I don’t refactor, just to let the duplication build up and save for conversation later.

But we do this as a group, and it gives students a nice intro on a codebase and a problem they already know.

Refactoring

Something that’s surprised me as a middle aged programmer (cough) is how many people still haven’t read Martin Fowlers seminal book on refactoring. I have a lot of fun with this.

Refactoring, even in really tight circles of programming, is still a very misunderstood term. Usually it just means rewriting code. But people don’t appreciate always that when you are refactoring you aren’t adding any new value. You are only improving the existing design.

So I really hit home that the reason why that word appears in a menu at the top of your favorite ID is because of this book. And then I ask how people refactor without unit tests.

It’s a trap of course. Because you can’t. But a lot of people still do. So we talk about that.

So that’s day one. And during the day we also sprinkle in discussions about YAGNI, production readiness, and other XPisms and attitudes.

Code me a game

Day two is all about putting TDD, unit testing, refactoring, continuous integration, collective code ownership, and pairing all into practice. In teams of four, the class then goes about building a text based adventure game.

Text based games are great for learning TDD. They are fun, most people understand how they work, and they don’t contain a lot of hairiness. But they contain enough hairiness to give a taste of what applying TDD in the real world is like (like how do you handle all those input output streams?).

We have a few rules for the text based game we are going to build.

1. No production code without a failing unit test.
2. No code not written in pairs.
3. Refactoring happens continuously while the code is being developed.
4. Check in early and often.

It’s really fun seeing how teams of x4 tackle handling a new code base. We also have the challenge that many people come from different parts of the world. So everyone has their own keyboard which can make pairing tricky.

But people overcome. We have lots of discussion about how to test, how to design, and how to tackle all the hairiness that seems to come with coding, even on a simple text based game.

We usually do x3 one hour iterations. With a demo, code review, and discussion at the end of each.

We also track number of commit, number of stories, and code coverage.

After three to four hours people are pretty pumped and exhausted. We then sit back and reflect on what we’ve learned.

It’s really interesting watching people try TDD for the first time. On the surface, when you see other people do it, it looks really easy. But it’s not. At least at first. It’s hard. It goes against everything not only everything you’ve been taught in school. It also not the natural state for people who are just used to hacking.

But once people get it, you can see a light go one. They design their code differently. They find they need less code. And it takes a lot of the guesswork away. They only end up creating what they need. And for many that’s a revelation.

Of course TDD is only one leg of the XP stool. And all the other practices also come into play – particularly pairing. People often ask how do you keep the discipline up. You play a big part of that I say. But your pair can help you too.

Insights, Actions, and Histories

We wrap up the day with Insights, Actions, and Mysteries. Here we ask people what they learned, things they want to do, and things we still wonder about.

Big insights today were the awesomeness of pairing (you can learn a lot working with someone else). Actions were YAGNI – try hard not to over engineer. And mysteries were things like how fast to move when doing TDD vs going really slow and gearing down to really really small tests.

Overall it was a great day. I always learn as much if not more than the attendees. And this was a great group to work with. See you out there!

Launching Spotify on the Sony Playstation

Delivering a new product to 60 million users

Last week was an exciting one for me and my team here at Spotify. We launched the Spotify player on the PS3 and PS4 and brought the Spotify music experience to over 60 million PlayStation users. Here are some notes on how we did it.

How it was run

This was a big project – one that spanned many tribes and cut right across the entire organization. Marketing, sales, licensing, distribution, all of tech. It was also very distributed with Sony and Spotify teams spread across San Francisco, London, Stockholm, Tokyo, and New York.

Spotify doesn’t have project managers. But for this project we did appoint someone to play the role of an overall programme manager. This was key because there were a lot of moving parts, and someone needed to help coordinate.

We did several onsite visits. Many teams came to Stockholm. We went to Tokyo. And there were a lot of early morning/late night calls (not to mention a tonne of email and Slack chats). Every Friday we also had a standing lunch where anyone interested could get an update on where things were at along with the current problems we were facing.

My team was responsible for building the app that would run the Spotify player on the PS3 & PS4. Four developers, three QA, a designer, a Product Owner, and me the coach.

Challenges we faced

Spotify doesn’t normally do projects. Instead we prefer giving teams a goal, and then letting them decide when best to release. We didn’t have that luxury. Sony’s old music application was due to shutdown at end of March, and we needed to be ready with our player to take it’s place. So in that sense, this was a very traditional project with a really hard deadline.

How we overcame

We ran this project like a typical Scrum project, only we quickly resorted to a kind of code and fix mentality that often comes when you realize you have too much to do and not enough time.

In addition to playing coach I also played the role of project tracker (tracking things like our team velocity and keeping an eye on overall deadline). For pretty much the entire project things didn’t look good. We had too many features. Not enough time. Typical project stuff.

Spotify’s approach to situations like these is to leave the team alone and let them sort things out for themselves. If they want extra help it’s there. But really it’s up to the team to solve their own problems.

What was interesting on this project was that the team (mostly the dev’s) didn’t initially want any outside help. Even when it became apparent that there was too much to do.

There was an inflection point in the project were senior management insisted we take someone else on (a fourth developer). This turned out to be a very good choice. Our new addition ended up making an invaluable contribution and we wouldn’t have made it without him.

But this leads to an interesting question for management – how far should you trust the team, and how do you know when to step in and ‘overrule’ their judgement. It’s not an easy call.

Finally, and perhaps most importantly, the one thing we did have going for us is we were the #1 priority project for the entire company. This meant that whatever we wanted – we got. A project this cross cutting and of this size can’t be handled alone. And the entire company was needed to pitch in. So when we needed people, meeting rooms, resources, or just decisions, people on the team just pulled out these ‘magic’ project cards and things got done. It was a fun way to work. But one you must be careful not to abuse.

Finally, this project required a lot of overtime, weekend, and late nights to bring across the finish line. We made it. We delivered. But there was definitely a human cost in terms of time, capital, and technical debt.

The launch

Now for the fun stuff! Here are some pictures of the war room on launch day.

There was a lot of coordination and monitoring that needed to happen on launch day. We created a war room, with each team represented at their own workstation.

We also had sample Sony Playstation on standby, so we could log in to different regions around the world and make sure things were working.

We also had a real cool analytics team that specializes in tracking usage in real time around the world.

The Apollo launch feeling was created by design. Several pictures a phones like these were in full force that day.

And this is what things looked like just before launch.

We kept the war room going for about 48 hours. Once Sony pushed their package out to all the PlayStations, we slowly saw people start to come online around the world, and it was great to see no major hiccups or disruption our backend services couldn’t handle.

To be honest I was amazed. I wasn’t expecting anything to go smoothly. What isn’t easy to see is the amount of work that goes on behind the scenes to make something like this happen. So many things can go wrong.

But somehow it worked. It all came together. It wasn’t Agile. It wasn’t any process, or secret sauce. It’s that same old cliche – it was the people. The talented, passionate group that went the extra mile, stayed the extra night, and worked the extra weekend to make this thing happen.

In Summary

I don’t know if I will ever get to participate in an event of this magnitude ever again. It’s pretty incredible to see this much focused work come together in this timeframe, in a single effort.

But I am thankful to have been a part of it. And I want to thank my team for all their hard work and making it happen.

Newsletter

If you like this newsletter, you can find more here:

http://www.agilenutshell.com/newsletter

XP Tech Practices Workshop at Spotify

Last week, a group of us did an XP Tech Practices workshop here in Stockholm. We covered Test-Driven Development, Refactoring, Unit Testing, Pair Programming, and a host of other Old school XP practices. Here are some notes and a write up about the course.

What is XP

XP (Extreme Programming) was the first really popular Agile method. Not only did it introduce Agile planning concepts such as user stories, adaptive planning, and iterative development. It helped popularize engineering practices such as unit testing, refactoring, test-driven development, and continuous integration.

It isn’t as widely practiced today as it was in the early 2000’s (Scrum has largely taken over). But it has many wonderful practices and ideas that deserve repeating and are still very much relevant for software teams today.

This workshop aimed at revitalizing some of software these practices, showing participants who they were originally meant to be performed, and then discussing how they can be introduced into their workplace.

How do you feel about your work?

We start off the course by asking participants how they feel about their work. Specifically around quality and design. We do this to start a conversation around what quality is, how we know when we have good design, and what obstacles prevent us from reaching them in our software.

Build something!

We then break the ice by asking participants to code something up (like a calculator). We do this to get the juices flowing, engage the participants, and just get them hacking. This helps us see where they are coming from, their familiarity with the programming language, and how comfortable they are writing code.

We don’t judge or do anything with the code that we produce here. We simply park it, and revisit it later. We then introduce XP.

XP Intro

XP can best be described as the software methodology that turns the knobs up to 11.

If code reviews are good, we will review code all the time (pair programming).
If testing is good, we will test continuously (acceptance tests, unit tests, TDD, demos).
If design is good, we will design continuously, every minute and every day (refactoring).
If simplicity is good, we vow to always leave the system in its simplest state.
If integration is good, we will integration continuously (continuous integration).
And if iterative development is good, we will iterate from day one, continuously getting feedback on our product, plan, and ability to please our customer.

XP Demo

Once we’ve covered the spirit and intent of XP, we demo the practices. We pair program up a sample problem, applying TDD, refactoring, unit testing, and pair programming in an extreme way, just to give the participants a sense of how all the practices work.

We then revisit the exercise they did in the ice breaker, and try it again, this time using the XP practices, specifically writing the tests first.

Build a game!

We then unleash them on their own codebase – specifically a game. They take what we’ve covered, and apply the practices in as an extreme a way as they can, and we build a fun interactive game over the course of several iterations.

XPisms

Over the span of the course we look for opportunities to introduce XPisms. Things like:

YAGNI – You aint gonna need it. A reminder to keep things simple, and not add excess functionality / code unless absolutely required (a good test is whether you can write a failing test first before adding the new code).

Production Readiness – A system spends a lot more time in production than in development. So why don’t we start treating it that way, and write code as if we were in production from day one.

Doing the simplest thing that could possibly work –

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. – C. A. R. Hoare

Test everything that could possibly break – We can’t test everything. But we know we can’t test nothing. So we start by testing everything we think could break. And evolving our suites from there.

Dials to 11 – XP’s take on hard problems is to take them head on. Taking this approach takes many of the traditionally hard problems on software projects, and breaks them down into much smaller, easier to digest pieces.

Courage – Have the courage to write that failing unit test. Have the courage to say no to the hack on your finger tips. Have the courage to say no to the unrealistic schedule, and help another team out when they really need it.

Why we feel this is important

It may seem that XP is all about engineering. It’s not. It’s just as much about culture. But the culture XP wants the team to operate under doesn’t happen if certain practices aren’t in place. This course is about explaining the practices, showing how they work, and then helping teams adopt them their work place.

A special thanks to Henrik Kniberg for the initial course outline and for his support in making this course happen.

Quotes

“I was supposed to have a Hackday today, but this is WAY better”

“I found the course to be a lot of fun, and learned a lot about TDD/XP in the process. The exercises, particularly the four-part exercise to build a game for a customer, were a very good balance of difficulty and fun, and allowed me to learn at a good pace without being bored by trival tasks or overwhelmed by difficult ones.

In fact, the game task actually, perhaps accidentally, was almost tricking me into learning stuff. You know you give a kid a toy that’s actually teaching them maths without them knowing because they’re having fun with the flashy lights? It was kinda like that.

★★★★★ Five stars, genuinely one of the best in-house workshops I’ve attended.”

“Got a good amount of new perspective on XP and TDD. Got into the habit of writing unit tests during instead of after development. And it was a lot of fun!”

Copy with care

I understand the desire to copy others. I do it all the time. I read an article about Facebook having no QA department, or see first hand how Spotify delivers projects with no Project Managers, and I can’t help but wonder how if they can do it, why can’t we do it here?

There’s just one problem. Copying others is never that simple.

When we see or admire what one company is doing, we are only seeing it through the lens of the end result. And not the underlying foundations that were setup to get them there.

Facebook can get away with not having a QA department because of the huge level of accountability they place on their engineers. Not to mention the insane level of talent.

Spotify doesn’t have formal Project Managers. But it empowers, and gives a level of autonomy and independence to it’s teams, so that teams are inspired to manage themselves.

For fun, this is the conversation I imagine trying to have with the Oil and Gas executive back home.

“OK. For next year we are going to try something new. No annual budgets. When Toronto asks us how much we are plan on spending, we will simply say we are going to spend whatever the cost is for us to work here this year. Our burn. That’s our budget. And in exchange for that they will empower us to do whatever it takes to meet the goals we have jointly agreed upon and laid out before us.”

Needless to say this wouldn’t fly.

But that’s my point. It wouldn’t fly because most companies won’t give the trust and accountability necessary to get the level of commitment and passion they see and read about in others. For their employees it will always be a job.

So am I saying we should give up, stop looking to others to inspiration, and just accept that we work for companies that will never give us the levels of autonomy, accountability, and independence we crave.

Hell no. Just remember. Not everyone wants this level of accountability. For many people work IS just a job. And trust is something that needs to be earned.

So keep reading. Keep studying. And keep looking to others. Just understand. What works at Apple, or Google, won’t necessarily work out of the gate at yours. Don’t get discouraged, keep trying to make where you work a better place, because at the end of the day, what other choice is there.

Joining Spotify

Well, after a whirlwind summer, I can proudly announce I have joined Spotify as an Agile Coach here in Stockholm Sweden. I just completed my first week, and before entering bootcamp I wanted to share some thoughts, observations, and comments from week one.

Surface observations

Spotify, for those of you who don’t know, is a music streaming company founded in 2006 which today has about 40M active users and 10M paying customers.

The best way to think about what they do is to imagine having access to all of iTunes for free. You don’t download the songs. They are streamed to you in real time on whatever device you happen to be listening. Then for $10/month you can get rid of the occasional add – this is called the premium service. Spotify competes with Google and Apple in the music service industry.

Being a music tech company Spotify has some pretty incredible engineering talent. They have music players, iOS/Android clients, embedded hardware in speaker systems, not to mention some enormous scaling issues for when it comes to streaming music to people anywhere, anytime around the world. Very strong engineering.

They are also the most mature Agile shop I have ever had the chance of working with. They have been innovating in the Agile space for some time. Most of their challenges are organizational. Like how do we scale this thing.

For a good video on Agile at Spotify watch this.

http://vimeo.com/85490944

Sweden

This being Sweden, there is a strong culture of building consensus (similar to Japan). But different also in that there very little formal hierarchy. Spotify stress autonomy, and empowerment at a level I have never seen before in a company of it’s size. Every team here truly is a startup and empowered (and expected) to make their own decisions and follow through.

So overall, a very high-level of self awareness, a great deal of maturity, but an understanding that they haven’t got it all figured out (despite the number of daily tours and requests they give to other companies visiting the office, and asking them how they do it). They answer of course is there is no one way – this just happens to be the Spotify way.

Great challenges

Working here is also like having a front row seat to one of the greatest battles our industry is going to see – who is going to dominate music. Going up against the likes of Google and Apple is no small thing. And Spotify is well aware of the challenges they face.

Organizational scaling, reduced friction, iterating fast, and discovering the future before others have real meaning here. There are going to be some real challenges. And I feel very fortunate to be a part of that.

Coming soon

For my friends and family back in Canada stay tuned. Spotify is coming! There were some regulations from the Canadian government that needed to be sorted out before Spotify could launch, that that being complete Spotify should show up sometime I hope this year.

So stay tuned. Sign up. And listen to the music.

Cheers – Jonathan

Links

CEO Daniel EK Charlie Rose Interview

Personal blog of family life in Sweden