Agile Development with Scrum

  • Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/bknight/agiledevelopmentwithscrum.asp

  • I've recently moved in to a new position which uses agile programming.

    It is a Windows development written in C#. Before joining the team I had little experiance of C#. (my background was COM programming with VB and Web Development with Javascript/ASP).

    What I like about this development methodology is that as an inexperianced C# Developer I am able to pick the easier tasks, which allow me to improve my C# knowledge, whilst still contributing to the Sprint. As time goes on I can pick the more difficult tasks which continue to improve my C# knowledge and become a more productive member of the team.

    I've only been working in this are for 4 months but my knowledge of C#, SQL Sever 2000, XML and Web Services has increased immeasurably, in part I believe down to the Agile Development methodology.

    I have a question though. Are Agile Development and Extreme Programming the same thing ?

  • "It adds an element of peer-pressure to hopefully make a person feel they have to move a sticky note every few days."

    Personally, I would remove that sentence: it smells very un-Agile. The sticky gets moved when the work is done, period. Peer-pressure isn't going to make a professional developer work any harder (nor will not-so-subtle hints from management). Being patronized may, however, annoy the developer enough to slow him down. Just my opinion.

  • 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?

  • 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?

    [font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
    Business Intelligence Administrator
    MSBI Administration Blog

  • "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.

    [font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
    Business Intelligence Administrator
    MSBI Administration Blog

  • 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

    • "Your requirements are already done - Just make it like the old app."
    • "It's not done until it does everything that the old app does."

    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

  • Where does QA fit into this schedule?

    Also, here's a book I've had on my Amazon wishlist for quite a while, on Agile Database Techniques... Looks interesting:

    http://www.amazon.com/exec/obidos/tg/detail/-/0471202835/ref=ase_ambysoftinc/104-8467509-7877506?v=glance&s=books

    --
    Adam Machanic
    whoisactive

  • Thanks for all the comments. Extreme is just another variant of Agile. A great website that shows all the variants is http://www.xp123.com.

  • You are correct in an ideal world. Professionals always step up to the plate. That word is a big assumption and when you may culture shifts like this, you may use something like this to weed out the non-professionals and expose their lack of productivity. Some come around and some frankly will find another gig where they can coast. It should never be explicit peer pressure but peer pressure should remain all the same. Everyone knows that if they screw up their task, then they let their small team down. In Scrum, it's not a faceless team of 30 but instead an intimate team of 5-10.

  • THere's two ways of looking at that. You can do a 30 day cycle to get it to QA and then the prod deployment happens whenever they're ready. Another is to make the cycle 3 weeks long and the last week goes to QA. I've done both myself. In the later method, I send weekly builds to QA so they can start testing.

  • I would think the former would cause problems as QA found bugs -- the developers would be in another cycle and would therefore not have time to fix the bugs from the previous cycle...

    --
    Adam Machanic
    whoisactive

  • I agree. That's why 4 of the 5 projects we have run on the second type of cycle. Luckily with a 30 day iteration the features shouldn't be more than a weeks worth of regression and weekly build tests couldn't kick the tires on.

Viewing 15 posts - 1 through 15 (of 18 total)

You must be logged in to reply to this topic. Login to reply