Це не просто якась методологія.
Звичайно, 12-місячну обіцянку Джонсона було дано з певною натяжкою. Адже насправді вони не знали, коли закінчать, – просто не могли знати. По суті, ніхто в ФБР навіть не здогадувався, як швидко здатні працювати їхні команди. Саме про це я постійно кажу керівникам різного роду підприємств: «Я знатиму дату завершення проекту, коли побачу ступінь прогресу членів команди. Як швидко вони просуватимуться вперед. Наскільки вони прискоряться».
Було також дуже важливо, звичайно, щоб члени команди визначили, що може завадити їхньому прискоренню. Джефф Джонсон говорить про це так: «Я став майстром усунення перешкод». Концепція перешкоди зародилась у компанії, що колись сформувала багато ідей, на яких сьогодні базується Scrum. Конкретніше, у виробничій системі Toyota, створеній Таїчі Оно.
Не хочу заглиблюватись тут у подробиці, але однією з ключових концепцій, яку ввів в обіг Оно, є ідея «потоку». Суть у тому, що виробництво має бути швидким та безперервним протягом усього процесу, а одним із головних завдань менеджменту, за його словами, є виявлення та усунення перешкод для цього потоку. Усе, що стоїть на його шляху, є марнуванням. У своїй класичній книзі «Виробнича система Toyota» Оно дає цьому явищу моральну, а також ділову оцінку:
Не буде перебільшенням сказати, що в період незначного зростання таке марнування є злочином проти суспільства, а не просто комерційними втратами. Усунення марнування має стати першорядним завданням будь-якого підприємства[4].
Оно багато говорить про різні види марнувань та перешкод, що можуть виникнути на шляху виробництва. Щоб Scrum став по-справжньому ефективним, хтось у вищому керівництві компанії має глибоко зрозуміти, що перешкоди майже рівнозначні злочину. Про те, як позбутись марнування, я розповім вам пізніше в цій книжці. Зараз же буде досить сказати, що ефект усунення зайвого вражає, але люди часто цього не роблять, бо воно потребує чесності із собою та з іншими.
Джефф Джонсон розумів, що зайнятися цим доведеться саме йому.
Команді «Вартового» знадобилося близько трьох місяців, щоб визначити, скільки насправді займе виконання проекту. Чому? Повернімось до циклу перевірки та адаптації, про який я вже говорив раніше. Scrum працює шляхом визначення послідовних цілей, яких потрібно досягати у фіксований проміжок часу. У випадку ФБР було вирішено задіяти двотижневі цикли, де передбачено, що наприкінці кожного циклу буде готовий продукт. Це означало, що вони матимуть щось робоче, щось, що можна буде показати всім охочим, особливо зацікавленій стороні та, в ідеалі, людям, які фактично будуть цим користуватись.
Такий метод дозволяє командам отримувати майже негайний відгук про свою роботу. Чи рухаються вони в правильному напрямку? Чи дійсно те, що вони планують робити далі, відповідає тому, що вони мають робити, враховуючи виявлене протягом цього циклу?
У системі Scrum ми називаємо такі цикли спринтами. На початку кожного циклу відбувається