Off the back of a two hour whistle stop tour on the Software Development Lifecycle and touching on Agile Principles and Methodologies (apprenticeship training), I found inspiration in Spotify's management style and work culture not too dissimilar to my current work setting. This post is to pull out some of the interesting topics from the videos that make Spotify workplace unique and then compare and contrast with my expectations of those topics.

What's the mission?

• In a nutshell, make a great audio experience. Easier said than done. Spotify hopes to continually provide value back to its customer base (and monetise its efforts) by letting its workers come up with innovative solutions supported by client feedback. In order to nurture idea growth, it relies on a management style where strong leaders communicate the problems in the industry and on the company. It hopes to gain workers buy-in, then give the employees autonomy (and trust) to solve the problems.
• Our company's vision and industry is vastly different. We have strong and passionate leaders and a flat organisation structure, as well as clear communication channels. But, we are not profit-driven, rather various teams looking to facilitate charitable efforts for our representatives. Our team is smaller and operates from one office, a budget incomparable to Spotify yet arguably problems if solved could have far-reaching social impact.

  Scrum, Kanban or Other?

• Spotify departs from restricting defining roles and frameworks. They use aspects that suit their work and either tweak other systems or just don't use them at all. Overall, they lean on scrum technique and Kanban because they are geared towards concentrated efforts / features and continuously redeveloping these features.
• Our workplace follows a similar pattern: use whatever technique suits your team and don't be afraid to experiment. We don't have to chain ourselves to every rule that defines that agile framework. In fact, in wouldn't be in keeping with Agile's mantra: responding to change over following the plan to the letter. We follow sprint planning, daily stand-ups and retros. But we shy away from story points allocation and metrics like velocity. Tickets maybe assigned to a developer and visualised with a Kanban-style board but there's no hesitation on the whole group getting together to progress a story to support the developer 'assigned' to that issue.

  Source Control and other Tools

• Spotify have numerous developers working internationally in several 'squads'. So, each squad may establish tools that suit their particular workflow. If it's good and has a proven track record, it's not surprising to see the same tool being used between teams. Each squad is welcome to alter another squad's codebase if the other team are too busy. But, a thorough peer code review is expected. Squads release updates regularly and are responsible for their own decoupled components. For example, a team maybe tasked with the search functionality, another responsible for compatibility with an OS or mobile version. There is even an infrastructure team delivering testing, CI/CD and monitoring tools to help the other teams (self-service model).
• There aren't many comparisons here. Although, we are in alignment with experimenting with new software, especially open-source and finding a use-case for it in our workflow. As a small team, we work from the same remote codebase, initially testing functionality in the local environment, then pushing through to development, stage and production. We have an open style of management, anyone can make suggestions and test new features so no one person is restricted to a particular facet of development.

  Sprint Management

• In terms of building and shipping code, all features regardless of completion are pushed from the sprint week (they can be toggled off in production). Although it would be evident which features didn't get finished, the transparency is supposed to reduce code branches and avoids hiding un-merged code.
• We do not follow this approach. All peer-reviewed code releases go into a centralised repository. There isn't the concept of decoupled components, only different website environments.

  Managing Failure / Learning from our Lessons

• Spotify takes a bold approach in that it encourages you to make mistakes quickly and often, in the hope that you will learn from them twice as fast and never repeat them! They can afford to do this as their decoupled approach means that likely any bugs or breaks will only affect one feature and one team for a short period of time (reduce blast radius) so the fix should be quicker to implement rather than requiring hand-off code and a cross-discipline approach. To accelerate this process, new features are trialled by a control group before rolling out to the wider public.
• Making mistakes is part of the learning journey in development, so it's no doubt encouraged here. We acknowledge our errors but obviously like Spotify, we try to understand how the mistake was made and how to stop it from reoccurring.

  Implementing New Features

• They start by developing a narrative around the idea or problem. Spotify will actively use prototypes for early feedback. Then, they build the minimum viable product (MVP) to fulfil the narrative. This is so they can push to release quickly, get quick feedback which again allows them to tweak and re-release, eventually rolling out to the public. When it comes to innovation, the emphasis is on delaying deadlines until the MVP is proven. This is to allow experimentation to happen organically and not strangle innovation by someones corporate deadline.
• We follow a similar agenda but original idea growth is perhaps lacking, as the backlog is the priority. The issues stem from content teams or general web users not being able to achieve some functionality on the site or not having the information served to them in a readily accessible manner. In one example, we use front-end prototypes for early team engagement and after agreement, take this on into the backend. We certainly need to improve on testing implementation though and could benefit from the faster feedback loop. We have to draw the line on deferring delivery dates, as we are a support team in a wider organisation. We provide support to other more 'client-facing' teams and we do this by delivering them the information they need before or on the agreed deadlines.

  Continued Learning

• Employees are encouraged to spend 10% of their contract hours developing ideas and projects in the hope that Spotify can monetise these efforts. They also hold internal hackathons, manage bootcamps for new starters, train for agile coaches and present at various forums for experience sharing.
• This organisation promotes continued professional development and are willing to financially support employees, provided that there is a clear and justifiable end-goal that benefits the company. Examples include taking on apprentices, paying for technical training courses and certified exams. In terms of wider developer community training, it is not as diverse as Spotify and that is mainly due to size of the organisation in terms of people and financial resources.