Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Agile Development with Scrum Expand / Collapse
Author
Message
Posted Thursday, May 12, 2005 10:11 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: Moderators
Last Login: Wednesday, June 4, 2014 12:29 PM
Points: 1,931, Visits: 234
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/bknight/agiledevelopmentwithscrum.asp

Brian Knight
Free SQL Server Training Webinars
Post #182098
Posted Wednesday, May 18, 2005 1:23 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, January 19, 2009 9:37 AM
Points: 186, Visits: 7
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 ?
Post #183227
Posted Wednesday, May 18, 2005 6:00 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, September 23, 2006 5:01 PM
Points: 1, Visits: 1
"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.
Post #183294
Posted Wednesday, May 18, 2005 6:42 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, August 10, 2005 6:36 AM
Points: 10, Visits: 1
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?
Post #183314
Posted Wednesday, May 18, 2005 6:51 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, September 4, 2014 9:46 AM
Points: 295, Visits: 280

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?



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #183315
Posted Wednesday, May 18, 2005 7:07 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, September 11, 2014 5:55 AM
Points: 2,302, Visits: 560

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




Post #183325
Posted Wednesday, May 18, 2005 7:29 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, May 20, 2005 8:04 AM
Points: 1, Visits: 1

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




Post #183336
Posted Wednesday, May 18, 2005 7:34 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, September 4, 2014 9:46 AM
Points: 295, Visits: 280

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.



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #183339
Posted Wednesday, May 18, 2005 7:39 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, May 19, 2005 3:09 PM
Points: 3, Visits: 1

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




Post #183341
Posted Wednesday, May 18, 2005 11:36 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 6:46 PM
Points: 1,113, Visits: 704
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
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Post #183451
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse