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 Friday, September 18, 2009 3:47 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, October 5, 2010 10:36 AM
Points: 2, Visits: 11
Sorry for top posting, but this was long. But wow, you make it sound like non if this could have been done unless someone 'invented' Agile. Shorten iterations and take customer input, what a concept. Another example of PMS Programming
PMS Programming



Stephanie J Brown (9/18/2009)
Nice article on the impact Agile can have on DBA's, David.

Full disclosure: Agile Scrum Master here!

Agile can work well in a lot of situations, but you do need to get buy-in from the people involved. I'm 'mastering' several Agile projects (since January 2009), and we're seeing a lot of benefits from the process.

One thing that hasn't been mentioned yet, either in the article or the responses, is that Agile was in part designed to expose obstacles posed by the corporate culture. This allows you to remove the obstacles - assuming you have some support from upper management. If you don't have a fairly powerful Agile Champion (buzzword alert!) in the upper echelons, it will be difficult to succeed with Agile methodologies.

I'm fortunate that our CTO is both our Agile Champion, and a VERY effective communicator at the upper levels. I have a regional VP on one of my Agile projects - he's the Product Owner (for those steeped in the Agile buzzwords, again). Great to work with, can make fast decisions about what he needs from us. We're on track to complete a project in two months - very tight time schedule. We're using 2-week long Sprints.

Another of my projects has an external client in the Scrum - another Product Owner, very quick to make decisions or get us information that we need. We couldn't succeed without her, because she know what she wants - not us! We need her input, and her review of use cases, web screens, data gathering, and so on. She discusses code issues and database structure questions directly with the DBAs and Developers, and I occasionally do a little translating from geek-speak to client-speak. The team is highly productive, communicates well, and the client is VERY happy with the most recent demo of the software.

