Jump to content
Frequently Asked Questions
  • Are you not able to open the client? Try following our getting started guide
  • Still not working? Try downloading and running JarFix
  • Help! My bot doesn't do anything! Enable fresh start in client settings and restart the client
  • How to purchase with PayPal/OSRS/Crypto gold? You can purchase vouchers from other users
  • Agile - A Way of Thinking


    noCap

    Recommended Posts

    AGILE

    Hello everyone!

    Something that has been brought up at work a lot by management is Agile. From what I can tell, management thinks Agile is a methodology. Unfortunately, this is not the case.

    We recently hired a new Chief Engineer that gave a wonderful presentation on Agile. I'll sum up her points below.

     

    What is Agile?

     

    I can't stress this point enough...

    Agile is a way of THINKING!

    Agile is NOT a methodology!

    Your software team can be agile and can use methodologies that are Agile, but Agile itself is not a methodology!

    How should management view an Agile program?

     
     

    To answer that question we first have to see what a traditional approach to SW development looks like.

     
     

    https://imgur.com/7nTGhTj

     

    It is important to note that when I say "traditional" what I really mean is a SW team using a traditional method to develop software. For example, waterfall, spiral, or iterative.

    In the image above you'll notice that there are fixed requirements, variable cost, and variable schedule and quality. There are a few problems with developing software this way that I will detail below.

    • Intrinsically, humans are horrible at estimating cost and schedule. Which means that 9 times out of 10, you are lying to your customer about how much the product is going to cost, and when they are going to receive it.
    • In the later stages of development, having building a product towards fixed requirements can come back to bite both the developer and customer in the butt. For example, let's say you are developing the latest and greatest pencil. From the time it takes a company to conduct initial research, develop requirements, develop the product, prototype the pencil, and then deliver the product to the customer. It may take a long time. Long enough time to the point where the design for the pencil and the materials used in the pencil may be obsolete. There is zero room to change the requirements.

    Jumping over to the Agile way of doing things.

     
     

    https://imgur.com/1e0X9IE

     

    In the image above you will notice that there are fixed costs, fixed schedule, fixed quality, and variable requirements. Remember earlier when I said that, as humans, we are really bad at estimating cost and schedule? Well an agile way of development can fix that! :) 

    The whole point of Agile development is to LISTEN to the customer. Throughout the development process, the developer should know that requirements should and will change based on the needs of the customer. Our job (as developers),  should be to deliver the most BUSINESS VALUE to the customer as quick as we can.

    But wait, what is Business Value?

    That's a great question. I don't know how to sum it up in a definition so I'll give an example instead.

    Pretend for a minute you are a an explorer. You needs to be able to get across a river  so that you can explore the other side. I want to break this down using the two models explained above.

    https://imgur.com/QBHL4B7

     

    Here is your scenario illustrated using both a waterfall (traditional) and Agile model.

    In the traditional model, a viable product is not delivered to you until the end. Whereas in the Agile model, a usable product that adds value to you is delivered after the first iteration.

    Something really important to note here that is not illustrated is that in a traditional model, flaws in the design of the product might not be caught till the end. For example, the haul of the boat might not be the right material to traverse the river you must cross. In addition, you, the explorer, might find that the fishing boat (iteration 3) might be exactly what you where looking for! Which means that in a traditional model, you overpaid for something you gained no value from having. 

    Closing thoughts... Agile is something a team should be. It's a mentality that everyone on the team has to buy into for it to work.

    There is a lot I did not cover in this post. So if you have any questions feel free to shoot me a DM or start a conversation on the thread!

    Link to comment
    Share on other sites

    Practiced Agile for a year and a half and recently gone into a waterfall and spiral methodologies with government work flows.  Drastic differences right off the bat. 

    I personally prefer working with scrum but at the same time that really depends on the scrum master and how your work handles scrum titles.  You get a complete idoit at the wheel as scrum master its suddenly the worst methodology around. If done correctly I feel as if development times were drastically lower and the work environment as a whole was much much better.

     

    @Nuclear Nezz mind if I ask if DreamBot has any sorta standardized work flow methodology or if it's at the developers own discretion?

    Link to comment
    Share on other sites

    17 minutes ago, noCap said:

    AGILE

    Hello everyone!

    Something that has been brought up at work a lot by management is Agile. From what I can tell, management thinks Agile is a methodology. Unfortunately, this is not the case.

    We recently hired a new Chief Engineer that gave a wonderful presentation on Agile. I'll sum up her points below.

     

    What is Agile?

      Reveal hidden contents

    I can't stress this point enough...

    Agile is a way of THINKING!

    Agile is NOT a methodology!

    Your software team can be agile and can use methodologies that are Agile, but Agile itself is not a methodology!

    How should management view an Agile program?

      Reveal hidden contents
     

    To answer that question we first have to see what a traditional approach to SW development looks like.

      Reveal hidden contents
     

    https://imgur.com/7nTGhTj

     

    It is important to note that when I say "traditional" what I really mean is a SW team using a traditional method to develop software. For example, waterfall, spiral, or iterative.

    In the image above you'll notice that there are fixed requirements, variable cost, and variable schedule and quality. There are a few problems with developing software this way that I will detail below.

    • Intrinsically, humans are horrible at estimating cost and schedule. Which means that 9 times out of 10, you are lying to your customer about how much the product is going to cost, and when they are going to receive it.
    • In the later stages of development, having building a product towards fixed requirements can come back to bite both the developer and customer in the butt. For example, let's say you are developing the latest and greatest pencil. From the time it takes a company to conduct initial research, develop requirements, develop the product, prototype the pencil, and then deliver the product to the customer. It may take a long time. Long enough time to the point where the design for the pencil and the materials used in the pencil may be obsolete. There is zero room to change the requirements.

    Jumping over to the Agile way of doing things.

      Reveal hidden contents
     

    https://imgur.com/1e0X9IE

     

    In the image above you will notice that there are fixed costs, fixed schedule, fixed quality, and variable requirements. Remember earlier when I said that, as humans, we are really bad at estimating cost and schedule? Well an agile way of development can fix that! :) 

    The whole point of Agile development is to LISTEN to the customer. Throughout the development process, the developer should know that requirements should and will change based on the needs of the customer. Our job (as developers),  should be to deliver the most BUSINESS VALUE to the customer as quick as we can.

    But wait, what is Business Value?

    That's a great question. I don't know how to sum it up in a definition so I'll give an example instead.

    Pretend for a minute you are a an explorer. You needs to be able to get across a river  so that you can explore the other side. I want to break this down using the two models explained above.

    https://imgur.com/QBHL4B7

     

    Here is your scenario illustrated using both a waterfall (traditional) and Agile model.

    In the traditional model, a viable product is not delivered to you until the end. Whereas in the Agile model, a usable product that adds value to you is delivered after the first iteration.

    Something really important to note here that is not illustrated is that in a traditional model, flaws in the design of the product might not be caught till the end. For example, the haul of the boat might not be the right material to traverse the river you must cross. In addition, you, the explorer, might find that the fishing boat (iteration 3) might be exactly what you where looking for! Which means that in a traditional model, you overpaid for something you gained no value from having. 

    Closing thoughts... Agile is something a team should be. It's a mentality that everyone on the team has to buy into for it to work.

    There is a lot I did not cover in this post. So if you have any questions feel free to shoot me a DM or start a conversation on the thread!

    Also hella quality write up forgot to tag that on!  

    Link to comment
    Share on other sites

    1 hour ago, yeeter01 said:

    Practiced Agile for a year and a half and recently gone into a waterfall and spiral methodologies with government work flows.  Drastic differences right off the bat. 

    I personally prefer working with scrum but at the same time that really depends on the scrum master and how your work handles scrum titles.  You get a complete idoit at the wheel as scrum master its suddenly the worst methodology around. If done correctly I feel as if development times were drastically lower and the work environment as a whole was much much better.

     

    @Nuclear Nezz mind if I ask if DreamBot has any sorta standardized work flow methodology or if it's at the developers own discretion?

     

    1 hour ago, dQw4w9WgXcQ said:

    very professional

    Thank you both!

    @dQw4w9WgXcQ thank you :)

    @yeeter01 Speaking from experience, you'll notice the government still lags behind and will lean towards using more traditional models when it comes to software development. Scrum is actually one of the more Agile methodologies because (when done correctly) fixes schedule. The problem is, people get so caught up with including every fix they promised they would into (typically) a sprint, that they forget that it is okay NOT to complete every object/requirement/user story. That was one of the measures of how agile a team actually is.

    Also, great question for Nezz! Excited to hear their response :)

    Link to comment
    Share on other sites

    3 hours ago, yeeter01 said:

    Practiced Agile for a year and a half and recently gone into a waterfall and spiral methodologies with government work flows.  Drastic differences right off the bat. 

    I personally prefer working with scrum but at the same time that really depends on the scrum master and how your work handles scrum titles.  You get a complete idoit at the wheel as scrum master its suddenly the worst methodology around. If done correctly I feel as if development times were drastically lower and the work environment as a whole was much much better.

     

    @Nuclear Nezz mind if I ask if DreamBot has any sorta standardized work flow methodology or if it's at the developers own discretion?

    It's basically at our own discretion at this point.

    Pandemic handles server, Noto handles new stuff, I handle DB2 (well, now Arti too)

    Because of our location/time differences, doing stand ups is not practical. We're far enough into our development that it's mostly upkeep.

    Plus when we first started, we were just a group of people who had no fuckin idea what we were doing.

    Link to comment
    Share on other sites

    2 minutes ago, Nuclear Nezz said:

    It's basically at our own discretion at this point.

    Pandemic handles server, Noto handles new stuff, I handle DB2 (well, now Arti too)

    Because of our location/time differences, doing stand ups is not practical. We're far enough into our development that it's mostly upkeep.

    Plus when we first started, we were just a group of people who had no fuckin idea what we were doing.

    thanks for the dank insight!

    Link to comment
    Share on other sites

    14 minutes ago, Nuclear Nezz said:

    It's basically at our own discretion at this point.

    Pandemic handles server, Noto handles new stuff, I handle DB2 (well, now Arti too)

    Because of our location/time differences, doing stand ups is not practical. We're far enough into our development that it's mostly upkeep.

    Plus when we first started, we were just a group of people who had no fuckin idea what we were doing.

    Thanks for the insight! How about in your irl job? Have you experienced anyone in management that just seem to be stuck in their ways and is not willing to change? I think the hardest thing for people to grasp is the complete 180 they have to do in terms of how they approach development.

    Link to comment
    Share on other sites

    16 minutes ago, noCap said:

    Thanks for the insight! How about in your irl job? Have you experienced anyone in management that just seem to be stuck in their ways and is not willing to change? I think the hardest thing for people to grasp is the complete 180 they have to do in terms of how they approach development.

    This is my job :P
    Since I'm management...

    Yeah fuck those guys. I hear he's a real dick.

    Link to comment
    Share on other sites

    Archived

    This topic is now archived and is closed to further replies.

    ×
    ×
    • Create New...

    Important Information

    We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.