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

Agile, again....

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

    #31
    Originally posted by milanbenes View Post
    was involved in a Project earlier this year, new Project new .net implementation of one of the Business Suite products with integration to other existing Business Suite products.

    One of my contributions was to confirm that all of the .Net Business Suite products involved have enough capacity for the new Demand.

    I said to the PM, can you share numbers of Users, peaks of concurrent activity, data transfers, volumes of data, frequency.

    This was in February.

    They wanted to go live in September.

    PM says, we haven't done that yet, capacity planning.

    I says, why not ?

    PM says, this is an Agile project and we're gonna do that in July/August.

    I said Agile or not, adding capacity to these .Net Business Suite systems has considerable lead times, and if you start doing your calculations in July/August there won't be enough time to get the capacity in place before your goLive.

    PM says, oh.

    Milan.
    The Chunt of Chunts.

    Comment


      #32
      Originally posted by milanbenes View Post
      was involved in a Project earlier this year, new Project new .net implementation of one of the Business Suite products with integration to other existing Business Suite products.

      One of my contributions was to confirm that all of the .Net Business Suite products involved have enough capacity for the new Demand.

      I said to the PM, can you share numbers of Users, peaks of concurrent activity, data transfers, volumes of data, frequency.

      This was in February.

      They wanted to go live in September.

      PM says, we haven't done that yet, capacity planning.

      I says, why not ?

      PM says, this is an Agile project and we're gonna do that in July/August.

      I said Agile or not, adding capacity to these .Net Business Suite systems has considerable lead times, and if you start doing your calculations in July/August there won't be enough time to get the capacity in place before your goLive.


      PM says, oh.

      Milan.
      And this is where Agile falls down - it assumes that all tasks can be done in a 1 week sprint therefore anything we desperately need is only 1 week away.

      However this is not the case if you have to hook into third parties etc who will have their own timescales and methodologies.

      Which is why you still need proper architecture management for large projects.

      In fact unless you are doing a front end change to a website which people are just consuming from then I am starting to see that Agile really quickly looses it's benefits.

      Comment


        #33
        Originally posted by original PM View Post
        And this is where Agile falls down - it assumes that all tasks can be done in a 1 week sprint therefore anything we desperately need is only 1 week away.

        However this is not the case if you have to hook into third parties etc who will have their own timescales and methodologies.

        Which is why you still need proper architecture management for large projects.

        In fact unless you are doing a front end change to a website which people are just consuming from then I am starting to see that Agile really quickly looses it's benefits.
        The only reason companies want agile is that it allows them to hide their inability to make decisions and stand behind them.
        merely at clientco for the entertainment

        Comment


          #34
          Originally posted by eek View Post
          The only reason companies want agile is that it allows them to hide their inability to make decisions and stand behind them.
          +1 for that

          because they can change their mind ever week and it will get done....

          which works fine until you release that the decision you made 10 weeks ago now means the last 10 weeks work needs to be binned!

          Comment


            #35
            Originally posted by original PM View Post
            +1 for that

            because they can change their mind ever week and it will get done....

            which works fine until you release that the decision you made 10 weeks ago now means the last 10 weeks work needs to be binned!

            it's Agile innit

            Sprinting around circles, what's not to like ?

            Milan.

            Comment


              #36
              Originally posted by original PM View Post
              +1 for that

              because they can change their mind ever week and it will get done....

              which works fine until you release that the decision you made 10 weeks ago now means the last 10 weeks work needs to be binned!
              IMO, it works for web sites and applications, in fact anything that can be compartmentalised, to an extent.

              I can't see it would ever work, in the purest form, for a large system deployment.
              The Chunt of Chunts.

              Comment


                #37
                Originally posted by MrMarkyMark View Post
                I can't see it would ever work, in the purest form, for a large system deployment.
                And yet it is used for large roll-outs. Not very well, but it is used.
                …Maybe we ain’t that young anymore

                Comment


                  #38
                  Originally posted by WTFH View Post
                  And yet it is used for large roll-outs. Not very well, but it is used.
                  that's because it's the fashion innit

                  Milan.

                  Comment


                    #39
                    Originally posted by WTFH View Post
                    And yet it is used for large roll-outs. Not very well, but it is used.
                    Sure, I'm under no illusion that some muppets try, but I could never see it working due to the points raised above.
                    A mixture of methods has always worked well for me.
                    IMO, large systems are best delivered by waterfall, with the right people engaged to make that happen.
                    The Chunt of Chunts.

                    Comment


                      #40
                      Componentisation - That's the Key

                      Originally posted by MrMarkyMark View Post
                      IMO, it works for web sites and applications, in fact anything that can be compartmentalised, to an extent.

                      I can't see it would ever work, in the purest form, for a large system deployment.
                      There's only one thing you need to remember about software development: always break your project into components - as small as you can get. Then you can run each component with a small team (yes - the smaller; the better )

                      You do of course need to agree interfaces up front. There are only two things you need to remember about software development: always break your project into components and make sure you define interfaces up front.

                      I know you're thinking that trying to define interfaces before you've designed a system can be tricky. So you need to make your interfaces very virtual. There are only three things you need to remember about software development: always break your project into components, make sure you define interfaces up front and make your interfaces very virtual. A classic virtual interface strategy is always to use views when accessing databases. Never write to tables, but always to views. The principle however can be extended to all manner of interfaces: the more layers on the interface; the more chance you can adjust the interface without screwing up your code.

                      Componentize and the world is your oyster
                      "Don't part with your illusions; when they are gone you may still exist, but you have ceased to live" Mark Twain

                      Comment

                      Working...
                      X