• 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

    #11
    Originally posted by BlasterBates View Post
    Indeed I do, because the article points out the weaknesses of agile.

    The article is well written, I agree with his points and I have nothing further to add.

    Have a nice day.

    That article is terrible
    The guy has clearly never worked on a project that could legitimately be called anything like agile.
    He keeps on criticising 'the agile methodology' where no such thing exists.
    In that context it all makes perfect sense - he is seeing poor results because because he learned this imaginary 'agile methodology' from some snake-oil salesman and is hoping to achieve agility by following some shrink-wrapped 'Agile' ready meal recipe.

    What the heck is this massive defect backlog he keeps banging on about? If there's a massive defect backlog they're doing something wrong, and assuming he's talking about a Scrum team then this :
    What is dangerous, though, is that focusing on continuous delivery has the effect of creating an unmanageable defect backlog while developers work to put something in front of the customer.
    just points out clearly that he and his team have missed the point entirely! And the odd bug that does slip through unnoticed is generally relatively easy to fix because in order to be agile you've already built up a comprehensive suite of automated tests - you can fix away without fear of regression.

    The principle he's alluding to in the manifesto actually reads
    Working software over comprehensive documentation
    and the focus on delivery is to deliver WORKING and valuable increments of software; And that's why a good Scrum team will have velocity which is a reliable estimation of the amount of working and valuable software which they can deliver each iteration - because their velocity represents ONLY that. Hacked together, insufficiently tested, and defective code does not constitute a 'done' user story.

    The guy's probably just done a CSM cert and now thinks he knows 'Agile' (that imaginary methodology ). I've seen it enough to be sick of it - presumably like Dave Thomas has.

    Comment


      #12
      Originally posted by SpontaneousOrder View Post
      In my experience it leads to much better quality code.

      I've seen 'it' lead to what you describe but that was because 'it' wasn't real agile software development (and what you were describing earlier was Scrum - not agile software development) - it was buzzword compliance used as an self-deceiving excuse to make a company full of hackers feel better about themselves.
      The thing you have to ask yourself is why is it failing in so many cases - 64%, so maybe the guy's experience is more typical of what is going on, and is not just a few exceptional cases. 28% report success.

      New Analyst Report Rips Agile: Says It's 'Designed To Sell Services,' a 'Developer Rebellion Against Unwanted Tasks' -- Application Development Trends

      You're right in that it can lead to improvement, but from the survey it's more likely that it doesn't.
      I'm alright Jack

      Comment


        #13
        It's a scam

        I have had the misfortune to recently sit through two days of Agile training and I came to the conclusion it's a con. The whole thing reeks of scam. It was like two days of timeshare pitch, except a timeshare salesman would get a sale long before two days were up.

        The big boys at the top writing the books, holding the seminars and running the training companies are at least aware of its true nature and are making decent money. They've dreamt up a product, are out there selling it and it's not their fault people are buying it. It's all B2B so caveat emptor.

        Further down the scale are the useful idiots paying the big boys for the right to take the scam direct to the mark and pick up a few crumbs in the process. Many at this level either don't know or don't care it's a con but it's still a con. The bulltulip terminology makes it sound serious so that means they are now Billy Big Balls. Just like they would have been if they'd been able to stick it out in a productive, technical role.

        The reality of Agile:

        1. The answer to pretty much everything is the assertion that everyone else is doing it successfully. No need for specific success stories. The "expert" (scrumlord of epicness, or whatever bulltulip titles they give themselves) have just seen it and the anecdotes of some unskilled shiny-suit wearer obviously outweigh practical experience;

        2. If it's failing at the client site then it's because of the client (rule 1 being conclusive proof). This is the point where they take inspiration from the dating game and neg the mark. Marks just love a bit of negging, it makes them work harder at being conned;

        3. Any questions, critical or otherwise, that can't be answered with "everyone else is doing it" (like a teenage boy trying to get his girlfriend to drop her knickers) are turned around to being about the questioner and what they have to change about themselves. In other words, more negging, definitely no answering. In other words, like a teenage boy etc;

        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.

        5. The whole movement at the frontline, useful idiot level is full, just chock full, of middle aged men. It reeks of failure;

        6. By the time a company like my client takes it up it must be over. When dinosaurs like them pick up on a trend the cool kids have moved on. Expect some new fashion soon, possibly incorporating terminology from ballet. The scrum leader will be the danseur noble (no prima ballerina because it's always washed-up old men), a sprint will be an adagio, partnering will be partnering and stretch goals will be grand jetés.

        In fact, I'm off to work on my Plan B - the Effacé approach to IT development.

        Comment


          #14
          The slight hiccup is that there is often more to a project than just the software.

          No documentation needed - it's all there in well written code for the developers. Well whoop-de-do for them.

          What about the poor suckers expected to run, support and use it?

          The time I was a BA for a (well run, it must be admitted) agile project, I ended my stint there being a Service Manager for ETL, Identity and Access Management and SAP integration.

          But, it did allow the Scrum Master (who should have been PM'ing the rest of the stuff as well) and the team to concentrate on the 'fun' stuff...
          "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


            #15
            Originally posted by cojak View Post
            The slight hiccup is that there is often more to a project than just the software.

            No documentation needed - it's all there in well written code for the developers. Well whoop-de-do for them.

            What about the poor suckers expected to run, support and use it?

            The time I was a BA for a (well run, it must be admitted) agile project, I ended my stint there being a Service Manager for ETL, Identity and Access Management and SAP integration.

            But, it did allow the Scrum Master (who should have been PM'ing the rest of the stuff as well) and the team to concentrate on the 'fun' stuff...
            The project that I enjoyed the most over the last few years was a classic waterfall. It was planned over a 12 month period, with key dates for requirements, system design, detailed design, impementation and rollout. We spent most of our time doing documentation

            However, everything went like clockwork, all dates were achieved and I experienced no stress whatsoever during the whole process.

            When it went live there was a deafening silence as everything worked 100%, there was not even one single bug fix required, and further more there was a complete document as to how the system worked.

            I'm not saying that everything should be done as a "water fall" but it has it's place, and any process consultant should be aware of how to make it work.

            After a few huge cock-ups in an agile project we started to move to "mini waterfall", due to misunderstandings and some rather angry customers, also a huge amount of effort spent answering customer queries because no-one really knew how the system worked, so you had to rummage around the code.

            Agile is a different way to develop Software but isn't better than everything else. In the end you have to understand all the different ways to develop software then throw away the books and generate your own process that suits the job in the hand.
            I'm alright Jack

            Comment


              #16
              Originally posted by BlasterBates View Post
              The project that I enjoyed the most over the last few years was a classic waterfall. It was planned over a 12 month period, with key dates for requirements, system design, detailed design, impementation and rollout. We spent most of our time doing documentation

              However, everything went like clockwork, all dates were achieved and I experienced no stress whatsoever during the whole process.

              When it went live there was a deafening silence as everything worked 100%, there was not even one single bug fix required, and further more there was a complete document as to how the system worked.

              I'm not saying that everything should be done as a "water fall" but it has it's place, and any process consultant should be aware of how to make it work.

              After a few huge cock-ups in an agile project we started to move to "mini waterfall", due to misunderstandings and some rather angry customers, also a huge amount of effort spent answering customer queries because no-one really knew how the system worked, so you had to rummage around the code.

              Agile is a different way to develop Software but isn't better than everything else. In the end you have to understand all the different ways to develop software then throw away the books and generate your own process that suits the job in the hand.
              Waterfall works if you have a project with competent Analysts and competent super users who know what is required.

              It dies on its arse when the Analysts aren't 100% competent which is sadly most of the time.

              personally I look for entertainment. As where there is entertainment, there is chaos and money...
              merely at clientco for the entertainment

              Comment


                #17
                Originally posted by eek View Post
                personally I look for entertainment. As where there is entertainment, there is chaos and money...
                This is a philosophy that I'm beginning to use, even my frustration and stress is starting to fade...
                "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


                  #18
                  Originally posted by BlasterBates View Post
                  I've been working on an "agile" project for the first time and well I don't really see much difference. A project meeting is a "scrum meeting" and you have them every day, although it's a waste of time you regurgitate what you're doing and no-one's interested. Requirements are called "stories", the PM is a "Scrum Master", the BA is a "Product Manager" and a release is a "Sprint".

                  That's all you need to know.

                  If the inventors of Agile had spoken to Quality Engineers in the 1990's they could have saved themselves a lot of effort, because it's all in the ISO9000 standards.
                  Agreed and that is if the client implements Agile anywhere near properly, my current client has gone 'Agile' on the Business Change side but no one seems to have told IT (yes really) so we have scrum deliverables, write requirements in SBE, etc but we are not truly an Agile environment. My previous client was also liked this but they freely admitted it was a mixed model!

                  An Agile qualification may help but any client worth their salt will prefer Agile experience to a paper qualification.

                  Comment


                    #19
                    Originally posted by BlasterBates View Post
                    The thing you have to ask yourself is why is it failing in so many cases - 64%, so maybe the guy's experience is more typical of what is going on, and is not just a few exceptional cases. 28% report success.

                    New Analyst Report Rips Agile: Says It's 'Designed To Sell Services,' a 'Developer Rebellion Against Unwanted Tasks' -- Application Development Trends

                    You're right in that it can lead to improvement, but from the survey it's more likely that it doesn't.
                    'It' is failing because 'it' isn't agile. I've had some experience of real agile projects and ALOT of experience of fake agile projects, and I'm at the point now where I don't doubt myself anymore and can sniff out the bulltulip in double quick time.

                    ClientCo at the moment are doing 'Agile' (like it's some kind of noun). What they're actually doing is just Scrum, and don't understand that it's entirely pointless because none of the rationale behind agile development has any bearing to this particular project at all - it's a regulatory compliance project and there is zero potential for change, zero scope for prioritising when it comes to scope, and the changes & enhancements required are all well understood and entirely distinct from one another.
                    I.e. there is no need for agility and there are no feedback mechanisms which would make an iterative lifecycle like Scrum useful. In fact our sprint paradigm is entirely illusory - we could just have one 6 month sprint any the end product would be exactly the same.
                    Standups don't seem to make much sense because rather than talking about what we've done since yesterday and what we will do today in order to help reach the sprint goal, we just tell everyone what we're up to even though they couldn't care less because there is no sprint goal - just a load of individual and barely related tasks that need doing.

                    My ScrumMaster basically runs the show and says things like "I know it's not very Agile, but..." or "this is the Agile way to do it" which instantly tells me he has done a CSM course but doesn't have any understanding of the reasons we might use the techniques he's been taught.

                    When i pointed out that we shouldn't get too tangled up with worries about other people's expectations with regards to the Scrum process, because we aren't really at all agile anyway (so the expectations when it comes to visibility and velocity metrics, etc are an imaginary point of failure), I was reprimanded for confusing the newbies.


                    Basically in my personal experience over 50% of organisations either use the word 'Agile' as an excuse to be hackers in a way they'd never get away with in a more traditional environment; Or they buy into this 'Agile' as a join the dots process to magically make projects successful. ClientCo are sending guys on CSM curses left right and centre, yet (almost) none of them have ANY clue about agile software development - so what the hell is the point of sending someone entirely ignorant of agile development on a ScrumMaster certification?!

                    The few good agile projects I've had the pleasure to work on have really been a joy. My key question to ask next time I'm interviewing (now that I've got some war chest) will be "Why agile?". I reckon I could get a good view of what kind of operation they're running just from the answer to that question.

                    Comment


                      #20
                      Originally posted by cojak View Post

                      No documentation needed
                      That's nothing to do with Agile (i'll reluctantly call it that for brevity). 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.".

                      I've not worked on a successful project before where we didn't document the more subtle parts of the system; We just tended to write the code first - i.e. code evolves until we're pretty happy with it, and then we document it so we don't end up handing the client a magic black box. SOAP or RESTful interfaces etc tend to speak for themselves, but non functional internal behaviour will need something.

                      Originally posted by cojak View Post
                      - it's all there in well written code for the developers. Well whoop-de-do for them.
                      Again this is a (deliberate?) misunderstanding on developers parts. Devs shouldn't need to document their code (i.e. actually in the code source itself) 99.9% of the time - if they do it means it could be written better. But perhaps they've misunderstood that kind of sentiment being used from a BDD perspective?
                      If your acceptance tests are well written using something like JBehave (i'm a java guy) then your tests are written in English, reports are generated in English, and those reports document what the system does under different circumstances - in English.

                      Comment

                      Working...
                      X