Phillip: Are Agile Development and Extreme Programming the same thing?
Extreme Programming and SCRUM are two Agile methodologies.
Eric: Does the emphasis on short term (30 day) results lead to problems because there is limited time for planning the overall project such as the database design and documenting the system?
No because you are working on the system in very small pieces. Basically, you do as much as you can in the 30 days; if problems result in delays then features get pushed to a later iteration. The key thing here is that the features are prioritized by the customer so you are always working on the most important thing to them at any given time and only less important things get delayed.
My Question: I may be missing something since I don't know much about SCRUM. I have read several Extreme Programming (XP) books and in XP the technical staff estimates all the features to help the customer decide on the priority. Priorities can change depending on cost. Is there something like this in SCRUM?
"The customer lists all the features they want in priority order."
And how often can your customers tell you exactly what they want, let alone as a prioritized list?
If you are lucky enough to get a feature list, and it doesn't change half-way through, everything will be top priority. If you make the decision for them, you can bet you'll make the wrong one - whatever you choose to treat as low-priority will be the one thing they really, really needed yesterday.
...and to follow up on "Newbie"s comments...of which s/he is 100% right...
If you ask the user, they well do a "brain dump" of everything that they ever thought of that would be "neat!" THEN, after the list is made you will find that a high percentage of this "nice to have's" will slowly become MANDATORY requirements. This will happen quite rapidly if there is a group of customers that are "contributing" requirements since one persons "neat feature" suddenly triggers a thought from another customer, etc.
As to making the decision for the user: This has been the cause of the adversarial relationship which exists between many customers and IT. On the one hand the customer thinks that he recognizes his problem (which might be a symtom instead) and he is frustrated by it BUT he really doesn't appreciate an "outsider" telling him what his problem is. AND, if the proposed IT solution is wrong you can be assured that the customer will "wipe his hands" of any connection with the consequences!
Solution: The customer MUST accept ownership of the solution (and the problem) and become a member of the team, or at least an active "spectator." If any customer says, "Just let me know when it's done," this should be your clue that you can assume that there will be LOTS of problems ahead of you.
The whole point to agile development is that we know that requirements are going to change midstream (probably many times). That's fine because the customer can change the priority of the items at any time.
One thing that isn't mentioned (there isn't room to discuss SCRUM or XP or any other methodology in less than several books) is that you often have someone between the customer and the technical people for translation purposes. This person, we'll call it the business analyst role, would have some knowledge of the problem domain along with some technical knowledge. The analyst can do some basic modeling of the processes in a form that both the techs and the customer can understand (use cases, process flow diagrams, etc.).
Techs often consider the customer to be stupid because the customer doesn't understand the technology and vise versa. Agile methods provide a situation where business people make the business decisions and technical people make technical decisions; i.e. everyone does what they are good at and not what they are bad at.
richardd wrote: If you are lucky enough to get a feature list, and it doesn't change half-way through, everything will be top priority. If you make the decision for them, you can bet you'll make the wrong one - whatever you choose to treat as low-priority will be the one thing they really, really needed yesterday.
We're in that boat. We have re-designed and re-wrote an existing product. We knew that the new app would need to do most everything that the old app did, so everything did have a top priority. We still needed to break those down into deliverable units so that we could get the pieces in front of the customer for sanity checks.
...and (of course) we heard statements like
Our managers honestly believed that was the correct strategy, but the development team focused on deliverable units, and prioritized the features based on our experience with the customers.
Our company's founder (who is no longer on this earth) used to say "Just get most of it done, and we'll sweep up the sh**later." I've used that strategy with much success when porting new systems, because it allows us to remove features that some previous developer thought were "so important" and that no one uses!
SCRUM rocks because it balances procedure with common sense. It provides a framework to make decisions and take action, but it does neither of those things for you; SCRUM does not replace effective people.
Thanks for writing that article! Good stuff.--Scott Fletcher--Propeller Head
