<div dir="ltr">Thanks for sharing these articles. They were most interesting to me.  As a newly certified PSM and just having studied The Scrum Guide and now working a Scrum team I found these articles really very enlightening. I would agree with all of the comments Kevin talked about as I read the articles I had many of the same thoughts. Please bear with my basic thoughts below and these articles shed light on what hiccups I can run into or what more I could do as a Scrum Master.<div><br></div><div>As I understand (please note that I am still learning) that Scrum is based on the empiricism which means that knowledge comes from experience and making decisions based on what is known. Three pillars (transparency, inspection and adaptation) uphold every implementation.  So in the first article, it was interesting to read about the "one sided transparency" since every Scrum event is based on those 3 pillars including transparency. Scrum is about long term goals and short term planning. In the Sprint review is where the Product owner should make it visible about the long term goal and the assessment on the progress toward completing projected work by the desired time for the goal.</div><div><br></div><div>I was surprised to read that the author felt that their creativity is stifled if they have to explain themselves while working as from what I understand Scrum's team model "is designed to optimize flexibility, creativity and productivity."  The reason behind the daily standup is a short meeting related to the 3 pillars and inspecting and adapting and making it transparent to the development team on how things are going rather than waiting to the last minute or a weekly status meeting.  In my understanding the development  team is responsible or committed for the estimates of the user story and the "how" of implementing them. To be self managed including having those "expertise or specialized" skills in the development team to create the product increment. I would think that is how teams are motivated and want to work or be is to have their autonomy, mastery and purpose. In Scrum by being cross functional and self organizing it should enable them to that end.</div><div><br></div><div>In regards to the engineering driven and "calling the shots" comments in the article, as I understand the Product Owner is the sole person that owns the product backlog and responsible for maximizing the value of the product and the work of the Development Team. However "in the Sprint Review the entire group collaborates on what to do next, so that it provides valuable input input to the subsequent Sprint Planning." The basic "Scrum Value" of "respect" of each person's role on the Scrum Team and what they bring needs to be there. In an engineering driven organization just because the engineer/developer called the shots does it mean they brought the most value to the customer/marketplace or did something they thought was cool? Again this also does not mean that there is no room for discussion which takes "courage" and "openness" among the Scrum team members.</div><div><br></div><div>In regards to the "terminal juniority" I am not sure I understand the argument as I think the best Development team is made of cross functional team members which means all skill sets and levels. And that the senior developers could be paired up with the junior ones as needed which could be fulfilling for both and the entire team.</div><div><br></div><div>In regards to the comments about the sprint being an "emergency" or running as fast as you can and "weeding out low performers" makes me feel like the Scrum Master did not teach or coach on the Scrum Framework.  The Development team from what I have heard should be at 80% capacity so that there is time for exploration and creativity and 10% of the current Sprint should be for "backlog grooming" so there is not a constant looking ahead.  The statements at the end that "Agile" glorifies "emergency" and an "aspiring demogague (scrum master)" is not how I view Scrum or my role as Scrum Master. In fact as a servant leader and in an utopian (naive) world I would work myself out of the job/role.</div><div><br></div><div>If you've read this far, thank you for your time and attention.  Your comments are welcome as I learn.</div><div><br></div><div>Regards,</div><div>Geeta</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 5, 2016 at 1:46 PM, Kevin Smith <span dir="ltr"><<a href="mailto:ksmith@wikimedia.org" target="_blank">ksmith@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" id="m_4881255722778913988gmail-docs-internal-guid-389fc6ac-9691-275b-984d-ba2f0c1b3bc7"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Again, thanks Joaquin for sharing these. <br></span></font></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><br></span></font></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">This (insanely long) email is in response to article: <br></span></font></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><a href="https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/" style="text-decoration:none" target="_blank"><span style="font-family:arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline">https://michaelochurch.<wbr>wordpress.com/2015/06/06/why-<wbr>agile-and-especially-scrum-<wbr>are-terrible/</span></a></font></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"> </span></font></p><font size="2"><br></font></div><div class="gmail_default" style="font-family:verdana,sans-serif"><font size="2">Here's my tl;dr of the article: He associates agile with aggressive management, hyper-focus on individual productivity, stifling developer creativity, poor code quality, and a lack of professional development. <br><br></font></div><div class="gmail_default" style="font-family:verdana,sans-serif"><font size="2">Here's my tl;dr of my response: Agile encourages humane management, de-emphasizes individual performance, enhances developer creativity, can/should improve code quality, and is neutral to positive regarding professional development. <br><br></font></div><div class="gmail_default" style="font-family:verdana,sans-serif"><font size="2">And with that, I invite you to marvel at my massive wall o' text....<br></font></div><div class="gmail_default" style="font-family:verdana,sans-serif"><font size="2"><br><br></font></div><div class="gmail_default" style="font-family:verdana,sans-serif"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Disclaimer/context: I was a professional programmer for a decade before agile was invented. I have been a strong advocate for agile software development since 2001, but I remain agnostic about the specific implementation called Scrum.</span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I disagree with much of what is in this article. I can see that the author has been in some highly dysfunctional environments, and he has my sympathy for that. He pins the blame on agile and scrum, where I see other causes. I’m afraid that much of my response is the dreaded “that’s not agile!”[1]. But  I will try to focus on my own experiences, and will try to comment on his statements which seem more refutable. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Speaking as a developer, switching to “stories” and “iterations” greatly improved my sense of accomplishment, rather than stripping it away. Stories are written loosely enough that I would have to work closely with the customer (or proxy) to figure out what was really needed (and technically possible). Iterations allowed me to celebrate every couple weeks that we had made tangible progress. The typical pre-agile alternative was to futz around aimlessly for a few months, and then have a few months of all-out death march, before releasing something that was both late and unfinished at the same time. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I tend to agree about the pitfalls of open-plan offices. But I was complaining about those in the 80’s, so I don’t see those as an agile problem. And if I have experienced “humiliating visibility” into my work, it was in non-agile environments. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">In agile, programmers should never be “jerked around or punished when things take longer than they ‘seem’ they should take.” If that’s happening, it’s not agile. Period. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The distinction between business-driven and engineering-driven is a real thing, although there are some subtleties that I think the author overlooks. I have seen a lot of engineering-driven organizations make really bad choices: They can produce things nobody wanted; they can overproduce things to the point of bankruptcy; they can bounce from cool idea to cool idea without finishing anything. Basically, either approach can be done well or poorly. At least in theory, I believe that the business people (or more accurately the “product” people) can and should understand the customer, and from that they should be able to guide the team to satisfy those needs. If the business people ignore technical concerns raised by developers (including tech debt), then they’re not doing it right. This idea that code quality suffers under agile/scrum seems to be a recurring theme. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The author claims that “Architecture and R&D and product development aren’t part of the programmer’s job, because those things don’t fit into atomized ‘user stories’ or two-week sprints.” Wow, I disagree so strongly with that. Especially with Test-Driven Development (of which I’m a huge fan), architecture is *always* a part of the programmer’s job. Architecture and code design are ongoing, and require constant attention. The developer is always expected to find (research?) the optimal design. And I’m not sure how “product development” could not be a part of software development. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I agree that estimates are often misused/abused. But I disagree that they are useless or harmful. I wrote a lengthy email in an earlier thread on that topic. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The author feels that agile methods put programmers in the role of children. Personally, I have experienced two kinds of non-agile environments: Those that are more structured (waterfall-ish), and those that are less structured (chaos/cowboy-ish). In the former, I have felt like a powerless child. In the latter, I have felt like an out-of-control teen. In agile environments, I have felt like a responsible adult. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">This might be a good place to mention that I strongly believe that programming is a craft. The output has to be functional, so it’s not an art. We’re generally not inventing entire new paradigms and ideas, so it’s not science. We’re usually not applying universal laws and heuristics, so it’s not engineering. As a craft, those who have the skills and knowledge should be respected, appreciated, and rewarded. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I dispute the claim that “Agile is designed for and by consulting firms that are marginal”. Some of the biggest early proponents of agile were developing in-house systems for Chrysler. My friend and I had independently discovered several agile practices before the term “agile” was being used, while working for a company that built an operating system. The practices which just made sense to us included: Iterative development, automated testing, refactoring, and pair programming. I should also point out that Linux was developed agilely. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The author claims “Under Agile, technical debt piles up”, and again, I’ll say that there is no reason that should happen in agile any more than in any other approach. Waterfall tends to lock designs in early, creating brittle code, and then rushing the product out the door with bugs. Chaotic/cowboy coding tends to result in vast piles of spaghetti code. Those problems aren’t inevitable in any process, but tech debt is *always* a risk.</span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Through automated testing, heavy refactoring, pair programming and/or code review, and iterative development, agile provides the tools to reduce problems with tech debt. I worked on a Java application from 2001 through 2015, and despite all those years of purely agile development, the code remained relatively clean and maintainable. In 2014, we completely rewrote the UI to use a different framework, and it only took a few months. They are still adding significant new features to it, with relative ease. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I find this statement curious: “Agile is just one mindless, near-sighted ‘sprint’ after another: no progress, no improvement, just ticket after ticket after ticket.” I agree that it is one sprint after another, and one ticket after another. However, for me it is the opposite of “no progress, no improvement”. It is visible progress with almost every ticket (because tickets, or stories, are user-centric). It is visible progress with every iteration, as opposed to other approaches where you can go 6 months between releases. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I’m not sure about the career development concern. The claim that “I was on a scrum team” shouldn’t be equal to “kick me”, and I doubt it is for most hiring managers. When you apply for a job, hopefully you can point out specific innovations you came up with, specific features you developed or improved, areas where your code reviews were vital, examples of mentoring, etc. Being a grunt on a waterfall team is certainly no better (and I would argue is worse because you couldn’t have been involved with design, requirements, etc.) </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The next claim by the author is ridiculous: “Scrum is sold as a process for ‘removing impediments’, which is a nice way of saying ‘spotting slackers’.” Speaking as one whose job it is to remove impediments, that is completely wrong. If that’s how your organization works, it is definitely not doing Scrum, nor agile. The author then goes on about “constant surveillance”, which makes me feel bad for how he has been treated. Again, if that’s happening, it’s neither scrum nor agile. Daily checkins are an opportunity to reach out for help; an opportunity to describe the cool thing you just finished; an opportunity to figure out what you should work on next. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I agree with parts of the “whiskey goggles” effect, including that one goal of agile is to raise the performance of average developers. I think that generally in the industry, high-performing programmers are underpaid (and under-appreciated), and low-performing programmers are overpaid. But I also think that prima donna programmers are overpaid. Programming is a team sport, and anyone who doesn’t realize that is likely to cause problems for the team. I would rather have a bunch of 8’s on my team than a bunch of 4’s. But I’ll always take a 4 with a good attitude over a primadonna 8 who might refuse to teach the 4’s anything, or refuse to do some QA when the team is in a bind, or who refuses to believe that they might have anything left to learn. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The author refers to scrummasters as “aspiring demagogues”, which I have trouble even understanding. Then he says that “Agile and Scrum glorify emergency”, which if anything is the opposite of my experiences. He tries to align agile with “scientific management”, when the truth is that agile is much closer to being a rebellion against scientific management. </span></font></p><font size="2"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The author’s closing paragraph begins with “It’s time for this culture of terminal juniority, low autonomy, and aggressive management to die.” To which I say AMEN! Yes! And then I immediately claim that agile is, in fact, a remedy for terminal juniority, a complete cure for low autonomy, and is incompatible with aggressive management. <br></span></font></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><br></span></font></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">[1] <a href="https://en.wikipedia.org/wiki/No_true_Scotsman" target="_blank">https://en.wikipedia.org/wiki/<wbr>No_true_Scotsman</a><br></span></font></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><br></span></font></p></div><div class="gmail_extra"><span class=""><font size="2"><br clear="all"></font><div><div class="m_4881255722778913988gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font size="2"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></font></div></div></div></div></div></div></div></div></div>
<font size="2"><br></font></span><div class="gmail_quote"><span class=""><font size="2">On Wed, Oct 5, 2016 at 11:36 AM, Joaquin Oltra Hernandez <span dir="ltr"><<a href="mailto:jhernandez@wikimedia.org" target="_blank">jhernandez@wikimedia.org</a>></span> wrote:<br></font></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div><div><font size="2">Hi!<br><br></font></div><font size="2">Some time ago I found a couple of articles from engineers discussing their opinion on scrum. At the time I found that many of their arguments resonated with things I was feeling in our work.<br><br></font></div><font size="2">Max saw the links and suggested chatting about them, so I've thought I'd post them to tpg to try and spur some discussion.<br><br></font></div><font size="2">As scrum masters and fans, it is going to be easy to feel attacked by these articles, so if you know you're going to be affected, it is better to not read them.<br><br></font></div><font size="2">I am genuinely interested to learn when Scrum is not a good choice. As we know in engineering, there is no silver bullet, and it is very important to learn about the trade-offs and the adequacy of solutions to different situations.<br><br><br></font></div><font size="2">Without further ado:<br></font><div><div><div><div><div><div><font size="2"><br>Why “Agile” and especially Scrum are terrible – Michael O. Church<br><a href="https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/" target="_blank">https://michaelochurch.wordpre<wbr>ss.com/2015/06/06/why-agile-an<wbr>d-especially-scrum-are-terribl<wbr>e/</a><br><br>Why I'm not a big fan of Scrum<br><a href="http://okigiveup.net/not-big-fan-of-scrum/" target="_blank">http://okigiveup.net/not-big-f<wbr>an-of-scrum/</a></font></div></div></div></div></div></div></div>
</div></div><font size="2"><br>______________________________</font><font size="2"><wbr>_________________<br>
teampractices mailing list<br></font>
<font size="2"><a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.<wbr>org</a><br></font>
<font size="2"><a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/ma<wbr>ilman/listinfo/teampractices</a><br></font>
<font size="2"><br></font></blockquote></div><font size="2"><br></font></div></div>
<br>______________________________<wbr>_________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.<wbr>org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/<wbr>mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>