|
-
Oct 22nd, 2014, 01:23 PM
#20
Re: Pairing up developers for enhanced learning and better productivity
 Originally Posted by NeedSomeAnswers
Methodologies like SCRUM are actually well defined, that link i posted probably wasn't the best to give you a clear definition though.
To be fair, the link wasn't really about SCRUM.
It is also worth saying these kind of methodologies are not for individuals or small development teams and if you work in one of these environments then Agile can look very strange to you.
This is a good point, in my case, as I work with other developers only to the extent that I say hello to them in the halls. We barely even know what each other is working on, so we are very much individual. I have long realized that all of Agile makes no sense to us with our teams of 1 (not even that in some cases), but I'm still interested in it as a way to move projects along. I guess I have the hope that some day the organization will see a project as sufficiently valuable that it deserves more than one person on it. That day hasn't come, yet, but it might, so I think about it.
If you work in a Software house where you sell software to business customers then Agile can do a great job making you more reactive to your customers, and if done well can definitely improve your software delivery and product quality.
That's actually the part of agile that I find appealing. One of the things I have learned with all the projects I have done in this organization over the last 17 years is that we really fall down when it comes to involving the customer (all the apps are internal, but internal customers are customers nonetheless) in the process. Even when we do get feedback from the customer, that's how it is structured: Feedback and JUST feedback. We say, "we're doing this thing for you, and this is how it will work, what do you have to say?" That's not good. So, that customer-centric focus of agile is appealing to me. However.
Having worked in an Agile environment i can assure you that if done properly it can work well.
This is the problem I have. If you decide to use Agile, and everything works out great, then did you do it properly? If you decide to use Agile and the project ends up being a mess, is it because you didn't do Agile properly, or is it just that the people involved....were themselves a mess.
As a case in point, I have been tangentially involved with a project that has been a mess....I mean been in production....for several years now. I don't know the methodology very well, though it appears to consist of replacing the developers every other year, or so. However, I'm VERY familiar with all of the people involved (other than the developers, since they never stick around long enough to bother learning their names, even). On the one side is management, which are all a bunch of researchers who moved up the ladder a bit. These people are all decisive, stong-willed, and highly analytical. Personality testing, like Meyers-Briggs make them out to be analytical types, and they really are. In fact, this particular group is some of the finest examples of that personality type.
On the other side is a group of people who are even more strongly selected to be relationship oriented. They run semi-autonomous fiefdoms where they have to keep a small team of people motivated at work that is often tedious and occasionally very strenuous (though almost never dangerous except to hands and teeth). Those are the toughest conditions to keep people motivated at, and these people have few tools to work with other than their own personalities. Therefore, they are selected for their ability to achieve goals with disparate people by understanding those people and avoiding the types of conflicts that cause breaks. They won't succeed through force, but are great at persuasion.
Put together, these two groups are oil and water. The one group is forceful and decisive, but not knowledgeable, so they look to the other group for the knowledge, but the other group isn't about to correct the mistakes of the first group, so the mistakes of the first group end up being ratified until the fact that they really are mistakes has caused all the mischief possible.
As a team, the two groups are a disaster, and the project is a limping scrod as a result. Saying that they did, or didn't implement Agile all that well seems like little more than a convenient scapegoat from a deeper realization that these two groups simply don't make a good working team, no matter what the methodology.
My usual boring signature: Nothing
 
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|