Post by Mohammed Refat

Backend Engineering Leader in FinTech | Distributed Systems | Engineering Leadership | Scaling Systems & Teams

أسرع Sprint في تاريخ الفريق... كان من أسوأ الـ Sprints اللي اشتغلناها. كل الـ Tasks كانت مقفولة، الـ Velocity عالية، والـ Dashboard على الـ Jira شكلها يطمن. لكن بعد كام أسبوع، اكتشفنا إن مفيش حد فاهم جزء كامل من الـ System غير شخص واحد، والـ Junior developers كانوا بينفذوا الـ Tasks من غير ما يتعلموا ليه الحل اتعمل بالطريقة دي. أول ما حصل ضغط حقيقي على الـ System... بدأ كل ده يبان. ساعتها فهمت إن قياس نجاح الـ Sprint بالأرقام بس بيخلق إحساس زائف بالإنجاز، والنجاح الحقيقي مش إنك تقفل أكبر عدد من الـ Tasks وخلاص. النجاح الحقيقي هو إن الـ Mid-level engineer يبقى قادر ياخد الـ Ownership لـ Epic كاملة بثقة، وإن الـ Junior يطلع من كل Sprint أحسن من اللي قبله، مش مجرد قفل Tickets أكتر. والأهم، إن الـ Code review يبقى نقاش حقيقي عن الـ Architecture، والـ Trade-offs، وطريقة التفكير... مش مجرد تصحيح للـ Syntax أو الـ Formatting. الاستثمار الحقيقي في أي فريق مش بيبان في الـ Dashboard، بيبان لما حد ياخد إجازة والفريق يكمل عادي، وبيبان لما يحصل Incident والناس تعرف تتحرك وتتصرف من غير انتظار شخص بعينه. بيبان لما يزيد الـ Load على الـ System، وتكتشف إن جودة القرارات اللي اتبنت على مدار الشهور هي اللي أنقذت الفريق، مش سرعة تقفيل الـ Tasks. لو خرجت من كل Sprint والـ Velocity زادت، لكن مستوى الفريق ثابت... فغالبًا أنت بتحسن الأرقام، مش الفريق.