So YES, Agile can work. It takes some work, some practice, some commitment, and the ability to be flexible. But I LOVE what it's doing for my projects - if they don't come in "on time" (meaning we don't meet that unrealistic deadline that someone pulled out of a hat), EVERYONE on the project know why, and understands how it occurred. I'm a convert, ever since the first time one of my internal clients said "Oh, it's US that are the obstacle! We'll have to get better at this." Music to my ears...
Post #790717
Posted Friday, September 18, 2009 7:49 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 7:44 AM
Points: 76, Visits: 379
Having had a quick read over this, I'd like to mention two great (and free!) ORMs for .NET. A bit OT perhaps, but there is a lot of discussion of the dev process happening.

SubSonic (www.subsonicproject.com.au)
builds all your CRUD for you, and wrappers for all DB objects. From a DBA perspective, it is refreshingly non-presciptive in its approach (ie. doesn't railroad you into a particular philosophy of doing things) - it just helps developers do what they were already doing, more quickly.
Subsonic is for 'lightweight' projects (it is aimed at website devs, but can be used equally for forms application development).

For the enterprise-strength apps out there, CSLA .NET (www.lhotka.net/cslanet/) offers out-of the box features which trump any ORM I've ever seen - security, compression, object remoteability over different layers. You have to buy his book to get the full 'product manual', but reading his discussion of software layering (ie. tiers) alone (the first 40 pages) is worth the price of the book.
Again, it automatically generates an entire layer for you. The only thing which I don't understand is why it's not way more popular.

They are both .NET I'm afraid, but remember that .NET is essentially rebadged Java
The recent features of .NET such as generics and partial classes are leveraged to great effect.

(My excuse for mentioning this is that I find these tools invaluable in agile development because they take so much of the work out of coding and re-coding the Data/Business Logic layers)

Ben McIntyre
-------------------------------------------------------------------------------------
"We must never forget that if the war in Vietnam is lost... the right of
free speech will be extinguished throughout the world."
-- Richard Milhouse Nixon, 10/27/65
Post #790740
Posted Saturday, September 19, 2009 4:15 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 2:44 PM
Points: 2,901, Visits: 1,806
I've just been reading "The Mythical Man Month" by Fred Brooks. Some people think his book is brilliant other people deride it with comments such as "it taught me nothing new".

Those who deride it should look at the publish date. It was written in 1975 based on 25 years in the computer industry. I have the copy with the 1995 adendum. My point being that the book is the IT equivalent of Genesis.

You can clearly see the germination of ideas that are now part of agile development. For example Harlan Mills advocated an itterative approach back in the 1970's and he wasn't the first. From what I can gather the idea of iterative development dates back to the 1950s.



LinkedIn Profile
Newbie on www.simple-talk.com
Post #790767
Posted Sunday, September 20, 2009 2:22 PM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Wednesday, August 13, 2014 8:18 AM
Points: 110, Visits: 783
An example I have worked on that used the iterative approach did so purely for reasons of cash flow. The project was a £500K project in total but the company I was working for was small and couldn't survive the wait for an end-of-project payment. The project was broken down into a series of phased deliverables with payment on delivery.

Nothing I have read on agile development mentions cash flow and I think this is a major omission. It offers a win-win situation

* The development company gets paid per deliverable.
* The customer gets the use of software commissioned to help their business.


Take a look at work done by Mary and Tom Poppendieck at http://www.poppendieck.com/ and in particular their book "Lean Software Development: An Agile Toolkit" that has a chapter on contracts. And I seem to remember hearing mention of a book completely dedicated to Agile contracts that is soon to be released if it hasn't already been, but sorry, I can't remember the name.
Post #790917
Posted Monday, September 21, 2009 6:51 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Today @ 8:08 PM
Points: 43, Visits: 111
Regarding Visio 2007:

Question: Does Visio 2007 support forward engineering of DDL?

Answer : No, Visio 2007 does not support forward engineering of DDL. Only, Visio for Enterprise Architects (VEA) supports forward engineering of DDL.

Question: Is VEA installed as part of VSTS 2008?

Answer: No, VEA is not installed as part of VSTS 2008. VEA 2005 is a supported product.

Question: Does Visio 2007 Pro support Database modeling?

Answer: Yes, Visio 2007 Pro does support database modeling. Please go to http://office.microsoft.com/en-us/visio/FX101759431033.aspx for a feature comparison.
Post #791478
Posted Tuesday, September 22, 2009 4:36 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 3:01 AM
Points: 326, Visits: 2,220
I have my concerns about agile development and I suspect that it is like all other methodologies prone to being applied wrong due to it being used for its buzz value. I am inclined to qualify it as much as a marketing instrument as a development methodology at this point.

At the core the good points are in my view the bigger role of the customer has and the iterative development that supports this involvement. But comparisons of methodologies are usually done in a Duracell kind of way. A mediocre battery brand that compares it’s batteries to the most basic of all batteries and then advertises theirs lasts 7 times longer. What is most important is how does it stack up against other forms of development and which one is more suited to your customer and line of work?

I got a bit of experience with DSDM myself which looks far more traditional in the sense of roles and the analysis upfront. Its strong points are essentially iterative prototyping and project manageability in both time and costs. For this features are essentially prioritized and not everything on the list will necessarily make it in release. This means the customer must be willing to accept this and get involved in the design and prioritization process to get the most useful result. No longer can a customer deliver a list of things it wants and call it specs and then set a deadline and negotiate a price. The list of customers willing to go the length on this is not big…most do some unguided in-house brainstorming and only then a 3rd party is sought to build it.

For us IT professionals to have discussions on how to develop where the design and prioritization is far more important for a project to succeed is strange. This sort of discussion should be on management forums and so I can fully agree with an earlier poster that you need high level management (and customer) support for agile development to deliver. Without it you are likely to just end up with hard to maintain underperforming prototype code delivered too late and over budget.
Post #791653
Posted Tuesday, September 22, 2009 5:53 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 3:01 AM
Points: 326, Visits: 2,220
Stephanie J Brown (9/18/2009)
Nice article on the impact Agile can have on DBA's, David.

Full disclosure: Agile Scrum Master here!

Agile can work well in a lot of situations, but you do need to get buy-in from the people involved. I'm 'mastering' several Agile projects (since January 2009), and we're seeing a lot of benefits from the process.

One thing that hasn't been mentioned yet, either in the article or the responses, is that Agile was in part designed to expose obstacles posed by the corporate culture. This allows you to remove the obstacles - assuming you have some support from upper management. If you don't have a fairly powerful Agile Champion (buzzword alert!) in the upper echelons, it will be difficult to succeed with Agile methodologies.

I'm fortunate that our CTO is both our Agile Champion, and a VERY effective communicator at the upper levels. I have a regional VP on one of my Agile projects - he's the Product Owner (for those steeped in the Agile buzzwords, again). Great to work with, can make fast decisions about what he needs from us. We're on track to complete a project in two months - very tight time schedule. We're using 2-week long Sprints.

Another of my projects has an external client in the Scrum - another Product Owner, very quick to make decisions or get us information that we need. We couldn't succeed without her, because she know what she wants - not us! We need her input, and her review of use cases, web screens, data gathering, and so on. She discusses code issues and database structure questions directly with the DBAs and Developers, and I occasionally do a little translating from geek-speak to client-speak. The team is highly productive, communicates well, and the client is VERY happy with the most recent demo of the software.

So YES, Agile can work. It takes some work, some practice, some commitment, and the ability to be flexible. But I LOVE what it's doing for my projects - if they don't come in "on time" (meaning we don't meet that unrealistic deadline that someone pulled out of a hat), EVERYONE on the project know why, and understands how it occurred. I'm a convert, ever since the first time one of my internal clients said "Oh, it's US that are the obstacle! We'll have to get better at this." Music to my ears...

This reads to me you are enthusiastic to have a customer that does what a customer is supposed to do for a project to succeed. But how much less of this benefit would a non agile method get is the valid question to ask. Given the same customer and experienced designers/modelers, I think you get the same synergy and for developers have even clarity before they start coding.

Now the question becomes what benefits beyond the above did the agile method bring that cannot also be attributed to having the correct people do what they are supposed to do anyway. In IT I seen the same people jump from one ** insert new thing ** to the next, always claiming the newer is better and the old doesn't work. While this implies they are always wrong, they still claim the opposite every time and never seem to have learned anything from the past....people are wise to be follow such trends with caution.

There certainly have come new things to the field that advanced developing such as XML and the internet that allowed more flexible networking. But when it comes to organizing and developing code none of the for example DLL/OO/component/generator trends ever turned out to be the holy grail advocates made it to be. Each and every time the next incarnation declared the previous obsolete and makes all the same mistakes all over again. A lot of energy was spend that could have just as well gone into skilling up and develop ways to improve human/customer interaction.

If the core of the problems derive from non technical issues, namely how to organize and communicate then do not expect a technical solution to fix it. I welcome any change that improves customer involvement and awareness, but can do without the circus acts usually surrounding these things. In fact it puts me off, which means the most fanatic supporters are missing the point of what they do in the first place.

This last paragraph is not addressed to you by the way, just something in general.
Post #791679
Posted Tuesday, September 22, 2009 1:24 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 2:44 PM
Points: 2,901, Visits: 1,806
My first exposure to agile lead me to think of it as the bodge it and wing it methodology. It fundamentally isn't. It isn't even a methodology, it is a set of principles.

The means by which requirements are gathered and designs produced is much more informal but the shortness of communication lines means that it is much more relevant. I've just had the first team meeting on a project and straight away a discussion begins on the way in which the business users want to capture contact details on a form. This discussion is mainly beween the poor sods who are actually going to use the system and the poor sods who are actually going to develop it. The traditional approach would be for an analyst to talk to a line manager and produce a document that (assuming it was read thoroughly) could be mis-understood by all.

Early on in the project a great deal of time is spent at whiteboards drawing out how the system will work from the user perspective and how the fundamental architecture will look. The resulting drawings are photographed and the resulting jpegs captured for further reference. In fact the first itteration is usually ALL design and feasibility studies.

Subsequent iterations also have a lot of design discussions but will actually produce test cases and code.

If you've not done it before it is very alien. Expect it to be 3-6 months before you start to feel comfortable with it. I think it will probably be 12 months before you are as productive with agile as you were with previous approaches.

If you do it correctly you should see quality improve. I stress again, it takes quite a while for the processes that come under the banner of agile development bed in.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #792130
« Prev Topic | Next Topic »

Add to briefcase «««12345

Permissions Expand / Collapse