41–50 of 62 posts
> Product owners can replace planning meetings by simply filing issues in the issue tracker, assigning priority, assigning them to people, and setting a release milestone. People will know what to work on by simply working on whatever the highest priority issue is in their queue. This goes against approximately everything I've learned about process in the last 10 years. In fact, I think there's literally nothing corr…
It's tough in an Agile project to keep up with all the stuff. Documenting everything wastes a lot of time.
I sort of disliked the last point >Document Everything. It's tough in an Agile project to keep up with all the stuff. Documenting everything wastes a lot of time.
This also relies on the spec being updated with any changes agreed in the work process.
Earlier quoted context omitted.
I've worked on teams that do precisely this and, and it's worked remarkably well - sometimes. It varies a lot by team; some combinations of people just absolutely fly with this process, they're happy and extremely productive, while others flounder around unsure of what to do. Some of my observations from it that hopefully answer some of your concerns: 1.) This only works when you have a team full of self-motivated en…
There is, just out of reach, a dream of unifying methodology and effectiveness and decent life outside of work - Agile that demands collocation starts to hurt teams that want people with families in central London. I can almost reach the goal.
We work in a very fortunate society - rich enough now, connected enough now, to contemplate the almost impossible - having people far-flung work as well together as people in the same rooms.
We need to focus on the feelings of safety, of duty and comraderie, on the measurement of achievement and on the collegiate nature of lifting the less educated to par.
I can only achieve this dream if I throw out the nicieties of society and out reach others - or I can achieve this dream in the company of others - a harder task, but not impossible.
Agile Manifesto - put together after lots of thought and signed by acclaimed industry professionals.
Async Manifesto - someone's opinion on a website.
> Product owners can replace planning meetings by simply filing issues in the issue tracker, assigning priority, assigning them to people, and setting a release milestone. People will know what to work on by simply working on whatever the highest priority issue is in their queue. This goes against approximately everything I've learned about process in the last 10 years. In fact, I think there's literally nothing corr…
> this manifesto seems built around the idea of minimizing communication Of course, because communication is expensive (as in time wasted, brainpower wasted, decreased focusing-ability etc.). But I think they get it wrong with meetings: A few time boxed stand-up meetings are great instead of "full-time IM-ing" for distributed teams or "anytime possible interruptions for collocation ones. I think the OP dreams of an "…
I think synchronous communication is incredibly important for big-picture items - here is what we're building, here is what we think it should look like, here is how we think it should generally work - and often necessary for working through tricky problems (pair-programming is a great example of this), but that asynchronous is better for pretty much everything in between.
Seems more like a manifesto for Autistic Software Development. Take scrum, cut out everything that involves direct human interaction and replace it with tools and documents. God forbid us developers should waste time communicating with other human beings. Who needs the bandwidth of face-to-face interaction when you can just do a pull request?
Do you really want to know what the developer three rows down is working on every day?
The next shift in management will likely include group calisthenics followed by corporate dormitories.
Seems more like a manifesto for Autistic Software Development. Take scrum, cut out everything that involves direct human interaction and replace it with tools and documents. God forbid us developers should waste time communicating with other human beings. Who needs the bandwidth of face-to-face interaction when you can just do a pull request?
"Take scrum, cut out everything that involves direct human interaction and replace it with tools and documents." Do you really want to know what the developer three rows down is working on every day? The next shift in management will likely include group calisthenics followed by corporate dormitories.
Unequivocally yes.
Pros:
- General concept of leveraging asyncronous communication and minimizing disruptions to workflow; most organizations could probably benefit from considering this in their process improvement efforts, because its something that many don't do well,
- Preference for documented process (which is very important for team ownership of process and continuous bottom-up experimental and evidence-driven process improvement), and again its a place lots of organizations, of all types, seem to fall down on.
Cons:
- The idea that product owners can just assign priority; I think the best priority concept to come out of the agile tradition is that the product owner determines the value of a work item to a client, and the team estimates the effort of the item, and the priority is assigned in descending order of value/effort ratio.
- Related to the above, the idea that you can dispense with backlog grooming with no replacement. Backlog grooming is essential to get work properly divided into reasonably sized chunks (to avoid wasted effort on an improperly-scaled item) with independent value, and to assure that they are in a state ready to assess both independent value of the chunks and the work effort associated with them to set priority.
- Related to both of the above, the idea of skipping planning meetings, which aren't frequent so as to pose significant flow barriers, and for which (aside from shifting things that require the input of the team to being done without input by the PO) the manifesto provides no real alternative.
- skipping daily standups (proper daily standups should be scheduled so as not to be interruptions in workflow, and are designed to enable flow, not impede it, but providing both an important venue to address barriers and by constraining the disruption to other people that trying to do so by broadcast rather than regularly scheduled brief meetings would impose.)
- (mostly tangential, but, hey, its false and its right up at the top) the premise that "Scrum" (a top-down defined process-over-people-do-it-by-the-prescribed-Scripture-as-interpreted-by-your-centrally-Certified ScrumMaster®-or-you're-doing-it-wrong methodology) is implementation of Agile, which prioritizes, as the first element of the Agile Manifesto, people and interactions over processes and tools, is, while popular, dead wrong. Lots of the things in the Scrum guide are things that Agile organizations have found work for them and so do -- but Scrum is pretty much the opposite of Agile, and is the exact kind of packaged one-size-fits-all solution that the Agile Manifesto was a reaction against.
First of all, both agile manifesto and this new one annoy me, mostly because the statements are far too open ended and vague to be of use. I like them because they're clever, but when employed by someone who takes everything literally they are at best a pain and lead to all the crap out there they try to label as agile/scrum. Anyways, for anyone trying to grok this: Agile: 1) Individuals and interactions over process…
The Agile Manifsto isn't supposed to be "of use" in the sense of a canned methodology, its supposed to be a starting point for thinking about what works for you rather than adopting canned methodologies. So, that's as designed.
(The Async Manifesto doesn't really seem vague -- it dictates specific practices as well as general principles. So I think its unfair to ding it for vagueness, and better to ding it for the specific practices being generally ill-conceived.)