LessThanDot Site Logo

LessThanDot

A Technical Community for IT Professionals

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Highly Rated Users

Forum
No Posts Rated

Top 50
Given
Received

Links

Wiki
Blog

Forum Statistics

Users
Members:
1884
Members Online:
1
Guests Online:
96

Total Post History
Posts:
81461
Topics:
18719

7-Day Post History
New Posts:
4
New Topics:
1
Active Topics:
2

Our newest member
manails232x

Other

FAQ
All times are UTC [ DST ]

Agile Development Practices

Please wait...

Agile Development Practices

Postby Emtucifor on Sat Nov 22, 2008 12:30 am

I just went to my second Agile Development Practices Conference in Orlando, and it was great!

If you haven't learned all about Agile, you should. I do not believe that you can be "too small to use Agile", as I am only one person doing development on projects (the other person who does development generally works on his own projects without me and vice versa) and what I'm learning is already helping me create better software.

Agile is, in my opinion, at its root as much a philosophy of system organization (people, culture, teams, processes, etc.) as it is how to develop or write code. I won't try to sell you on it too much, but I really do think you *should* go to the conference next year if you possibly can. (It is something like the second week of November.)

What I've been learning from Agile has been really, really useful to me.
God cries a little bit every time someone builds a database.
User avatar
Emtucifor
Guru
Guru
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033
 
Posts: 2835
Joined: Fri May 30, 2008 9:30 pm
Location: Bellingham, WA
Unrated

Re: Agile Development Practices

Postby SQLDenis on Sat Nov 22, 2008 12:40 am

we scrum at my job
User avatar
SQLDenis
LTD Admin
LTD Admin
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
 
Posts: 21784
Joined: Wed Oct 10, 2007 6:43 pm
Location: Princeton, New Jersey, USA,World, Solar System, Milky Way, Universe and Beyond
Unrated

Re: Agile Development Practices

Postby Emtucifor on Sat Nov 22, 2008 12:53 am

That's good. Do you know how helpful it is?

Several speakers at the conference talked about hearing from shops that said "we've gone Agile" but when you examine what they're doing, they in fact weren't. And I heard lots of stuff about people getting scrum master certification but being short on actual successful experience and coaching, and not really succeeding.

So I'm not exactly skeptical, more curious about whether you think it has benefit and how "true to practice" your company's version of it is—with the caveat that everyone implements Agile differently, and trying to follow Agile best practices too rigidly yields something that isn't actually Agile.
God cries a little bit every time someone builds a database.
User avatar
Emtucifor
Guru
Guru
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033
 
Posts: 2835
Joined: Fri May 30, 2008 9:30 pm
Location: Bellingham, WA
Unrated

Re: Agile Development Practices

Postby ThatRickGuy on Wed Nov 26, 2008 4:11 pm

We are currently using a SDLC that goes along the lines of what I call "Sh!t and Fix".

Poor user requirements gathering? Check
Limited pre-development documentation? Check
Nonexistance communication between users and developers? Check
Complete lack of testing standard and budget? Check
Lacking buyin from user managers? Check
Long and arduous process for promoting software to production? Check

Luckily the software development team and IT management as a whole has just restructured, so we're looking to change things up. I'm not sure if Agile is right for us, but it's definately on my list of things to learn more about.

-Rick
O_o \__o- \__o- \__o- \__o-
User avatar
ThatRickGuy
LTD Admin
LTD Admin
LTD Silver - Rating: 311LTD Silver - Rating: 311LTD Silver - Rating: 311LTD Silver - Rating: 311LTD Silver - Rating: 311
LTD Silver - Rating: 311
 
Posts: 1598
Joined: Thu Oct 11, 2007 3:21 pm
Location: Madison, WI
Unrated

Re: Agile Development Practices

Postby SQLDenis on Wed Nov 26, 2008 4:17 pm

Emtucifor wrote:That's good. Do you know how helpful it is?



We are not 100% but we are implementing what makes sense
we do 3 week sprints with deliverables, we also identify the bottle necks within a day

I must say that we have been pleasantly surprised by the outcome

I even have a deck of planning poker cards to estimate tasks
User avatar
SQLDenis
LTD Admin
LTD Admin
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
 
Posts: 21784
Joined: Wed Oct 10, 2007 6:43 pm
Location: Princeton, New Jersey, USA,World, Solar System, Milky Way, Universe and Beyond
Unrated

Re: Agile Development Practices

Postby Emtucifor on Wed Dec 03, 2008 7:14 pm

How do you know if you're doing REAL Agile/Scrum rather than Scrum-but? ("We do Scrum, but we don't ...")
• Are you doing iterative development?
• Sprints must be time boxed to four weeks or less
• Software features must be tested and working at the end of an iteration
• Sprints must start with an Agile specification

* Only 50% of Scrum teams worldwide meet these criteria

Other measurements:
• You know who the product owner is
• There is a product backlog prioritized by business value
• The product backlog has estimates created by the team
• The team generates burndown charts and knows their velocity
• There are no project managers (or anyone else) disrupting the work of the team

83% of waterfall projects over $3M fail
God cries a little bit every time someone builds a database.
User avatar
Emtucifor
Guru
Guru
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033
 
Posts: 2835
Joined: Fri May 30, 2008 9:30 pm
Location: Bellingham, WA
Unrated

Re: Agile Development Practices

Postby SQLDenis on Wed Dec 03, 2008 7:22 pm

Emtucifor wrote:How do you know if you're doing REAL Agile/Scrum rather than Scrum-but? ("We do Scrum, but we don't ...")
• Are you doing iterative development?
• Sprints must be time boxed to four weeks or less
• Software features must be tested and working at the end of an iteration
• Sprints must start with an Agile specification

* Only 50% of Scrum teams worldwide meet these criteria




All those criteria are true for our team when we do scrum

For 2 day projects we don't do scrum but we do the daily stand up meeting etc etc etc
User avatar
SQLDenis
LTD Admin
LTD Admin
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
 
Posts: 21784
Joined: Wed Oct 10, 2007 6:43 pm
Location: Princeton, New Jersey, USA,World, Solar System, Milky Way, Universe and Beyond
Unrated

Re: Agile Development Practices

Postby Emtucifor on Wed Dec 03, 2008 7:31 pm

Awesome! I got this stuff indirectly from Little Scrum Pigs and the Big, Bad Wolf.
God cries a little bit every time someone builds a database.
User avatar
Emtucifor
Guru
Guru
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033
 
Posts: 2835
Joined: Fri May 30, 2008 9:30 pm
Location: Bellingham, WA
Unrated

Re: Agile Development Practices

Postby damber on Wed Dec 03, 2008 8:14 pm

Emtucifor wrote:83% of waterfall projects over $3M fail


haha - I'd love to see the statistician that dreamt that one up :-)

Considering a large proportion of traditional projects in big companies are done in a waterfall type approach (and a few moderate variants) - this would mean that companies were losing $12m for every $15m they spend on projects - or in other words, each project costs them 5 times as much as the original estimate. I guess someone has a pretty loose definition of the word "fail". I wish I could work at some of these mythical companies, I really do... getting approval for a few million and being able to actually spend 5 times that would make it much easier to actually get things done that sorely needed funding, but nobody wants to pay for :-)

And no doubt there was a "CIO" survey - which is open to anyone that registers at one of the many cio info sites, which captured how many projects the CIO's felt had 'failed', the sums were done on the back of a napkin and some coke was knocked over, and the ash from a lit cigarette all helped to mangle the calculations so that some popularised number emerged from the mess, thus giving us a scientific definition that 'the other guy's proces' is just crap, whilst 'this new jazzy fandangled way' is just peachy. :-)

I've seen processes with all sorts of names abused by all sorts of idiots. something tells me it's the quality of the work contained therein that makes more of a difference, than just a particular process. GI->Process->GO or something to that effect :-)

Don't get me wrong - I think some of the ideas behind agile methodologies are great - but I don't think some of the zealous or polar-perspective statements made are useful to anyone really interested in improving quality of work.
a smile is worth a thousand kind words, so smile, it's easy! :-)


CODE: $5
WORKING CODE: $500
PROPERLY DESIGNED & WORKING CODE: Priceless
User avatar
damber
LTD Admin
LTD Admin
LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663
LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663
 
Posts: 3138
Joined: Tue Oct 09, 2007 1:48 pm
Location: North Wales, UK
Unrated

Re: Agile Development Practices

Postby Emtucifor on Wed Dec 03, 2008 9:05 pm

I'm pretty sure fail means: not on time, over budget, or lacking important functionality. I don't think it means "everything was thrown in the bin."

And I think you're guilty of exactly what you're accusing the people of who claimed that statistic: making stuff up without real evidence.

damber wrote:And no doubt there was a "CIO" survey - which is open to anyone that registers at one of the many cio info sites ...

Actually, it looks like 12 years of independent research:

InfoQ Interview: Jim Johnson, Creator of the CHAOS Chronicles

Jim Johnson, the founder and chairman of the Standish Group is probably best known for his research on why projects fail, published in The CHAOS Chronicles. The Chronicles comprise 12 years of independent commercial research on project performance of over 50,000 completed IT projects.

The objectives of CHAOS research are to document the scope of application software development project failures, the major factors for failure, and ways to reduce failure. In 1994, The Standish Group made public its first CHAOS Report, documenting the billions of dollars wasted on software development for projects that were never completed. That report included statistics such as: "84% of projects fail or are significantly challenged", and "45% of developed features are never used" and is among the most oft-quoted in the industry since then.

Taking time out from his vacation, Johnson spoke with InfoQ in this interview about how this research came to be, how it is done, and the role of Agile in his findings. Johnson's work with project failure has reinforced his belief that small is best - small teams, small projects, and the Agile approach to software development.
God cries a little bit every time someone builds a database.
User avatar
Emtucifor
Guru
Guru
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033
 
Posts: 2835
Joined: Fri May 30, 2008 9:30 pm
Location: Bellingham, WA
Unrated

Re: Agile Development Practices

Postby ThatRickGuy on Wed Dec 03, 2008 10:23 pm

To be fair though, a large portion of those failure likely aren't following appropriate waterfall techniques either.

Heck, right now I'm working on an app that supposedly follows the organization's waterfall template.

I have no request, proposal, detail document, technical spec, or any of the pre-development work that is included in the waterfall template. We also have an "end of the year" dead line, but no one has defined what it is we are delivering by end of the year.

If interviewed on this project, senior management would claim that it is being run with a waterfall approach, and that it has failed to meet it's initial deadline.

But that failure is hardly the fault of the waterfall approach. Rather it is a project management failure, and an inability to adhere to any standard (waterfall or agile), a matter of priorities, and extremely poorly handled time management by the BA.

Given 12 years of data on the SCRUM approach and you'll likely see the same thing. Right now, I would expect it to be better as the people who are early adopters are likely being more rigerous in their training and adoption of its methodologies. But, given enough time you'll see the same sh!t and fix mentality with an Agile label on it.

-Rick
O_o \__o- \__o- \__o- \__o-
User avatar
ThatRickGuy
LTD Admin
LTD Admin
LTD Silver - Rating: 311LTD Silver - Rating: 311LTD Silver - Rating: 311LTD Silver - Rating: 311LTD Silver - Rating: 311
LTD Silver - Rating: 311
 
Posts: 1598
Joined: Thu Oct 11, 2007 3:21 pm
Location: Madison, WI
Unrated

Re: Agile Development Practices

Postby damber on Wed Dec 03, 2008 10:47 pm

Emtucifor wrote:And I think you're guilty of exactly what you're accusing the people of who claimed that statistic: making stuff up without real evidence.

damber wrote:And no doubt there was a "CIO" survey - which is open to anyone that registers at one of the many cio info sites ...


Geez, man... when are you going to install your sarcasm filter ? this is the second time in as many months... !! :-) I enjoy your posts, and love to debate this stuff with you, but it doesn't half give me a headache ;-) Besides, I think I'm starting to get a complex !

Anyway - Let me make it clear: I don't REALLY believe they had a napkin and coke and cigarette. really, I don't. :-) At least not until the after-party ;-) with maybe a dash of JD..

Actually, ironically - infoq ebizq was the site I had in mind when I was typing that - I've been a member there for years, and although it has some interesting stuff - they have some dodgy surveys... almost as good as the register's ;-).
(edit: oops - I meant ebizq, not infoq)

But (on a more serious note) to say that less than 1 in 5 projects over $3m are succesful using Waterfall is a bit of a stretch - even if you take the absolute literal 1 day, 1 dollar over is a failure (which in 95% of businesses eyes, it is not)... I have seen so many reports, stats, etc like this for different things that I tend to take it with a pinch of salt - stats can be used to prove anything - I've worked on both sides of that equation and although it can be used as a rough guide, you have to be careful about how you interpret them.

A few years ago I took my then team through an external audit by an analyst group to evaluate how good the development process, service management, cost management, etc was. They had stats too. Different to this too. Different to Gartner's too. Different to Forrester's too. Funny that. Oh, and we scored exceptionally high on the 200+ projects undertaken each year (from very small 10-20 days to medium 12 month+ projects), most of them delivered under budget, ahead of schedule, within scope and with 100% functional and non-functional compliance, most of which were delivered using a waterfall methodology. The team was already certified ISO 20000 (one of the first in the world), so this did of course help on the service management side of things. I think there were something like 5 or 6 'fails' as they could be called - various reasons behind them, some the team's fault, other's more complicated business related issues. So, sorry (again!) for my sarcastic retort to yet another stat from the underworld of statisticians, but I trust my first hand experience over a link to a report from an analyst that likely contradicts other analyst reports, and doesn't present the 'facts' in a way that is meaningful (e.g. how many projects using Agile over 3m have succeeded ? if it is 1 in 5, then that tells you a very different story, doesn't it?).

Also, the development team I managed before that were never formally evaluated other than our own internal metrics, though I would say they were at a similar level of quality, maybe a little less as the process lacked a bit of maturity in handling scope creep/requirements management - again, mostly waterfall with occasional iterative aspects thrown in.

Now of course, and in my last role, I work with Enterprise Architecture Development Methodologies which are quite different in some ways to a software development methodology, some things are similar, but after all, these are very different working environments - builders and architects face different but similarly difficult challenges.

How about you? what is your experience of both Agile and Waterfall, or RUP, V-Model, etc? And their relative successes/failures on different types and sizes of projects? I bet you've had some good and bad experiences of both - or if you're new to Agile (or don't do it formally), then at least the waterfall method? I've certainly had bad experiences with Waterfall when not managed/performed properly - but that's my point from my last post - the quality of the work is often the deciding factor on success. Different methodologies also fit better with different personalities/workstyles too. Which is what actually surprised me about your initial post - I would have had you pegged for a waterfall developer - I don't mean that negatively, just that you are very methodical and structured, I would have thought this approach would have felt more natural to you?
a smile is worth a thousand kind words, so smile, it's easy! :-)


CODE: $5
WORKING CODE: $500
PROPERLY DESIGNED & WORKING CODE: Priceless
User avatar
damber
LTD Admin
LTD Admin
LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663
LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663
 
Posts: 3138
Joined: Tue Oct 09, 2007 1:48 pm
Location: North Wales, UK
Unrated

Re: Agile Development Practices

Postby damber on Wed Dec 03, 2008 11:07 pm

the comments in that link are quite amusing :-) especially the response from the interviewee - "buy my book, it has all the answers" (ok, not a literal quote, but close enough :-))

Also, "84% of projects fail" does not mean that "84% of projects fail because of the Waterfall method" - besides, if 84% of projects over 3m fail, that means that only 15% of projects under 3m fail, assuming similar ratios of 83% of the 84% for >3m (69%) leaving 15% to make up to the 84% of total failed projects. Why didn't these smaller projects fail with the waterfall methodology? Or are we saying that only projects over 3m use waterfall (not true) and only projects under 3m use Agile ? (also, not true). Crazy... Or maybe just taken out of context and used to prove a point? (I don't mean by you, I mean by the original author / presenter)

Still - let's not let that detract from the point of the topic - Agile approaches provide some valuable lessons for us to learn.
a smile is worth a thousand kind words, so smile, it's easy! :-)


CODE: $5
WORKING CODE: $500
PROPERLY DESIGNED & WORKING CODE: Priceless
User avatar
damber
LTD Admin
LTD Admin
LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663
LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663LTD Silver - Rating: 663
 
Posts: 3138
Joined: Tue Oct 09, 2007 1:48 pm
Location: North Wales, UK
Unrated

Re: Agile Development Practices

Postby Emtucifor on Thu Dec 04, 2008 12:37 am

Well, I knew you didn't mean literally on a napkin and all that, but I wanted to hear more about why you thought the way you did. You've given that now, and it was perfect!

I honestly don't have as much development experience as I would like. Which is part of the dynamic for me: I am pretty much on my own in an IT department that officially "doesn't do development" but in actuality a couple of us do. My past experience has been mostly with small teams, but there was a lot of thrashing: Things weren't being tested well, there was no clear plan, etc. Particularly, at one company, they were trying to do so much that they never got a product out before the funding dried up and the company went out of business (and we all lost our jobs). This was the start of 2+ years of unemployment for me. What everyone was saying right at the end was, "we should have made a product that was useful to people and had only these basic features first." Interestingly enough, if they had been doing Agile, they would have had exactly that.

Anyway, when I started searching the world for a kind of generic "how to get better at programming" (note, not "how to program") I came across Agile and saw that it focuses as much on how the people and processes operate as it does on the nitty gritty of writing cold, hard program code. I realized that, one-man team or not, I still have to do project planning and management, and I have managers who need to know what I am doing and expect the most value possible in the shortest time possible. And waterfall just does not seem to offer in all these areas what Agile does. Agile brings a very deliberate focus on systems and processes, on automation and using computers to ease our work and make the quality of the work better, on getting feedback sooner and delivering value sooner, on treating people with respect and empowering them at the lowest level possible. I myself at work have made mistakes about putting too much stuff in release 1 of something: management would have been much happier to have more limited or less sexy functionality sooner. I don't know that waterfall has much to say about that, but Agile does have a LOT to say about that.

I am suffering through a side contract project that could probably have seriously benefited from some anything including waterfall at the beginning rather than what it had (which was not much) but the experience of this project is showing me that the customer could never have told me all of his requirements until he had something working, since the new system is completely different from the old system, and he didn't understand his own business at the level I had to, and it was very hard to get it out of him. Some of that probably comes down to my own lack of experience at the time, but not all of it.

Some way to meet the following two goals seems necessary to me for even basic sanity in software development: 1) to start delivering functionality early so that some kind of iteration can be done (e.g., where the customer can find out that what he told you wasn't right, so he can get it right) and 2) to keep enough rigor (adherence to some formal and useful set of principles) in the development process so it doesn't turn into nothing more than flying by the seat of the pants and hoping not to crash before getting somewhere.

As for thinking of me as methodical and structured, I suppose that I am in many ways, but Agile to me is that! It is all about how to apply method and structure in a different way than waterfall: to be driven by early feedback and have frequently working releases in a practical way. I don't see Agile as by any means unmethodical or unstructured.

Regarding personality. Agile doesn't really require that much change on the parts of the developers and the testers. For example, programmers are still writing the same, best code they can to solve the same kinds of problems. A lot of the difference for these types of people is about automation and taking the hit of mistakes or design change decision early rather than late. I can't see those kind of benefits as having much to do with personality. People may not like test-driven development because it seems like extra work, but when you start to get good at it and are discovering bugs within *minutes* instead of *months* and start adding up the value of something like that, what programmer wouldn't want it? And your test-first code suddenly becomes your automated regression test. One part of Agile is a sort of continuous mini-refactoring: ultimately the programmer is super happy with this because it makes the code easy to mantain and understand, which for the programmers is of very high value.

Waterfall came from civil engineering—building bridges and hospitals. The cost of change on those types of things is enormous. If you get halfway through building a bridge from both ends and find out they won't meet in the middle, you're seriously in trouble. So you had better figure out every single girder and nut and bolt and pin to the millimeter before you start building a thing! But software is just typing (an oversimplification, but essentially true). In software you can do the analogy of building a short bridge that can only hold a dozen 10-pound cars, then iteratively transform that in steps into the final mile-long bridge that can handle a fleet of cement trucks. (It is a working bridge as of release 1 and it stays that way.) But the problem with building software like structures is that transforming business needs into software is much less obvious. There is certainly art in building bridges and hospitals, but most of the structure of a bridge follows quite directly from its weight-carrying need and required span length. There are of course architectural parallels in software development, but the two are still wildly different beasts.

Where I agree personality does come in is at the project management level. Those folks really do have to radically change what they do. They have to believe different things, trust their team more, get used to not seeing all the way to the end--all sorts of soft stuff. Planning, power, control, trust, leadership, procedures: Agile has something to say about all of these. My answer to this is that I don't think the personality of the project management should decide the effectiveness of the team. The company should look for those who will fit their business goals and they should let go those who don't.

To get back to more of your own points, I fully agree that the quality of the work really, really, really matters. (At the Agile conference they talked a LOT about software quality.) However, you can take a super software development team and cause the project to fail anyway through bad project management. (Though usually things come back to the problem being the system rather than any one individual or group.)

Let me close by saying Waterfall done well is surely superior to Agile done badly. Agile is not necessarily easy to implement or even to understand. But companies are seeing real and very significant improvements in productivity and profit in their software development by using it.
God cries a little bit every time someone builds a database.
User avatar
Emtucifor
Guru
Guru
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033LTD Gold - Rating: 1033
LTD Gold - Rating: 1033
 
Posts: 2835
Joined: Fri May 30, 2008 9:30 pm
Location: Bellingham, WA
Unrated

Re: Agile Development Practices

Postby SQLDenis on Wed Dec 24, 2008 2:41 pm

Just for Emtucifor http://aboutscrum.com/
User avatar
SQLDenis
LTD Admin
LTD Admin
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
LTD Gold - Rating: 3467LTD Gold - Rating: 3467LTD Gold - Rating: 3467
 
Posts: 21784
Joined: Wed Oct 10, 2007 6:43 pm
Location: Princeton, New Jersey, USA,World, Solar System, Milky Way, Universe and Beyond
Unrated

Re: Agile Development Practices

Postby shalimar on Sat Feb 11, 2012 8:01 am

cool
shalimar
Newbie
Newbie
 
Posts: 4
Joined: Thu Dec 31, 2009 5:19 am
Unrated