kHUB All Member Forum

Discussion Thread View
  • 1.  Agile in non-software environments

    Posted 06-11-2019 15:50
    I was having coffee with a friend and ex-colleague recently. He said they were trying out Agile in his organisation, in a mostly non-software arena of telecoms, where traditional waterfall models involving looooong-duration development intervals have reigned supreme for decades. And I understand that albeit The Agile Manifesto was originally about software, the theory and concept is now there that Agile is not specific to software and can be used to achieve pretty much any project. (Not that I have anything against software. Some of my best friends are software engineers. In fact I used to be one myself!)

    I'd love to hear examples from contributors who have implemented Agile Development successfully in this way that was not mostly about software? And what were the key challenges and success factors?

    ------------------------------
    Brian Martin
    ------------------------------


  • 2.  RE: Agile in non-software environments

    Posted 06-25-2019 13:10
    Interesting topic.  I have found the limiting factors in non-software environments is the ability to change the product combined with the market life of product.  In the telco world, we dealt with massive infrastructure investments that involved very long life cycles, and were difficult to change once deployed.  Here it was slow and steady with a lot of up front analysis to reduce investment risk. In a different situation, we dealt with computer systems (desktops and laptops) where one again difficult to change once hardware design was set and tooling was set-up, but in this case, the market life of the product was very short as the next round of cpu technologies would quickly obsolete current product. It actually took longer to develop the next generation product that the length of the market window. 

    While these environments were not as agile as the pure software environment, there were still basic tenants of the agile approach that applied.  One of which was to stay flexible and allow for room to respond to new learning as the project progressed. In these environments, the development was still rather agile, but you just did not have the continuous development, continuous release cycle of software.  Instead you had a continuous development and learning cycle that would get reviewed until you reached acceptable market viability, at which time the less flexible product attributes would be frozen as the product moved to production. Other aspects of agile that apply include:
    (1) get the customer/end user involved as soon as possible for early feedback and validation.
    (2) leave room for response to this feedback in the development cycle.
    (3) maintain a list of prioritized features and is continually reassessed as new learning evolves.
    (3) do not lock down features until they need to be lock down for production release

    Dan Lewis

    ------------------------------
    Daniel E. Lewis PhD, PE, PMP, NPDP
    President - Product Acuity Consulting
    www.productacuity.com
    The Woodlands, Texas
    ------------------------------