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

    Post a Comment

    Popular posts from this blog

    Test automation framework - do I need it at all?

    -
    Image
    While there're lots of information published on the internet about how one should develop/buy a Test Automation solution, there's an elephant in the room - which is the fundamental question "Do I need to do it at all?". That is a good question. While I think that there’re some legitimate contexts where product/project/team can benefit from having a sophisticated test automation solution/framework, my general rule of thumb is “If you need a framework - you do it wrong” . There’re at least several decent papers showing the benefit of unit-testing ([1],[2], [3]), while I could not find any research proving that system level tests could bring better results. Please let me know if you can prove me wrong. There’s at least one half-scientific paper showing the benefits of unit tests in comparison to integration/system level tests [4] There’s a good paper bringing a notion of running/writing and maintaining test vs. the benefit of having/running it at...
    Read more

    Efficient test automation - Secret #1 | Test Club

    -
    Image
    It seems everyone talks about efficient test automation, but not so many people have actually seen it! To cover this I decided to make several videos regarding the secrets of efficient test automation. Today we will talk about the first (and, arguably, the main) secret - realistic expectations. Very often, test automation projects or initiatives are started with the following unrealistic expectations: "Test automation will replace 'manual' testing" "Test automation will provide fast results and benefits" "Test automation efficiency depends solely on test automation engineers" Unfortunately, all those expectations are not realistic! Watch the video to know more!
    Read more

    An alternative to ubiquitous UI-level checking - Subcutaneous tests

    -
    Image
    Let's assume a hypothetical situation - you were assigned to a project to help with the "test automation" initiative. You have a huge "test plan" as an input, containing hundreds (if not thousands) of "test cases" and you need to do something about it, quick. Problem statement Your first urge (if it is a Web application) may be to write some UI-level automated checks using tools like, you know, Selenium. In fact, there's a huge demand for such "Selenium test automators" in the industry these days. But please, please, don't do this. There're lots of things which make UI-level automated checking the least desirable approach: UI-level automated checks will be slow. There's just no way to avoid it. You can parallel them or do some other tweaks to speed them up somehow, but they still will be slow. UI-level automated checks will be flaky. Partly - because they're slow. Partly because Web browser and UI interface w...
    Read more