Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: Your opinion on Agile in the Software Development Space

  1. #11
    Gaming Wizard StarBound's Avatar
    Join Date
    Oct 2008
    Posts
    10,328
    Experience

    Default

    My brother works in the animation space. They've had clients that come in and say what they want then on the day of deadline the client comes in and does a 180. I believe the best way of doing things is with constant review of where you are at the time and not to review something once its completely built. So I guess the practice would be called progressive development where are you on the front line as it were and every view days or weeks progress is reviewed to see if its still on target or not.
    LG OLED 55E6V|Samsung K950
    XboneX - PS4 Pro - Switch - SUPER AWESOME PC
    Hidden Content

  2. #12
    Gaming Wizard
    No.1 Pose
    SauRoN's Avatar
    Join Date
    Nov 2007
    Location
    Cape town
    Posts
    26,476
    Game IDs
    Experience

    Default

    Quote Originally Posted by wolv0303 View Post
    Project methodology depends on the product, project and demand from the client.

    Some cases waterfall is the best, others agile or a combination of both.

    Ideally for me if we have something that works after sprint 1 deploy it. I don’t like waiting 10 sprints to get something out only to find out right at the end we need to make an architectural change because of something that caught us out when we went live with the software.

    Best practice is to have the project team decide on the methodology upfront taking into consideration the need and demand.
    See this is where I take an issue with it.

    It seems to work best when the client provides the spec and something is custom built to that for them.

    However in our case we provide industry led proprietary application with minor modification per customer so there is no logic in having them drive it.

    They get to put in the odd feature request and things get modified at implementation time so by and large only one silo needs to really address customer needs and not the entire product/team.

    Besides the whole concept of not having silos only really works if everyone charges the same across the board. Unless that happens nobody really wants to help anybody else because there is an internal budgeting problem in regards to who pays for the work to be done.

    So it’s definitely not a one size fits all and can probably work fine if restricted to departments but not necessarily across the board for a company.
    Hidden Content
    Hidden Content - "I am Quiet, I am the absence of words."

  3. Saying Thanks:

    Raikan007 (June 27th, 2018)  

  4. #13
    Addicted Member
    RESPECT MY AUTHORITY!!!
    AdrianH's Avatar
    Join Date
    Jan 2015
    Location
    Edenvale, Joburg
    Posts
    3,612
    Experience

    Default

    Quote Originally Posted by Vanilla View Post
    Care to elaborate?
    First read the Agile manifesto


    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan


    Some reasons why I think agile does not work


    1. Most companies believe that Agile is basically having routine scrums!
    2. Agile has been hijacked by project managers/scrum masters who love to micro-manage time. IE: The product owner/project manager basically use the backlog and sprint as project plans and timelines.
    3. Its almost impossible for anybody except developers to weigh a task not by time, it just seems impossible for them separate effort required from time required. IE: Check point above.
    4. When ever something is not completed on time, the sprint and backlog is whipped and the developer needs to explain why they didn't finish a task in the current sprint as another similar weighed task was completed on time, basically showing them up as under performing.
    5. Developers are not listened to, and when things go wrong or become late, the developers are normally blamed. This in turn creates low moral in the development team.
    6. Deadlines are put before quality.
    7. If the company couldn't get things working correctly in waterfall, you won't get it working in Agile.


    If we look back at development, programmers came up with ideas like pair programming and user stories to make their lives easier, deal with change more efficiently, and deliver better software solutions in shorter times. These ideas changed team by team, new ideas were tried, some successfully and some not. Jump ahead many years, and authors took some of these ideas, lumped them together to make a process called Agile.

    The whole point of agile is to react to change quickly, and this should filter in scrums as well. The problem is not necessarily agile, but scrums. People want to structure and enforce rules in scrums, backlogs and prints, and due to how people and especially management are, this is what normally happens. It also allows certain role players in the scrum to "disown" responsibilities as well as making it easier to blame when something is not done correctly or on time. When something goes wrong, its easy to blame the agile process or scrum, and to some extend, the blame is normally pushed towards the development team. This is when everything begins falling apart as the scrum becomes devs against the rest. Estimations begin to be warped as developers buffer their estimations don't want to "fail" again. The devs begin "hacking" leading to a reduction in quality as they don't want to "fail" again.

    Agile has become a project management process forced upon the team by management where responsibility and accountability are never given to a single person.


  5. Saying Thanks:

    SauRoN (June 27th, 2018),  Vanilla (June 27th, 2018)  

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •