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 10:05 AM


SSC-Addicted

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

Group: General Forum Members
Last Login: Monday, March 17, 2014 2:19 PM
Points: 457, Visits: 470
Loner (2/14/2008)
. . .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 !:)


You maybe surprised and I know I will get a lot of flak on this, but in my 30-years experience the best overall development relationships I've seen was in the military (especially USAF). NASA also has a good handle on a team approach but that is because they have rewritten the DOD regs to meet their specific needs. But, possibly a good reason that government offices seem to have a better approach is that they are not profit driven and have deep pockets -- Care to enlist?



Ron K.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler
Post #455839
Posted Thursday, February 14, 2008 11:17 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, September 08, 2008 11:33 AM
Points: 332, Visits: 64
Great article. I've been an agile proponent long before the term was invented. As a one-man-gang developer in the user world for a large part of my early career I learned that giving the end users something useful, quickly and then continually evolving it was the most effective approach and the most value for the business... and one's career - you become a god to the users. It lives on in all the users called analysts that build useful (to their group) tools that get the job done. They use things like MS Access and don't necessarily follow standards or document - but they get the job done while the traditional IT world is scratching their butt. Even as a department head I made sure I had my "guy" that could make things happen quickly.

The trick for IT is to do the same thing on larger, team-sized projects with supportable tools, standards, etc. If you need an incentive to get on board, consider that agile done effectively is an almost ironclad defense against outsourcing or offshoring.


Regards,

Greg Young
Post #455886
Posted Thursday, February 14, 2008 12:24 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, February 09, 2009 12:56 PM
Points: 9, Visits: 30
Saw this article's title on a news feed and I thought there might finally be some enlightened discussion on databases and agile development on SSC.

Instead I found :
- A DBA (who believes his databases are the "foundation" of all good projects) justifying how some cool, new agile buzzwords apply to him also.
(Thus, he is cool also. Many other DBA's also agreed with him, so they must be cool too!)
- Previous buzzwords and good practices dug up and equated to agile development buzzwords.
- Crazy analogy regarding "Christmas dinner of the nymphomaniacs anonymous society!".
- Opinion on the Iraq war as if HE knew the all requirements up-front. (Maybe a well thought out database schema would have helped our war effort.)
- Final thoughts that have nothing to do with agile development.
- Business as usual - keep making CRUD, but "prioritize" your CRUD.

Please read Scott Ambler's book for yourself, don't take Mr. Poole's assessment as the whole agile story. Some of the concepts in his book might push you out of your comfort zone. That is where the growth is.

If you dig a little deeper into agile development you may find that often the early parts of a project don't require a relational database at all. (Don't throw things at me!) It may just slow the development cycle down. But contributing your "data" expertise in other ways might be helpful in making a transition later - IF THE REQUIREMENTS SURFACE! If they never do, you will still have contributed something important to the project.

Post #455930
Posted Thursday, February 14, 2008 12:50 PM
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, October 23, 2013 12:46 PM
Points: 3,843, Visits: 3,833
Steve,

That is why David wrote the article; so we can have a professional debate on the topic. I for one don't know much about it but I'm being thrown into the hornets nest so to speak. I would like to know both the pros and cons of the agile approach. My gut feeling tells me to put up my dukes and get ready for a fight, but my experience with the agile approach to this point has been zero so I have no idea what to expect. My initial impression with the project that I am working on is that the developers and leads want to bypass certain database design planning and documentation phases that I deem critical to the design of a efficient and scalable database model.

Your response started to go into some of the pitfalls of the agile approach. Do you care to elaborate? Like I said, this is meant to be a professional discussion so let's get to discussing so others (well, me really :)) can benefit. Having both the pros and cons in mind will greatly help me in knowing what to watch out for. Any input?




John Rowan

======================================================
======================================================
Forum Etiquette: How to post data/code on a forum to get the best help - by Jeff Moden
Post #455948
Posted Thursday, February 14, 2008 1:20 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 2:12 PM
Points: 7,084, Visits: 14,685
Steve Schmechel (2/14/2008)

