4 ms·

> Interacting with 3rd parties, writing contracts, hiring developers, planning how your project interacts with other projects and the wider organization, respon

> Interacting with 3rd parties, writing contracts, hiring developers, planning how your project interacts with other projects and the wider organization, responding to regulations and external enquiries, managing the demand for certainty from stakeholders, obtaining funding, maintaining financial control... These aren't part of Agile 101, but the Agile community has been discussing these things for years. I first heard Mary Poppendieck discuss Agile contracts in 2006 or so [1]. Pat Reed has been talking about Agile accounting since at least 2014, and I doubt that was the beginning of it [2]. My book discusses techniques for making commitments to stakeholders, and it was written in 2007 [3]. Literally Google the phrase "Agile" + anything you wrote and you'll find a wealth of resources. If you're not finding that information, it's because you're not looking. [1] http://agileconsortium.pbworks.com/f/AgileContracts.pdf http://agileconsortium.pbworks.com/f/AgileContracts.pdf [2] https://www.slideshare.net/ITRevolution/wednesday-530-pat-reed-gb-final https://www.slideshare.net/ITRevolution/wednesday-530-pat-re... [3] https://www.jamesshore.com/Agile-Book/risk_management.html https://www.jamesshore.com/Agile-Book/risk_management.html

blub 8y ago
The agile community is currently an amorphous blob of people connected by words like "Agile!", "Scrum", "TDD" and so on. Agile was stolen from its creators and mutated into a corporate version - which I have to say I find pretty darn funny. Point is, that info is certainly not included in any of the Agile resources I've seen. The only one that handles some of this is Ambler's D.A.D, but I didn't bother reading that for a simple reason: after seeing various Agile methods (mostly Scrum) fail so much, I've come to the conclusion that Agile development processes do not represent a real-world solution. There's always an excuse why Scrum fails in practice, but in the end it requires such a paradigm shift from our typical development approaches in order to succeed, that it's about as useful as a diet plan that only works on super-athletes. XP is in zombie mode for a decade, Scrum is only good for mobile apps and small websites, Kanban is not even a way of making software. What are we left with? Scaled Agile, LeSS, which even the original Agile people bitterly complain about? These won't work either, but I know some consultants make a crapton of money selling them to corps.
- dajohnson89 8y ago
  just curious -- what do you recommend?
  - blub 8y ago
    I find the whole idea of one size fits all processes dubious. I don't have a solution for this and I haven't seen any such process work reliably in large scale projects. Scrum quite clearly can't tolerate the peculiarities and pressures of a large scale mixed HW-SW projects for instance. Those will turn the whole sprint / PO / independent SW team arrangement into mush. A long time ago I did some waterfall-RUP mix which didn't feel worse compared to the Scrum I did recently, but it did result in better documentation and traceability. If I had the chance I would take bits and pieces from several processes and experiment to see which work for a particular company and department, perhaps even at project level. Things that come to mind: Kanban-like task management, regular retrospectives, an exploratory design phase at the beginning, documentation (FFS!), history-based estimation + careful team-private time tracking, a project manager that doesn't also manage the team and doesn't have too much power, regular customer-feedback cycles, CI/CD pipeline, etc.
- shandor 8y ago
  > I've come to the conclusion that Agile development processes do not represent a real-world solution. I think one of the problems regarding this whole discussion, whenever it stirs up, is that Agile (as defined in the original manifesto) is explicitly not about any particular processes, but still most of the critique against Agile seems to actually be against different kinds of "agile processes". The manifesto explicitly states "Individuals and interactions over processes and tools". In real world, one of course needs actual processes, and all kinds of consults are trying to ride the wave to lucrative contracts. But since the Agile Manifesto is about values, not processes, you cannot steal it from its creators. You can pervert the meaning and utilize some braindead processes in your company and call them "agile", but that doesn't lessen the worth of the original values. I know that that's a highly unsatisfactory answer, a kind of a cop-out, but I think applying more to Agile than it's meant to be is part of the problems surrounding it today. Edit: those "you"s are meant for passive voice. No personal offense or commentary meant.
beat 8y ago
People tend to say "Resources don't exist" to mean "I have never bothered to look".

blub 8y ago

The agile community is currently an amorphous blob of people connected by words like "Agile!", "Scrum", "TDD" and so on. Agile was stolen from its creators and mutated into a corporate version - which I have to say I find pretty darn funny. Point is, that info is certainly not included in any of the Agile resources I've seen. The only one that handles some of this is Ambler's D.A.D, but I didn't bother reading that for a simple reason: after seeing various Agile methods (mostly Scrum) fail so much, I've come to the conclusion that Agile development processes do not represent a real-world solution. There's always an excuse why Scrum fails in practice, but in the end it requires such a paradigm shift from our typical development approaches in order to succeed, that it's about as useful as a diet plan that only works on super-athletes. XP is in zombie mode for a decade, Scrum is only good for mobile apps and small websites, Kanban is not even a way of making software. What are we left with? Scaled Agile, LeSS, which even the original Agile people bitterly complain about? These won't work either, but I know some consultants make a crapton of money selling them to corps.

dajohnson89 8y ago
just curious -- what do you recommend?
- blub 8y ago
  I find the whole idea of one size fits all processes dubious. I don't have a solution for this and I haven't seen any such process work reliably in large scale projects. Scrum quite clearly can't tolerate the peculiarities and pressures of a large scale mixed HW-SW projects for instance. Those will turn the whole sprint / PO / independent SW team arrangement into mush. A long time ago I did some waterfall-RUP mix which didn't feel worse compared to the Scrum I did recently, but it did result in better documentation and traceability. If I had the chance I would take bits and pieces from several processes and experiment to see which work for a particular company and department, perhaps even at project level. Things that come to mind: Kanban-like task management, regular retrospectives, an exploratory design phase at the beginning, documentation (FFS!), history-based estimation + careful team-private time tracking, a project manager that doesn't also manage the team and doesn't have too much power, regular customer-feedback cycles, CI/CD pipeline, etc.
shandor 8y ago
> I've come to the conclusion that Agile development processes do not represent a real-world solution. I think one of the problems regarding this whole discussion, whenever it stirs up, is that Agile (as defined in the original manifesto) is explicitly not about any particular processes, but still most of the critique against Agile seems to actually be against different kinds of "agile processes". The manifesto explicitly states "Individuals and interactions over processes and tools". In real world, one of course needs actual processes, and all kinds of consults are trying to ride the wave to lucrative contracts. But since the Agile Manifesto is about values, not processes, you cannot steal it from its creators. You can pervert the meaning and utilize some braindead processes in your company and call them "agile", but that doesn't lessen the worth of the original values. I know that that's a highly unsatisfactory answer, a kind of a cop-out, but I think applying more to Agile than it's meant to be is part of the problems surrounding it today. Edit: those "you"s are meant for passive voice. No personal offense or commentary meant.

beat 8y ago

People tend to say "Resources don't exist" to mean "I have never bothered to look".