Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Michael Hübl, profile picture
Uploaded byMichael Hübl
12,220 views

How our product team works

The document discusses the agile methodology adopted by the product team at Flinc, emphasizing continuous improvement, collaboration, and adaptation to change. It outlines the team's structure, processes for prototyping, and the importance of testing and code reviews before deployments. The team regularly reflects on their practices to learn and improve while remaining flexible to meet various challenges.

Small Business & Entrepreneurship◦
Download to read offline
@flinc, @m_ic How our product team works
@flinc, @m_ic Being agile is a never-ending journey. An adventure with ups and downs, failures and successes - this presentation shows where we are right now..
@flinc, @m_ic Being agile means: If you see something wrong or inefficient, fix it!
@flinc, @m_ic It doesn’t mean to follow a specific methodology like Scrum or Kanban. Instead, it is about using the right tools at the right time to get the job done. // Image © Spotify
@flinc, @m_ic There’s only one thing that never changes: We need to improve continuously! That’s why we get together every two weeks to do a retrospective. Bild Retro // Image © Spotify
@flinc, @m_ic Outcomes of retrospectives are learnings, best practices and common principles which are accessible for everyone in our team handbook.
@flinc, @m_ic But guess what: Every challenge is different, so a best practice can be outdated tomorrow. It is a constant learning cycle.
@flinc, @m_ic Working in an agile environment sometimes feels a little chaotic. While we try to avoid chaos, it is still better than bureaucracy. // Image © Spotify
@flinc, @m_ic Enjoy the change! And do your best to stay in control while not losing speed. // Image © Spotify
@flinc, @m_ic We are 13 people in 4 main roles: 
 Product Manager, Developer, Designer and QA // Image © Thinslices
@flinc, @m_ic Make sure things work,
 fixing bugs, maintenance, refactoring.. Everybody is part of a client team, where the ground work is done. iOS Android Core
@flinc, @m_ic If new things come up, we build a new feature team. Feature Team iOS Android Core
@flinc, @m_ic A feature team is an interdisciplinary team that can act on its own. iOS Android Core Decide & Deploy Feature Team
@flinc, @m_ic Every feature team has a leader. Without taking ownership, things will fail.
@flinc, @m_ic Team: Collaborate with everyone to find the best solution. Leader: Communicate which problems need to be solved and why. TODO WIP DONE Prioritised list
@flinc, @m_ic Goal of the team is to build an MVP that solves the problem and can be released to production. // Image © Spotify
@flinc, @m_ic It starts with understanding. What is the real problem? What are the real user needs? What is really important? This can be done through research, data analysis, customer interviews, customer experience maps… * Most of this work is done before we build the feature team
@flinc, @m_ic The prototyping phase has several steps we run through. * Depending on the complexity of the feature. Feature Kickoff PrototypingDeveloper Kickoff Acceptance criteria for MVP Success metrics Head scratchers Tested prototype
@flinc, @m_ic Collaboration is key and stakeholder involvement is important. That’s why we do a feature kickoff where we try to figure out side effects (e.g. legal & contract issues) and get everyone on the same page. Feature Kickoff PrototypingDeveloper Kickoff Acceptance criteria for MVP Success metrics Head scratchers Tested prototype
@flinc, @m_ic Prototyping is the only way to ensure we build the right solution. This step is iterative - we do it until we have a potential solution. A prototype is worth a 1000 meetings. Feature Kickoff PrototypingDeveloper Kickoff Acceptance criteria for MVP Success metrics Head scratchers Tested prototype
@flinc, @m_ic There are lots of great tools for prototyping like sketches, wireframes and technological prototypes. No matter what you choose - the important thing is user involvement. So get out of the building and start testing!
@flinc, @m_ic While things could look easy from the outside, it may have complicated technological dependencies on the inside. To avoid bad surprises we try to find “head scratchers" before we start the main development. Feature Kickoff PrototypingDeveloper Kickoff Acceptance criteria for MVP Success metrics Head scratchers Tested prototype
@flinc, @m_ic If we have a common understanding of the problem and a (potential) solution, we start developing it. If not, we start over again. * This takes days, not months. Feature Kickoff PrototypingDeveloper Kickoff Acceptance criteria for MVP Success metrics Head scratchers Tested prototype
@flinc, @m_ic Prototyping is awesome to show quick results. But: Prototypes are made to throw away. Their code may never become part of the production code base.
@flinc, @m_ic To get code to production two things need to be done: 1. Proper test coverage 2. Review by a peer.
@flinc, @m_ic Tests are as important as the implementation itself! It is up to the developer to decide how to achieve the best possible test automation. TDD is great, but so are other principles.
@flinc, @m_ic Every push to GitHub triggers a complete run of our test suite (~10k tests) on Travis CI. This gives us the confidence to deploy often. // Image © Travis CI
@flinc, @m_ic For code reviews we use Githubs Pull Requests. Pair programming is also a great way, especially when you are new in the team.
@flinc, @m_ic We prefer simple over clever! No one “owns” any code. // Image © Spotify
@flinc, @m_ic We have three environments: Production, Staging and Testing
@flinc, @m_ic For deployments we use our own deployment tool: Applikatoni. With Toni everyone can deploy code with one click (i.e. designers on staging). Toni also shows the current CI status of every branch or pull request you want to deploy. * It’s Open Source, get it here: http://applikatoni.com/
@flinc, @m_ic Everybody in the company can have access to our code base and is able to open a pull request. Even people from marketing and sales do this (i.e. for frontend changes).
@flinc, @m_ic We do small and frequent releases. In average we deploy 2 times a day on production // Image © Spotify
@flinc, @m_ic If we’ve deployed a feature, we measure its success over time. If it fails, we remove it. (And sometimes we fail to fail) // Image © Spotify
@flinc, @m_ic To spread knowledge, we do Hackathons, Lunch Talks, Offsites, Daily Standups… We also have a book club.
Contact me: Michael Hübl
 michael.huebl@flincteam.org
 Twitter: @m_ic, @flinc As said, being agile is a journey, an adventure with ups and downs, failures and successes. Now you know where we are right now! I would love to hear your story!
@flinc, @m_ic This is a follow up presentation to “How flinc works - Best practices after 5 years of company building” where I describe how we organise our company in general. Check it out online at http://www.slideshare.net/ michaelhuebl/how-flinc-works-best-practices-after-5-years- of-company-building
@flinc, @m_ic Thanks to Spotify and Thinslices <3 Scribbles taken from “Spotify engineering culture”:
 https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ Role icons taken from “Ready. Steady. Go Scrum Methodology!”
 http://www.thinslices.com/ready-steady-scrum-methodology/