methodologies

[Jonathan]

http://en.wikipedia.org/wiki/Scrum_(development)

I know some of you study this stuff, and others use it. What are crap methodologies? Any good ones?

[quantus]

Most of them work since they're pretty similar when you sit down and compare them. Besides, none of these methodologies are replicated exactly from organization to organization because people tend to pick and chose what they want to use. The keys are summed up by the Agile Manifesto. Basically, you have to communicate a lot in order to generate working software quickly especially since your target will change over time (maybe even from iteration/sprint to iteration/sprint) and you don't have time for generating documentation that is not strongly linked to the development process. Scrum has the brief daily meeting, which you hit highlights (good or bad) of your progress since yesterday and what you plan to do today. Everyone knows what you're gonna do, and if what they does affects what you're working on, they can come see you. Many of these agile methods don't work well with people who can't collaborate well, which most organization accept as the norm. That's why departments that set up rigorous hand-off requirements and don't talk to anyone else exist.

Anyways, I've had experience with working in an XP team my first semester and it went well even though we weren't collocated, which is often a requirement of agile methods. It really depends how well you can get your team to gel, because communication will break down and potentially implode your project if your team doesn't gel.

[Jason]

We're currently proposing SCRUM on all the development projects we're trying to do right now. As of right now, I know of only one that is actively using it and it's a fairly small team. What's really interesting is trying to map this to an enterprise size system. One of our larger proposals is being done that way, but I can't say how because of proprietary/competition-sensitive reasons.

Another developer on our side compiled a list of best practices. I'll see if I can track it down.

[Jonathan]

We're currently proposing SCRUM on all the development projects we're trying to do right now. As of right now, I know of only one that is actively using it and it's a fairly small team. What's really interesting is trying to map this to an enterprise size system. One of our larger proposals is being done that way, but I can't say how because of proprietary/competition-sensitive reasons.

Can you say if you are happy about it?

[quantus]

Usually, larger projects are managed as a SCRUM of SCRUMS as I think wikipedia mentioned... It's just that the integration of pieces can be more difficult or you just assign that difficult piece to one of the two teams that made it. If you're organization is particularly good at forming and reforming teams well, then you might even just make sure the integration step is done after you switch teams around and just make sure that people involved in the pieces end up on that team.

A main idea of these agile methods is that people have a lot of the information in their heads rather than written in documentation that gets out of date. You have to invest in your people to make this work. If you drive your people unreasonably hard, they'll find somewhere else to work and take some crucial information with them. Of course, you should be doing some things in pairs so that the information is not quite so compartmentalized...

I personally think that switching teams around after a set number of sprints is good for everyone involved since if you're not in a good team, you're not locked into that group and will probably get a chance to be on a better team. It just keeps things interesting because they're not the same for months/years on end and it helps spread best practices across your organization. From a business standpoint, it breaks down hierarchy, which leaves your company more flexible for changing business needs.

[Jonathan]

The place where I see this falling down is the sprint, because all the architects have to support multiple projects. Sightings trickle in from customers from old projects. Debug occurs on the project in the lab. We've got three other projects which are various numbers of months from tapeout. The same architects are responsible for all five chips. Yes, 99% of the software effort and maybe 75% of the total effort is on that one project that's 60 months out, but the other projects are priority interrupts.

All the important stuff is in people's heads anyway, so that's not an issue.

[Jonathan]

I'll let you know after tomorrow.

[Jason]

I have issues with all of these points ...

Usually, larger projects are managed as a SCRUM of SCRUMS as I think wikipedia mentioned... It's just that the integration of pieces can be more difficult or you just assign that difficult piece to one of the two teams that made it. If you're organization is particularly good at forming and reforming teams well, then you might even just make sure the integration step is done after you switch teams around and just make sure that people involved in the pieces end up on that team.

Whoever wrote that obviously hasn't tried it on a larger project. I don't think anyone has tried it on a larger project. (If you know of one, please let me know). For a truly enterprise size system, the amount of intercommunication for a SCRUM of SCRUMs would be huge. You have to break things down a bit. Let's just say that in order to do reasonable management, you have to do something similar but rather than using the same methodology you need to slip-stream another methodology on top of the SCRUMs.

A main idea of these agile methods is that people have a lot of the information in their heads rather than written in documentation that gets out of date. You have to invest in your people to make this work. If you drive your people unreasonably hard, they'll find somewhere else to work and take some crucial information with them. Of course, you should be doing some things in pairs so that the information is not quite so compartmentalized...

Technically SCRUM was supposed to be better than other agile methodologies since you have to create documentation for what you develop during each sprint. So in "theory" all information is written down and kept more up-to-date since sprints are shorter than typical development cycles. Supposedly even a high turnover environment should work. Now, I've never seen this in practice, but you can't blame the methodology for a flaw in implementation.

I personally think that switching teams around after a set number of sprints is good for everyone involved since if you're not in a good team, you're not locked into that group and will probably get a chance to be on a better team. It just keeps things interesting because they're not the same for months/years on end and it helps spread best practices across your organization. From a business standpoint, it breaks down hierarchy, which leaves your company more flexible for changing business needs.

This sounds good in theory, but I doubt it's possible in many environments. Most of the resumes/people we go through are highly specialized in one thing (i.e. UI devs, DB guys, middle-ware, web applications, etc.). Literally every team we can usually put together is a minimum coverage of the required skills. Very few people are interested or inclined to break out of their sweet spot, so it's not easy to transfer them between teams.

[Jason]

The place where I see this falling down is the sprint, because all the architects have to support multiple projects. Sightings trickle in from customers from old projects. Debug occurs on the project in the lab. We've got three other projects which are various numbers of months from tapeout. The same architects are responsible for all five chips. Yes, 99% of the software effort and maybe 75% of the total effort is on that one project that's 60 months out, but the other projects are priority interrupts.

All the important stuff is in people's heads anyway, so that's not an issue.

If you figure out 'good' cycles for sprints and allowed for full team interrupts it might work. On one project we have week-long sprints. On another we said we would do six-week sprints. The true magic in SCRUM is coming up with the right partioning of the storypoints. If you have a good SCRUM master you should be ok. If you don't, I wouldn't try it.

[Jonathan]

I foresee a bit of scrumming in my future.

[quantus]

If your team just does the daily meeting, that's a huge step forward in group communication. I tried mentioning it to my manager, but it never went anywhere, so we still communicate very little with a bunch of, "didn't I tell you?" or "didn't you know?" and I have no interest in trying to fix it anymore.

[Jonathan]

They're talking two week sprints to start, with longer sprints as an option for later. Personally I think longer sprint are a requirement due to the time to get results back after a change in the simulator.