[teampractices] FYI: Article: Transcend the “Feature Factory”

[Kevin Smith]

I saw this article[1] the other day, titled *Transcend the “Feature
Factory” Mindset Using Modern Agile and OKR*. Parts of it resonated with
concerns I have heard here at the foundation. Notably the disconnect
between being agile on the ground, but having high-level waterfall-style
planning. I found this quote to be provocative:

Using Agile development with waterfall goals turns teams into "feature
factories" with no focus on delivering value.

The article is tied to "modern agile", which seems to be a marketing effort
I'm not thrilled about. But I like the idea of constantly delivering value,
rather than just delivering "features" or "software". I'm also generally a
fan of decentralization, and rapid experimentation and learning.

[1]
https://www.infoq.com/articles/transcend-factory-modern-agile?utm_source=infoqWeeklyNewsletter&utm_medium=WeeklyNL_EditorialContent_culture-methods&utm_campaign=08292017news&utm_content=other

Kevin Smith
Engineering Program Manager, Wikimedia Foundation

[Erika Bjune]

Post by Kevin Smith
The article is tied to "modern agile", which seems to be a marketing effort

Yup, that's Joshua Kerievsky's thing (see http://modernagile.org/)

I actually like a lot of what he has to say about the modern state of Agile
in general, but he does tend to be marketing-focused.

------------------------------------
Erika Bjune
Engineering Manager - Search Platform
Wikimedia Foundation

Post by Kevin Smith
I saw this article[1] the other day, titled *Transcend the “Feature
Factory” Mindset Using Modern Agile and OKR*. Parts of it resonated with
concerns I have heard here at the foundation. Notably the disconnect
between being agile on the ground, but having high-level waterfall-style
Using Agile development with waterfall goals turns teams into "feature
factories" with no focus on delivering value.
The article is tied to "modern agile", which seems to be a marketing
effort I'm not thrilled about. But I like the idea of constantly delivering
value, rather than just delivering "features" or "software". I'm also
generally a fan of decentralization, and rapid experimentation and
learning.
[1] https://www.infoq.com/articles/transcend-factory-
modern-agile?utm_source=infoqWeeklyNewsletter&utm_medium=WeeklyNL_
EditorialContent_culture-methods&utm_campaign=
08292017news&utm_content=other
Kevin Smith
Engineering Program Manager, Wikimedia Foundation
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices

[Jeroen De Dauw]

Hey,

Thanks for sharing this nice article! I will be forewarning it to my
colleagues :)

Post by Kevin Smith
Using Agile development with waterfall goals turns teams into "feature

factories" with no focus on delivering value.

I've also seen people discuss such situations using the term Water Scrum
Fall.

PS: I recently read "Leading Lean Software Development" which is mentioned
and quoted from in the "Transcend the Feature Factory" article. My
highlights are available at
https://www.goodreads.com/notes/18897951-leading-lean-software-development/16821921-jeroen-de-dauw

Cheers

--
Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw
Software craftsmanship advocate | Developer at Wikimedia Germany
~=[,,_,,]:3

[Anne Gomez]

I find this topic really fascinating and challenging - and echo your
concerns, Kevin.

I'm thinking about this from the programmatic perspective as well. There
are interesting non-profit impact frameworks (logic models) that connect
activities and outputs to impact, but they generally come from a waterfall
approach. I think this is part of what has made it hard for the software
teams (agile) to work with the community teams (waterfall), at least in my
small corner of the world.

I think there are ways to marry the two approaches and stay focused on
impact if we treat activities and outputs as experiments (using agile) to
try to affect that change/impact. It means that we have to make space for
reflection throughout the experiment, but especially at the end, and be
honest about if what we're doing has the impact we're after as well as what
we learned along the way.

Post by Jeroen De Dauw
Hey,
Thanks for sharing this nice article! I will be forewarning it to my
colleagues :)

Post by Kevin Smith
Using Agile development with waterfall goals turns teams into "feature

factories" with no focus on delivering value.
I've also seen people discuss such situations using the term Water Scrum
Fall.
PS: I recently read "Leading Lean Software Development" which is mentioned
and quoted from in the "Transcend the Feature Factory" article. My
highlights are available at https://www.goodreads.com/note
s/18897951-leading-lean-software-development/16821921-jeroen-de-dauw
Cheers
--
Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw
Software craftsmanship advocate | Developer at Wikimedia Germany
~=[,,_,,]:3
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices

[Dan Garry]

Post by Kevin Smith
I saw this article[1] the other day, titled *Transcend the “Feature
Factory” Mindset Using Modern Agile and OKR*. Parts of it resonated with
concerns I have heard here at the foundation. Notably the disconnect
between being agile on the ground, but having high-level waterfall-style
planning.

As long as high-level plans are seen as projections that may change rather
than immutable commitments, it's certainly possible to balance agile
practices with waterfall-style planning, and therefore benefit from both.
It seems to be a balance that's difficult to get right.

I've definitely seen both of these patterns (too focussed on agile at the
expense of the bigger picture, or too focussed on high-level plans at the
expense of focussing on the present and responding to change) at the
Foundation. I feel that the Foundation has, for the most part, gotten
better at striking that balance over time.

Thanks for forwarding, Kevin.

Dan