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 12345»»»

Accidently Agile Expand / Collapse
Author
Message
Posted Thursday, February 14, 2008 12:17 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:02 PM
Points: 2,892, Visits: 1,785
Comments posted to this topic are about the item Accidently Agile

LinkedIn Profile
Newbie on www.simple-talk.com
Post #455538
Posted Thursday, February 14, 2008 6:05 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, February 12, 2013 9:16 AM
Points: 23, Visits: 186
Thank you for this valuable insight, and for validation of what I've been preaching to project participants from all walks of life for a few years now...
-Often, the first step should be nothing more than a piece of paper and a flowchart ruler. Drawing up some symbolized objects and entities, with joins, and using this for discussion is far less expensive than starting a Cartesian project of misdirected development efforts and database design. Minutes as opposed to hours are expended, and consensus is achieved at each step of the iterative process, leaving an audit trail of who agreed to what, and when.
Post #455649
Posted Thursday, February 14, 2008 6:35 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
I've had both good and bad Agile experiences as a DBA.

In one case, "we're an agile shop" was used mainly as an excuse to avoid planning and documentation. Lots of half-finished software that was of some use, but that was hated by every user.

Another case was a mix of up-front planning on what the end result's functionality needed to be, and then more or less documented iterations up to that point.

All to often, I've run into the idea amongst "Agile developers" that properly planning the database was somehow counterproductive, and then they end up with a database that routinely has locking conflicts, has all the performance of a glacier and what I like to call "database epilepsy". Tables are slapped together with "we'll fix it later" attitudes, and you have dirty data all over the place because part of "fixing it later" is leaving off foreign keys, column constraints, unique indexes, etc.

On the other hand, I've heard (though not experienced) stories of databases so over-planned and over-normalized that no human can possibly manage them, where adding a new function, or changing the definition of an entity in some minor way, takes months of coordination and effort, if it can be accomplished at all.

As with all things, I think Agile methodology should be taken in moderation, and treated with a due amount of logic and review.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #455658
Posted Thursday, February 14, 2008 7:07 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 5:53 AM
Points: 15,560, Visits: 27,934
Nice article. You do a good job of outlining the issues that come up on the database side of things when doing Agile development.

The one thing I'd add is that we support the Agile methodology, but we also come around behind (underneath, whatever) the Agile process and do regular database only performance and stress testing, independent of the iteration cycles. Because of this we know that the designs that we're constantly tweaking and adjusting are remaining a viable design.

I absolutely agree with your final point.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #455676
Posted Thursday, February 14, 2008 7:47 AM


SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Thursday, July 10, 2014 1:33 PM
Points: 457, Visits: 476
Great article! I was particularly impressed with your "garage-building" analogy. Although it has some merit, I have always been strongly (not totally) anti-KISS (Keep It Simple Stupid) or its latest incarnation of YagNi. Your analogy really points out the pitfalls of this approach. Of course there is the other side of the argument that having to totally rewrite a complex application to add some minor functionality which was not envisioned in designing the foundation, is what keeps us employed and making the "big bucks".

Ron K.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler
Post #455702
Posted Thursday, February 14, 2008 8:22 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 6:54 AM
Points: 1,556, Visits: 1,849
Agreed! I, too, really liked the garage-building analogy - I'll have to save that for future use. I also liked your comments about keeping the lines of communication short (ie. direct) between the end-users and the developers. My boss instructs me NOT to attend meetings with the end-users (my boss will tell me what to do, and he leans towards giving them the bare minimum). I find this frustrating, because I want to hear the vision (hmm, mixed metaphor) of where the client wants to go, so I CAN plan ahead.

Thanks, David, for a very useful article.
Post #455729
Posted Thursday, February 14, 2008 9:03 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, July 16, 2014 3:01 PM
Points: 3,843, Visits: 3,836
Great read David. Your article offers me some comfort for a huge project that I have just been allocated to. Your garage building analogy hits the nail on the head. From a DBA perspective, we have to have the big picture in mind as the iterations are being worked.

Up until now, I've worked with a more traditional software development methodology where detailed specifications are first written, reviewed, and then finally worked. This new project is using the agile approach and they have very little documentation on requirements or specifications. It's a bit scary for me as I like to plan a bit more. Luckily, I was able to sit with one of the main product guys and get the big picture before we start with the iterations.

Just curious, but what level of control do you give the DBA in your agile process? They are talking about having the Lead developers do the initial data modeling until they have a 'stable', working product and then passing ownership over to the DBAs. Have you experienced this type of approach before? How has your group gone about communicating the data model requirements back to your DBA team?




John Rowan

======================================================
======================================================
Forum Etiquette: How to post data/code on a forum to get the best help - by Jeff Moden
Post #455782
Posted Thursday, February 14, 2008 9:14 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, July 17, 2014 7:55 AM
Points: 2,805, Visits: 3,067
Great article.
I had used a lot of other development tools - waterfall method, iterative method, extreme programming (it sucked), CMM (capability mature model). So Agile is another one. All these methods are good in theory. I had not seen one worked as well as it supposed to be.
The management team forgot one thing - the people. Not all everyone agreed to this kind of development method, some dragged their way to do it, some totally ignored it.

As you said in the article it requires a good team including customers and good communication to make this tool successful.

I want to ask a question, does anyone work in a company that has a good development team (including project managers and developers) that works on the same goal, has a good relationship with customers and has good communication between the team themselves and other departments?

I haven't found one yet, maybe just me!! If you do, let me know the company name, I am sending out my resume to that company immediately !:)
Post #455792
Posted Thursday, February 14, 2008 9:47 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 8:41 PM
Points: 7,122, Visits: 15,028
David -

Great Stuff! Nice primer on Agile. You touched the highs AND lows of the approach.

Your final points are critical, and just became ten times more relevant with the Visual Studio 2008 launch, and its LINQ integration. You'd best learn to get along and have an open channel between the dev's and the DBA's - or you'll end up with dev's writing a bunch of dynamic and Linq code just to "get around" the pesky DBA who's trying to keep a handle on performance. The DBA will then retaliate with dropping the service account servicing said application out of the database... and then a 2000-year long nuclear winter sets in, after the large meltdown that happens with both teams in the CIO office, etc....

It's really important to remember that Agile is great, but it does have an end-goal or destination in mind. Like you - I'd have to say that the overal data structure still needs to be fleshed out from the start, and reviewed/adjusted during each iteration if need be.


----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #455818
Posted Thursday, February 14, 2008 10:02 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Yesterday @ 2:35 PM
Points: 6,779, Visits: 1,868
David, Im surprised you're so late joining the agile movement! But pleased nonetheless!

I'm a huge fan of Scrum. XP is interesting, but is seriously rigid. By comparison Scrum is a very analog approach that can be sized to fit your situation. For example, they suggest 30 days sprints and I've had success shortening them to as little as 30 days.

I agree that its counter intuitive not to plan for the future, but your analogy is flawed in my opinion. Software isnt the same as house building, the cost to refactor can be (not always) substantially cheaper than having to tear down a room to upgrade the foundation. In practice experience should play a role in what you decide to deliver, but I've learned to err on the side of leaving something out rather than risk putting one more thing in that I might not need. Too many projects fail because of sheer scope, take out all the extras and build something, then iterate.

I've seen a lot of people dismiss agile as the 'flavor of the month' and I think they are missing out. Like any tool/process it can be used badly, but used well it maps nicely to how the real world works. Most of us need to see the software to figure out it works the way we need it to, we need to use it to learn what would make it better, and we all need to get in the same room to talk about it.


Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #455836
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse