• 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!

Business analysts: why are there so many of you?

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

    #71
    Originally posted by Antman View Post
    Agile BAs should become Product Owners (a lot of them were just SMEs before they became BAs). However even in the same industry you can't become a product owner over-night with a different company (different architectures, processes, systems)

    Also agree about the glorified note-takers, done it once, now steer clear of anything that says Agile BA unless they're talking about yoga.

    Before anyone says that Agile's not being done right I also agree it's not being done right, agile's just a buzz word put in ads by clients who think that they may not deliver by not having a BA. If agile's being done right, I wouldn't bother with a BA.

    TL: DR - The BA role exists because of client ignorance.
    I disagree with you. In my point of view, a BA can't be “substitute” by a methodology, it's the BA that should be able to adapt to any new (crap or not) methodology invented.

    A BA needs to have a strong business oriented skills, creating products, knowing the markets and the company business needs.

    Comment


      #72
      Originally posted by Fronttoback View Post
      What you fail to realise is that the dev can do your job. You cannot do the devs job. Your career used to be one of my tasks.
      The dev needs to focus on the implementation and usually have a limited view of the business.
      Can be very good developers and not so good BA, this can be useful when the client want's a BA/Architect.

      Comment


        #73
        Originally posted by eek View Post
        My usual complaint about BA's is that they try to be things they are not.

        Prime examples I've seen in the past are them trying to be architects (I mention that as that disaster of a business appeared on my radar earlier this week), trying to design the system (because they think they know the business better than the developers) or over promising because they know no better.

        A BA that knows what they can and can't do and where they add value is a good addition to a project. Sadly most overstep the mark...
        I think the titles can be a mess too. In one of my projects I was a Functional Architect and my title was BA.

        Just because I had some BA activities, in my point of view I was not a real BA, I was a Functional Architect, designed the solution...etc... Existed a business team in the organization to create the products, for me the real BAs.

        Comment


          #74
          Originally posted by Bee View Post
          The dev needs to focus on the implementation and usually have a limited view of the business.
          Can be very good developers and not so good BA, this can be useful when the client want's a BA/Architect.
          That sentence was going so well until you lumped those two together. A good architect is another job entirely.
          The greatest trick the devil ever pulled was convincing the world that he didn't exist

          Comment


            #75
            Originally posted by LondonManc View Post
            That sentence was going so well until you lumped those two together. A good architect is another job entirely.

            Correct, when you work with a true enterprise level architect, its as far from a BA role as you can get.
            The Chunt of Chunts.

            Comment


              #76
              Originally posted by VillageContractor View Post
              This happens a lot, management don't understand the problem and make bad decisions. A good Scrum Master should be shouting out saying the requirements aren't good enough and working with PO and BA to improve them.
              Before the PM, the design team should detect this problem first.

              Comment


                #77
                Originally posted by LondonManc View Post
                That sentence was going so well until you lumped those two together. A good architect is another job entirely.
                I know and I agree with you, but what you are going to do if the client wants?

                Comment


                  #78
                  Originally posted by Bee View Post
                  Before the PM, the design team should detect this problem first.
                  Why should the design team detect it? A good BA should be the first port of call then whoever agrees that they have specified the requirement correctly. If I were Scrum Master, then as VC quite rightly said, I wouldn't let the specs go over to dev.
                  The greatest trick the devil ever pulled was convincing the world that he didn't exist

                  Comment


                    #79
                    Originally posted by LondonManc View Post
                    Why should the design team detect it? A good BA should be the first port of call then whoever agrees that they have specified the requirement correctly. If I were Scrum Master, then as VC quite rightly said, I wouldn't let the specs go over to dev.
                    Yes, but the point here is when the BA failed.

                    Comment


                      #80
                      Well thanks to Bee this thread went south. It was quite an interesting read up to post 73 and there are so many comments since that need correcting it's gone all squiffy.
                      'CUK forum personality of 2011 - Winner - Yes really!!!!

                      Comment

                      Working...
                      X