Scrum Master Jira-ს დარაჯი არ არის

საკმაოდ ხშირია, როდესაც Scrum Master-მა ნაცვლად იმისა, რომ გუნდის, ან ორგანიზაციის დონეზე აკეთოს Super საქმეები, ორგანიზაციაში აღქმულია, როგორც Jira-ს დარაჯი. ამ სტატიაში მოგიყვები ამ უცნაური მაგრამ საკმაოდ გავრცელებული ფენომენის შესახებ.

Scrum Master-ი Jira-ს დარაჯი ორ შემთხვევაში ხდება ხოლმე. პირველი შემთხვევა, თვითონ უნდა, მეორე კი ორგანიზაციას ასე ესმის მისი როლი.

პირველის შემთხვევის Jira-ს დარაჯი უფრო მძიმე კლინიკით ხასიათდება. ეს არის Scrum Master-ის ისეთი ტიპი, რომელიც შეპყრობილია Jira-ს სრულყოფილებამდე მიყვანით. მისი ერთადერთი საზრუნავი და ფოკუსი ამ ინსტრუმენტის იდეალურად მოწესირიგებაა, თუმცა ამის ის შორდება Agile-ის რეალურ პრინციპებს. არავინ დავობს, რომ Jira პროექტების მართვის ერთ-ერთი საუკეთესო ინსტრუმენტია და არც იმას ამბობს ვინმე, რომ Jira-ში ქაოსი გქონდეს, მაგრამ გაიხესენე Agile Manifesto-ში პირველივე ჩანაწერი "პიროვნებებს და ურთიერთქმედებებს ვამბიჯიებთ, პროცესებსა და და ინსტუმეტებს".

მეორე კატეგორიის Jira-ს დარაჯი Scrm Master, მეტწილად გარემოების მსხვერპლია. ეს არის შემთხვევაა, როდესაც ორგანიზაციაში ყველა როლი, Scrum Master-ის ფუნქციას აღიქვამს, როგორც "Jira-ს მომწესრიგებელად და სხვადასხვა ეჯაილური, თუ სკრამული შეხვედრების ჩამგდგებად."

ასეთი Scrum Master-ის მიმართ მოლოდინებიც დიდი არ არის ხოლმე. მისგან არავინ ელის რთული, კომპლექსური პრობლემების მოგვარებას. ბევრი გაუმჯობესების საკითზე დაორგანიზებული შეხვედრაც მის გარეშე მიმდინარეობს, მაგრამ როგორც კი საქმე რთულდება, ორგანიზაციის ყველა თითი Scrum Master-ისკენ არის ხოლმე გაშვერილი. ამ დროს ისმის ისეთი კითხვები, როგორიცაა: "რას აკეთებს სქრამ მასტერი, როგორ გავზომოთ მისი წარმატება, ვერ ვიგებ ეჯაილი რად გვინდა და ა.შ."

ამ ისტორიაში ყველაზე დრამატული ნაწილი ის არის, რომ ეს კითხვები ორგანიზაციაში იმ დროს გაჩნდა, როდესაც Scrum Master გულმოდგინედ დარაჯობდა Jira-ს.

მერე Scrum Master რა შუაშია? გეტყვი, Scrum Master იმ შუაშია, რომ ორგანიზაციაში ჩამოყალიებული პარადიგმულად მცდარი შეხედულებების წინააღმდეგ არ დაიწყო ბრძოლა. დიახ, შეიძლება ერთი სქრამ მასტერი მთელ ორგანიზაციას ვერ მოერიოს, მაგრამ მინიმუმ, მისი გუნდის ჭრილში, მაინც უნდა ეცადოს ამ თავისი როლის მიმართ, თუნდაც თეორიასთან მიახლოებული სწორი წარმოდგენები ჩამოაყალიბოს.

ხშირად, რატომაც Scrum Master-ებს უჭირთ ასეთი მაშტაბის ცვლილებები განახორციელონ, არის დაბალი ატორიტეტი. გუნდში ავტორიტეტი კი რამდენიმე ასპექტის გათვალისწინებით მიიღწევა: იცოდე პროდუქტი, იცოდე ტექნოლოგია, რითაც შენი გუნდი მუშაობს, რეალურად უგვარებდე გუნდს შეფერხებებს და დაიცვა შენი გუნდი ე.წ. Context Switching-ისგან.

იმედია ეს პოსტი დაგეხმარება არ გახდე Jira-ს დარაჯი და ფოკუსი გქონდეს რეალურად ისეთი საქმეები კეთებაზე, რომელიც გუნდისთვის დიდი ღირებულების მომტანია.