how our product team works
TRANSCRIPT
@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ü[email protected]: @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/