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

ThoughtWorks

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

    #71
    I've never seen a large scale business transformation / ERP Programme successfully delivered utilising an Agile methodology. Seen many done via a waterfall approach though.

    Comment


      #72
      Originally posted by vadhert View Post
      Client co is in West London.
      Sky near Osterley?

      Comment


        #73
        Originally posted by LondonManc View Post
        To have credibility, a scientist should have a PhD, no question about it.

        The problem with agile is that 90% of the projects that I've seen claim to be Agile aren't run as Agile. There's either a failure to convince senior management to arrange their budget differently (this guys have delivered successfully under waterfall/v/JFDI for many years so have a different mindset) or nobody with the stones to attempt to convince them that an agile methodology is totally different to waterfall and explain with simple pictures how it works, including roles.
        Have you heard of "SCRUM-BUT"?

        We do "SCRUM" at the Donkey Nuts Investment Bank GMbH, "BUT" we do it our way.

        We are Agile, our daily sit-down last 30-45 minutes and we have 20 people in the office on average meeting time at 8:30am.
        Of course we do two week iterations, we don't bother with sprint planning nor do we like retrospective.


        Sheesh. Get out of that so-called Agile environment fast!

        Comment


          #74
          Originally posted by ChrisFromGreece View Post
          Spot on!

          You should only go for it if everyone is committed to it!
          And I agree with that.

          The trouble is that technical leaders and project managers must also communicate up the organisation chain, especially as soon as they think that deadlines will slip.

          You should be able to work out generally what the budget for a project is. The total cost depends on the quality of software. I have seen tons of legacy software with lip service paid to unit tests. How can a developer safely refactor without any tests? If the Unit test fixture are brittle and the code is band-aid upon band-aid over several years. If the software quality is so bad that to simple add a new property to web form means that you have to edit the HTML5, fix AJAX, adapt the server side controller, fix the back end and then finally run a script to fix SQL in the database, then you are dealing X*Y*Z complexity. Explaining this to the managing director is the hardest thing, and they simply sometimes don't want hear it. So it is not Agile fault or Water fault. The Tulip just happens!

          And finally there are some people who are PASSIVE AGGRESSIVE, say fun things and stab you in your tulip tulip back when you are not looking or around.

          Comment


            #75
            Originally posted by m0n1k3r View Post
            In waterfall they know how much "it" will cost and when "it" will be delivered, but they don't know what quality or how useful for what reality will be then, thus the ROI is questionable.

            In agile they know how much "it" will cost and when "it" will be delivered, and they can be quite certain that "it" will be of good quality and be far better aligned with what reality will look like by the delivery date. The one thing they can't be certain about is what "it" will be, but whatever it is, it will provide far better ROI.



            ROI is one good metric. EVM is another one. Both works very well with agile and especially EVM can be embedded in burn-up charts.

            At one time I dared ask the PMO what the RAG status colours actually meant. Nobody knew. The status was pretty much assigned by gut feel rather than by any empirical or scientific method.

            At the end of the day stakeholders tend to care about risk, and agile is an excellent way of managing risk.
            Moniker

            Interesting observations: what is your opinion on LEAN and SCRUMBAN?

            In my contracting career today, I have not yet found a company that was working as proper LEAN: down the tools, stop the assembly line.

            Comment


              #76
              Originally posted by rocktronAMP View Post
              Have you heard of "SCRUM-BUT"?

              We do "SCRUM" at the Donkey Nuts Investment Bank GMbH, "BUT" we do it our way.

              We are Agile, our daily sit-down last 30-45 minutes and we have 20 people in the office on average meeting time at 8:30am.
              Of course we do two week iterations, we don't bother with sprint planning nor do we like retrospective.


              Sheesh. Get out of that so-called Agile environment fast!
              Yes, it's like anything that just gets paid lip service. That's the main reason agile doesn't work and never will work. I can see the advantages of agile done properly but the Agile fanboys cannot get their head round not doing it properly, which is their main weakness. A senior manager made his way up the corporate ladder without agile, therefore doesn't see the need for it but it keeps the staff happy and makes one of his subordinates the scapegoat for project delivery failure.

              It's all a political game as to what's used. I'll just keep workin', smilin' and billin'
              The greatest trick the devil ever pulled was convincing the world that he didn't exist

              Comment


                #77
                Pair Programming is old hat nowadays....

                May I introduce you to Mob Programming – All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer Why only have 1 backseat driver when you can have 5 including the product owner and the BA....
                merely at clientco for the entertainment

                Comment


                  #78
                  Originally posted by rocktronAMP View Post
                  Moniker

                  Interesting observations: what is your opinion on LEAN and SCRUMBAN?

                  In my contracting career today, I have not yet found a company that was working as proper LEAN: down the tools, stop the assembly line.
                  Lean is the basis for Kanban - continuous improvement. Lean gives you tools to highlight bottlenecks and how to improve on existing process.

                  ScrumBan is neither Scrum or Kanban. It essentially is a ScrumBut (which is what most companies do). I've rarely seen companies who do Scrum by the book

                  Comment


                    #79
                    Originally posted by eek View Post
                    Pair Programming is old hat nowadays....

                    May I introduce you to Mob Programming – All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer Why only have 1 backseat driver when you can have 5 including the product owner and the BA....
                    Which is an analogy of why quiz teams with more than four are not great.
                    The greatest trick the devil ever pulled was convincing the world that he didn't exist

                    Comment


                      #80
                      Originally posted by LondonManc View Post
                      Which is an analogy of why quiz teams with more than four are not great.
                      Eggheads?

                      Comment

                      Working...
                      X