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

Re: Would longer build time hamper Agile Development?

Expand Messages
  • steveteske
    ... I can speak from experience on this one. Our build time was about 4-5 hours. This really makes it difficult for individual designers and or CM to make a
    Message 1 of 14 , Aug 24 6:03 PM
      --- In scrumdevelopment@yahoogroups.com, "petriheiramo" <petri.heiramo@...> wrote:
      >
      > > > I've seen build times become a problem in large organization with a
      > > > multi-tier environment. In this case the software stack was 7-10 layers
      > > > deep. You do the best you but sometimes the problems can't be solved. In
      > > > this case a full series of builds took over 24hrs.
      >
      > > That sounds seriously scary. I don't know how you can operate with a build process that long??
      >
      > Well, do you mean "how to operate in Agile ways" or "how to operate" in general? :)
      >
      > Such organizations probably have challenges in getting their software working. I've worked with one such company a rather long time and I think fixing that build process is one of their greatest challenges in getting Agile.
      >
      > But in the mean time, they can foster Agility in smaller "bubbles" where the build times are shorter. While it doesn't solve all the problems, it sets a precedent for future improvement higher up.
      >
      >
      > Yours Sincerely,
      >
      >
      > Petri
      >
      > ---
      > Petri Heiramo
      > Process Development Manager, Agile Coach (CST)
      > Digia Plc., Finland
      >

      I can speak from experience on this one. Our build time was about 4-5 hours. This really makes it difficult for individual designers and or CM to make a build that can quickly be tested.

      Their are a couple specific things (one agile, one pragmatic) that happened to our team when builds were long. On the agile front, people stopped creating streams for individual activities, because they didn't want to wait for build. They would bundle everything into their stream. They would have features and bug fixes and all sorts of stuff. When it came time "incrementally deliver anything, it was difficult because the developers would have to tease everything apart. More than that, each developers delivery became a nightmare for everyone because code change was significant for each delivery. At the end of the day, iterative and incremental where not especially desirable from the developers perspective because the cost to build was too high. You could argue that they should have known they cost to deliver and rebase would be overwhelming expensive with big deliveries, but the build time was driving their behavior.

      On the pragmatic side, developers started doing partial builds...and sometimes missing dependencies. When they loaded the new objects on the target hardware, ugly things happened because not all objects believed they have the same object size. I know this type of problem is special to our embedded development, but it did consume considerable effort...it was intended to save time, but it work opposite it's purpose.

      We brought the build time to 10-20 minutes (coffee break) and we see people being more incremental. We moved from 4 week iterations to 3 week iterations and we test a lot more. ElectricCloud Accelerator was the tool that reduced our build time.

      Steve Teske
      Embedded Software Development Manager
      Thales Communications Inc.
    Your message has been successfully submitted and would be delivered to recipients shortly.