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

Re: [XP] Re: Agile is not always the right option

Expand Messages
  • Charlie Poole
    Hi George, I have the same misgivings and I ve seen some really bad examples of high level groups intended to foster agile, but degenerating into yet another
    Message 1 of 95 , Oct 14, 2010
      Hi George,

      I have the same misgivings and I've seen some really bad examples
      of high level groups intended to foster agile, but degenerating into
      yet another version of the "process police."

      OTOH, I wouldn't want to tell someone not to try it if they had the right
      motives and were willing to put into place some mechanism to prevent
      that sort of outcome. It would have to be quite explicit and I'm not sure
      it's a very efficient use of time anyway, but it's an idea. Maybe some sort
      of "agile ombudsman" with the power to say "Wait a minute ARB,
      you're getting too big for your britches!"

      Of course, having such power and using it could be a career killer. :-(


      On Thu, Oct 14, 2010 at 6:03 AM, George Dinwiddie
      <lists@...> wrote:
      > Hi, Marvin,
      > On 10/13/10 11:24 PM, MarvinToll.com wrote:
      >> George... my apologies... I'm just not up for another round of public
      >> discussion about Principle #11.
      >> However, I did hear three sessions today with Ivar Jacobson of IJI.
      >> I was initially skeptical because of his past affiliation.
      >> However, his current views were encouraging.  He went right after the
      >> challenge of scaling agile within a Successful Large Enterprise (SLE)
      >> and the tension between the notion of the 'self-organizing team' and
      >> 'enterprise application architecture'.
      >> His suggestion was a Technical Review Board (ARB).  Although the term
      >> is dated, I understood him to say the scope could be defined as those
      >> issues that have enterprise significance.
      >> In other words, there may be a huge architecture/design issue but if
      >> it does not impact the enterprise it is solely in the
      >> 'self-organizing' team's space.  Conversely, a minor issue for the
      >> team might have enterprise significance so it shows up on the ARB
      >> agenda.
      >> I can not speak to the effectiveness of an ARB instantiation with a
      >> stated intent of seeking to preserve the sanctity of the
      >> 'self-organizing team'.  It intuitively seems that trust and respect
      >> would be key enablers.
      >> Anyone try this approach within a large company?
      > I share Steven's misgivings with this approach.  Instead, I /have/ tried
      > to encourage spreading those people who tend to look at the enterprise
      > architectural issues across the teams, as members, and having them form
      > an association to discover and discuss issues and opportunities.  I
      > encourage similar associations by role across teams for other roles, also.
      >  - George
      > --
      >  ----------------------------------------------------------------------
      >   * George Dinwiddie *                      http://blog.gdinwiddie.com
      >   Software Development                    http://www.idiacomputing.com
      >   Consultant and Coach                    http://www.agilemaryland.org
      >  ----------------------------------------------------------------------
      > ------------------------------------
      > To Post a message, send it to:   extremeprogramming@...
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      > ad-free courtesy of objectmentor.comYahoo! Groups Links
    • James Grenning
      ... hey if your requirements do not change, cool. Does your understand of them change? Does your knowledge of the solution change? ... In an embedded context,
      Message 95 of 95 , Oct 17, 2010
        On Oct 14, 2010, at 11:19 AM, Vlietstra, Joe (ES) wrote:

        > > Which of the 12 principles at
        > http://agilemanifesto.org/principles.html
        > > do you find not generally applicable?
        > OK, I've followed this thread and resisted jumping in until now.
        > In our area (embedded spacecraft software), we run into difficulties
        > with:
        > -- Welcome changing requirements, even late in development...
        hey if your requirements do not change, cool. Does your understand of them change? Does your knowledge of the solution change?
        > -- Deliver working software frequently...
        In an embedded context, I like to think of this one as regular visible progress. Not just documents that say how the code/system is expected to work and may be designed, but working slices of functionality backed by automated test to keep them working.

        > Time window in which 100% agile development makes sense is bracketed by:
        > -- Availability of hardware
        > Hardware is not usually available in the early part of the project.
        > We usually spend this time working on requirements and design simply
        > because we can't develop code.
        When I first saw TDD in Extreme Programming back in 1999 I immediately saw it as a part of the solution to the "we don't have hardware" problem.
        You can choose to dual target your code, making sure that certain code is independent of the hardware. This lets many unit tests and story tests run off the target platform. When you finally get your target hardware, you know that much of the code behaves per your tests off the target. You can then run them in the target as well.

        This approach also encourages better design by managing the dependency on the target hardware

        There is more to the target hardware bottle neck than just no hardware at the beginning of a development effort. You also have to deal with
        hardware that has defects
        long edit, build, load and test cycles
        scarse hardware that everyone needs

        When and if you have a target, you can also run tests on the target. Differences in execution and portability problems come to the surface.
        > Although it's possible to code/test
        > on a simulated platform, this hasn't worked out well in practice
        > since most of the "interesting" development is for new hardware.
        BTW: using TDD for embedded does not mean you need a simulated platform. Using stubs, fakes and mocks allow unit tests, as well as higher level tests.

        > -- System test
        > At this point the flight software is a small piece of a very
        > expensive
        > system and no one "appreciates" frequent software builds. As launch
        > date approaches, flight software updates affects hundreds of people;
        > after launch, flight software updates are "once per career".
        The fact that you have a very expensive system is one of the reasons that it is really important to assure your code does what you think (the point of unit tests). testing to prevent defects seems that it would be very important to keep from losing systems where there is no air.

        The idea behind continuous integration is that if something is difficult, you should do it more often. Wait a long time to integrate, and integration will be a big issue getting more and more difficult. Integrate frequently and integration issues will be smaller though you will have more of them. You have a chance of applying continuous Improvement.

        In embedded development frequent builds likely do not usually lead to early releases. That does not negate the value of them. They provide concrete progress. They offer early opportunities for integration.

        I'd like to learn more about how you protect your career.

        James Grenning TDD for Embedded C is in Beta
        www.renaissancesoftware.net http://pragprog.com/titles/jgade/

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