If you dig a little deeper into agile development you may find that often the early parts of a project don't require a relational database at all. (Don't throw things at me!) It may just slow the development cycle down. But contributing your "data" expertise in other ways might be helpful in making a transition later - IF THE REQUIREMENTS SURFACE! If they never do, you will still have contributed something important to the project.


While that's certainly true - if it weren't going to involve a relational database, we'd be reading about this on AgileDevelopmentUsingExcelAsDataStoreCentral.com.

It's a shame to come in with all guns blazing, especially when making assumptions about the posters and what they "do for a living". It's also a shame you didn't catch the fact that David is now espousing Agile, albeit it with some reservations. After all - the job of the DBA is to make sure that whatever is being done on the data side is solid, and ultimately doesn't tear the rest of the house down.

Like just about any methodology - Agile can be very powerful if implemented and run correctly. However - like any other methodology - a lot of bad implementations of Agile have also been advanced, often by folks with either faulty understandings of what Agile is about or those who have no care or understanding of some of the roles involved in such a project. Once such implementation is the Extreme Agile programming David mentioned, which more or less advocates the data design as being irrelevant or an after-thought, which then of course makes the job of those with the DBA title or role very difficult, unpopular and frustrating.

The thing to remember about this is the person filling the role of DBA isn't necessarily being an A**hole when they're asking to look a little ahead. It's that (like Scott Ambler himself points out) the further into something like this - the harder/bigger continuous refactoring of the data gets to be. Making the developer's job easier at the expense of sending the data team through a never-ending loop of increasingly hard iterations to remodel/refactor the data is viciating the purpose of Agile to begin with (it's to save work for the TEAM, not help the developers and scr** the data side). I don't know when the last time it was when you tried to change the tire on a moving car - but it does get a little tricky.


----------------------------------------------------------------------------------
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 #455964
Posted Thursday, February 14, 2008 1:30 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Tuesday, June 21, 2011 10:03 AM
Points: 577, Visits: 102
A top notch article as usual, Mr. Poole. Where I work it's all waterfalls....

Signature is NULL
Post #455972
Posted Thursday, February 14, 2008 3:18 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 3:49 PM
Points: 2,866, Visits: 1,708
Thanks as ever for your comments.

Some of the books I've read on the subject do mention that house building is a bad analogy for agile development but I couldn't think of a more suitable one. The whole point of an analogy is to find a common point subject that most people can relate to and to utilise it to aid communication. An ORM layer for communication?

I am currently working on a project on which I have preached the agile gospel. The business people, the PMs, the programmers, the delivery managers and support staff all sat around a table having a face to face discussion and made a rapid choice in favour of a small, light weight project that would be designed to be extendable. There were quite a few points and counter-points made but the face-to-face element really worked.

My role is now as a DBA as I have chosen to be a specialist in a particular area. Regardless of whether I were a DBA or not I would say it would be blindingly obvious that a data driven project is going to require a good database foundation.

If you were talking about a project to harvest information from a web site and store it then I would say that the database layer would be of lesser importance than the harvesting part of the project.

The one thing that the DBA role encourages is not to test the depth of the water with both feet!

The move to agile development is a paradigm shift but having spoken with experience XP protagonists (backed up my own reading) you have to buy into it whole heartedly, you can't really cherry pick bits here and there or the whole deck of cards comes down. My personal opinion is that agile development suits object orientated programming, I believe it originated in the JAVA camp. Even for object orientated programmers I believe some of the techniques came as a shock. i.e. inheritance is bad, association is good. Objects should be open for extension but closed for change etc.

As a final point one XPer pointed out that there are two sorts of itteration. If you see the deliverable as a drawing of a man then one draws an outline of the man on the first itteration and subsequent itterations add more and more detail until you get the finished drawing.
The 2nd approach draws a part of the man in entirety and each subsequent itteration adds a new body part.

If you subscribe to this site then you have almost certainly had to deal with a database that was put in place with the "it doesn't matter now, we'll fix it later" attitude. There are 1001 reasons why it won't be fixed later the least of which are the technical hurdles. I am currently liaising with 3 different triametrically opposed groups of people to get them to agree to do the investigation work to find out what the effects getting rid of a small amount of data that prevents DRI being added would have on their systems.
To the business this is a non-issue as it has zero visiblity. To the DBAs keeping the database functioning is a mind-numbing and time consuming job. Had DRI been put in place in the first place the DBAs could be building the better mousetrap and devoting more time to the developers rather than acting as a bottleneck while they fix legacy problems.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #456029
Posted Thursday, February 14, 2008 3:39 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Tuesday, June 21, 2011 10:03 AM
Points: 577, Visits: 102
Steve Schmechel,

Thanks for logging in just to crap all over the article, that time as not wasted. I'm sure everyone appreciates your snide comments and asinine POV. You remind me of a high schooler still caught up in what is "cool" and what is "not cool", as if that has anything to do with the right ways to develop software.

I've been critical in this forum before, and I've even occasionally been critical of some of the things Poole has said. It's OK, his ego can take it; but for God's sake please keep things constructive!

(To all Forum Members: I know, I know...don't feed the stinkin' trolls)


Signature is NULL
Post #456036
Posted Thursday, February 14, 2008 3:42 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, February 15, 2008 5:11 PM
Points: 1, Visits: 2
A well written article, but this is exactly the type of thinking that has brought Development in America to an all time low and why ultimately businesses continue to seek external resources.

Agile Development is definately a methodology that allows the customer to see more frequent results. From a Business perspective, that may be what your customer wants to see. However, what they want and what they need are often two very different things and this is absolutely an area where a customer's ferver for a 'visual fix' each couple weeks should be managed. The very best project managers try to balance the customer's excitement to see something against the need for quality and attention to detail. For those projects with no real competent technical project management and no layer inbetween the develper and the customer, Agile may be the only way to passify the customers regular need for that 'fix'. However, you are ultimate not serving that customer or yourself and you are exchanging true development quality for short term customer satisfaction during the development process.

For me personally, I believe the Sales and Marketing parts of our industry have encouraged this approach because it makes more sense to them and unfortunately, we'll always have a set of 'experienced' people who buy into the hype and the cool word "Agile".

While I'm certainly no advocate of a long drawn out waterfall model where you do 6 months worth of hardcore development before anyone see's you emerge from a cube, I KNOW a far better result will be achieved for a project that is managed by clear and early identification of MILESTONES at regular short intervals. Those milestones don't necessarily need to be some new screen that a customer can see, but are still identifiable progression points that at the very least, a develper and technical project manager can identify and agree on and measure.

I'll completely agree that great team communications and regular measurement points are fundamental to a project and those aspects of Agile are points well considered for any developer. However, the precepts of Agile involving the complete end-to-end development of one small piece of the project at a time often defeats the goal of having a well thought out system archtecture with the necessary attention to system integration that great products display. You can say that you can overcome this by having a lot of communication, but in practice it doesn't work that way.

For a set of software development tasks that have been repeated by develpers a few hundred times in their career, Agile makes a lot of sense. For the other 98% of the projects that most of us find ourselves doing, the process will ultimately work against a quality result.

Brad Benham
Senior Architect
McKesson Corporation
Post #456039
Posted Thursday, February 14, 2008 3:47 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, February 09, 2009 12:56 PM
Points: 9, Visits: 30
I'm sorry if it appeared I came in "guns blazing". I have read other articles by David Poole and normally I think he is right on the money. This time I think he missed the mark.

The article has more of the flavor of a blog/opinion piece than a call for professional discussion.

Where I work we embed databases in our products. Often, before the user requirements are even fully understood, database developers and code developers (who know enough about databases to be dangerous) are busy discussing the database requirements and schema so they can "begin" their work. So maybe this idea of "As a database guy I tend to look at the database layer as the foundations for software development" rubs me the wrong way.

If your job is to maintain the a big OLTP database of financial data that software developers write against you probably won't have easier alternatives to offer them for the near future, so you will have to figure out how to be agile within those constraints. Maybe that is the audience the author had in mind.

I know this is SQL Server Central (database work is part of my job description and daily activity). However, I read the "Central" as a "central place to get information about SQL Server". (Which it does quite well - probably the best! :) )

For many people, SQL Server is one of many useful tools for solving problems and not "Central" to their identity. Information on how to integrate database development into an agile process is useful to those people also. Put yourself in their shoes and ask what they take away from the article "Accidently Agile". Not much I am afraid.
Post #456040
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse