Часті Релізи

Розробники повинні випускати версії системи користувачам (або бета-тестерам) якомога частіше.

Планування Релізу використовується для пошуку невеликих функціональних фрагментів, що мають значущий бізнес-сенс і які можуть бути випущені в реальне оточення на ранніх стадіях розробки. Це критично для своєчасного отримання корисних відгуків, щоб мати можливість впливати на процес розробки. Чим більше ви затримуєте випуск важливої частини системи тим менше у вас буде часу виправити її.

Пробне рішення

Створюйте пробні рішення для відповіді на складні технічні питання, для обгрунтування тих або інших технологічних рішень. При ухваленні будь-якого технологічного рішення існує ризик і пробні рішення покликані зменшити його.

Зробіть програму, яка відтворює досліджувану проблему і ігнорує все останнє.

Збори стоячи

Кожен ранок проводяться збори для обговорення проблем, їх рішень і для посилення концентрації команди. Збори проводяться стоячи для уникнення тривалих дискусій не интересных всім членам команди.

Якщо у вас проводяться щоденні збори стоячи, то решта всіх зборів повинна відвідувати тільки ті люди, які необхідні і що-небудь привноситимуть. Більш того, є можливість навіть уникнути деяких зборів. З обмеженням учасників, більшість зборів можуть бути проведене спонтанно перед монітором, де обмін ідеями набагато інтенсивніший.

Щоденні уранішні збори це не ще одна витрата часу. Воно дозволить вам уникнути багатьох інших зборів і заощадить більше часу, чим на нього витрачено.

Метафора Системи

Завжди вибирайте System Metaphor – просту і зрозумілу концепцію щоб члени команди називали всі речі однаковими іменами. Для розуміння системи і виключення дублюючого коду надзвичайно важливо як ви називаєте об'єкти. Якщо ви можете припустити як називається який-небудь об'єкт в системі (якщо ви знаєте що він робить) і він правда так називається – ви збережете силу-силенну часу і сил.