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

Re: [scrumdevelopment] Simple ain't Easy: Myths and Misunderstandings about S...

Expand Messages
  • Brad Appleton
    ... Agreed. And recognizing which details of the problem-to-be-solved are essential and should remain, versus which are incidental and should be removed,
    Message 1 of 2 , Jun 7, 2006
    • 0 Attachment
      PaulOldfield1@... wrote:
      > (responding to Brad)
      > > I guess here I'm thinking about the underlying problem to be
      > > solved. The problem to be solved may likely be quite complex
      > > (not-simple). And I'm going to assert that a great deal of the
      > > complexity inherent in the underlying problem has a high
      > > likelihood of being present in the solution too.
      >
      > Part of the job of the analyst is to remove as much as possible
      > of the complexity of the problem as presented. You do talk of
      > the 'underlying' problem. IME many systems need a lot of
      > detail to solve what is fundamentally a simple problem. Here
      > dealing with the detail is much easier once the problem has
      > been reduced to its simple form. There are, of course, some
      > complex problems; and of course dealing with the detail
      > brings more problems.

      Agreed. And recognizing which "details" of the problem-to-be-solved are
      "essential" and should remain, versus which are incidental and should be
      removed, is no "simple" task :-)

      When I wrote the blog-entry on "Simple Ain't Easy", one of the recurring
      experiences that fueled my writing was the scenario of having and
      existing problem, and an existing solution currently in place that is
      falling short somehow. It is meeting someone's need, but its not meeting
      the needs of all the stakeholders involved:
      * It may be "simple" (easy) for the project-manager, or the CM "lord",
      or the QA "queen", but its not meeting the needs of the developer or
      imposing undue burden upon them.
      * Or it may be "fine" for the developers, who may not care for or may
      not be directly exposed to the business-consequences that the
      program-mgr or CM or QA person face

      I run into common organizational dysfunctions such as "warring tribes"
      and "stovepipe-syndrome" a lot, where folks claim to be consensus-based,
      but are really just trying to worry about their own piece of the puzzle
      rather than the "whole" project or the "whole" team, and treat a problem
      in the overall "system" as a shared problem and take shared
      responsibility for solving it *together*.

      So even tho it can be demonstrated that "the whole" system isnt
      ultimately producing the correct result, and it can be demonstrated that
      some "need", or previously dismissed domain-entity, or inaccurate
      assumption is at the crux of the failure, getting them to accept and
      acknowledge that something "is broke" and needs fixing (and it might
      mean they have to change some of their thinking/behavior) is very
      frustrating. Because its difficult to get them past the frame of mind of
      whether or not it works "for them" to move to the frame of mind
      concerned with whether or not "the whole system" is working.

      And it is commonplace to see/hear them resist in the name of
      "simplicity", and wanting to "keep it simple" when theyre really talking
      about whether its easy/hard, or whether their suboptimized subpart fits
      in to the larger context (and needs) of the whole. And I see obviously
      broken and/or complex solutions defended in the name of simplicity and
      resistance against something that does demonstrably make "the whole"
      less complex. Because they mostly don't want to have to adjust their
      ways of thinking and/or valuing things "outside their box"
      --
      Brad Appleton <brad {AT} bradapp.net>
      Agile CM Environments (http://blog.bradapp.net/)
      & Software CM Patterns (www.scmpatterns.com)
      "And miles to go before I sleep" -- Robert Frost
    Your message has been successfully submitted and would be delivered to recipients shortly.