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 the plan. We have options:
  • Long waterfall-like sprint, where the 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 a third obvious option, which is to decrease regression time, but no-one seems to have knowledge about how it can be done in the 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. Maybe it not as cool as Spotify Engineering Culture videos tell you. The 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 has 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 the change occurs we don't get out of 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 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.



    Comments

    Popular posts from this blog

    Test automation framework architecture. Part 2.1 - Layered architecture example

    Test automation framework architecture. Part 2 - Layered architecture

    Efficient test automation - Secret #1 | Test Club