В январе 2015 началось наше неизведанное плаванье. Следующий шаг в самоорганизации и управлении продуктом. Магеллан. Мы начинали тихую революцию в рамках одного продукта и одной платформы, имея команду порядка 50 человек. Прошел год. Мы убедились и убедили многих в компании, что Магелан работает. Теперь в рамках этого подхода разрабатывается несколько мультиплатформенных продуктов и работает более чем 100 человек. И все так же отсутствуют сложные механизмы синхронизации, специфические роли, иерархические структуры, предопределенные процессы и брендированные scaling-фреймфорки. Как у нас это все еще получается? Приходите и послушайте историю команды HERE Maps.

1. Магеллан. Год спустя
Антон Зотин
HERE Berlin

2. • 14 years in IT industry
• 12 years in Agile world
• Too many ‘hats’
• CSM, CSPO, PS... XYZ
• Still don’t believe into the seriousness

6. Magellan Principles
• TEAM OWNERSHIP: Our team knows web mapping. We love our product. We will take the business goals
and design/implement amazing solutions to fulfill these goals.
• MEASURABLE AND TIME-BOXED PROJECT MISSIONS: Project teams get a single “project mission”,
project success metrics and mutually agreed time box (in # of weeks allocation). When the project is
completed, the team stops working on the project and gets staffed onto new projects.
• SELF-ORGANIZED TEAMS: We will form self-organized teams organized for a specific mission. Different
disciplines are added to the teams (or available “as a service”) as the teams decide.
• WORK HOW YOU WANT BUT KNOW WHERE YOU ARE: Teams can chose their way of working (Scrum
or Kanban or …), but they must be able to report burn-down of scope (completion vs. target) and
performance against project metrics at any time of the project.
• REVIEW, DON’T SPECIFY: Teams review their work weekly with a product manager, but product managers
are NOT allowed to write JIRA tickets (or other types of specification).
• DONE MEANS DONE: Code goes into “maintenance” when project completes, i.e. bugs will not get fixed
unless critical. Because of that, project acceptance will have strict quality requirements.
• END TO END: Teams are responsible for getting their feature into production, load testing, measuring user
metrics, looking for errors/problems, etc .
• EVERYONE IS AN INNOVATOR: Everyone can request a project (ideally supported by a research week
prototype), projects are accepted on the basis of business relevance (how does it fit the proposition /
roadmap) and differentiation potential.

7. • TEAM OWNERSHIP
• MEASURABLE AND TIME-BOXED MISSIONS
• SELF-ORGANIZED TEAMS
• WORK HOW YOU WANT BUT KNOW WHERE YOU
ARE
• REVIEW, DON’T SPECIFY
• DONE MEANS DONE
• END TO END
• EVERYONE IS AN INNOVATOR

11. ! !!

12. 17 weeks
2015 2016 2017

16. M1.1
M1.2
M1.3
M1.4
M2.1
M2.2
M2.3
M2.4
M2.5
M3.1
M3.2
M3.3
M3.4
M3.5
M3.6
M4.1
M4.2
M4.3
M4.4
M4.5

20. Leadership Team

21. M5.1
M5.2
M5.3
M5.4
M5.5
M6.?
M6.?
M6.?
M6.?
M6.?
M?.?
M?.?
M?.?
M?.?
M?.?
M4.1
M4.2
M4.3
M4.4
M4.5
?!?
?!?
?!?
?!?

33. Mission Team

34. ScrumKanban

43. • Painless continuous deployment
• AB tests
• Lean Startup culture
• Safe to fail environment

45. 2 weeks

46. S SS S
2 weeks

49. S SS S
2 weeks

50. S SS
R RS
2 weeks

52. S SS
R RS
2 weeks

53. S SS
R RS
D
2 weeks

61. + = ♥

71. Anton Zotin
agile coach
anton.zotin@gmail.com
+49 151 216 90225
@antonzotin