1. The Power of Small Wins
1.1. Of all things that can boost inner work life, the most inportans is making progress in meaningful work
1.2. Small win can make all the difference in how they feel and perform
1.3. People are more creative when they feel happy, are instrinsially motivated by the work itself, nad have possitive perception of thei their colleagues and organization
1.4. What happens on a good day
1.4.1. Progress
1.4.2. Catalysts
1.4.2.1. help from person or team
1.4.3. Nourishers
1.4.3.1. respect and words of encouragemeng
1.5. What happens on a bad day
1.5.1. Setbacks
1.5.2. Inhibitors
1.5.3. Toxins
1.6. Key aspects
1.6.1. Emotions
1.6.2. Motivation
1.6.3. Perception
1.7. Ideas
1.7.1. small wins boost inner work life
1.7.2. small losses can have extremely negative effect
2. US
2.1. Always expect the unexpected when doing business in this country.
2.2. Americans tend to be friendly and collaborative.
2.2.1. they can quickly become aggres- sive and somewhat hostile.
2.3. money is a key priority and monetary aspects tend to dominate most arguments.
2.3.1. Status and personal honor play a smaller role.
2.4. Americans tend to show at least some of their emotions
2.5. Eye contact should be frequent, as this conveys sincerity and helps build trust.
2.6. Scheduling meetings in advance is required.
2.7. Use Mr./Ms. plus the family name.
2.8. Before calling Americans by their fi rst name, wait until they offer it.
2.9. When entering a room full of people, it is ok just to smile and say ‘hi, every- one.’
2.10. ‘how’re you doing?’
2.10.1. ‘I’m doing great, and you?’
2.11. American negotiators may focus mostly on near-term benefi ts.
2.12. emphasizecommon objectives, work to fi nd mutually acceptable alternatives,
2.12.1. compromising is usually only a last resort for American negotiators.
3. User Story Applied
3.1. Start
3.1.1. Overview
3.1.1.1. User story
3.1.1.1.1. written description - Card
3.1.1.1.2. Conversations to flesh out the details
3.1.1.1.3. tests - Confirmation
3.1.1.2. customer should write the story
3.1.2. Writing Stories
3.1.2.1. INVEST
3.1.2.2. Story + Short details + How to test
3.1.2.3. Including a spike - time for investigation
3.1.3. User Role Modeling
3.1.3.1. List of roles with groups
3.1.3.2. Brainstorming an Initial Set of User Roles
3.1.3.2.1. writing roles on the cards
3.1.3.3. Consolidating roles
3.1.3.3.1. Delete non important roles, mix roles
3.1.3.4. Refining the roles
3.1.3.4.1. add attributes and details about the role
3.1.3.5. Persona for role
3.1.3.5.1. detailed description + photo
3.1.3.6. Extreme Characters
3.1.4. Gathering Stories
3.1.4.1. User interviews
3.1.4.2. Open-Ended and Context-Free Questions
3.1.4.3. Questionnaires
3.1.4.3.1. how to prioritize the stories
3.1.4.4. Observation
3.1.4.5. Story-Writing Workshops
3.1.5. User Proxies
3.1.5.1. Users’ Manager
3.1.5.2. Development Manager
3.1.5.3. Salespersons
3.1.5.4. Domain Experts
3.1.5.5. The Marketing Group
3.1.5.5.1. may provide useful high-level guidance
3.1.5.6. Former Users
3.1.5.7. Customers
3.1.5.7.1. who are buying the SW
3.1.5.8. Trainers and Technical Support
3.1.5.9. Business or Systems Analysts
3.1.5.9.1. an excellent user proxy
3.1.5.10. Technics
3.1.5.10.1. user task force meetings
3.1.5.10.2. use more than one user proxy.
3.1.5.10.3. release the product as soon as possible
3.1.5.10.4. Constituting the Customer Team
3.1.6. Acceptance Testing
3.1.6.1. Write Tests Before Coding
3.1.6.2. Questions to customer
3.1.6.2.1. • What else do the programmers need to know about this story? • What am I assuming about how this story will be implemented? • Are there circumstances when this story may behave differently? • What can go wrong during the story?
3.1.6.3. The Customer Specifies the Tests
3.1.6.4. Testing Is Part of the Process
3.1.6.5. The Framework for Integrated Test
3.1.7. Guidelines for Good Stories
3.1.7.1. Start with Goal Stories
3.1.7.2. Slice the Cake
3.1.7.3. Write Closed Stories
3.1.7.4. Put Constraints on Cards
3.1.7.4.1. • The software must run on all versions of Windows. • The system will achieve uptime of 99.999%. • The software will be easy to use.
3.1.7.5. Size the Story to the Horizon
3.1.7.6. Keep the UI Out as Long as Possible
3.1.7.6.1. user interface guidelines are often described in documents with lots of screen captures.
3.1.7.7. Write in Active Voice
3.1.7.8. Ideally the customer writes the stories
3.1.7.9. Don’t Number Story Cards
3.1.7.9.1. try adding a short title to the card
3.2. Estimating and Planning
3.2.1. Estimating User Stories
3.2.1.1. Estimate as a Team
3.2.1.2. Estimating
3.2.1.3. Triangulate
3.2.1.3.1. Triangulate an estimate by comparing it to other estimates
3.2.1.4. Estimate stories in story points, which are relative estimates of the complexity, effort or duration of a story.
3.2.2. Planning a Release
3.2.2.1. a new release every two to six months
3.2.2.2. talk about a range of dates, rather than a specific date
3.2.2.3. MoSCoW
3.2.2.3.1. • Must have • Should have • Could have • Won’t have this time
3.2.2.4. Risky Stories
3.2.2.5. Prioritizing Infrastructural Needs
3.2.2.6. Selecting an Iteration Length
3.2.2.7. From Story Points to Expected Duration
3.2.2.7.1. to get an initial value for velocity
3.2.2.8. Creating the Release Plan
3.2.3. Planning an Iteration
3.2.3.1. Discussing the Stories
3.2.3.2. Disaggregating into Tasks
3.2.3.3. Guidelines
3.2.3.4. Accepting Responsibility
3.2.3.5. Estimate and Confirm
3.2.4. Measuring and Monitoring Velocity
3.3. Topics
3.3.1. What Stories Are Not
3.3.2. Why User Stories?
3.3.2.1. emphasize verbal communication.
3.3.2.2. comprehensible by everyone.
3.3.2.3. are the right size for planning.
3.3.2.4. work for iterative development.
3.3.2.5. encourage deferring detail.
3.3.2.6. support opportunistic design.
3.3.2.7. encourage participatory design.
3.3.2.8. build up tacit knowledge.
3.3.3. A Catalog of Story Smells
3.3.3.1. Stories Are Too Small
3.3.3.2. Interdependent Stories
3.3.3.3. Goldplating
3.3.3.4. Too Many Details
3.3.3.5. Including User Interface Detail Too Soon
3.3.3.6. Thinking Too Far Ahead
3.3.3.7. Splitting Too Many Stories
3.3.3.8. Customer Has Trouble Prioritizing
3.3.3.9. Customer Won’t Write and Prioritize the Stories
3.3.4. Using Stories with Scrum
3.3.4.1. The Scrum Team
3.3.4.2. The Product Backlog
3.3.4.3. The Sprint Planning Meeting
3.3.4.4. The Sprint Review Meeting
3.3.4.5. The Daily Scrum Meeting
3.3.4.6. Adding Stories to Scrum
3.3.4.7. Stories in the Sprint Planning Meeting
3.3.5. Additional Topics
3.3.5.1. Handling NonFunctional Requirements
3.3.5.1.1. • performance • accuracy • portability • reusability • maintainability • interoperabilty • availability • usability • security • capacity
3.3.5.2. Paper or Software?
3.3.5.2.1. starting with cards and seeing how they work in your environment - then, if there’s a compelling reason to use software, switch.
3.3.5.3. User Stories and the User Interface
3.3.5.3.1. we might need to think about the user interface right from the start.
3.3.5.3.2. 1. Perform user role modeling. 2. Trawl for high-level user stories. 3. Prioritize stories. 4. Refine high- and medium-priority stories. 5. Organize stories into groups. 6. Create a paper prototype. 7. Refine the prototype. 8. Start programming.
3.3.5.4. Retaining the Stories
3.3.5.4.1. it useful to have retained stories
3.3.5.5. Stories for Bugs
3.3.5.5.1. Staple small bug reports together with a cover story card and treat them as a single story.
3.4. An Example
3.4.1. The User Roles
3.4.1.1. The Project
3.4.1.2. Identifying the Customer
3.4.1.3. Identifying Some Initial Roles
3.4.1.4. Consolidating and Narrowing
3.4.1.5. Role Modeling
3.4.1.6. Adding Personas
3.4.2. The Stories
3.4.2.1. story writing workshop
3.4.2.1.1. start with a specific user role or persona and write all the stories
3.4.2.2. add non functional reqs
3.4.3. Estimating the Stories
3.4.4. The Release Plan
3.4.4.1. Select an iteration length.
3.4.4.2. Estimate the velocity.
3.4.4.2.1. loosely defined one story point as one ideal day of programming.
3.4.4.2.2. that it will take them between two and three real days to do one ideal day worth of work.
3.4.4.3. Prioritizing the Stories
3.4.4.3.1. Must Have, Should Have, Could Have, and Won’t Have.
3.4.4.4. The Finished Release Plan
3.4.5. The Acceptance Tests
3.5. Appendices
4. Agile Estimating and Planning
4.1. The problem and the goal
4.1.1. The pupose of planning
4.1.1.1. cone of uncertainty -0.6 + 1.6
4.2. Estimating Size
4.3. Planning for Value
4.4. Scheduling
4.5. Tracking and Communicationg
5. Практика
5.1. Прыжок веры
5.1.1. Прыжок веры - это предположение предпринимателя
5.1.1.1. Описывают в форме аргумента по аналогии
5.1.2. Стратегия основана на предположениях
5.1.3. Выходите на улицу для встречи с потребителями
5.2. Тестирование
5.2.1. MVP - минимально рабочий продукт
5.2.1.1. позволяет быстро пройти цикл "создать - оценить - научиться"
5.2.2. MVP и качество
5.2.2.1. Если мы не знаем кто наш клиент - мы не знаем что такое качество
5.2.3. Проблемы при создании MVP
5.2.3.1. Патентная защита
5.2.3.2. Конкуренция
5.2.3.3. Демотивация команды при провале MVP
5.3. Оценка (учет инноваций)
5.3.1. Три этапа учета инноваций
5.3.1.1. Создание MVP
5.3.1.2. Приближение базовых показателей к идеальным
5.3.1.3. Решение: продолжаем или делаем вираж
5.3.2. Показатели тщеславия и действенные показатели
5.3.2.1. Кагортный анализ
5.3.2.1.1. выделение группы потребителей - когорты и анализ эффективности в разрезе групп потребителей
5.3.2.2. Сплит тестирование (AB тестирование)
5.3.3. Аспекты учета инноваций
5.3.3.1. Действенные показатели
5.3.3.2. Простота изложения
5.3.3.3. Возможность проверки данных
5.4. Вираж
5.4.1. Вираж - это стратегическая гипотеза, которая требует тестирования с помощью нового MVP
5.4.2. Типы виражей
5.4.2.1. Вираж технологии
5.4.2.2. Вираж канала сбыта
5.4.2.3. Вираж механизма роста
5.4.2.4. Вираж способа монетизации
5.4.2.5. Вираж платформы
5.4.2.6. Вираж бизнес-архитектуры
5.4.2.6.1. B2B vs B2C
5.4.2.7. Вираж потребности клиентов
5.4.2.8. Вираж сегмента потребителей
5.4.2.9. Вираж уменьшение
5.4.2.9.1. Функционала продукта недостаточно - необходимо добавить опции для создания полноценного продукта
5.4.2.10. Вираж увеличение
5.4.2.10.1. Опция продукта становится отдельным продуктом
6. Методы и инструменты
6.1. Размер партий
6.1.1. Метод небольших партий
6.1.1.1. Метод позволяте быстрее обнаруживать проблемы
6.1.1.2. Стартап может быстрее получать знания, основанные на фактах
6.1.2. Метод непрерывного развертывания
6.1.2.1. Это процесс непрерывного тестирования продукта автоматизированными тестами и пользователями
6.1.3. Метод получения по запросу
6.1.3.1. Это метод небольших партий во всех звеньях системы поставок - производство "точно вовремя"
6.1.3.2. Для стартапов Запросом является "гипотеза о клиенте", которую надо проверить или запрос от клиента
6.2. Рост
6.2.1. Типичная проблема роста: у стартапа есть первые клиенты, есть обратная связь, НО нет роста / рост замедлился
6.2.2. Стартап должен добиться "жизнеспособного" роста: новые клиенты должны приходить благодаря действиям клиентов, которые пришли раньше
6.2.2.1. Сарафанное радио
6.2.2.1.1. хорошие отзывы
6.2.2.2. Побочный эффект использования продукта
6.2.2.2.1. модный или статусный продукт
6.2.2.3. Затраты на рекламу
6.2.2.3.1. за счет прибыли от клиентов, которые пришли раньше
6.2.2.4. Повторные покупки или обращения
6.2.2.4.1. продление подписки / покупка новых фитч
6.2.3. Механизмы роста
6.2.3.1. Цель механизма роста: определить набор показателей для анализа и оценки
6.2.3.2. 3 механизма роста
6.2.3.2.1. Механизм "липкого" роста
6.2.3.2.2. Механизм вирусного роста
6.2.3.2.3. Механизм оплаченного роста
6.2.3.3. Механизм роста определяет соответствие Рынок/Продукт
6.3. Адаптация
6.3.1. Адаптация - корректировка процессов и действий в стартапе в соответствии с текущими условиями
6.3.2. Скорость движения стартапа
6.3.2.1. Нельзя жертвовать качеством ради скорости
6.3.3. Инструменты
6.3.3.1. Метод пяти "почему"
6.3.3.1.1. Необходимо начать с незначительных проблем
6.3.3.1.2. Необходимо выделить отв. специалиста для данного метода
6.3.3.1.3. Этим методом нельзя решать хронические проблемы
6.3.3.1.4. Избегать проклятия "пяти обвинений"
6.3.3.1.5. На встречи приглашать всех, кто имеет отношение к рассматриваемой проблеме
6.4. Создание инноваций
6.4.1. Условия для создания инноваций
6.4.1.1. Скромные и доступные ресурсы
6.4.1.2. Возможность развиваться и проверять свои идеи
6.4.1.2.1. проверка идей без согласования с множеством начальников
6.4.1.3. Личная заинтересованность в результате
6.4.1.3.1. владения акциями компании
6.4.1.3.2. премиии, бонусы
6.4.2. Создание "Песочницы инноваций" в компании
6.4.2.1. Эксперимент полностью проводит одна команда
6.4.2.2. Эксперимент ограничен по времени
6.4.2.3. Эксперимент распространяется на определенную часть потребителей
6.4.2.4. Оценка эксперимента по стандартному отчету
6.4.2.5. Единные показатели для оценки успеха
6.4.2.6. Во время эксперимента - отслеживать реакцию потребителей (при необходимости - остановить эксперимент)
7. Принципы Lean StartUp
7.1. Предприниматели есть повсюду
7.1.1. Lean StartUp можно применять в любых компаниях / любой отрасли
7.2. Предпринемательство - это менеджмент
7.2.1. Это менеджмент, адаптированный к условиям чрезвычайной неопределенности
7.3. Подтверждение фактами
7.3.1. Стартапы проводят эксперименты для проверки своих гипотез - для создания отличных продуктов
7.4. Цикл "создать-оценить-научиться"
7.4.1. Главная задача стартапа - превращать идеи в продукты, оценивать реакцию потребителей, а потом принимать решения о том, следует ли совершить вираж или лучше двигаться прежним курсом.
7.5. Учет инноваций
7.5.1. Новый вид отчетности для оценки успеха и определения приоритетов
8. Видение
8.1. Старт
8.1.1. Общая концепция
8.1.1.1. Видение >> Стратегия (вираж) >> Продукт (Оптимизация)
8.1.2. Цель стартапа - выяснить, что нужно рынку, чего хотят клиенты, за что они готовы платить, - и как можно быстрее создать продукт
8.1.3. Lean Startup - новый подход в разработке инновационных продуктов
8.2. Определение
8.2.1. Стартап - это вновь созданная организация, которая занимается разработкой новых товаров или услуг в условиях чрезвычайной неопределенности.
8.2.2. Продукт стартапа - инновации
8.3. Обучение
8.3.1. Обучение = "Подтверждение фактами"
8.3.2. Знания, подтвержденные фактами, возникают на практике, в процессе экспериментов.
8.3.3. Главное в обучении - ответ на вопрос: какие наши действия создают ценность, а какие приводят к напрасным тратам?
8.3.4. Дерзость "нуля"
8.3.4.1. Легче заработать деньги или приобрести другие ресурсы, когда у вас ноль доходов, ноль клиентов и вы никуда не движетесь, чем когда у вас есть небольшие доходы, немного клиентов и бизнес хоть как-то растет.
8.4. Эксперименты
8.4.1. Цель эксперимента - выяснить, как создать жизнеспособный бизнес на основании видения стартапа.
8.4.2. Для экспериментов необходимо разбить видение на части
8.4.2.1. Проверить гипотезу ценности
8.4.2.2. Проверить гипотезу роста
8.4.3. Эксперимент - как продукт
9. Retrospective
9.1. Retrospective Exercises
9.1.1. Asking questions
9.1.1.1. four key questions
9.1.1.1.1. what did we do well (if we don't discuss we might forget?
9.1.1.1.2. What did we learn?
9.1.1.1.3. What should we do differently next time?
9.1.1.1.4. What still puzzles us?
9.1.1.2. another questions
9.1.1.2.1. see book
9.1.2. Starfish
9.1.2.1. evolution of 3 questions exercise
9.1.2.1.1. What went well?
9.1.2.1.2. What did not go so well?
9.1.2.1.3. Ehat can be inproved?
9.1.2.2. Circle with 5 words
9.1.2.2.1. stop
9.1.2.2.2. less
9.1.2.2.3. keep
9.1.2.2.4. more
9.1.2.2.5. start
9.1.2.3. http://linoit.com/users/evanwilliams/canvases/Retrospective
9.1.2.4. Toyota approach
9.1.2.4.1. choose single topic
9.1.2.4.2. responsible person
9.1.2.4.3. due date
9.1.2.4.4. success criteria
9.1.3. Sailboat
9.1.3.1. remind the team of their goals, product, risks...
9.1.3.2. picture
9.1.3.2.1. boat
9.1.3.2.2. rocks
9.1.3.2.3. clouds and wind
9.1.3.2.4. island
9.1.4. One-word retrospective
9.1.4.1. check-in before the retrospective
9.1.4.2. how fo you feel about the past iteration in one word?
9.1.4.2.1. ask why they feel that way?
9.1.4.2.2. list the major issue
9.1.4.2.3. define actions
9.1.4.2.4. use images form the internet - how I feel
9.1.4.3. if conflicts and personal issues between team members
9.1.5. Rate team performance
9.1.6. Hapiness Index
9.1.6.1. in the end of the day each team member set a point to emotion axis (positive, negative)
9.1.7. Five times why exercise
9.1.8. Constellation exercise
9.1.8.1. if team members are in agreement or disagreement about relevant topics
9.1.9. Team assessment survey
9.1.9.1. from SAF
9.1.10. Strength-based retrospective
9.1.11. High performance tree
9.1.11.1. refine the destination where team want to go
9.1.12. Value stream mapping
9.1.13. Retrospective of retrospective
9.1.13.1. for multiple teams
9.1.14. Car brand
9.1.14.1. if you think about this itteration as a car brand, which brand would you choose?