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

What about Scrum + CI + Automated-Tests?

Expand Messages
  • Brad Appleton
    I have a question for the group. After multiple experiences and then reading James Shore s The Decline and Fall of Agile (see
    Message 1 of 49 , Dec 21, 2008
      I have a question for the group. After multiple experiences and then
      reading James Shore's "The Decline and Fall of Agile" (see
      http://www.infoq.com/news/2008/11/decline-of-agile) ...

      I have a concern that I think is important, but am having trouble
      getting others to see/agree ...

      We agree that doing Scrum (or even XP) without the technical practices
      is *not* sufficient to see the benefits of agility. But what about if
      I'm doing Scrum *and* Continuous-Integration *and* automated testing
      (both unit-tests and acceptance tests), but I am NOT doing TDD and I am
      NOT doing refactoring?

      My knowledge and experience tells me that Scrum helps set up the
      feedback loops of iterations and daily-standups, and that CI sets up the
      teams inner-feedback loop (e.g., hourly or so). SO, GREAT, I have
      frequent feedback loops in place at the per-iteration, daily, and hourly
      "levels" to help me sense and respond to the need for change.

      But without the ability to actually make the changes quickly and easily,
      and without acknowledging the importance of the need to make changes
      that make the software easy to change, arent I still setting myself up
      for (most) of the same failure that James Shore is describing?

      Supposing the group in question is pretty darn good (or at least
      believes themselves to be) pretty darn good at up-front architecture and
      design? And suppose they do have very low defects?

      --
      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
    • Brad Appleton
      ... Would that it were my call. Actually, I did do this for my own department. For other groups in the organization, all I can do is recommend. I tend to base
      Message 49 of 49 , Dec 25, 2008
        Ron Jeffries wrote:
        > > If we had some sort of "average" backlog-item size (a semi-nebulous unit
        > > of time) then amount of those per unit time might be an improvement over
        > > what is used today.
        >
        > Pick one?

        Would that it were my call. Actually, I did do this for my own
        department. For other groups in the organization, all I can do is
        recommend. I tend to base my recommendation based largely on what they
        are currently using and familiar with that might work.

        One group uses MkII function points with great success. Another uses
        "use-cases", but with a constraint on the "size" of the use-case (which
        look ssuspiciously like it would have to be no bigger then could fit on
        an index-card of a certain size :-). Yet another group insists on using
        "shall" statements in their formal reqts specs, and so uses shall-stmts
        implemented. Another uses test-cases. Another makes use of model-driven
        code, and whether code is generated or hand-crafted, they can generate a
        corresponding UML model for it. And they use #of model elements implemented.

        All of which basically goes to prove your original point of "pick one".
        Any suitable "proxy" will do as long as it has some reasonable
        relationship to amount of functionality (or even effort) rather than
        amount of code.

        --
        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.