Dead Zone Streamline requirements flow in distributed projects by Sergey Prokhorenko @ Agile Pizza

Presentation
  • Whoami
    • http://ua.linkedin.com/in/sergeyprokhorenko
    • Head of head of Agile Practice at Luxsoft
      • Since 2005
      • 15+ customers
      • 50+ ongoing projects
      • 700+ Agile practitioners
      • 100+ Certified Scrum Masters
      • 15+ internal Agile Coaches
  • Agile as a silver bullet
    • Agile Providers vs Client problem
      • Business value driven prioritization to deal with Always late with the things we really need
      • Pay for DONE to deal with Paying for the wrong things
      • Change without penalty to deal with Too expensive to make even little changes
      • Client is in full control of the project to deal with Difficult to understand where we are right now
    • Actual use of requested features
      • Always 7%
      • Often 13%
      • Sometimes 16%
      • Rarely 19%
      • Never 45%
      • Source: The CHAOS Manifesto, The Standish Group, 2011
    • Simple rules
      • RUP Referece and certification guide - 289 pages
      • SCRUM Guide - 16 pages
      • presentation slide 4
    • Scrum is a game of chess - simple rules - but endless combinations
    • idealized role of PO in a company
      • Responsible for maximizing the value of the product and the work of the Development Team
      • Sole person responsible for managing the Product Backlog
        • Power
        • Expertise
        • Dedication
      • Does Sprint Planning and PBR with the Development Team
      • Tracks total work remaining at least every Sprint Review
    • Real life PO example - a team of PO
      • presentation slide 7
      • End users / stakeholders - Product vision team - prototypes - PO - pPOs for teams.
      • several PO - customer side PO, user side PO, intermediate pPO.
      • customers are on the "other side"
      • there are different time zones - 8hrs turnaround to get a solution
      • product owner is involved either in business, or in PO activities.
    • SCRUM becomes a cargo cult - doing SCRUM for SCRUM sake - no results.
      • things don't happen
    • How did we end like this? presentation slide 10
  • Sprint level visualization
    • SCUM rules - describe moves & technics, but not the strategy.
      • What to do on the higher level to sync teams is left in the "grey", "dead" zone
        • Management
          • Are we on track to deliver scope on time?
          • When release epics will be ready and what is the current status?
          • What are PO (BA, pPO) doing? Do they have blockers?
          • How many stories are ready for the next sprint?
          • Are we ready for the next release planning?
        • Developers
          • What is the goal of the current release?
          • Are we on the track to deliver on time?
          • What are other teams doing?
          • Are there any dependencies on a project level?
          • Does PO and BA have enough requirements? - what would we do, when this sprint ends?
  • What can we do about it?
    • People and interactions!
      • Who is PO?
        • man from business - no time for team - BETTER - can at least explain something.
        • man from IT - no time for business.
      • Clear roles and Responsibilities of dedicated PO on/from customer side
        • Prioritization - only PO can do. If PO can't do - SCRUM wont live on
        • Expertise - we can live with it. At least PO will understand business globally and get priorities.
          • we can get external experts to help with
        • Communication
          • first in a list to save time on.
          • least important - can gather once in a week to work.
    • Processes and tools
      • Use Kanban on high level at Project (program) level (presentation slide 18)
        • Goals / epics
        • Analysis ongoing
        • Ready for Development
        • Next 20 stories to pick
        • InDev
        • Acceptance OnGoing
        • Ready for production
      • High level flow
        • Request from stakeholders
        • Backlog prioritization
        • Backlog refinement
        • Ready for development
        • Sprint
        • Ready for release
      • Value stream mapping
        • Request from business sponsors
        • Program initiation <- involve / add team here!!!
        • Project chartering
        • Epics breakdown
        • User story drafting
        • User story grooming <- if team joins here - you will get waterfall
        • Ready for spring
        • In development
        • Ready for demo
        • Ready for UAT
        • in UAT
        • Ready for release.

        • Backog prioretization
        • +Addons
        • sign off
        • release publishing
    • DoD Agreements (Definitions of Ready) (Analysis phases)
      get more detailed on each phase
      • Do not build a formal contract, but rather visualize as much as possible for sprint.
      • Finishing of ready. (FoR)
      • Program initiation
        • PID is shared with BAs
        • Project charter is drafted and shared with business sponsors and BAs
      • Project chartering
        • Charter is approved by business sponsors
        • Final charter is reviewed with BAs in a meeting
      • Epics breakdown
        • Charter breakdown into epics is approved by PO
        • All epics are described in Confluence with:
          • Business context
          • Problem statement
          • High-level acceptance criteria
        • All epics are presented to the team(s)
        • Epics are included into backlog and prioritized
        • Business contacts identified
      • User story drafting
        • User story is well-analyzed by BA and conform to INVEST criteria
          • https://en.wikipedia.org/wiki/INVEST_%28mnemonic%29
        • Detailed BDD scenarios are created
        • Mockups are created (where applicable)
        • Data requirements specified (if any)
        • Business logic is specified (if any)
        • US reviewed with business SME
        • Acceptance criteria are reviewed by business SME
        • US is prioritized in backlog and priority approved by PO
      • User story grooming
        • Team reviewed and agreed that US conforms to INVEST criteria
        • BDD acceptance scenarios are well understood by team and approved by business
        • All research spikes identified and completed
        • US breakdown is approved by team (and re-approved by business if any changes)
        • Business contacts are shared with the team
        • Design is approved
      • DoD for last analysis phase = DoR for sprint
    • Limit WIP for BAs - not more than one Epic. Only 30% value added as they work on several projects
    • Backlog grooming Ground Rules
      • Regular
        • At lease once a week, scheduled with PO
        • Started upfront (at least a week before planning)
      • Timeboxed
        • 15-20 min per story
        • If timebox isn't enough - go offline and prepare for next session
      • Includes the whole team
        • All team members ask questions upfront
        • Team members (not only PO/pPO) describe story value and scenarios
      • Strict DoD
        • If artifact doesn’t follow agreed DoD it isn’t moved to the next phase
    • Effective collaboration
      • Feature team US - Scrum of Scrums - Feature team UA
      • Scrum of Scrums
      • Cross-functional teams
      • Single backlog with unified estimates
      • Single Product Owner for the whole backlog.
      • Proxy Product Owners for each location #TBD - feedback loop
      • Joint release planning
    • SCRUM of SCRUMs = Big picture of the project
      • Anything depends on everything. SCRUM as a mirror of the processes.
      • also as a feedback to management
      • Inspect and adapt
  • Product vision and goals. Sprint Zero Workshop
    • Who needs it most?
      • Scrum Team
      • Product owner
      • Scrum Master
      • Gathered all together in the same place
    • How long it takes?
      • one - two weeks
    • What do we get from it?
      • Synchronize product vision - get same language
      • Establish long term goals
      • Get Shared understanding of business
      • A common training and common language for the team
    • How do we do it?
      • Synchronize the product vision between the stakeholders (business canvas)
        • why do we need this product?
        • what problem does it solve?
        • who are the users - what are their problems?
        • what this product can do you can't do with other tools?
        • if you automatise something existing- how better the life would be with this product?
        • The goal is to get to a point, where team get a first hands on the product vision
        • Business model canvas as a tool
      • Obtain Goals
        • Create middle-term goals for the close half year. Some examples are:
          • get userbase
          • get to some minimal functionality
          • if it is an internal product - create SMART (measurable) goals (70% of manual activity to automatize)
          • get to understand - how do we measure success/failure
      • Create user personas for story mapping
      • Go for Story mapping.
        • Story mapping is created from the system users (persona's) point of view
        • Create a separate storymap for each user
          • as a user ... (persona from previous step)
          • I would like to do ...
          • so I would achieve ...
        • Use different coloured stickers for different personas - the one who needs the story - gets it
        • We must create complete story
          • either for one user
          • or for single process
      • Storymap becomes first backlog draft
      • Add weight for each story (can use fibonacci numbers as indicative weight) - affinity estimation
        • if some stories are over some measure in points - they are key target for splitting or lower priority
      • Slice user stories
      • Establish DoD (definition of done), Acceptance criteria
        • unit tests
        • introduction
        • testing
      • Set Priorities
      • Formulate Sprint 1 from stories (half sprint or quarter - better as they tend to grow ;)
      • Agree on working agreements (DoD partially, DoR (definition of ready) for requirements, Sprint pulse (timings)
  • Recommended literature
    • Implementing Lean software development
    • Lean from the trenches
    • Scaling lean and agile development
    • Practices for Scaling lean and agile development

Тренинг Продавцов в Компаниях

20140114 Тренинг Продавцов в Компаниях
  • Проблемы с продавцами в компаниях
    • Продавцов всегда недостаточно
    • Продавцы делают одни и те же ошибки
      • наступают на одни и те же грабли
    • Тренинги вызывают сопротивление персонала
    • Протоколирование в CRM системах
      • требует много админ воздействия для заполнения протоколов
      • результирующие протоколы формальные, но не информативные
      • протоколы есть, но никто их не читает
  • Ситуация с обучением продавцов
    • В компании нет единой системы оценки проведения переговоров (оценить=измерить)

    • Предлагаемые тренинги по продажам
      • Не адаптированы под компанию
        • под специфику бизнеса
        • под продвигаемый продукт
        • под определенный тип клиента
      • Продавцы не желают посещать тренинги оправдываясь занятостью
      • Внутренний тренер не является авторитетом
        • авторитетом мог бы быть руководитель - но он постоянно занят
    • Передача опыта происходит хаотически - руководителям заниматься обучением некогда
    • Передача опыта и контроль за эффективностью продавцов - происходит стихийно
    • Новые продукты не продаются так же хорошо, как старые
    • Часто, как только продавец обучен - он переходит в другую компанию
  • Технология подготовки продавцов
    • Необходимо очное обучение продавцов - только заочный формат не работает
    • Темп обучения у всех разный (перевод материалов в электронный вид позволяет учиться с разной скоростью)
    • Необходимо выявить ключевые моменты в переговорах и продажах
      • Они отличаются в разной специфике бизнеса
    • Помогают видеоролики важных моментов в продажах
      • продавец всегда теряется, когда спрашивают - сколько стоит
      • работа с возражениями
      • возражения "я подумаю"
  • Предлагаемые этапы обучения продавца
    • Этап 1. Тренинги и работа с материалом онлайн
      • Содержание теоретической части онлайн
        • можно пройти несколько раз.
        • видео ролики
        • тексты
        • блок-схемы
      • задания. не абстрактные - а по специфике конкретных продуктов
        • цель задания
        • описание
        • на что ставится акцент в тренировке
        • разные типы клиента
          • разные презентации
          • разные клиенты задают разные вопросы
          • разные возражения
          • какая информация получена от клиента - какие наводящие вопросы продавец задал клиенту
      • скрипты
        • подготовка конкретных ситуаций
        • речевые шаблоны
        • упражнение по конкретным текущим ситуациям
        • продавцы генерируют много возражений
      • примеры
        • заснять на видео начальника продаж, комм. директора, владельца
        • производит впечатление - та как он - признанный авторитет
      • тренировка
        • запись на видео всех упражнений продавцов и их оценка в баллах
          • большинство продавцов к этому относится неоднозначно
            • боится того, что увидит руководство
              • по факту - никто не будет просматривать 200 роликов.
        • инструмент изменения методики поведения
        • оценка записи тренинга - получение video pass - балла на выполнение заданий.
        • пересъемка и оценка этого видео - увеличение баллов - как мотивация для изменения поведения
      • экзамен
        • должен быть по теории
        • не с открытыми вопросами (cases)
        • небольшая длительность - 5-6 минут
        • нет ограничения по времени, разрешено пользоваться всеми материалами
        • цель - повторение успешных знаний
        • вопросы на определение понятий
        • экзамен нужен, чтобы пересмотреть теорию
    • Этап 2. Пост обучение и практика
      • коучинг продавцов
      • заполнение протоколов по каждому типу клиента
      • продавец сам себя оценивает
      • обычно продавцу некогда заниматься самоанализом продаж
        • продажи по принципу "гей славяне побежали"
      • как решение - требовать 5 протоколов по каждому типу клиента - требование для прохождения исп. срока
      • по каждому протоколу - написать короткое резюме как мотивация собственной оценки
      • в идеальной компании руководитель просматривает протокол и корректирует оценку - дает обратную связь
      • рекомендации - на основании протокола можно расписать рекомендации для улучшения следующих переговоров
      • архив успешных и провальных действий
    • Этап 3. Коррекция результатов по протоколам
      • Руководитель по результатам протоколов принимает решение - по каким разделам курса отправить продавца на корректирующее обучение.
      • Корректирующее обучение
        • Пересмотреть теорию
        • Сделать тренировку с напарником - несколько раз
        • Записать на видео тренировку и получить video pass
        • переписать экзамен по данному разделу
      • Руководитель (в лучшем случае) видит - как растут баллы продавца - как функция улучшения его уровня.
    • Этап 4. Повторение (после определенного периода времени)
      • Заново на практике написать протоколы.
      • Заново оценить себя (больший балл)
      • Руководитель заново пересматривает и корректирует баллы
  • Аттестация продавцов
    • Продавец должен пройти весь теоретический блок
    • Получить все video-pass на определенный балл
    • Написать безошибочно текстовые экзамены

    • Аттестация - инструмент для корректировки оплаты работы
    • корректировка оплаты - премия / депремирование / оставить оплату как есть.
    • как варианты поощрения - значки, единоразовые премии, внеочередной отпуск.
  • Время подготовки продавца
    • Обучение
      • все этапы обучения занимают 40 часов - 5 полных дней на обучение. в условиях работы - 3 недели.
      • пятница, суббота, воскресенье
        • можно добавить понедельник-вторник
    • Все этапы системы
      • 70 часов
  • Изменение восприятия
    • На первом этапе проходят формально
    • На видео задумываются
    • На этапе протоколов задумываются серьезно
    • На 4м этапе анализа благодарят
  • Тренинг, как инструмент обмена опытом
    • протоколы продаж по каждому типу клиента - ресурс опыта компании
    • позволяют кросс-сравнение и анализ протоколов и результатов продаж между разными подразделениями компании.