4 ms·

I'm sure this won't be popular with the devoted, but I find Scrum, Kanban and daily stand-ups a huge waste of time. It's funny how rigid agile becomes when you

I'm sure this won't be popular with the devoted, but I find Scrum, Kanban and daily stand-ups a huge waste of time. It's funny how rigid agile becomes when you can make a lot of money making it rigid through consulting dollars.

maxxxxx 9y ago
Kanban is not that bad. It's essentially a prioritized pipeline of things that need to be done. You can do it without standups.
- 0xFFFF0000 9y ago
  Agreed with mandatory daily standups. Nothing that prevents you from skipping or doing it differently. I always found Kanban to be the more "do whatever works" approach, that might work better for teams that know each other very well.
cstejerean 9y ago
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.
- 9y ago
mixmastamyk 9y ago
Am not devoted but was tempted to downvote this. They may be a waste of time depending on project/team size, or they may facilitate communication to avoid folks "going dark." As always it depends on many factors, so I wouldn't be quick to throw out absolutes.
- Clubber 9y ago
  It was never stated as an absolute. I stated it as "I find that." There are much more efficient uses of communication when direct communication isn't required: - Email - Messaging service - Backlog queue Here's the problem with standups and sprint debriefings, etc. They halt all progress to basically read from a computer screen out loud to people who can read it for themselves. Not only that, depending on the size of the team, most people aren't concerned with what I did yesterday and what I'm going to do today. The only benefit is identification of blockers, and that can be more efficiently done in an email. To me, it's just ritualistic for the sake of ritual.
  - mixmastamyk 9y ago
    > find that they are… No ifs, whens, or buts? That said, you are preaching to the choir here.

maxxxxx 9y ago

Kanban is not that bad. It's essentially a prioritized pipeline of things that need to be done. You can do it without standups.

0xFFFF0000 9y ago
Agreed with mandatory daily standups. Nothing that prevents you from skipping or doing it differently. I always found Kanban to be the more "do whatever works" approach, that might work better for teams that know each other very well.

cstejerean 9y ago

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.
9y ago

mixmastamyk 9y ago

Am not devoted but was tempted to downvote this. They may be a waste of time depending on project/team size, or they may facilitate communication to avoid folks "going dark." As always it depends on many factors, so I wouldn't be quick to throw out absolutes.

Clubber 9y ago
It was never stated as an absolute. I stated it as "I find that." There are much more efficient uses of communication when direct communication isn't required: - Email - Messaging service - Backlog queue Here's the problem with standups and sprint debriefings, etc. They halt all progress to basically read from a computer screen out loud to people who can read it for themselves. Not only that, depending on the size of the team, most people aren't concerned with what I did yesterday and what I'm going to do today. The only benefit is identification of blockers, and that can be more efficiently done in an email. To me, it's just ritualistic for the sake of ritual.
- mixmastamyk 9y ago
  > find that they are… No ifs, whens, or buts? That said, you are preaching to the choir here.