5 ms·

Anything that's rigid is by definition not agile. For every practice it's important to understand the reason behind it and what it's supposed to accomplish, and

Anything that's rigid is by definition not agile. For every practice it's important to understand the reason behind it and what it's supposed to accomplish, and then you can determine if that's something that you care to accomplish, or if perhaps there is a better way to accomplish it within your own team. The converse is also true though. A lot of things will get resistance because people don't like to change, or they'd rather not leave their desk and talk to other people, or they only want to optimize for their personal productivity without considering the productivity of the team as a whole. That last one in particular is the source of a lot of friction with developers in my experience. Individuals like to optimize for their own personal productivity, and sometimes in order to increase the productivity of the team the individual productivity needs to suffer. So as long as you're being mindful of your practices, what you're doing and why you're doing it, and looking to constantly improve the output of the team as a whole then feel free to adopt what makes sense and discard what doesn't work, and ignore anyone trying to sell you on dogma that they barely understand themselves.

GVIrish 9y ago
> Individuals like to optimize for their own personal productivity, and sometimes in order to increase the productivity of the team the individual productivity needs to suffer. This makes a lot of things click into place for me. I've consistently seen it be a struggle for people to buy into the activities that may not immediately make things easier for the individual, but are necessary for the team, myself included. Stating it this way cuts right to the essence of why those activities are vital.
cottsak 9y ago
> Anything that's rigid is by definition not agile. Disagree only in that you need some rigidity for some time in order to get consistency and value. Agile dictates that this time-boxed rigidity should be routinely inspected and adapted over time. Does that make sense? More of my views here https://leanpub.com/agileforleads/ https://leanpub.com/agileforleads/
- nameless912 9y ago
  Right, this is my view on agile. The only constant should be re-evaluation. We started out differently than most teams, where we began with a very loose process and tightened it over time (as opposed to many who start out very rigidly and let them slack over time) and this has led to us: 1. Predicting with surprisingly good accuracy (within 10% usually) how much work we can get done 2. Spending only ~3 hours a week doing "rituals" (we do our stand ups in HipChat and we have two backlog grooming sessions a week; every other week we spend an hour for review/retro and an hour for planning), which gives us an overhead of ~8% time "wasted" doing our planning 3. onboarding new members in only a couple of weeks; we plan so that they always join mid-sprint so that they get a solid week to just read up on our code and observe our process before jumping in for their first planning 4. creating a really cross-functional "everyone works on everything" team; for my part, I spend most of my day in the weeds of Kubernetes for a variety of projects, but I'm able to cross-train on the other components my team works on, and I'm slowly teaching all of them K8s. I won't call it "agile" because it's a dirty word apparently, but I really like it now that we've spent a few months hammering out the kinks.
OnlyRepliesToBS 9y ago
"you're doing it wrong" Always the singleton implement's fault for doing it wrong... Do you understand how much like a religion that sounds?

GVIrish 9y ago

> Individuals like to optimize for their own personal productivity, and sometimes in order to increase the productivity of the team the individual productivity needs to suffer. This makes a lot of things click into place for me. I've consistently seen it be a struggle for people to buy into the activities that may not immediately make things easier for the individual, but are necessary for the team, myself included. Stating it this way cuts right to the essence of why those activities are vital.

cottsak 9y ago

> Anything that's rigid is by definition not agile. Disagree only in that you need some rigidity for some time in order to get consistency and value. Agile dictates that this time-boxed rigidity should be routinely inspected and adapted over time. Does that make sense? More of my views here https://leanpub.com/agileforleads/ https://leanpub.com/agileforleads/

nameless912 9y ago
Right, this is my view on agile. The only constant should be re-evaluation. We started out differently than most teams, where we began with a very loose process and tightened it over time (as opposed to many who start out very rigidly and let them slack over time) and this has led to us: 1. Predicting with surprisingly good accuracy (within 10% usually) how much work we can get done 2. Spending only ~3 hours a week doing "rituals" (we do our stand ups in HipChat and we have two backlog grooming sessions a week; every other week we spend an hour for review/retro and an hour for planning), which gives us an overhead of ~8% time "wasted" doing our planning 3. onboarding new members in only a couple of weeks; we plan so that they always join mid-sprint so that they get a solid week to just read up on our code and observe our process before jumping in for their first planning 4. creating a really cross-functional "everyone works on everything" team; for my part, I spend most of my day in the weeds of Kubernetes for a variety of projects, but I'm able to cross-train on the other components my team works on, and I'm slowly teaching all of them K8s. I won't call it "agile" because it's a dirty word apparently, but I really like it now that we've spent a few months hammering out the kinks.

OnlyRepliesToBS 9y ago

"you're doing it wrong" Always the singleton implement's fault for doing it wrong... Do you understand how much like a religion that sounds?