The framing of the article is perfect. This kind of information on SCRUM is not easily available.
In my project, we follow the SCRUM method and follow the above said approach, but out team is like 12 people at the SCRUM Meeting.

I would suggest a few tweaks to this very good article... Some details provided are not prescribed in Scrum, but are what some teams choose to implement.

For example, the length of a Sprint is not always 30 days - each team defines how long their Sprints will be, the most common lengths being 1 week, 2 weeks, and 1 month. For the purposes of this article, the specific length is unimportant as long as you realize that it is a fairly brief "timeboxed" development period.

I agree that the number of people on the Scrum team should be carefully considered, but I have heard it should be no larger than 10 to 12 before you consider splitting it into multiple, smaller teams.

Overall, this article does a very good job giving a quick overview of Scrum. Thanks for posting it!

Hi:

It was written: no new features can be added to the sprint once it is kicked off, and team members cannot be pulled off to work on other side project in the middle of a sprint.

Zarfman writes: If the president of a company gets a call from his biggest customer who demands that some problem be fixed right now or he can kiss him goodbye. Guess what, if that team member is needed to solve the customer’s problem he/she is going to get pulled.

It was written: unlike traditional software development methods, in Scrum there is little separation of duties between team members. Each team member may fill the role of analyst, designer, coder, tester, and documentation writer.

Zarfman writes: This I do not understand. I seriously doubt that a coder/programmer can do the work of a skilled DBA. A skilled DBA knows the internal working of his DBMS. I suspect that a coder would not have that depth of knowledge. I doubt that an analyst et al is going to have the knowledge to implement FASB 157 without some outside expertise.

Regards,

Zarfman

It's zarfman again.

I was talking to a business associate of mine (a very talented DBA ) about the scrum idea that unlike traditional software development methods, in Scrum there is little separation of duties between team members. Each team member may fill the role of analyst, designer, coder, tester, and documentation writer.

He laughed and said thank God for Scrum. He said the it allowed him to live in a $500,000 house because he made a lot of money cleaning up the crap that coders/programmers produced who thought they knew how to design and set up a database.

Regards,

Zarfman

Zarfman,

Hello, skeptic. :) It's obvious you don't like Scrum. That's fine.

I don't know if your intent was to help people better understand the Scrum methodology to prepare for an interview...but I'll take the opportunity to respond because these items may help someone in that situation.

Re: making changes mid-Sprint. Let's take an example of a 2 week sprint (perhaps the most common Sprint length). If a change is needed within the 2 week window:
1) Compare this to other methods like waterfall. How long would the customer have to wait in these scenarios? 2 weeks is comparatively VERY short.
2) The Agile approach actually makes these types of decisions much clearer. This is a capacity-based model where the customer is "paying" for a certain number of people to work a certain amount of time. Every 2 weeks, they together decide what business value they aim to deliver for the "cost" of the 2 weeks.
Thus, we can easily grasp the impact of interrupting the 2 week sprint - we know what was committed to that won't be done and it's much easier than the waterfall methodology to understand because the impact is sooner and the scope of what was being worked on at the time was smaller.

Regarding "little separation of duties between team members," I agree that this one is hard or unwise to fully implement in many scenarios. After 1 1/2 years on a Scrum team, I have come to view it this way:
- This is directional (aim in this direction), not destination-al (here is the absolute goal you must achieve)
- There is a beauty and strength in letting each team member bring all of their capabilities to the table. On my team, there is one developer in particular who asks some really great analytical questions...the kinds of thing a BA would normally ask. There are also times I bring up some technical design ideas that a developer would normally propose even though I usually wear the BA & QA hats. This is very healthy for the team and enables all of us to contribute to a great solution.
- Perhaps the most important concept hidden in this view is that we are focuses on trying to optimize the WHOLE process (reference Agile Manifesto: "We value working software...") rather than our own individual sub-processes. As a BA on a waterfall project, I might normally just be concerned with delivering the best requirements doc I can (my sub-process), even if the software ultimately delivered may not work right (overall process)...not my problem, not in my scope of control or influence. In Agile, the whole team owns the whole thing. That's not to say that I don't write nearly all the requirements, but it ensures my mindset is on delivering value to the customer in working software.

Hi:

Zarfman writes: I do have my own set of biases.

It was written: making changes mid-Sprint

Zarfman writes: I’m not sure if sprints are run in series or parallel or both. My point is the changes or work stoppages/required by upper management in one sprint may have an adverse effect on previous or perhaps subsequent sprints.

It was written: This is a capacity-based model where the customer is "paying" for a certain number of people to work a certain amount of time.

Zarfman writes: To me it would make a difference on whether the customer was internal or external. If the customer is external, paying involves invoices, accounts receivable and checks. If the customer is internal, the scrum group is simply a cost center or perhaps some form of internal cost transfer takes place.

It was written: Every 2 weeks, they together decide what business value they aim to deliver for the "cost" of the 2 weeks.

Zarfman writes: How is business value measured? Costs are usually measured in dollars.

It was written: This is directional (aim in this direction)

Zarfman writes: I’m not sure what this phrase means. To me aiming usually involves a target.

Zarfman writes: The reason that I mentioned FASB 157 in one of my posts is that FASB 157 is an intensely technical accounting problem. Unless, a BA or some scrum member is well schooled in accounting for fair value and cost within financial statements, it is doubtful they can make any significant contribution. In fact many companies do not have the internal expertise and rely on an outside accounting firm or their auditors.

It was written: Perhaps the most important concept hidden in this view is that we are focuses on trying to optimize the WHOLE process (reference Agile Manifesto: "We value working software...") rather than our own individual sub-processes.

Zarfman writes: What optimization technique and/or optimization software would Scrum or Agile use? Optimization typically involves working in N dimensional space. Not for the faint of heart or mathematically disinclined. Valuing working software is not the same as optimization.

Regards,

Zarfman

It is written: "There is a beauty and strength ...." Oh please!

I think a Rugby match might not be the best model for software development.

What's left at the end of a Rugby match? A winning team (and a losing team) and likely many minor (some major) injuries.

Hopefully, something more tangible is left at the end of a software development sprint.

I recently worked on an "Agile" project where we did a really good job of moving sticky notes (footballs?) and a really poor job of addressing the user's needs.

Maybe a better model would be something like an Amish barn raising...

also scrum works best when all the team members are based out of the same location.
i've worked in global teams where scrum model is adopted and the daily scrum meetings last 30-45 mins at least. In such scenarios scrum really is an overkill.