Principles of Software Flow



Sorry Agile, I Need To Move On.

I’m sorry Agile, but it’s time for me to move on.

Moving On by Romy Mistra

I’m afraid you’re no longer the Agile I fell for.  Now you’re something else entirely.  I don’t like what you’ve become.

You used to have such high principles, but now all you want to do is set down rules.

Once when I looked at you I see alluring mystery.  You used to be so magical, so full of surprises and apparent contradictions.  Now all I see are to-do lists and time boxes.

We don’t like to listen to the same sounds.  I still adore the relational model.  Every time I listen I discover something new.  You just find it old fashioned.  You tell me I should be listening to NoSQL but it just sounds like a lot of noise to me.  I want to experiment and solve new problems but you seem satisfied with BDD.  Hearing those same three chords repeated over and over again is boring me.  I’m sick of you dismissing everything I find interesting as ‘too waterfall‘.

I hope we can stay friends.   It has been an interesting journey, but now I need to find a path less travelled.

Advertisements

Trackbacks & Pingbacks

Comments

  1. Don’t be too sad. Maybe it is just the through of disillusionment of a hype cycle. Or “The Dip” (from Seth Godin). There is hope. 🙂

    | Reply Posted 3 years, 11 months ago
    • * Ged Byrne says:

      Hi Jens,

      You might be right about the hype cycle. Next is the plateau of productivity. Agile is now just something I do at work. It is no longer something I pursue in my spare time. Other things inspire me now.

      | Reply Posted 3 years, 11 months ago
  2. * Erik says:

    Leadership is pursuit. Send up a flare when you find something.

    | Reply Posted 3 years, 11 months ago
    • * Ged Byrne says:

      Thanks Erik.

      | Reply Posted 3 years, 11 months ago
  3. * Ged Byrne says:

    This may be a path less travelled, but I’m still following the footsteps of others:

    http://flowchainsensei.wordpress.com/2009/06/30/my-forlorn-love-letter-to-agile/

    | Reply Posted 3 years, 11 months ago
  4. * JJ Dubray says:

    I have proposed a very simple change (express User Stories as Problem Statements) which I believe can have a tremendous impact on the outcome of a project.

    http://www.ebpml.org/blog2/index.php/2013/04/26/reinventing-agile-from-value-to

    I’d be interested to know what you think.

    | Reply Posted 3 years, 11 months ago
    • * Ged Byrne says:

      Hi JJ,

      I like what you’ve written. It reminds of Boehm’s Value Based Software Engineering and the use of a “Results Chain.”

      See figure 14.3 here: http://lyle.smu.edu/~lghuang/CSE8340/papers/VBSEChapter2.pdf

      One element in the “Results Chain” I don’t see in your proposal is the declaration of assumptions. You use the form “Actor performs action to receive benefit.” Is the method limited only to situations where there is a simple action->benefit relationship?

      This would suggest the form “Given these conditions, actor performs action to receive benefit.”

      You may also find Carroll’s work on Claims interesting.
      http://jcarroll.ist.psu.edu/files/papers/GettingAroundTAF-TOIS92.pdf

      Carol has the form for User Interface design:
      (artifact feature or technique) CAUSES (desirable psychological consequence)
      BUT MAY ALSO CAUSE (undesirable psychological consequence ).

      This acknowledges the fact that some action may involves risks or unintended consequences.

      This would suggest the form “Given these conditions, actor performs action to receive benefit. There is a risk that something undesirable happens.”

      Basically there is a need to recognise context. What is good in one situation may be bad in another. That needs to be captured.

      This lack of situational awareness is what has frustrated me about Agile. It says “Do this, it is always better.” That isn’t true. For example, Agile says “Do TDD, it is always better.” Sometimes TDD is not the appropriate strategy.

      See also: http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku-solvers.html?m=1

      What I want to hear is

      Given this context, Using TDD will delivery these benefits. There is a risk that these bad things might happen.

      | Reply Posted 3 years, 11 months ago
      • Ged, thank you so much for you detailed response.

        I wrote a book about the broader context of that approach. The book (http://www.b-mc2.com) is generally free (but it depends on your country, otherwise I can send you a copy, just email me at jdubray@gmail.com).

        Here I was just trying to focus on User Stories because I had come to the realization of two important facts (at least I believe they are facts):
        a) a problem statement can be expressed formally
        b) based on that definition, requirements and/or user stories are always expressed with the solution in mind

        A lot of projects fail or get delayed simply because of the fact that the problem is poorly understood, the solutions embedded in the requirements is incomplete, possibly wrong or not optimal and the delivery team has back track from the wrong solution to solve the problem correctly.

        At the next level of detail, the problem is that the vast majority of people think in terms of actions when they should be thinking in terms of outcomes. “value” is way to fuzzy and subjective to drive the solution in the right direction. Once the outcomes are clearly defined, then it is far easier to decide on a course of actions. A huge benefit of being outcome centric is that it allows the solutioning team to take into account the end user affinity with the proposed solution (see for instance http://www.b-mc2.com/learn/). You could have the best solution to a problem, if an end user can’t get to it, it is still not a solution…

        If I may, I’d like to explain the broader context of my work in a few paragraphs. The way we conceptualize something can be modeled in 3 levels (I don’t think it is oversimplifying)
        – knowledge / context
        – insight
        – communication

        I would say that your statement is true regardless of xxx: “This lack of situational awareness is what has frustrated me about xxx”. We live in the age of “insight” passed the age of knowledge. Up until about ten years ago, we used to get our knowledge from schools, sometimes books and also our immediate surroundings. Yet that knowledge was hardly applicable as is, it was often behind the work that people were doing (as in solving new problems), and yes, let’s admit it, there was a time when we had to think and integrate that knowledge with the problem at hand, as we were formulating a solution.

        Today, we live in the age of “insight”: when you are looking for solutions (Note that I don’t say you have a problem you want to solve), you google a few keywords and you find 10 solutions that seem to match what you were looking for. You pick one and you try to apply it. They call it “don’t reinvent the wheel”, they laugh at the “not invented here” syndrome… You get my point. Insight is packaged and delivered to your door, with a one click shopping experience. No thinking needed.

        The problem with that ocean of insight is that it is both overwhelming in volume of information, and rarely (shall I say never?) applicable as-is to the problem that you have. This is why it is more critical than never before to look at everything we do from the angle of the problem that we need to solve, as a company, as a unit, as a product or a service. Hence, before we reuse someone’s insight we have to understand the problem solved by that insight and match it with precision to our problem. As you can guess the solution will be partial and need to be adapted.

        Unfortunately our communication tools don’t help at all, they are not well suited to align people’s insight either. Human languages (which were invented a very long time ago) can’t describe complex graphs easily (i.e. problem statements), verbally or in writing. This compounds the problem, so to speak. We can’t federate easily a group of people and harness their collective intelligence. The fundamental problem any organization has today is to align everyone’s insight about the solution that is being built.

        Ultimately my passion is about harnessing Collective Intelligence, that’s why I believe it is very important that we start understanding the paradigm shift that has just happened.

        Give me a couple of weeks to read the papers you sent me and I’ll write a new post to detail some of these ideas.

        http://www.b-mc2.com/2013/04/28/communication-insight-education-and-innovation/
        http://www.b-mc2.com/2013/04/24/organizational-iq/
        http://www.b-mc2.com/2013/02/03/revisiting-the-conway-law/
        http://www.b-mc2.com/2012/12/06/cooperation-essential-for-innovation/

        Posted 3 years, 10 months ago


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: