September 22, 2009 at 4:36 am
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.
September 22, 2009 at 5:53 am
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... :w00t:
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.
September 22, 2009 at 1:24 pm
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.
Viewing 3 posts - 46 through 47 (of 47 total)
You must be logged in to reply to this topic. Login to reply