5 ms·

What is actually Agile then, and how does one actually practice it?

ajmurmann 4y ago
agilemanifesto.org Constant reflection and drive towards faster feedback. XP or if I squint Scrum can be a starting point, but you gotta adapt to the individuals on the team and the characteristics of the type of problem you are solving.
lr4444lr 4y ago
It's a methodology that makes software more resilient to the changing needs of the business. Anything that violates the 12 canonical principles[0] should be thrown out - and this has to be determined by each org. individually. [0] https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html
mindcrime 4y ago
/u/lr4444lr and /u/ajmurmann nailed it. "Agile" is just what the Agile Manifesto says. Strictly speaking, "Agile" in and of itself isn't even a methodology - it's just a set of principles, to which a number of concrete methodologies claim some association. They differ in the degree to which they faithfully represent the spirit of the manifesto. So really, you're never "doing Agile". You're "doing $X" where $X can be Scrum, XP, Crystal, AgileUP, SAFe, or whatever. At most companies what you get, in my experience, is a bastardized version of Scrum cobbled together by somebody who has never actually developed software, took a couple of Scrum classes (maybe), paid too much money for some "help" from some "Agile coaches", and is hoping some of the resulting shit will stick to the wall. FWIW, I've actually had the pleasure of working at company that did Scrum and really did it well, and it was honestly a great experience. Actual Scrum, as documented in the Scrum Guide, isn't bad. The problem is when people take base Scrum and start tacking on additional shit (see: "agile coaches" and "agile consultants") and wind up with a bureaucratic / kafka-esque tarpit of interminable meetings, ceremonies, and artifacts. In other words, pretty much exactly what the Agile Manifesto stood against in the first place.
- RHSman2 4y ago
  Difference between doing Agile and being agile is the same as education. You can have engineers who are educated well and you can have engineers who get stuff done, well without a high level of ‘education’.
  - ttyprintk 4y ago
    You’re talking about training, not education. A masters in engineering will be an experience in software architecture. An engineering role under one of these management styles will be an experience in training.
    - RHSman2 4y ago
      No I’m not. You are.
  - jimbomins 4y ago
    If you have an engineer the whole point of them being able to claim the title is they are educated and expert in their field. Without knowledge and expertise in a field you aren't going to get any engineering done. Which is different to saying anyone trained to be an engineer will be able to get stuff done. But getting stuff done was always a recnognised requirement of an engineer; i.e. by definition they should be getting stuff done.
cwingrav 4y ago
Agile is to Lenin as Agile processes are to Stalin. Read the Agile Manifesto. That’s what Agile is. All else is either: - (good) trying to implement the Agile Manifesto, or - (bad) trying to make current process appear like Agile.
gonzo41 4y ago
You speak with a client. They say what they want. You build it they test it, and state objections and or request more features. You discuss and then build the agreed thing. And then you do this loop untill you ship
Too 4y ago
The whole idea is that there is no strictly formal version of the process. It can't be answered with a package. The process itself is agile, ammendable, fluid, mutable, improvable. You do what works for you. Just stick to the principles of focusing on the product customer value over the processes themselves, with recurring reflection over how your process is working, as per the agile manifesto. If your company hasn't done this before, Scrum is a good starting point, but it is by no means a goal nor the final destination. This is where most companies fail.
- fabioborellini 4y ago
  Some companies will just request a ready-made agile process from a certified agile overlord. The process will hinder productivity since only reporting parts and rituals are implemented, and all improvements suggested by individuals participating are dismissed since they are “against the agile process”. I did leave and the company did crumble shortly afterwards. The main reason wasn’t related to processes, though. It was already too late when the faux-agile was introduced.
Viliam1234 4y ago
You asked about Agile, but I will talk about Scrum instead, because I am more familiar with it. https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html Ctrl+F "JIRA" - 0 results Ctrl+F "velocity" - 0 results Ctrl+F "on-call" - 0 results Ctrl+F "manager" - 0 results Selected quotes: > Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how. > During the Sprint: No changes are made that would endanger the Sprint Goal; > The Daily Scrum is a 15-minute event A short version is that you have a small team of intelligent people who are given sufficient autonomy. They split time into intervals called "sprints", each sprint is 2-4 weeks long. (If you have no experience with Scrum, start with 2 weeks. When you get used to it, the team can decide the correct length.) At the beginning of the sprint, the developers and the representative of the customer agree what gets done. During the sprint, the developers do it. Every day there is a short meeting in the morning, when developers say "I completed this; I am going to work on this; I am blocked by this", nothing more. At the end of the sprint, developers show the implemented changes to the representative of the customer. Then the developers talk among themselves about what was good during this sprint, what was bad, and what they want to do differently the next time. The important thing (ignored at almost all companies pretending to do Scrum) is that in this ideal world, managers do not exist. Developers manage themselves. In the daily meetings, developers report their progress to each other. What needs to be done, is decided by the representative of the customer (literally a person from a different company, or from a different department if this is an internal project). How it gets done, that is decided by the developers. When developers talk about what was good and bad, and what needs to be done differently, they actually have the power to do it differently the next time. Developers assign the work between themselves, and make estimates how long something would take. Shortly: the developers are treated as adults, and their responsibility to the customer is defined on a biweekly or monthly basis.

