Loading ...
Sorry, an error occurred while loading the content.

Two Threads of Agile

Expand Messages
  • Charlie Poole
    Hello Marvin, Ron has said we re off topic here... but I think one aspect of the discussion is relevant so I m changing the subject line to indicate it. I
    Message 1 of 20 , Feb 26, 2011
    • 0 Attachment
      Hello Marvin,

      Ron has said we're off topic here... but I think one aspect of the
      discussion is
      relevant so I'm changing the subject line to indicate it. I think it would
      be
      helpful if folks who want to hit on some other aspects were to do the same.

      I'm glad - and surprised - that you do recognize the two different threads
      present
      in the agile movement. I had previously read your comments to mean that you
      didn't actually understand that the promotion of organizational change was a

      part of it.

      It seems to me that this is not "scope creep" at all but is inherent in the
      stated
      Agile values, particularly the one that puts people over process. I believe
      that the
      agile movement has always had an underlying theme of social change. Some
      practitioners stress it more and others making it less prominent, but it's
      pretty
      much always there, in the foreground or in the background as the case may
      be.

      This is seen by some - apparently by you - as a weakness. It might be so
      if it could be demonstrated that the two threads were inherently
      contradictory.
      But they aren't. It has been demonstrated repeatedly that we can have our
      cake
      and eat it too - we can empower folks to make their own choices of how they
      work and (still? as a result?) end up producing great working software.

      There remains one residual "weakness" of this approach in the eyes of some.
      Not all people, not all companies are willing to adopt it. Many want to
      extract
      the "productivity" from Agile without adopting the spirit of it. Generally,
      they
      do that by skipping the values and cherry-picking practices to follow.
      Sometimes
      they achieve a modicum of success this way, sometimes not.

      Folks who value "agile adoption" rates over all else are happy to help
      them transform agile in this way and want to "count" them as Agile. Other
      folks are motivated by the fact that they work at a particular company,
      which
      will never adopt Agile as is, want to remain at that company and therefore
      have to adapt their practice to what's possible. You seem to fall into that
      second group.

      What you call the "social engineering" aspect of Agile has been there from
      the
      beginning. It's not something that has come up recently and it's certainly
      not
      something we need to apologize for. Very possibly, it could actually work at
      your company if someone were willing to try it. Very possibly, it might even
      be tried if someone like you were to press for it. Or maybe not.

      By the way, there's nothing in Agile that prevents the creation of an
      Application
      Architecture and Design group. The challenge for you - if you wanted to take
      it -
      would be to figure out how such a group might operate in an truly Agile
      manner.

      Charlie

      On Sat, Feb 26, 2011 at 3:50 AM, MarvinToll.com <MarvinToll@...>wrote:

      >
      >
      > Charlie,
      >
      > There is nothing 'wrong' with self-organizing teams... I personnally like
      > them.
      >
      > However, the tension arises when considering whether the 'Agile' movement
      > should stay focused on "working software" or continue down the path of using
      > "working software" as a wedge issue to promote social engineering.
      >
      > The significant words (to me) defining scope on the Agile Manifesto site
      > have always been:
      >
      > "Now, a bigger gathering of organizational anarchists would be hard to
      > find".
      >
      > The reason the notion of producing great "working software" without using a
      > self-organizing team is threatening... is because the movement is
      > (currently) not just about "working software". And the reason the notion of
      > a SLE producing great "working software" is threatening is because folks
      > instinctively (and probably correctly) understand that an SLE is not going
      > to typically empower project ("self-organizing") teams to establish their
      > own Application Architecture and Design independent of an Enterprise
      > context.
      >
      > My hope for the 2011 gathering at Snow Bird was that they would stop the
      > scope creep. Let 'Agile' be about "working software" and let some other
      > "organizational anarchists" carry-on about the social re-engineering of our
      > companies.
      >
      > _Marvin
      >
      >
      > --- In extremeprogramming@yahoogroups.com, Charlie Poole <charliepoole@...>
      > wrote:
      > >
      > > Hello Marvin,
      > >
      > > The principle of using self-organizing teams arises from valuing people
      > over
      > > process.
      > >
      > > What the notion of a "self-organizing team" means to me is that folks
      > doing
      > > the work
      > > should not have the details of that work over-specified. In the context
      > of
      > > corporate
      > > standards, it means that results should be specified, not means.
      > >
      > > I don't tend to use the offensive term "dogmatic" as you do, since it
      > causes
      > > adds
      > > more heat than light to any topic in which it comes up. However, if I
      > were
      > > to use it,
      > > I'd be most likely to apply it to those who tell others how to get their
      > > work done and
      > > not to those who believe such top-down direction is a bad idea.
      > >
      > > In an earlier note, you suggested we were in agreement regarding
      > diversity
      > > within
      > > the agile community. I think not. It appears to me that you are a
      > supporter
      > > of
      > > diversity of practice only to the extent it allows your company to foster
      > a
      > > non-agile
      > > value system while still calling it agile. Within your company, based on
      > > what you
      > > have told us, it seems that diversity in the practice of agile is
      > > discouraged, if not
      > > entirely forbidden.
      > >
      > > I will state it baldly as I believe it: if a team is not permitted to
      > > develop its own
      > > set of practices, that team is not working in an agile environment.
      > >
      > > Charlie
      > >
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Steven Gordon
      ... In decades of consulting with all sizes of companies in a variety of domains, I have never seen an independent architecture group stay relevant to the
      Message 2 of 20 , Feb 26, 2011
      • 0 Attachment
        On Sat, Feb 26, 2011 at 6:49 AM, Charlie Poole <charliepoole@...> wrote:
        > Hello Marvin,
        ...
        >
        > By the way, there's nothing in Agile that prevents the creation of an
        > Application
        > Architecture and Design group. The challenge for you - if you wanted to take
        > it -
        > would be to figure out how such a group might operate in an truly Agile
        > manner.

        In decades of consulting with all sizes of companies in a variety of
        domains, I have never seen an independent architecture group stay
        relevant to the teams delivering applications over the course of time.
        They may start out relevant, but they start anticipating trends, be
        it architectural or technological, and end up creating architectures
        that do not actually help teams deliver working software.

        I am not sure if it is the allure of looking into the future, the
        elitism inherent in being involved in a prestigious group whose
        mission is abstracted from delivering working software, or just
        forgetting about the cost of YAGNI, but it seems it is inevitable that
        the work the group produces plays a smaller and smaller role in the
        value stream over time. Management is often impressed by the grand
        plans and nice looking work, but it rarely (if ever) makes a
        substantial difference in the value produced over the long run. The
        opportunity costs of wasting your best talent on something that will
        not make a substantial difference should not be ignored.

        Forget about whether it is agile or Agile or ELIGA or whatever, it
        looks great but is unproductive in the long run. I do not understand
        how not pushing back on this idea that has failed time and again to
        deliver value commensurate with the investment is doing the right
        thing for the company you work for? It is not social engineering to
        explain to management why you believe an idea is bad.

        I have never seen the following done except in startups (I have always
        been rejected when I propose it to a client with an existing
        architecture team). But, I am convinced that if the members of an
        architecture team spent at least half their time directly
        collaborating with the application teams on what they are doing, then
        the remaining time they do work on shared architectures would be
        grounded in reality instead of technological evangelism or
        intellectual elitism. I believe this kind of architecture team can
        create shared code that will be useful as well as improve the quality
        of work in the application teams because the best minds in the company
        are directly helping and also spreading their skills through active
        collaboration on delivering working software.
      • MarvinToll.com
        Charlie, I don t need a manifesto to tell me to talk face-to-face with my team mates. I don t care if people talk face-to-face, back-to-back or side-by-side
        Message 3 of 20 , Feb 26, 2011
        • 0 Attachment
          Charlie,

          I don't need a manifesto to tell me to talk face-to-face with my team mates. I don't care if people talk face-to-face, back-to-back or side-by-side frankly.

          I don't need a manifesto to tell me my team needs to be self-organizing. I really don't care if the team is self-organizing or self-destructive.

          I don't care if a team is led by a Scrum Master or a Drum Major. I don't care if my architecture came from Pluto (which was a planet back when the Manifesto was written) or Mars.

          What I care about is "working software".

          And the scope of my interest as a change agent for an SLE is "working software". If they want someone to work the "organizational change" issue go hire a psychologist.

          And although the Manifesto had this inherent weakness from the beginning, over time the voices for "organizational change" may have gotten louder while the voices for "working software" may be more muted. Or, said another way, in my opinion "organizational change" chatter has become more of a dogmatic distraction than an enthusiastic enabler of "working software".

          _Marvin

          --- In extremeprogramming@yahoogroups.com, Charlie Poole <charliepoole@...> wrote:
          >
          > Hello Marvin,
          >
          > Ron has said we're off topic here... but I think one aspect of the
          > discussion is
          > relevant so I'm changing the subject line to indicate it. I think it would
          > be
          > helpful if folks who want to hit on some other aspects were to do the same.
          >
          > I'm glad - and surprised - that you do recognize the two different threads
          > present
          > in the agile movement. I had previously read your comments to mean that you
          > didn't actually understand that the promotion of organizational change was a
          >
          > part of it.
          >
          > It seems to me that this is not "scope creep" at all but is inherent in the
          > stated
          > Agile values, particularly the one that puts people over process. I believe
          > that the
          > agile movement has always had an underlying theme of social change. Some
          > practitioners stress it more and others making it less prominent, but it's
          > pretty
          > much always there, in the foreground or in the background as the case may
          > be.
          >
          > This is seen by some - apparently by you - as a weakness. It might be so
          > if it could be demonstrated that the two threads were inherently
          > contradictory.
          > But they aren't. It has been demonstrated repeatedly that we can have our
          > cake
          > and eat it too - we can empower folks to make their own choices of how they
          > work and (still? as a result?) end up producing great working software.
          >
          > There remains one residual "weakness" of this approach in the eyes of some.
          > Not all people, not all companies are willing to adopt it. Many want to
          > extract
          > the "productivity" from Agile without adopting the spirit of it. Generally,
          > they
          > do that by skipping the values and cherry-picking practices to follow.
          > Sometimes
          > they achieve a modicum of success this way, sometimes not.
          >
          > Folks who value "agile adoption" rates over all else are happy to help
          > them transform agile in this way and want to "count" them as Agile. Other
          > folks are motivated by the fact that they work at a particular company,
          > which
          > will never adopt Agile as is, want to remain at that company and therefore
          > have to adapt their practice to what's possible. You seem to fall into that
          > second group.
          >
          > What you call the "social engineering" aspect of Agile has been there from
          > the
          > beginning. It's not something that has come up recently and it's certainly
          > not
          > something we need to apologize for. Very possibly, it could actually work at
          > your company if someone were willing to try it. Very possibly, it might even
          > be tried if someone like you were to press for it. Or maybe not.
          >
          > By the way, there's nothing in Agile that prevents the creation of an
          > Application
          > Architecture and Design group. The challenge for you - if you wanted to take
          > it -
          > would be to figure out how such a group might operate in an truly Agile
          > manner.
          >
          > Charlie
          >
        • Steven Gordon
          Your teams are producing working software, so what is the problem? If quality or productivity is not what it should be, but you refuse to consider the affects
          Message 4 of 20 , Feb 26, 2011
          • 0 Attachment
            Your teams are producing working software, so what is the problem?

            If quality or productivity is not what it should be, but you refuse to
            consider the affects of how teams are organized, rewarded/penalized,
            encouraged/discouraged, and institutionally blocked, then you are just
            blinding yourself to many of the most critical factors. You will hit a
            wall, whether you call what you do agile or not (and whether or not the
            agile community considers what you do agile or not).

            Software developers are humans, not machines. Your industry has discovered
            that factory line workers do higher quality work more productively when the
            work environment is made more amenable to humans. Why would the same not be
            true for software developers?

            On Sat, Feb 26, 2011 at 9:53 AM, MarvinToll.com <MarvinToll@...>wrote:

            >
            >
            > Charlie,
            >
            > I don't need a manifesto to tell me to talk face-to-face with my team
            > mates. I don't care if people talk face-to-face, back-to-back or
            > side-by-side frankly.
            >
            > I don't need a manifesto to tell me my team needs to be self-organizing. I
            > really don't care if the team is self-organizing or self-destructive.
            >
            > I don't care if a team is led by a Scrum Master or a Drum Major. I don't
            > care if my architecture came from Pluto (which was a planet back when the
            > Manifesto was written) or Mars.
            >
            > What I care about is "working software".
            >
            > And the scope of my interest as a change agent for an SLE is "working
            > software". If they want someone to work the "organizational change" issue go
            > hire a psychologist.
            >
            > And although the Manifesto had this inherent weakness from the beginning,
            > over time the voices for "organizational change" may have gotten louder
            > while the voices for "working software" may be more muted. Or, said another
            > way, in my opinion "organizational change" chatter has become more of a
            > dogmatic distraction than an enthusiastic enabler of "working software".
            >
            > _Marvin
            >
            >


            [Non-text portions of this message have been removed]
          • Adam Sroka
            ... It goes back to the Lean concept of Respect for People, which is also the fifth value of XP. I like to believe that we are making the world a better place
            Message 5 of 20 , Feb 26, 2011
            • 0 Attachment
              On Sat, Feb 26, 2011 at 5:49 AM, Charlie Poole <charliepoole@...> wrote:
              >
              > What you call the "social engineering" aspect of Agile has been there from
              > the
              > beginning. It's not something that has come up recently and it's certainly
              > not
              > something we need to apologize for. Very possibly, it could actually work at
              > your company if someone were willing to try it. Very possibly, it might even
              > be tried if someone like you were to press for it. Or maybe not.
              >

              It goes back to the Lean concept of Respect for People, which is also
              the fifth value of XP. I like to believe that we are making the world
              a better place for workers. XP initially did that by focusing on the
              practices that clearly delivered value while providing ample feedback,
              to the possible exclusion of other things that we might have been
              asked to do in the past.

              If you really want to make the world better for workers, though, you
              probably have to elevate that to the folks who are placing demands on
              the team, which quickly bubbles up to the entire organization. Agile
              at the team level is not sufficient, but neither is the org level. You
              need both.

              > By the way, there's nothing in Agile that prevents the creation of an
              > Application
              > Architecture and Design group. The challenge for you - if you wanted to take
              > it -
              > would be to figure out how such a group might operate in an truly Agile
              > manner.
              >

              Who is the customer of the Architecture and Design Group? What service
              do they need? And what level of service is required to meet that need?
              If you can answer those questions then I think you can do it in an
              Agile way (Lean and Kanban can be a huge help too.) Otherwise I think
              it is worth considering that if you have a pool of people who have
              great design skills you should put those people where they will be
              most effective -- on the team.
            • Adam Sroka
              ... We value face-to-face because it is proven to be more effective and because it is a vastly more human way to work. Our manifesto reflects that value, and,
              Message 6 of 20 , Feb 26, 2011
              • 0 Attachment
                On Sat, Feb 26, 2011 at 8:53 AM, MarvinToll.com <MarvinToll@...> wrote:
                >
                >
                >
                > Charlie,
                >
                > I don't need a manifesto to tell me to talk face-to-face with my team mates. I don't care if people talk face-to-face, back-to-back or side-by-side frankly.
                >

                We value face-to-face because it is proven to be more effective and
                because it is a vastly more human way to work. Our manifesto reflects
                that value, and, speaking for myself, that is a big part of why I
                signed it. No one is telling you you must value this, but it might not
                be the right manifesto for you if you don't.

                > I don't need a manifesto to tell me my team needs to be self-organizing. I really don't care if the team is self-organizing or self-destructive.
                >

                Saying "I don't care if the team is self-destructive" is tantamount to
                saying "I don't care about the team." A self-destructing team is not
                pleasant for anyone and not productive either. This is not a way to
                produce value, let alone to make the world a better place for workers.
                This is a way to make the world a worse place for everyone.

                > I don't care if a team is led by a Scrum Master or a Drum Major. I don't care if my architecture came from Pluto (which was a planet back when the Manifesto was written) or Mars.
                >

                I don't care about those either. But, this is pretty far afield of
                Agile. Scrummasters and particular architectures are implementation
                details that have nothing to do with the values expressed in the
                manifesto.

                > What I care about is "working software".
                >

                Everyone, Agile or not, who is involved in software development in any
                capacity at any point in its lifecycle, cares about working software
                to some degree. The reason that it is mentioned in the manifesto is
                that we value it above other "deliverables" that the team could
                produce, possibly even to their exclusion.

                To me, simply caring that we actually produce a product at some point
                is an *exceptionally* low standard. It is the barrier to entry. If you
                don't care about producing a product then I don't even know how we can
                have a conversation. That alone is not sufficient to understand Agile.

                > And the scope of my interest as a change agent for an SLE is "working software". If they want someone to work the "organizational change" issue go hire a psychologist.
                >

                So, Agile is for psychologists and other charlatans. Fine. Why are we
                still talking about this???

                > And although the Manifesto had this inherent weakness from the beginning, over time the voices for "organizational change" may have gotten louder while the voices for "working software" may be more muted. Or, said another way, in my opinion "organizational change" chatter has become more of a dogmatic distraction than an enthusiastic enabler of "working software".
                >

                It is obvious to me that you don't believe what the folks who wrote
                the manifesto believed or what many of us who signed the manifesto
                believe. There is absolutely nothing wrong with that. Given that, how
                is it that we can help you? Because we aren't going to change what we
                believe any more than you are.
              • William Pietri
                ... I saw this done one place, and it definitely helped. Before the intervention, the architecture team was in the building on the corporate campus with the
                Message 7 of 20 , Feb 26, 2011
                • 0 Attachment
                  On 02/26/2011 08:50 AM, Steven Gordon wrote:
                  > I have never seen the following done except in startups (I have always
                  > been rejected when I propose it to a client with an existing
                  > architecture team). But, I am convinced that if the members of an
                  > architecture team spent at least half their time directly
                  > collaborating with the application teams on what they are doing, then
                  > the remaining time they do work on shared architectures would be
                  > grounded in reality instead of technological evangelism or
                  > intellectual elitism.

                  I saw this done one place, and it definitely helped.

                  Before the intervention, the architecture team was in the building on
                  the corporate campus with the execs; developers were elsewhere.
                  Architects produced a lot of white papers and mandates. Many of their
                  architectural ideas were idiocy. Those that weren't were routinely
                  reduced to idiocy by mechanical compliance from well-meaning developers
                  who a) didn't quite get what the architects were after, and b) were
                  numbed to low productivity and hideous code bases by all the other
                  architectural mandates.

                  Forcing the architects to be assigned to teams and work side by side
                  with them helped some. Better relationships, more understanding both
                  ways, less bullshit. However, the architecture team was a symptom rather
                  than the problem, so it definitely didn't solve everything.


                  > I believe this kind of architecture team can
                  > create shared code that will be useful as well as improve the quality
                  > of work in the application teams because the best minds in the company
                  > are directly helping and also spreading their skills through active
                  > collaboration on delivering working software.

                  I think it still has a risk: it rewards people for behaviors that may or
                  may not be helpful to customers.

                  Once you've created an architecture team, people are evaluated on
                  production of architecture. In a typical company, they're evaluated by
                  managers who either have no expertise in software (e.g., MBAs) or have
                  outdated expertise in software (former technologists now in management).
                  Neither is competent to judge content, so they are forced to judge on
                  surface details: e.g.: presentation, confidence, sounding smart, having
                  pretty graphs. And activity, of course, which is worst of all in that it
                  encourages maximum architecture, not the desired minimum.

                  The two patterns I've seen work well are a) a software commons and b)
                  infrastructure teams. In the first, you treat architecture like an
                  open-source project. Individuals on teams improve the software commons
                  as teams see it necessary. In the latter, you spin up separate teams
                  around parts of the commons, with those teams acting as suppliers to the
                  teams actually creating customer value.

                  I think the software commons approach is safer, because you have less
                  opportunity for conflicts of interest and tail-wags-the-dog problems.
                  But you do risk tragedy-of-the-commons issues, and it's easier for
                  libraries than for services.

                  William




                  [Non-text portions of this message have been removed]
                • MarvinToll.com
                  Adam, I think the Value is already stated in the Manifesto as [Value] Individuals . Mary Poppendieck ( http://www.poppendieck.com/ ) in her Seven Lean
                  Message 8 of 20 , Feb 26, 2011
                  • 0 Attachment
                    Adam,

                    I think the Value is already stated in the Manifesto as "[Value] Individuals".

                    Mary Poppendieck ( http://www.poppendieck.com/ ) in her Seven Lean Principles uses the term "Engage Everyone".

                    That's a far cry from a pedantic assertion saying I need to talk "face-to-face" with my teammates. Actually, some "face-to-face" conversation may not be respectful at all!

                    But alas... once again, we loose focus on "working software".

                    _Marvin

                    --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                    >
                    > It goes back to the Lean concept of Respect for People, which is also
                    > the fifth value of XP.
                  • marty.nelson
                    Marvin - I am the head of architecture at an ISV with a development organization of ~250 that serves the corporate enterprise (think big pharma). I have an
                    Message 9 of 20 , Feb 26, 2011
                    • 0 Attachment
                      Marvin -

                      I am the head of architecture at an ISV with a development organization of ~250 that serves the corporate enterprise (think big pharma). I have an architecture board of four other developers who are all also key members of development teams.

                      I have been able to apply agile values and principals to enterprise architecture, let me share some of my key discoveries:

                      * There is an organizational entity above product development teams, you can call that the enterprise, or the business, whatever. It too is self-organizing and has needs to which teams must be subservient (just like we need to balance individual autonomy within a self-organizing team). I largely view my role, and that of the architecture board, to facility that high-level self-organization.

                      * You must identify and come up with a strategy for addressing enterprise-level goals and objectives that will not be addressed by the bottom-up product feature backlogs. Enterprise is about more than point-solutions. You should be involved in high-level customer collaboration, what is the served-industry trying to accomplish?

                      * You need to have a working agreement with Product Management that some percentage of the capacity will be used to address technology driven issues.

                      * Architecture is about delivering working enterprise solutions. That means it is not done by coming up with a diagram or spec but rather it is done when all the teams involved execute successfully. You need to leverage Conway's Law as a tool and build communication structures to produce intentionally designed systems.

                      * Because the product backlog is the primary avenue for work to be done by teams, you must learn to articulate architectural goals in terms of value and intended outcome (just like any other feature). You need to put on a PM hat and feel what is like to direct through intention without specification.

                      * Use short-term spikes for information gathering and learning. You'll better results getting some key people together for a couple of days then by talking 'about' technology for weeks on end.

                      * Leverage your organizational size to advantage. Meet release dates by knowing where projects stand and making adjustments as necessary. Not about 'Resource Allocation', about helping one another and being creative.

                      XP /practices/ are team level practices. So you don't scale the practices when talking about the enterprise, you need to go back to the values and principals in order to find the enterprise-level architecture practices.

                      - Marty

                      --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                      >
                      > On Sat, Feb 26, 2011 at 5:49 AM, Charlie Poole <charliepoole@...> wrote:
                      > >
                      > > What you call the "social engineering" aspect of Agile has been there from
                      > > the
                      > > beginning. It's not something that has come up recently and it's certainly
                      > > not
                      > > something we need to apologize for. Very possibly, it could actually work at
                      > > your company if someone were willing to try it. Very possibly, it might even
                      > > be tried if someone like you were to press for it. Or maybe not.
                      > >
                      >
                      > It goes back to the Lean concept of Respect for People, which is also
                      > the fifth value of XP. I like to believe that we are making the world
                      > a better place for workers. XP initially did that by focusing on the
                      > practices that clearly delivered value while providing ample feedback,
                      > to the possible exclusion of other things that we might have been
                      > asked to do in the past.
                      >
                      > If you really want to make the world better for workers, though, you
                      > probably have to elevate that to the folks who are placing demands on
                      > the team, which quickly bubbles up to the entire organization. Agile
                      > at the team level is not sufficient, but neither is the org level. You
                      > need both.
                      >
                      > > By the way, there's nothing in Agile that prevents the creation of an
                      > > Application
                      > > Architecture and Design group. The challenge for you - if you wanted to take
                      > > it -
                      > > would be to figure out how such a group might operate in an truly Agile
                      > > manner.
                      > >
                      >
                      > Who is the customer of the Architecture and Design Group? What service
                      > do they need? And what level of service is required to meet that need?
                      > If you can answer those questions then I think you can do it in an
                      > Agile way (Lean and Kanban can be a huge help too.) Otherwise I think
                      > it is worth considering that if you have a pool of people who have
                      > great design skills you should put those people where they will be
                      > most effective -- on the team.
                      >
                    • MarvinToll.com
                      Steve, It is great to have happy teams. But for someone in Utah 10 years ago to presume that my team will be happy with face-to-face conversation and being
                      Message 10 of 20 , Feb 26, 2011
                      • 0 Attachment
                        Steve,

                        It is great to have happy teams. But for someone in Utah 10 years ago to presume that my team will be happy with "face-to-face" conversation and being "self-organizing" may or may not be true.

                        I think Value #1 sufficiently makes the case and there is no need for such prescriptive kindergarten assertions tacked on as "Principles".

                        _Marvin

                        --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
                        >
                        > Your teams are producing working software, so what is the problem?
                        >
                        > If quality or productivity is not what it should be, but you refuse to
                        > consider the affects of how teams are organized, rewarded/penalized,
                        > encouraged/discouraged, and institutionally blocked, then you are just
                        > blinding yourself to many of the most critical factors. You will hit a
                        > wall, whether you call what you do agile or not (and whether or not the
                        > agile community considers what you do agile or not).
                        >
                        > Software developers are humans, not machines. Your industry has discovered
                        > that factory line workers do higher quality work more productively when the
                        > work environment is made more amenable to humans. Why would the same not be
                        > true for software developers?
                        >
                        > On Sat, Feb 26, 2011 at 9:53 AM, MarvinToll.com <MarvinToll@...>wrote:
                        >
                        > >
                        > >
                        > > Charlie,
                        > >
                        > > I don't need a manifesto to tell me to talk face-to-face with my team
                        > > mates. I don't care if people talk face-to-face, back-to-back or
                        > > side-by-side frankly.
                        > >
                        > > I don't need a manifesto to tell me my team needs to be self-organizing. I
                        > > really don't care if the team is self-organizing or self-destructive.
                        > >
                        > > I don't care if a team is led by a Scrum Master or a Drum Major. I don't
                        > > care if my architecture came from Pluto (which was a planet back when the
                        > > Manifesto was written) or Mars.
                        > >
                        > > What I care about is "working software".
                        > >
                        > > And the scope of my interest as a change agent for an SLE is "working
                        > > software". If they want someone to work the "organizational change" issue go
                        > > hire a psychologist.
                        > >
                        > > And although the Manifesto had this inherent weakness from the beginning,
                        > > over time the voices for "organizational change" may have gotten louder
                        > > while the voices for "working software" may be more muted. Or, said another
                        > > way, in my opinion "organizational change" chatter has become more of a
                        > > dogmatic distraction than an enthusiastic enabler of "working software".
                        > >
                        > > _Marvin
                        > >
                        > >
                        >
                        >
                        > [Non-text portions of this message have been removed]
                        >
                      • MarvinToll.com
                        Marty, Thanks! I want to study this to compare and contrast with our approach. Ron... is this a conversation we should continue here in a few days or take
                        Message 11 of 20 , Feb 26, 2011
                        • 0 Attachment
                          Marty,

                          Thanks! I want to study this to compare and contrast with our approach.

                          Ron... is this a conversation we should continue here in a few days or take elsewhere?

                          _Marvin

                          --- In extremeprogramming@yahoogroups.com, "marty.nelson" <noslenytram@...> wrote:
                          >
                          > Marvin -
                          >
                          > I am the head of architecture at an ISV with a development organization of ~250 that serves the corporate enterprise (think big pharma). I have an architecture board of four other developers who are all also key members of development teams.
                          >
                          > I have been able to apply agile values and principals to enterprise architecture, let me share some of my key discoveries:
                          >
                          > * There is an organizational entity above product development teams, you can call that the enterprise, or the business, whatever. It too is self-organizing and has needs to which teams must be subservient (just like we need to balance individual autonomy within a self-organizing team). I largely view my role, and that of the architecture board, to facility that high-level self-organization.
                          >
                          > * You must identify and come up with a strategy for addressing enterprise-level goals and objectives that will not be addressed by the bottom-up product feature backlogs. Enterprise is about more than point-solutions. You should be involved in high-level customer collaboration, what is the served-industry trying to accomplish?
                          >
                          > * You need to have a working agreement with Product Management that some percentage of the capacity will be used to address technology driven issues.
                          >
                          > * Architecture is about delivering working enterprise solutions. That means it is not done by coming up with a diagram or spec but rather it is done when all the teams involved execute successfully. You need to leverage Conway's Law as a tool and build communication structures to produce intentionally designed systems.
                          >
                          > * Because the product backlog is the primary avenue for work to be done by teams, you must learn to articulate architectural goals in terms of value and intended outcome (just like any other feature). You need to put on a PM hat and feel what is like to direct through intention without specification.
                          >
                          > * Use short-term spikes for information gathering and learning. You'll better results getting some key people together for a couple of days then by talking 'about' technology for weeks on end.
                          >
                          > * Leverage your organizational size to advantage. Meet release dates by knowing where projects stand and making adjustments as necessary. Not about 'Resource Allocation', about helping one another and being creative.
                          >
                          > XP /practices/ are team level practices. So you don't scale the practices when talking about the enterprise, you need to go back to the values and principals in order to find the enterprise-level architecture practices.
                          >
                          > - Marty
                          >
                          > --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@> wrote:
                          > >
                          > > On Sat, Feb 26, 2011 at 5:49 AM, Charlie Poole <charliepoole@> wrote:
                          > > >
                          > > > What you call the "social engineering" aspect of Agile has been there from
                          > > > the
                          > > > beginning. It's not something that has come up recently and it's certainly
                          > > > not
                          > > > something we need to apologize for. Very possibly, it could actually work at
                          > > > your company if someone were willing to try it. Very possibly, it might even
                          > > > be tried if someone like you were to press for it. Or maybe not.
                          > > >
                          > >
                          > > It goes back to the Lean concept of Respect for People, which is also
                          > > the fifth value of XP. I like to believe that we are making the world
                          > > a better place for workers. XP initially did that by focusing on the
                          > > practices that clearly delivered value while providing ample feedback,
                          > > to the possible exclusion of other things that we might have been
                          > > asked to do in the past.
                          > >
                          > > If you really want to make the world better for workers, though, you
                          > > probably have to elevate that to the folks who are placing demands on
                          > > the team, which quickly bubbles up to the entire organization. Agile
                          > > at the team level is not sufficient, but neither is the org level. You
                          > > need both.
                          > >
                          > > > By the way, there's nothing in Agile that prevents the creation of an
                          > > > Application
                          > > > Architecture and Design group. The challenge for you - if you wanted to take
                          > > > it -
                          > > > would be to figure out how such a group might operate in an truly Agile
                          > > > manner.
                          > > >
                          > >
                          > > Who is the customer of the Architecture and Design Group? What service
                          > > do they need? And what level of service is required to meet that need?
                          > > If you can answer those questions then I think you can do it in an
                          > > Agile way (Lean and Kanban can be a huge help too.) Otherwise I think
                          > > it is worth considering that if you have a pool of people who have
                          > > great design skills you should put those people where they will be
                          > > most effective -- on the team.
                          > >
                          >
                        • Adam Sroka
                          On Sat, Feb 26, 2011 at 10:05 AM, MarvinToll.com ... you forgot and Interactions... ... Respect for People is one of the two pillars of TPS and most
                          Message 12 of 20 , Feb 26, 2011
                          • 0 Attachment
                            On Sat, Feb 26, 2011 at 10:05 AM, MarvinToll.com
                            <MarvinToll@...> wrote:
                            >
                            >
                            >
                            > Adam,
                            >
                            > I think the Value is already stated in the Manifesto as "[Value] Individuals".
                            >

                            you forgot "and Interactions..."

                            > Mary Poppendieck ( http://www.poppendieck.com/ ) in her Seven Lean Principles uses the term "Engage Everyone".
                            >

                            Respect for People is one of the two pillars of TPS and most
                            interpretations of Lean incorporate it somehow. In fact, a quick
                            google search shows that the majority of top ranked results for
                            "respect for people" are about Lean. Respect is also an XP value that
                            was added some time after the first edition of the white book.

                            > That's a far cry from a pedantic assertion saying I need to talk "face-to-face" with my teammates. Actually, some "face-to-face" conversation may not be respectful at all!
                            >

                            Who's being pedantic? "Face-to-face" is an idiom that means "while
                            physically present." The willingness to be physically present and
                            engaged shows a certain amount of respect. There are other ways to
                            show respect, but saying that we don't care about being physically
                            present doesn't demonstrate any.

                            > But alas... once again, we loose focus on "working software".
                            >

                            Bullshit. No one ever said working software to the exclusion of all
                            else. Your attempts to reduce it to that are not going to work.

                            > _Marvin
                            >
                            > --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                            > >
                            > > It goes back to the Lean concept of Respect for People, which is also
                            > > the fifth value of XP.
                            >
                            >
                          • Curtis Cooley
                            ... So is the assertion here that a reference implementation is a better communication medium than face to face communication. That back in the day when I was
                            Message 13 of 20 , Feb 26, 2011
                            • 0 Attachment
                              On Sat, Feb 26, 2011 at 10:33 AM, Adam Sroka <adam.sroka@...> wrote:
                              > On Sat, Feb 26, 2011 at 10:05 AM, MarvinToll.com
                              > <MarvinToll@...> wrote:
                              >>
                              >>
                              >>
                              >> Adam,
                              >>
                              >> I think the Value is already stated in the Manifesto as "[Value] Individuals".
                              >>
                              >
                              > you forgot "and Interactions..."
                              >
                              >> Mary Poppendieck ( http://www.poppendieck.com/ ) in her Seven Lean Principles uses the term "Engage Everyone".
                              >>
                              >
                              > Respect for People is one of the two pillars of TPS and most
                              > interpretations of Lean incorporate it somehow. In fact, a quick
                              > google search shows that the majority of top ranked results for
                              > "respect for people" are about Lean. Respect is also an XP value that
                              > was added some time after the first edition of the white book.
                              >
                              >> That's a far cry from a pedantic assertion saying I need to talk "face-to-face" with my teammates. Actually, some "face-to-face" conversation may not be respectful at all!
                              >>
                              >
                              > Who's being pedantic? "Face-to-face" is an idiom that means "while
                              > physically present." The willingness to be physically present and
                              > engaged shows a certain amount of respect. There are other ways to
                              > show respect, but saying that we don't care about being physically
                              > present doesn't demonstrate any.
                              >

                              So is the assertion here that a reference implementation is a better
                              communication medium than face to face communication. That back in the
                              day when I was learning web application development, I was actually
                              better off reading the Tomcat code than I would have been if a Sun or
                              Apache developer/architect had been sitting side by side with me and
                              walking me through the architecture. Is that the assumption? Really?

                              --
                              Curtis Cooley
                              curtis.cooley@...
                              home:http://curtiscooley.com
                              blog:http://ponderingobjectorienteddesign.blogspot.com
                              ===============
                              Leadership is a potent combination of strategy and character. But if
                              you must be without one, be without the strategy.
                              -- H. Norman Schwarzkopf
                            • Ron Jeffries
                              Hello, MarvinToll.com. On Saturday, February 26, 2011, at 1:12:23 ... I asked you privately to show some respect. Now I m asking you publicly. Ron Jeffries
                              Message 14 of 20 , Feb 26, 2011
                              • 0 Attachment
                                Hello, MarvinToll.com. On Saturday, February 26, 2011, at 1:12:23
                                PM, you wrote:

                                > I think Value #1 sufficiently makes the case and there is no need
                                > for such prescriptive kindergarten assertions tacked on as "Principles".

                                I asked you privately to show some respect. Now I'm asking you
                                publicly.

                                Ron Jeffries
                                www.XProgramming.com
                                How many Elephant Points are there in the veldt? Let's conduct a poll
                                of the herds. Herd A reports 50,000 kg. Herd B report 84 legs. Herd C
                                reports 92,000 lb. Herd D reports 24 head. Herd E reports 546 elephant
                                sounds per day. Herd F reports elephant skin rgb values of (192, 192, 192).
                                Herd G reports an average height of 11 ft. So, there are 50,000 +
                                84 + 92,000 + 24 + 546 + 192 + 11 = 142,857 Elephant Points in the
                                veldt. The average herd has 20,408.142857143 Elephant Points. We know
                                this is a useful number because there is a decimal point in it.
                                -- Dave Nicolette
                              • Ron Jeffries
                                Hello, MarvinToll.com. On Saturday, February 26, 2011, at 1:33:32 ... It can be here if you and others will tone down the disrespectful rhetoric. Let s face
                                Message 15 of 20 , Feb 26, 2011
                                • 0 Attachment
                                  Hello, MarvinToll.com. On Saturday, February 26, 2011, at 1:33:32
                                  PM, you wrote:

                                  > Thanks! I want to study this to compare and contrast with our approach.

                                  > Ron... is this a conversation we should continue here in a few days or take elsewhere?

                                  It can be here if you and others will tone down the disrespectful
                                  rhetoric.

                                  Let's face it, gentlepersons, when it seems disrespectful to me, it
                                  is going way too far.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  Make it real or else forget about it -- Carlos Santana
                                • Charlie Poole
                                  Hello Marvin, ... That s ONE of the four values of the Agile Manifesto. If you stick with just that you re NOT aiming to be agile. ... software . If they want
                                  Message 16 of 20 , Feb 26, 2011
                                  • 0 Attachment
                                    Hello Marvin,

                                    > What I care about is "working software".

                                    That's ONE of the four values of the Agile Manifesto. If you stick with just
                                    that
                                    you're NOT aiming to be agile.

                                    > And the scope of my interest as a change agent for an SLE is "working
                                    software". If they want someone to work the "organizational change" issue go
                                    hire a psychologist.

                                    Again, that's fine, it's just not the entirety of what we call Agile, if
                                    organizational
                                    change is what's needed to incorporate the other values.

                                    > And although the Manifesto had this inherent weakness from the beginning,
                                    over time the voices for "organizational change" may have gotten louder
                                    while the voices for "working software" may be more muted. Or, said another
                                    way, in my opinion "organizational change" chatter has become more of a
                                    dogmatic distraction than an enthusiastic enabler of "working software".

                                    Do you get that many - maybe most - of us don't consider it a weakness?
                                    I'm asking because it really isn't clear.

                                    Introducing agile - or even 25% of agile - is about organizational change.
                                    The notion that the changes should only take place within the programming
                                    teams is a ridiculous limitation.

                                    Given the willingness of folks here to engage with you and try to explore
                                    your point of view - as foreign as it is to many of us - calling us
                                    "dogmatic"
                                    is quite a stretch - not to mention rather rude on your part.

                                    Charlie


                                    > _Marvin
                                    >
                                    > --- In extremeprogramming@yahoogroups.com, Charlie Poole <charliepoole@...>
                                    > wrote:
                                    > >
                                    > > Hello Marvin,
                                    > >
                                    > > Ron has said we're off topic here... but I think one aspect of the
                                    > > discussion is
                                    > > relevant so I'm changing the subject line to indicate it. I think it
                                    > would
                                    > > be
                                    > > helpful if folks who want to hit on some other aspects were to do the
                                    > same.
                                    > >
                                    > > I'm glad - and surprised - that you do recognize the two different
                                    > threads
                                    > > present
                                    > > in the agile movement. I had previously read your comments to mean that
                                    > you
                                    > > didn't actually understand that the promotion of organizational change
                                    > was a
                                    > >
                                    > > part of it.
                                    > >
                                    > > It seems to me that this is not "scope creep" at all but is inherent in
                                    > the
                                    > > stated
                                    > > Agile values, particularly the one that puts people over process. I
                                    > believe
                                    > > that the
                                    > > agile movement has always had an underlying theme of social change. Some
                                    > > practitioners stress it more and others making it less prominent, but
                                    > it's
                                    > > pretty
                                    > > much always there, in the foreground or in the background as the case may
                                    > > be.
                                    > >
                                    > > This is seen by some - apparently by you - as a weakness. It might be so
                                    > > if it could be demonstrated that the two threads were inherently
                                    > > contradictory.
                                    > > But they aren't. It has been demonstrated repeatedly that we can have our
                                    > > cake
                                    > > and eat it too - we can empower folks to make their own choices of how
                                    > they
                                    > > work and (still? as a result?) end up producing great working software.
                                    > >
                                    > > There remains one residual "weakness" of this approach in the eyes of
                                    > some.
                                    > > Not all people, not all companies are willing to adopt it. Many want to
                                    > > extract
                                    > > the "productivity" from Agile without adopting the spirit of it.
                                    > Generally,
                                    > > they
                                    > > do that by skipping the values and cherry-picking practices to follow.
                                    > > Sometimes
                                    > > they achieve a modicum of success this way, sometimes not.
                                    > >
                                    > > Folks who value "agile adoption" rates over all else are happy to help
                                    > > them transform agile in this way and want to "count" them as Agile. Other
                                    > > folks are motivated by the fact that they work at a particular company,
                                    > > which
                                    > > will never adopt Agile as is, want to remain at that company and
                                    > therefore
                                    > > have to adapt their practice to what's possible. You seem to fall into
                                    > that
                                    > > second group.
                                    > >
                                    > > What you call the "social engineering" aspect of Agile has been there
                                    > from
                                    > > the
                                    > > beginning. It's not something that has come up recently and it's
                                    > certainly
                                    > > not
                                    > > something we need to apologize for. Very possibly, it could actually work
                                    > at
                                    > > your company if someone were willing to try it. Very possibly, it might
                                    > even
                                    > > be tried if someone like you were to press for it. Or maybe not.
                                    > >
                                    > > By the way, there's nothing in Agile that prevents the creation of an
                                    > > Application
                                    > > Architecture and Design group. The challenge for you - if you wanted to
                                    > take
                                    > > it -
                                    > > would be to figure out how such a group might operate in an truly Agile
                                    > > manner.
                                    > >
                                    > > Charlie
                                    > >
                                    >
                                    >
                                    >


                                    [Non-text portions of this message have been removed]
                                  • MarvinToll.com
                                    I was also surprised to see the Engage Everyone principle... here is Mary s assertion: The principles are as stable as they ever have been, which is to say
                                    Message 17 of 20 , Feb 26, 2011
                                    • 0 Attachment
                                      I was also surprised to see the "Engage Everyone" principle... here is Mary's assertion:

                                      "The principles are as stable as they ever have been, which is to say I change the wording every year or two as the meaning of the words degrade and we find better ones to express the same things. :-)"

                                      As a change agent, I appreciate the qualitative difference between letting the Manifesto grow "stale" and a committment to keeping a set of principles "fresh" and "relevant" --- to be used as a relevant tool for communicating to an SLE.

                                      --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                      >
                                      >
                                      > > Mary Poppendieck ( http://www.poppendieck.com/ ) in her Seven Lean Principles uses the term "Engage Everyone".
                                      > >
                                      >
                                      > Respect for People is one of the two pillars of TPS and most
                                      > interpretations of Lean incorporate it somehow. In fact, a quick
                                      > google search shows that the majority of top ranked results for
                                      > "respect for people" are about Lean. Respect is also an XP value that
                                      > was added some time after the first edition of the white book.
                                      >
                                    • Adam Sroka
                                      ... Right, but you also have to recognize the fundamental differences between what Mary is doing and what the manifesto team did. What Mary is doing is taking
                                      Message 18 of 20 , Feb 26, 2011
                                      • 0 Attachment
                                        On Sat, Feb 26, 2011 at 1:22 PM, MarvinToll.com <MarvinToll@...> wrote:
                                        >
                                        >
                                        >
                                        > I was also surprised to see the "Engage Everyone" principle... here is Mary's assertion:
                                        >
                                        > "The principles are as stable as they ever have been, which is to say I change the wording every year or two as the meaning of the words degrade and we find better ones to express the same things. :-)"
                                        >

                                        Right, but you also have to recognize the fundamental differences
                                        between what Mary is doing and what the manifesto team did. What Mary
                                        is doing is taking someone's existing idea and attempting to
                                        articulate its relevance to software people. Her notion that she can
                                        change how she expresses it and the underlying principles remain true
                                        is an unavoidable consequence of the fact that it is someone else's
                                        principles she is conveying.

                                        What the manifesto team did was different. They were bringing together
                                        a diverse community of people and ideas and trying to express the
                                        things they had in common in a mutually agreeable way.

                                        The former is like a conduit that conveys ideas from one place to
                                        another, translating them into the language that is understood by the
                                        folks at the destination. The latter is like a pureed salad -- where a
                                        uniform essence has been extracted from an otherwise complex
                                        landscape.

                                        > As a change agent, I appreciate the qualitative difference between letting the Manifesto grow "stale" and a committment to keeping a set of principles "fresh" and "relevant" --- to be used as a relevant tool for communicating to an SLE.
                                        >

                                        So, if you want to communicate what your values are, and then change
                                        the wording as often as necessary, I say go for it. The Agile
                                        Manifesto is about the things that a small community of people saw as
                                        common values, and signing it is about a show of solidarity around the
                                        common goals that those values reflect. As our values change we may
                                        move away from the Agile Manifesto, but that is just a sign that we
                                        should go sign another manifesto, not that the manifesto itself should
                                        change.

                                        > --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                        > >
                                        > >
                                        > > > Mary Poppendieck ( http://www.poppendieck.com/ ) in her Seven Lean Principles uses the term "Engage Everyone".
                                        > > >
                                        > >
                                        > > Respect for People is one of the two pillars of TPS and most
                                        > > interpretations of Lean incorporate it somehow. In fact, a quick
                                        > > google search shows that the majority of top ranked results for
                                        > > "respect for people" are about Lean. Respect is also an XP value that
                                        > > was added some time after the first edition of the white book.
                                        > >
                                        >
                                        >
                                      • MarvinToll.com
                                        FYI - Mary Poppendieck s recently revised seven Lean Software Developement Principles are available as a PDF at http://AgileAndBeyond.org/downloads.html
                                        Message 19 of 20 , Mar 2, 2011
                                        • 0 Attachment
                                          FYI - Mary Poppendieck's recently revised seven "Lean Software Developement Principles" are available as a PDF at http://AgileAndBeyond.org/downloads.html

                                          --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@...> wrote:
                                          >
                                          > I was also surprised to see the "Engage Everyone" principle... here is Mary's assertion:
                                          >
                                          > "The principles are as stable as they ever have been, which is to say I change the wording every year or two as the meaning of the words degrade and we find better ones to express the same things. :-)"
                                          >
                                        • Michael Hill
                                          I wish y all would think of all the billions of little baby bits you re using up *every* *single* *day* of these endless threads. Please. Think of the
                                          Message 20 of 20 , Mar 2, 2011
                                          • 0 Attachment
                                            I wish y'all would think of all the billions of little baby bits you're
                                            using up *every* *single* *day* of these endless threads.

                                            Please. Think of the children.


                                            [Non-text portions of this message have been removed]
                                          Your message has been successfully submitted and would be delivered to recipients shortly.