همهچیز تحویل میدهیم؛ اما آیا واقعاً ارزش ایجاد میکنیم؟
یکی از چیزهایی که گاهی اوقات در کار با تیمهای چابک میبینم، اینه که تیم موفقیت رو با تعداد کارهای تحویلشده میسنجه؛ چند Feature تمام کردیم؟ چند تسک بسته شد؟ چند آیتم از Backlog خارج شد؟
اینجا معمولاً یک تفاوت مهم گم میشه: Output با Outcome فرق داره.
خروجی یا Output یعنی چیزی که تیم تولید میکنه و تحویل میده؛ مثلاً یک قابلیت جدید، یک گزارش یا یک ویژگی.
اما Outcome یعنی تغییری که در نتیجه آن خروجی برای کاربر یا کسبوکار اتفاق میافته؛ مثلاً افزایش استفاده، کاهش زمان انجام کار، کاهش خطا یا افزایش رضایت مشتری.
یک نشونه ساده برای تشخیص این مسئله وجود داره: اگر بعد از تحویل یک Feature، اولین سؤال تیم این باشه که «تسک بسته شد؟»، احتمالاً بیشتر حواسمون به Output بوده. اما اگر بپرسیم «این کاری که انجام دادیم چه تغییری ایجاد کرد؟ چه ارزشی خلق کرد؟»، داریم به Outcome نزدیک میشیم.
راهکار این نیست که Output رو کنار بذاریم. تیم باید خروجی تولید کنه؛ اما برای یک یا مجموعه ای از خروجی ها، انتظار داریم یک نتیجه مشخص هم ایجاد بشه. قبل از شروع کار بپرسیم: «قرار است چه تغییری ایجاد کنیم؟» و بعد از تحویل هم بررسی کنیم: «آیا واقعاً این تغییر اتفاق افتاد؟»
یه تیم چابک تیمی نیست که صرفا سریعتر تحویل میده؛ تیمیه که یاد میگیره چه چیزی ارزش تحویل دادن داره
#سهشنبههای_عملیاتی #از_دل_اجرا
#تیم_چابک #ارزش_آفرینی
#Outcome #Output
✍️محمود متین فر؛ راهبر چابکی کسب و کار
┈••••✾•🌿🌸🌿•✾•┈•
🔷در فضای مجازی با اجایل تاک همراه باشید:
🔹@agile_talk
🌟از اجرای Agile تا چابک شدن، یک فاصله جدی وجود دارد.
یکی از اشتباهات رایج در مسیر چابکی اینه که بعضی مدیران، داشتن Sprint، Planning، Daily و استفاده از جیرا رو نشانه چابک شدن میدونن. در حالی که اینها بخشی از نحوه اجرای چابک هستن، نه تمام مفهوم چابکی؛ آن هم به شرطی که همین رویدادها درست و با هدف واقعی اجرا بشن.
ما میتونیم فرآیند اسکرام رو دقیق انجام بدیم، اما هنوز تصمیمها کند باشن، مدیر همهچیز رو خودش تعیین کنه، تیمها منتظر دستور بمونن، تغییر تهدید تلقی بشه و از اشتباه و یادگیری فرار کنیم. در چنین شرایطی، فقط ظاهر Agile رو ساختهایم، نه چابکی رو.
از طرف دیگه، گاهی حتی همین اجرای ناقص رو هم بهدرستی انجام نمیدیم و بعد نتیجه میگیریم «Agile برای سازمان ما جواب نمیده!»
خوبه که قبل از قضاوت درباره Agile، بررسی کنیم آیا واقعاً اصولش را اجرا کردهایم یا فقط مراسم و ابزارهاش را؟
چابکی زمانی اتفاق میفته که پاسخ به تغییر، همکاری، یادگیری و بهبود مستمر، از جلسهها خارج بشن و وارد رفتار روزمره سازمان و تصمیمهای مدیریتی بشن.
#شنبههای_راهبردی #از_اتاق_مدیران
#چابکی_سازمانی #مدیریت_چابک #فرهنگ_سازمانی #بهبود_مستمر #رهبری
#BusinessAgility #AgileLeadership #AgileTransformation
✍️محمود متین فر؛ راهبر چابکی کسب و کار
🔗 لینک مطلب در لینکدین
•┈┈••••✾•🌿🌸🌿•✾•••┈┈•
🔷در فضای مجازی با اجایل تاک همراه باشید:
🔹@agile_talk
اسپرینت را با لیست کار شروع میکنید یا با هدف؟
یکی از چیزهایی که در تیمهای Scrum زیاد میبینیم اینه که Sprint Planning تبدیل میشه به یک جلسه تقسیم کار.
تیم میگه:
«این Story رو برمیداریم، اینم انجام میدیم، اینم اگر شد...»
بعد Sprint شروع میشه و هرکس میره سراغ کار خودش.
آخر Sprint هم ممکنه چند استوری Done شده باشه.
اما وقتی میپرسیم: "این Sprint قرار بود چه تغییری در محصول ایجاد کنه؟" جواب مشخصی نداریم.
در اسکرام، Sprint Goal اهمیت ویژه ای داره و قرار نیست یک جمله تزئینی باشه. قراره به تیم یک هدف مشترک بده تا انتخاب و اجرای کارها حول اون شکل بگیره حتی خود Scrum Guide، هدف اسپرینت را تعهد Sprint Backlog میدونه.
پس در Planning فقط نپرسیم:
«چه کارهایی رو توی این اسپرینت انجام بدیم؟»
قبلش بپرسیم:
«تا پایان این اسپرینت، دقیقاً میخواهیم چه چیزی را بهبود بدهیم یا به چه نتیجهای برسیم؟»
بعد کارهایی که برای رسیدن به اون نتیجه باید انجام بشه رو انتخاب کنیم برای انجام.
وقتی هدف روشن باشه، اگر وسط Sprint هم شرایط تغییر کرد، تیم راحتتر تشخیص میده چه چیزی واقعاً مهمه و چه چیزی فقط یک کار اضافه است.
#سهشنبههای_عملیاتی #از_دل_اجرا
#تیم_چابک #بهبود_مستمر #اسکرام
#Agile #Scrum #SprintGoal #SprintPlanning
✍️محمود متین فر؛ راهبر چابکی کسب و کار
🔗 لینک مطلب در لینکدین
•┈┈••••✾•🌿🌸🌿•✾•••┈┈•
🔷در فضای مجازی با اجایل تاک همراه باشید:
🔹@agile_talk