Thanks for sharing these articles. They were most interesting to me. As a
a Scrum team I found these articles really very enlightening. I would agree
many of the same thoughts. Please bear with my basic thoughts below and
could do as a Scrum Master.
making decisions based on what is known. Three pillars (transparency,
inspection and adaptation) uphold every implementation. So in the first
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
work by the desired time for the goal.
rather than waiting to the last minute or a weekly status meeting. In my
estimates of the user story and the "how" of implementing them. To be self
development team to create the product increment. I would think that is how
mastery and purpose. In Scrum by being cross functional and self organizing
it should enable them to that end.
and the work of the Development Team. However "in the Sprint Review the
to be there. In an engineering driven organization just because the
takes "courage" and "openness" among the Scrum team members.
team members which means all skill sets and levels. And that the senior
fulfilling for both and the entire team.
Scrum Master did not teach or coach on the Scrum Framework. The
should be for "backlog grooming" so there is not a constant looking ahead.
Scrum Master. In fact as a servant leader and in an utopian (naive) world I
would work myself out of the job/role.
If you've read this far, thank you for your time and attention. Your
comments are welcome as I learn.
Post by Kevin SmithAgain, thanks Joaquin for sharing these.
https://michaelochurch.wordpress.com/2015/06/06/why-
agile-and-especially-scrum-are-terrible/
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.
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.
And with that, I invite you to marvel at my massive wall o' text....
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.)
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.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/No_true_Scotsman
Kevin Smith
Agile Coach, Wikimedia Foundation
On Wed, Oct 5, 2016 at 11:36 AM, Joaquin Oltra Hernandez <
Post by Joaquin Oltra HernandezHi!
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.
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.
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.
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.
Why âAgileâ and especially Scrum are terrible â Michael O. Church
https://michaelochurch.wordpress.com/2015/06/06/why-agile-an
d-especially-scrum-are-terrible/
Why I'm not a big fan of Scrum
http://okigiveup.net/not-big-fan-of-scrum/
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices