How our product team works

@ﬂinc, @m_ic
How our product team works

@ﬂinc, @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!

@ﬂinc, @m_ic
It doesn’t mean to follow a speciﬁc
methodology like Scrum or Kanban.
Instead, it is about using the right tools at
the right time to get the job done.
// Image © Spotify

@ﬂinc, @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

@ﬂinc, @m_ic
Outcomes of retrospectives are learnings,
best practices and common principles which
are accessible for everyone in our team
handbook.

@ﬂinc, @m_ic
But guess what: Every challenge
is different, so a best practice
can be outdated tomorrow.
It is a constant learning cycle.

@ﬂinc, @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

@ﬂinc, @m_ic
Enjoy the change! And do your best
to stay in control while not losing
speed.
// Image © Spotify

@ﬂinc, @m_ic
We are 13 people in 4 main roles:  
Product Manager, Developer, Designer and QA
// Image © Thinslices

@ﬂinc, @m_ic
Make sure things work, 
ﬁxing bugs, maintenance,
refactoring..
Everybody is part of a client
team, where the ground work
is done.
iOS Android Core

@ﬂinc, @m_ic
If new things come up, we
build a new feature team.
Feature Team
iOS Android Core

@ﬂinc, @m_ic
A feature team is an
interdisciplinary team that can
act on its own.
iOS Android Core
Decide & Deploy
Feature Team

@ﬂinc, @m_ic
Every feature team has a leader.
Without taking ownership, things will fail.

@ﬂinc, @m_ic
Team: Collaborate with everyone
to ﬁnd the best solution.
Leader: Communicate
which problems need to
be solved and why.
TODO WIP DONE
Prioritised list

@ﬂinc, @m_ic
Goal of the team is to build an
MVP that solves the problem and
can be released to production.
// Image © Spotify

@ﬂinc, @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

@ﬂinc, @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

@ﬂinc, @m_ic
Collaboration is key and
stakeholder involvement is
important.
That’s why we do a feature kickoff
where we try to ﬁgure out side
effects (e.g. legal & contract
issues) and get everyone on the
same page.
Feature Kickoff
Kickoff
Success metrics
Head scratchers
Tested prototype

@ﬂinc, @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
Kickoff
Success metrics
Head scratchers
Tested prototype

@ﬂinc, @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!

@ﬂinc, @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 ﬁnd
“head scratchers" before we start the
main development.
Feature Kickoff
Kickoff
Success metrics
Head scratchers
Tested prototype

@ﬂinc, @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
Kickoff
Success metrics
Head scratchers
Tested prototype

@ﬂinc, @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.

@ﬂinc, @m_ic
To get code to production two things need to be
done:
1. Proper test coverage
2. Review by a peer.

@ﬂinc, @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.

@ﬂinc, @m_ic
Every push to GitHub triggers a complete run of our test suite
(~10k tests) on Travis CI. This gives us the conﬁdence to deploy
often.
// Image © Travis CI

@ﬂinc, @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.

@ﬂinc, @m_ic
We have three environments:
Production, Staging and Testing

@ﬂinc, @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/

@ﬂinc, @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).

@ﬂinc, @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

@ﬂinc, @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@ﬂincteam.org 
Twitter: @m_ic, @ﬂinc
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

@ﬂinc, @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/

How our product team works

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to How our product team works

Similar to How our product team works (20)

More from Michael Hübl

More from Michael Hübl (14)

Recently uploaded

Recently uploaded (7)

How our product team works