Agile is not the goal, but means

So we sit in the room and discuss the transformation plan for a company which was working in a waterfall manner for nearly a decade. The final goal is to switch to iterative development with somewhat small iteration (let's say, 3 weeks). The "only" problem we had is that we have 3 weeks if manual regression, and it does not really fit to the plan. We have options:
  • Long waterfall-like sprint, where first half of the sprint we develop features, second half - test them
  • Series of short sprints and one "hardening"/"release" sprint dedicated to regression when we finally decide to release things. 
There's third obvious option, which is decrease regression time, but no-one seems to have knowledge how it can be done in a next 5 years. So this gets dropped.
    "We need to have potentially shippable increment each sprint, "hardening" sprints are not Agile!" - says one man in a room.

    Well, that may be true. May be it not as cool as Spotify Engineering Culture videos tell you. First option does not look very "Agilish" for me as either. It is fairly difficult to combine letters "s", "h", "i", "t" into word "happy".

    But that is not the problem. The problem with the "not Agile" argument is that Agile was never the goal. We don't do transformation because we want to be, you know, Agile.

    "It is 2017, everybody have Agile, so we need to be Agile"
    "Not really."

    Agile was never the goal, but means. We have to be Agile to be able to adapt to the changing environment, so when change occurs we don't get out of a business. And to be able to do that we don't have to conform to someone's else definition of  Agile.

    Agile Manifesto was created a long time ago, and many things that associated with Agile now-days was never mentioned in that Manifesto.

    We have many definitions of Agile and I am OK with that. Anything can be Agile for me as long as it conforms with my understanding of agility (let's call it "My Agile").

    My Agile is about small iterative changes towards the end goal with frequent verification of:
    • How much closer to the end goal we got
    • Is the end goal still valid.
    So, pretty much any set up can be Agile as long as we commit to constant improvement. Do you agree?

    I can also suggest this brilliant slideshare: "Purity vs. Pragmatism" which has pretty much same message.


    Post a Comment

    Popular posts from this blog

    Test automation framework architecture. Part 2 - Layered architecture

    Test automation framework architecture. Part 2.2 - Two-layered architecture

    Test automation framework architecture. Part 2.1 - Layered architecture example