• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Bcs Agile foundation/practitioner

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #21
    Originally posted by GreyWolf View Post
    4. Real world pressures are not allowed to interfere with the running of the story. Who cares if the regulator is going to fine the business if the new figures aren't in next month's report. If it wasn't planned eight weeks ago and put in the epic (more bulltulip terminology to make it sound important) then it doesn't happen.
    The fact that you were on 2 days of agile training, in my mind, suggests the whole thing was a con (i.e. someone conned someone else into thinking that a 2 day course which sounds more like a Scrum course to me could possibly teach someone 'Agile').

    I just snipped number 4 above - that's not the reality of agile at all. Who told you this? I know a lot of people think this but it isn't true. This is a Scrum thing, not agile, but whatever... a product owner is perfectly entitled to negotiate (although he has the ultimate say) the ongoing sprint backlog at any time. In fact he can cancel the sprint entirely if he sees fit. The aim is to not have to do these things, but there is nothing to say that you cannot swap something out for a brand new story, mid-sprint, if it's deemed a priority.

    I'm not sure it would make sense to label a process as being 'agile' when it's actually rigid and inflexible The whole point is that reality (of the situation, of the client's present wishes, and of the fact that tulip happens) should trump process for the sake of process.


    If someone wants to train their team to embrace agility then they should start with software craftsmanship - quality code is the bedrock on which any agility must be built.

    Automation - you can't be agile when change is too expensive. This fits in with the software craftsmanship. So perhaps teams might need some TDD tuition - then their code will not only evolve such that every line of code has a reason to live, but it will be fully xUnit tested. Then you can layer on some automation when it comes to acceptance level testing, etc. Then some automation when it comes to CI and the release process (some mature teams release several times per week).
    At that point we can really get the testers pairing up with, or working closely with the devs on tasks. Perhaps the devs can build test fixtures for the testers who hopefully have some technical ability to build tests from them, while the developer is coding up the production code. This helps us to achieve agility because we don't end up with a load of tasks all coded up but in an indeterminate state because they haven't been system tested yet.

    Then there's the agility when it comes to working closely with clients and drawing requirements out of them, etc. We don't mind that they might change their minds because we have awesome test coverage making any changes to existing code stress free. We embrace the idea that requirements will change, rather than throwing a tantrum like some people would in a more old-school environment, because ultimately the whole reason we're doing this is to deliver the client value.


    THEN something like Scrum is the last layer to add. Getting a team to follow a Scrum methodology (which isn't 'Agile' - it's just a tool to help you work with agility) when they don't even understand what agility is, or why they might want agility, is like teaching someone to bake a cake without telling them what the ingredients are that they are using - they might get top marks, but the next cake they bake on their own is going to taste like tulip. What's worse is that the team will (which i'm observing now at clientCo) will end up jaded with the whole thing because it doesn't make sense to them.

    Comment


      #22
      Originally posted by SpontaneousOrder View Post
      The fact that you were on 2 days of agile training, in my mind, suggests the whole thing was a con (i.e. someone conned someone else into thinking that a 2 day course which sounds more like a Scrum course to me could possibly teach someone 'Agile').

      I just snipped number 4 above - that's not the reality of agile at all. Who told you this? I know a lot of people think this but it isn't true. This is a Scrum thing, not agile, but whatever... a product owner is perfectly entitled to negotiate (although he has the ultimate say) the ongoing sprint backlog at any time. In fact he can cancel the sprint entirely if he sees fit. The aim is to not have to do these things, but there is nothing to say that you cannot swap something out for a brand new story, mid-sprint, if it's deemed a priority.

      I'm not sure it would make sense to label a process as being 'agile' when it's actually rigid and inflexible The whole point is that reality (of the situation, of the client's present wishes, and of the fact that tulip happens) should trump process for the sake of process.


      If someone wants to train their team to embrace agility then they should start with software craftsmanship - quality code is the bedrock on which any agility must be built.

      Automation - you can't be agile when change is too expensive. This fits in with the software craftsmanship. So perhaps teams might need some TDD tuition - then their code will not only evolve such that every line of code has a reason to live, but it will be fully xUnit tested. Then you can layer on some automation when it comes to acceptance level testing, etc. Then some automation when it comes to CI and the release process (some mature teams release several times per week).
      At that point we can really get the testers pairing up with, or working closely with the devs on tasks. Perhaps the devs can build test fixtures for the testers who hopefully have some technical ability to build tests from them, while the developer is coding up the production code. This helps us to achieve agility because we don't end up with a load of tasks all coded up but in an indeterminate state because they haven't been system tested yet.

      Then there's the agility when it comes to working closely with clients and drawing requirements out of them, etc. We don't mind that they might change their minds because we have awesome test coverage making any changes to existing code stress free. We embrace the idea that requirements will change, rather than throwing a tantrum like some people would in a more old-school environment, because ultimately the whole reason we're doing this is to deliver the client value.


      THEN something like Scrum is the last layer to add. Getting a team to follow a Scrum methodology (which isn't 'Agile' - it's just a tool to help you work with agility) when they don't even understand what agility is, or why they might want agility, is like teaching someone to bake a cake without telling them what the ingredients are that they are using - they might get top marks, but the next cake they bake on their own is going to taste like tulip. What's worse is that the team will (which i'm observing now at clientCo) will end up jaded with the whole thing because it doesn't make sense to them.
      I'd suggest what you're talking about is XP which is classically labelled an Agile 'framework' - although it's application is perfectly applicable in isolation.

      In short, there are a number of charlatans out there - I myself am on the verge of leaving my contract as despite the fact that my team's output has more than doubled since I arrived (two months ago) there's no point having this, or indeed increased agility if the rest of the business is going to make strides to accommodate my team's ability to deliver business value on a frequent basis. There are far too many job roles that, as SpontaneousOrder highlights that lists Agile as a requirement but quite frankly miss the point, and it is frustrating because it leads to negative experiences for those who are subject to bad implementations (and therefore leads to the notion that Agile is concocted by snakeoil salesmen and the like).

      Comment


        #23
        Originally posted by SpontaneousOrder View Post
        Thats hackers deliberately focussing on the "Working software over comprehensive documentation" while conveniently forgetting the "That is, while there is value in the items on
        the right, we value the items on the left more.".
        This, and entirely this.

        Comment


          #24
          Originally posted by SpontaneousOrder View Post

          Then there's the agility when it comes to working closely with clients and drawing requirements out of them, etc. We don't mind that they might change their minds because we have awesome test coverage making any changes to existing code stress free. We embrace the idea that requirements will change, rather than throwing a tantrum like some people would in a more old-school environment, because ultimately the whole reason we're doing this is to deliver the client value.
          That alone deserves a

          You are, of course, right. Crap 'agile' projects are just crap projects wrapped in fancy packages.

          If common sense and competence using any method were commonplace we'd all be earning a lot less money than we do.
          "I can put any old tat in my sig, put quotes around it and attribute to someone of whom I've heard, to make it sound true."
          - Voltaire/Benjamin Franklin/Anne Frank...

          Comment


            #25
            Originally posted by cojak View Post
            That alone deserves a

            You are, of course, right. Crap 'agile' projects are just crap projects wrapped in fancy packages.

            If common sense and competence using any method were commonplace we'd all be earning a lot less money than we do.
            and be bored while doing it....
            merely at clientco for the entertainment

            Comment


              #26
              Originally posted by DigitalUser View Post
              I'd suggest what you're talking about is XP which is classically labelled an Agile 'framework' - although it's application is perfectly applicable in isolation.
              Exactly. XP isn't 'Agile' (the hypothetical noun), nor is Scrum. XP is set of practises and techniques which when done well will help you to achieve agility; And Scrum is a SDLC which when done well (and in the right context) will help you achieve agility from a lifecycle perspective.

              I would suggest that the latter is not much use without the former though (agile processes built on a foundation of rigid and clumsy practises?), which is what irks me about current clientCo sending every man and his dog on a ScrumMaster course. It makes very little sense IMO without a fundamental understanding of what agility is and what is required to achieve it.

              Comment


                #27
                Originally posted by cojak View Post
                That alone deserves a
                This is where the guys that have been sent on a 2 day Scrum/Agile course will fall over.

                Now they're running 2 week iterations to, among other things, allow the client to change their minds about something or change direction because perhaps the market has moved unexpectedly, or perhaps they simply have a better understanding of what they need now than they did when they started.

                BUT... when the client does ask for a change it's huge deal because that project probably hasn't been built on solid 'Agile' foundations - without a high quality & comprehensive suite of automated tests anything but a trivial change is going to be a real issue. People are going to go home and sleep disturbed after making pervasive changes across the code base.

                What's worse that team has probably developed features in isolated silos meaning that a fundamental change in strategy is going to cause real problems when applied to a code base developed without a common understanding of it's particular intricacies, without a common style and shared overall vision.
                Perhaps the contractor who worked on feature X & Y has left now, and the contractor who worked on feature A & B has left too - and no one else is quite sure exactly how it works or if there are any hidden pitfalls because they haven't paired up or at least rotated developers among different areas of the system regularly, and there aren't any self-documenting tests to highlight exactly what the requirements were and the peculiar circumstances that should be taken into consideration.

                So what was the point of adopting Scrum? Someone was hoping for a magic 2 day silver bullet, and someone else was happy to make a quick buck out of selling that silver bullet.

                'Agile' is for losers. Real men embrace agility

                I feel your pain.

                Comment


                  #28
                  The Ignorance of Clients

                  Originally posted by Shockuk View Post
                  More and more positions now request agile experience
                  That would be "agile experience" rather than actual useful and effective software development experience?

                  You've really got to question the Client about this.

                  Comment


                    #29
                    Originally posted by flipFlop View Post
                    That would be "agile experience" rather than actual useful and effective software development experience?

                    You've really got to question the Client about this.
                    You would need to get through the agent first which is easy if you know what "Agile" is and you have written appropriate things on your CV.

                    If you aren't interviewed by a idiot, then most Clients will admit what they are doing has loads of flaws in it and if you are really lucky they will admit it's not Agile at all.
                    "You’re just a bad memory who doesn’t know when to go away" JR

                    Comment


                      #30
                      As far as I can gather, Sky and Mail Online are very good when it comes to agile.

                      Comment

                      Working...
                      X