agilemanifesto.org Constant reflection and drive towards faster feedback. XP or if I squint Scrum can be a starting point, but you gotta adapt to the individuals on the team and the characteristics of the type of problem you are solving.

lr4444lr 4y ago

It's a methodology that makes software more resilient to the changing needs of the business. Anything that violates the 12 canonical principles[0] should be thrown out - and this has to be determined by each org. individually. [0] https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html

mindcrime 4y ago

/u/lr4444lr and /u/ajmurmann nailed it. "Agile" is just what the Agile Manifesto says. Strictly speaking, "Agile" in and of itself isn't even a methodology - it's just a set of principles, to which a number of concrete methodologies claim some association. They differ in the degree to which they faithfully represent the spirit of the manifesto. So really, you're never "doing Agile". You're "doing $X" where $X can be Scrum, XP, Crystal, AgileUP, SAFe, or whatever. At most companies what you get, in my experience, is a bastardized version of Scrum cobbled together by somebody who has never actually developed software, took a couple of Scrum classes (maybe), paid too much money for some "help" from some "Agile coaches", and is hoping some of the resulting shit will stick to the wall. FWIW, I've actually had the pleasure of working at company that did Scrum and really did it well, and it was honestly a great experience. Actual Scrum, as documented in the Scrum Guide, isn't bad. The problem is when people take base Scrum and start tacking on additional shit (see: "agile coaches" and "agile consultants") and wind up with a bureaucratic / kafka-esque tarpit of interminable meetings, ceremonies, and artifacts. In other words, pretty much exactly what the Agile Manifesto stood against in the first place.

RHSman2 4y ago
Difference between doing Agile and being agile is the same as education. You can have engineers who are educated well and you can have engineers who get stuff done, well without a high level of ‘education’.
- ttyprintk 4y ago
  You’re talking about training, not education. A masters in engineering will be an experience in software architecture. An engineering role under one of these management styles will be an experience in training.
  - RHSman2 4y ago
    No I’m not. You are.
- jimbomins 4y ago
  If you have an engineer the whole point of them being able to claim the title is they are educated and expert in their field. Without knowledge and expertise in a field you aren't going to get any engineering done. Which is different to saying anyone trained to be an engineer will be able to get stuff done. But getting stuff done was always a recnognised requirement of an engineer; i.e. by definition they should be getting stuff done.

cwingrav 4y ago

Agile is to Lenin as Agile processes are to Stalin. Read the Agile Manifesto. That’s what Agile is. All else is either: - (good) trying to implement the Agile Manifesto, or - (bad) trying to make current process appear like Agile.

gonzo41 4y ago

You speak with a client. They say what they want. You build it they test it, and state objections and or request more features. You discuss and then build the agreed thing. And then you do this loop untill you ship

Too 4y ago

The whole idea is that there is no strictly formal version of the process. It can't be answered with a package. The process itself is agile, ammendable, fluid, mutable, improvable. You do what works for you. Just stick to the principles of focusing on the product customer value over the processes themselves, with recurring reflection over how your process is working, as per the agile manifesto. If your company hasn't done this before, Scrum is a good starting point, but it is by no means a goal nor the final destination. This is where most companies fail.

fabioborellini 4y ago
Some companies will just request a ready-made agile process from a certified agile overlord. The process will hinder productivity since only reporting parts and rituals are implemented, and all improvements suggested by individuals participating are dismissed since they are “against the agile process”. I did leave and the company did crumble shortly afterwards. The main reason wasn’t related to processes, though. It was already too late when the faux-agile was introduced.

Viliam1234 4y ago

You asked about Agile, but I will talk about Scrum instead, because I am more familiar with it. https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html Ctrl+F "JIRA" - 0 results Ctrl+F "velocity" - 0 results Ctrl+F "on-call" - 0 results Ctrl+F "manager" - 0 results Selected quotes: > Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how. > During the Sprint: No changes are made that would endanger the Sprint Goal; > The Daily Scrum is a 15-minute event A short version is that you have a small team of intelligent people who are given sufficient autonomy. They split time into intervals called "sprints", each sprint is 2-4 weeks long. (If you have no experience with Scrum, start with 2 weeks. When you get used to it, the team can decide the correct length.) At the beginning of the sprint, the developers and the representative of the customer agree what gets done. During the sprint, the developers do it. Every day there is a short meeting in the morning, when developers say "I completed this; I am going to work on this; I am blocked by this", nothing more. At the end of the sprint, developers show the implemented changes to the representative of the customer. Then the developers talk among themselves about what was good during this sprint, what was bad, and what they want to do differently the next time. The important thing (ignored at almost all companies pretending to do Scrum) is that in this ideal world, managers do not exist. Developers manage themselves. In the daily meetings, developers report their progress to each other. What needs to be done, is decided by the representative of the customer (literally a person from a different company, or from a different department if this is an internal project). How it gets done, that is decided by the developers. When developers talk about what was good and bad, and what needs to be done differently, they actually have the power to do it differently the next time. Developers assign the work between themselves, and make estimates how long something would take. Shortly: the developers are treated as adults, and their responsibility to the customer is defined on a biweekly or monthly basis.