3 ms·

Agile principles, in an academic sense, are great. However, for agile to work best, it's my belief that the team needs to be of a similar skill level, trust eac

Agile principles, in an academic sense, are great. However, for agile to work best, it's my belief that the team needs to be of a similar skill level, trust each other implicitly, and have the same value system (i.e., "we believe in writing software for the long-term", "we believe in being disciplined", etc.) Too often this is not the case. Many things are good in theory but once applied to real human systems, fail.

natec425 11y ago
I disagree with one of your three conditions; I don't think all team members need to be of similar skill. Particularly, I think agile practices can be very good for knowledge sharing between senior and junior developers. As for trust and values, I might combine the two and say that members have to trust in each others values. For example, I don't want to bother to get my code reviewed by someone who doesn't care about its quality, and I don't want to put in the effort to review someone's code if they are only having it reviewed to satisfy the process. These differences in values can really suck the energy out of the process.
squeaky-clean 11y ago
I tried out Scrum at my company on a small team that matches these conditions, and it was incredible. I think the biggest points are the same value system, we all had the same standards for quality, and we were excited to try a new way of managing ourselves that we were open to adapting and being flexible about. And the trust to allow that to happen, and criticize the process without feeling like we were criticizing each other. The Sprint Review sections were most beneficial, because we were all quick to say what we felt needed changing, and everyone was excited to try. If we did something radical, we could call a 1-week sprint instead, or plan the sprint that we could easily adjust it and start a new one if that method didn't work, just in case the new method ended up sucking. The first month of it was weird, and eventually a few months in we were an extremely well-oiled machine running a system that was nothing like the original Scrum plan we followed, because we learned which parts worked best for us, and which didn't, and experimented with adding a few methods of our own to the system. The rest of the company moved onto Agile/Scrum after seeing our small team, but I don't think the majority of them are handling it well at all. The process isn't adaptable, if devs speak up about things they don't like, the managers tell them to "trust the process" and give it time (BUT THE PROCESS IS ALL ABOUT CHANGING THE PROCESS AND NOT BLINDLY TRUSTING THE ORIGINAL PROCESS!!!), and many of them would rather not work in a management system that should adapt like that. I'll get asked for advice on why their daily standups aren't working, give feedback, "Well that would involve changing things, and we'd rather not do that..." Really, they're just doing waterfall but with daily standups and a bi-weekly planning session which is mostly meaningless. Whatever, at least the team I'm on now is willing to play it the dynamic way (myself and another member of that original scrum team are in it), and we're enjoying it very much.

natec425 11y ago

I disagree with one of your three conditions; I don't think all team members need to be of similar skill. Particularly, I think agile practices can be very good for knowledge sharing between senior and junior developers. As for trust and values, I might combine the two and say that members have to trust in each others values. For example, I don't want to bother to get my code reviewed by someone who doesn't care about its quality, and I don't want to put in the effort to review someone's code if they are only having it reviewed to satisfy the process. These differences in values can really suck the energy out of the process.

squeaky-clean 11y ago

I tried out Scrum at my company on a small team that matches these conditions, and it was incredible. I think the biggest points are the same value system, we all had the same standards for quality, and we were excited to try a new way of managing ourselves that we were open to adapting and being flexible about. And the trust to allow that to happen, and criticize the process without feeling like we were criticizing each other. The Sprint Review sections were most beneficial, because we were all quick to say what we felt needed changing, and everyone was excited to try. If we did something radical, we could call a 1-week sprint instead, or plan the sprint that we could easily adjust it and start a new one if that method didn't work, just in case the new method ended up sucking. The first month of it was weird, and eventually a few months in we were an extremely well-oiled machine running a system that was nothing like the original Scrum plan we followed, because we learned which parts worked best for us, and which didn't, and experimented with adding a few methods of our own to the system. The rest of the company moved onto Agile/Scrum after seeing our small team, but I don't think the majority of them are handling it well at all. The process isn't adaptable, if devs speak up about things they don't like, the managers tell them to "trust the process" and give it time (BUT THE PROCESS IS ALL ABOUT CHANGING THE PROCESS AND NOT BLINDLY TRUSTING THE ORIGINAL PROCESS!!!), and many of them would rather not work in a management system that should adapt like that. I'll get asked for advice on why their daily standups aren't working, give feedback, "Well that would involve changing things, and we'd rather not do that..." Really, they're just doing waterfall but with daily standups and a bi-weekly planning session which is mostly meaningless. Whatever, at least the team I'm on now is willing to play it the dynamic way (myself and another member of that original scrum team are in it), and we're enjoying it very much.