Gesendet: Mittwoch, 20. Juli 2016 um 14:49 Uhr Von: "Christian Boltz" <opensuse@cboltz.de> An: heroes@opensuse.org Betreff: Re: [heroes] Welcome! Hello, Am Dienstag, 19. Juli 2016, 21:22:58 CEST schrieb Sarah-Julia Kriesch:
Christian is bringing all to the point. Admins in Provo have been the problem and not you, Lars. We can fix a small part with the new hardware, but not all. You'll need them for different issues in the future. And that was the reason, why I said they need new admin policys, too. You can think about adding that to the blog article or not. Speaking every Monday about issues and only doing that isn't a good workflow for such admins... I recommend Agile System Administration with Daily SCRUM in such a situation. Sysadmins, who don't know what to do, "have to" ask their team for coming to the next task or they blame themselves... What you need is a Team Member (with Sysadmin knowledge) who wants to play the SCRUM Master every day. :-) I had a Sysadmin without passion in the last company and at first he didn't do his tasks. I introduced Daily SCRUM and he saw the feature that he "has to" ask questions and all task come to an end. After 1 week he wanted to have it all the time and all Team Members had fun. I was in the first Sysadmin Team with SCRUM at 1&1 and all teams in our department copied that... Last week I read an article aabout that and that Google is using it in their best teams with the name "High Performers".
Wow. Until now, my opinion about SCRUM (and similar methods) was that it's "just" a different method to organize the work, but without serious benefit. Well, except "we use an (over?)hyped method" and "our workflow wins every buzzword bingo" ;-)) Oh, and http://www.commitstrip.com/en/2016/01/29/the-daily-stand-up/ ;-) That can happen, if the SCRUM Master does a bad job... Resposibilities of a SCRUM Master in a Sysadmin Team: - priorizing the tickets ( can be done by the team lead, too) - monitoring escalations, critical tickets,... and bringing them into the Daily - motivating the SCRUM team for team work - finding solutions in problem situations (with others in the team) - looking that all are doing their job If the Daily is interesting and all team members want to do a good job (in the team!), something like that above doesn't happen. You managed to completely surprise me :-) and I'll have to change my opinion about SCRUM.
You can think about that and the situation in Provo. Any time that will fall back again and it is the right time for doing changes...
Indeed. I'm _very sure_ that at least one admin [1] is open to improvements. IMPORTANT: Make sure to have enough popcorn ready before reading the next paragraphs! Popcorn ready? OK, here we go. Right now, M. is working on restoring the lost images [2] and had quite some "fun" while digging for those needles in a big haystack of deleted spam files. To make things more interesting, MediaWiki renames deleted files to a nearly-random name[3], so M. will need to find out the original names (based on the file timestamp and Special:Filelist), rename the files and finally re-upload them to the wiki. Funny, right? ;-) So to sum it up: The current policy in Provo means - wasting lots of time - most of the second bunch of spam could have been avoided by deploying my config fix instantly - wasting even more time (the lost images were collateral damage of deleting the spam that arrived between my config fix and getting it deployed) - reduced service quality ("temporary" data loss, and wiki pages with images missing for several days) - leaving an annoyed admin behind (I doubt M. likes searching through the haystack and re-uploading the missing files) - needless to say that I'm also not amused and needed some time to drive this - and, probably most important for the management level: wasting time also means wasting money (salery for the employees doing avoidable work) I hope that's enough for Lars for bringing new admin policies for the Provo admins on the table... Needless to say: feel free to forward this to whoever is responsible for the workflow in the Provo admin team ;-) Provo admins are part of the Sysadmin team and Lars is the team lead. But they are in another country. Craig has got the best contact to the management level in Provo (and should have assigned this mailing list). He can tell us who should get it. But Lars has to say a "Yes" or "No" for changing the Admin Policies in Provo. ;-) Regards, Christian Boltz PS: Non-random sig (in german, sorry) [1] I'm not sure if I should mention his name in public, so let's just call him "M.". (People involved in this discussion should know whom I'm talking about.) [2] https://progress.opensuse.org/issues/12694[https://progress.opensuse.org/issues/12694] contains more details. All Heroes should be able to read it - if not, I can CC you ;-) [3] using the sha1sum of the file content, so without knowing the file content the name is no better than random. At least the original file extension is kept... -- Die erprobte Strategie der Managementmotivation im Operating [ist] eine, die ich gerne mit "Teile die Schmerzen" beschrieben möchte. Zum Beispiel setzt man den Projekteigentümer auf dieselbe Alerting-Methode wie den Sysadmin, der am Ende Sonntag nachts um 4 Uhr wegen eines Alarms die vorbeugende Wartung durchführen muß. [...] Wenn wir nun also einen jungen Projektverantwortlichen haben, bei dem das Handy Sonntag nachts um vier die Frau und das 6 Monate alte Kind weckt, dann ist diese Person nach einigen Wochen unmittelbaren Alerting-Erlebens sehr viel zugäng- licher. [http://blog.koehntopp.de/archives/2859-Wieso-zehn-Prozent.html[http://blog.koehntopp.de/archives/2859-Wieso-zehn-Prozent.html]] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org