Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are a small team (3 developers) and one of our main clients is about to submit a bunch of new feature requests and a follow on project to us to get estimates on cost and delivery times. Our last project with them was a 'success' in that they are coming back to us but I know we could have done a much better job (we used waterfall... testing was an after thought and as a result unit-testing code coverage is significantly lower than we feel comfortable with, not to mention the never-ending 'we are ALMOST done' problem).
I have just finished reading 'Art of Unit Testing' and 'Working Effectively with Legacy Code' and I have used TDD on a pet project of mine outside of work and now I can never go back to waterfall and testing after the fact.
What I want to know is are there are good 'easy to digest' videos for non-developers that clearly show the benefits of TDD along with Agile practices in a business sense? I'd be super happy if there are any sub 10 minutes videos but I'm also OK with longer videos (and I will reference them to a time index in it). If there are no good videos then a written source is next best thing.
I want nothing more than for them to be on board and really excited with the transition.
For me it is not an option to 'just do it' as there will definitely be a learning curve for the other two developers and without doubt the first number of iterations may be stressful and bumpy and that needs to be communicated to our client.
[I have answered my own question below with a number of videos I found since asking the question... they are not perfect for my use but definately my plan B if no-one else knows of a better one]
Technical debt kills velocity. Thus, I like to include "No increased technical debt" in the Definition of Done. Without this, you can't achieve sustainable pace. This is illustrated by the picture below (borrowed from the Technical Debt - How not to ignore it presentation from Henrik Kniberg):
alt text http://img27.imageshack.us/img27/329/screenshotkq.png
To me, all these things are obvious and you can even prove it with numbers (by measuring the velocity over time). Explain these concepts to your client, explain him that TDD is one of the techniques allowing to control technical debt. Then, let him choose (or choose for him).
How you run your project internally is your business. Don't involve them in this decision. They are not experts in software development processes. Ask them about business requirements and things they know about.
Sound like you are doing this to improve project quality. Do you think it will cost more to do TDD? Why work to convince them of something and then ask their approval? Did you ask if you could do waterfall on the last project?
Why would your client even notice the transition to TDD? Stressful, bumpy; how so?
Tell the client why you are upgrading to TDD. I'm sure the reasons are as compelling to them as they are to you. To me, TDD first of all means a much greater sense of reliability on what you produce.
Surely your client remembers all the regressions and manual testing from your last project?
I don't know of any specific illustrations for you (the web is full of articles and blogs, but I'm not aware of any videos), but you pretty much answered your own question...
we used waterfall... testing was an after thought and as a result unit-testing code coverage is significantly lower than we feel comfortable with, not to mention the never-ending 'we are ALMOST done' problem
You just need to be honest with your client. Explain to them what the project methodology you used on your last project cost them in terms of flexibility, maintainability, and your ability to confidently provide them with quality code. Explain to them how TDD addresses that, and explain that you anticipate a slower start due to using a new methodology.
Illustrate for them, as concretely as possible, what they will gain, and it should be an easy sell. I would, however, approach it more from the "this is what we're planning on doing" angle, rather than the "can we please do this?" angle. Give them the impression (without being dishonest) that you are already planning on going this way and any change to that plan will be an inconvenience to you and your team, and will likely cost them productivity.
I'm not aware of any videos, but explain to them that it took you N man-hours to redesign a certain feature on the last project due to original design not being correct taht was not caught until you started testing; and with TDD it would take M (<<N) man-hours since you would not spend the extra hours working based on a bad design/bug as happened last time.
Also, explain that the confidence level of having less buggy software will be raised by Y percent due to thought-out tests.
Then explain you estimate X hours for learning curve on the FIRST peoject, and ask them if the given benefits on ALL future projects will be worth it, when the initial time investment is depreciated across those.
Firstly, unit testing isn't unique to Agile methodologies; I've been around a while and have seen it used on waterfall projects. In fact, I heard of unit testing long before I heard of Agile!
Afraid I can't point you to any videos that will help convince a client to switch development methodologies. Google may help though; if not with videos, then maybe with studies, blogs, etc.
Anyway, one suggestion for improving the chances that the client will accept your reduced productivity during your learning curve is to reduce his costs somehow. E.g. if you're billing by the hour either charge less by the hour for time spent learning, or just don't bill for those learning hours.
I spent the time since asking this question looking for the best videos I could and I've come across a number that are very close to what I need. I will post them here so that others will find them if they are in a similar position to me.
I realise that I asked more about TDD - but these videos capture a good portion of the message I'm trying to drive home... especially 'Why does Agile Software Development Pay' and 'Scrum in under 10 minutes'... it is the process of being responsive to change, producing higher quality code, having fewer defects and faster development cycles.
Agile vs waterfall: A Tale of Two Teams (8:20)
Why does Agile Software Development Pay? (5:03)
Scrum Basics (5:50)
Scrum in under 10 minutes (7:59)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have been doing TDD for the past 3 years. We were a small company, and we had very solid support for most aspects of the agile process from management. Everyone on the development team was sold on the process. And thus, the upfront investment it usually takes to build fixtures was accepted knowing it would pay off along the way. (Code that starts an http server, code that populates sql databases before tests, etc). Documentation mostly happened in the tests and help requests were usually presented in the form a failing test.
Now I moved to a bigger company, and while management is supportive of the Agile process, teammates are a mixed bag, some of them see it useful, some of them do it because of management and some don't see the value. It's been a challenge to convince people to spend some time building fixtures or to convince a team member the best way for me to help him if he took the time to write a failing test.
So what do you think is the best way to sell TDD to a hesitant teammate? The objections are usually : 'It's an unneeded cost', ' we can always write tests after the fact for parts that are important', 'it's a buzz word, teams pick it up and then it falls to the side as the heavy grind begins' etc.
"the best way to sell TDD to a hesitant teammate"
You can't. Don't waste time "selling".
Instead, invest time in "proving".
Just do it. Be successful. When people ask what the secret of your success is, then reveal the TDD. Not before.
simple -- maintainability. TDD gives you the ability to make changes, and see where those changes affect the rest of the code. The larger the code base, the more imperative it is that there be tests to validate any new changes.
correctness. Although tests can themselves be broken, eventually they reach a point where they make sure the components are doing what they are supposed to. The better the developer, the faster that is.
another advantage is that TDD informs the design of the components in the system. If you are trying to test something, and the test is too complicated, it probably means you need to break the problem down into smaller parts...
to sell it to people, you say that in the long run it makes adding new features cheaper, and reduces the risk of breaking existing functionality. So it reduces cost.
For the hesitant teammate, be patient, wait for an opportunity, then pounce. In software development there will undoubtedly be an problem where TDD would have prevented or mitigated the problem. Be on the lookout for such an opportunity. Work with him/her to create a test(s) that should have been developed from the beginning. However, make sure you craft your message in such a way to not embarrass your teammate.
I agree with S. Lott, you can't "sell" them you need to show the value.
One of the most effective ways to do that is with pair programming. Granted you have another "sell" problem convincing people that pairing is an effective approach, but after some time you may convince/convert a developer or too.
TDD was a tough concept for me initially, but now I can't imaging programming any other way.
I think Joel's post explains very well why testing is A Good Thing™.
I don't think he ever uses the phrase "TDD", but it's got some great info.
Show them this site: WeDoTDD.com - actual company team use cases. Those who are successfully practicing TDD in real companies.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I know this may not be exactly a coder question, but I feel it is still related to programming because I'm sure many developers have come across this before and might have some insight on how to resolve this or have advice. There is an actually programming question though.
My issue as a developer.
I work in a small company, roughly 15 people, 5 of which are developers include myself, the rest are tech support and management. Problem I'm having is, when we get a SOW (Statement of Work), our clients give us a rough description of the project they are requesting, which usually is a 1-3 page brief description, usually including a Visio document, now as a programming, I'm responsible for going over the document and relaying a time-line on how long it should take me to complete the project.
Unfortunately, there have been times, not only me, where we under-estimate the project because we didn't fully get into it till we actually developed it, which ends up slapping ourselves in the face, because my boss is upset because he is being hounded by the client, who is now upset because we missed our promised deadline.
My question is, how do you guys handle organizing basic project description when you need to give deadlines on more concept, and do you have any ideas on how to organize it.
I'm thinking of going to my boss and suggesting, instead of always pushing a estimated deadline to our clients which expect us to hit that, we should write up a detailed document that is more step-by-step (more like what to do) on how to develop the application they want, it may take a lot more time, but least if the project is moved to someone else it is laid out for them, and when I usually get back to it 4 months later, I don't have to refresh up again, I can just follow the steps I wrote.
What do you guys think? Ideas? Or better ways to handle this?
If you switch your development to using an iterative methodology (Agile, XP, Scrum, etc), then the customer will see results much earlier than any deadline you feel you have to promise - usually every 1 or 2 weeks.
The moment they see what you've developed, I can pretty much guarantee that they'll make changes to their initial requirements as they now have a visual representation of the product and it may not be quite what they were thinking of. Some of their changes might be quite radical, so best to get the feedback as early as possible.
In all the projects where i've insisted we do this, the customer was delighted - they saw the results early, could influence the project outcome, and we hit their end deadline. Unexpectedly, a whole load of features got left behind and - guess what - the customer did not mind at all as they got the top features they wanted and put the project/product straight into production as they'd had lots of time to refine it to suit their business, so they were already familiar with it.
It takes a lot of effort to get management, sales, creative, etc, to all buy-in to an iterative style, so you may need to implement a hybrid solution int he mean time, but in my experience, it is well worth it.
If a complete shift to iterative is not possible, split your project into tangible milestones and deliver on those milestones. As others have said, inflate your estimates. My previous manager doubled my estimates and the sales team doubled his too.
Inflate your project deadlines. It's something that most programmers should do (and I quote the VP of Freeverse, the company that I work at):
It is a well-known fact among people
who work in the software industry that
the last 5% of development always takes the longest.
If possible try to divide the higher level tasks as much as possible so that you can get a better approximation of how many man hours that sub-task would take.
Also, adding hidden buffers to your task execution helps in covering some of the unseen contingencies.
cheers
If you mock up (balsamiq or whatever) with your customer, you will get more details. Armed with those details and some experience, your estimates will be more accurate. And then double it and add 4 (hours,days,weeks,months)
First, unless you systematically under-estimate, your boss should not get upset. It's his job to answer to the client, and he should know that by definition, an estimate is NOT the future. Statistically, sometimes you should deliver earlier, sometimes later.
Personally, I think that the frame of "how long will it take" is not exactly the right discussion to have. Software development is a risky business, and change/surprises happen all the time. One approach which helps is to focus less on the "right" number, and more on the volatility. Look at the project, and consider the places where you are pretty clear on how long it will take (you have done it before and understand it well), and look at the places where you have uncertainty (unclear requirements, new technology), and for these, think about how bad it could go, and why. That will help you get not one number, but rather boundaries: what you think is reasonable, a worst-case scenario, maybe a best case scenario (which the client should never see :) ) - and convey that information to your boss, so that he can manage accordingly.
Additionally, this will allow you to identify the danger points of the project, and you can then prototype accordingly - look into the uncertainty points as early as possible, so that you can tighten up the timeline fast, and have early warnings for your boss and the client.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
In my organization we have to handle multiple projects with different technologies,like flex, iphone, .net, php etc. The problem is I know only java.
So if a developer says me that an issue will take 2 days to solve I really cant judge whether he is right or wrong.
How to handle this situation?
One more problem is that because I don't know a particular technology so its very tough for me to say that whether a particular thing is possible or not in that technology?
I prepare project plan, documents, contact with clients these things but have almost no controls on developers because my insufficient knowledge of all those technologies
What can I do about this?
If an estimate strikes you as a bit over the top, surely the developers should be able to explain what it is that will cause the delay. Especially if you know java - they should be able to explain it to a non-tech project manager as well (after all, the project manager might be required to explain to the customer).
Other than that; trust your developers. They probably don't underestimate badly enough to get you into a tight spot, but you should always give yourself some margin as well, when communicating with the customer. If they constantly over-estimate, you should notice that after a while.
This is from Scrum but it is applicable even if you don't do Scrum. In Scrum, only the developer is allowed to give an estimate of how long it would take to do something. Managers are not allowed to give, recommend or in any way modify that estimate. So first of all trust that estimate.
But.. most programmers are inherently over-confident. If a programmer says 2 days then it may take him 3 days to complete a task. The estimate does not reflect reality (at first).
The solution to this is to keep a record of the estimate. I usually write the task and estimate down on a piece of card and post it on a big whiteboard. If the task takes longer than the estimate then tactfully remind the developer and make a mental note. Next time, before making a new estimate drop subtle (or not so subtle) hints about missed deadlines or early completion. This way the developers will slowly learn to improve their estimates.
Be cordial in all this. The aim is to get accurate, reliable estimates - not to put pressure on people. The whole point of this is to train people to make better estimates. Trust me, having an accurate estimate is more important than missing a deadline. It is relatively easy to tell a client that a project will be delayed by 1 week if by the end of that week you can actually deliver the project. On the other hand repeatedly telling the client that the project will be completed "tomorrow" will quickly make the client lose trust in you.
A few other notes:
When I started this process it took around one month for most people to actually be able to give me accurate estimates. It's not that they were intentionally lying about previous estimates. It's just that people, especially programmers, don't actually know how to make good estimates without training.
Whenever developers come up with an estimate of more than 3 days I automatically ask them to break the task to smaller subtasks such that each subtask takes only 1 or 2 days to complete. This also automatically generates milestones that you can actually track to see if the task is going well or is stuck.
Explain this process to your boss and get his support. It is very hard (but not totally impossible) to do this if your boss keeps pressuring you because you will end up pressuring your developers. Your boss must understand that time estimates can only be made by people actually spending time doing the job.
you should probably trust your developer's estimates, yet expect that they won't always be 100% accurate, remember they are estimates. It might also be a good idea to use a process that has the acceptance built in that estimates are only estimates, and either doesn't require them (e.g. Kanban), or has features built in to adapt to the nature of estimates (e.g. Scrum).
PMs shouldn't really need to know that much about the technology, as that is what the developers are for, but I understand that is not always the case, particularly where the PM also has technical responsibilities.
So judging whether or not something is possible shouldn't be your responsibility alone, this type of evaluation should be delegated practically completely to the developers, at least regarding the technical considerations. You can still provide your evaluation where business, economic, and customer considerations reflect on the possibility or otherwise of some endeavor.
In short, leverage the developer's technical knowledge where it is needed.
Befriend your development team. Explain that your job is not to boss them around or tell them how to do something and how long it should take, but to help them co-ordinate and shield them from direct interaction with the clients.
Once you are in a situation of mutual trust, describe the needs of the client and rely on the estimates provided by your developers. They're the ones who have the knowledge anyway.
Should a client ask you for an estimate on the spot, answer that it's impossible to give an exact figure without putting some thought and expertise into it. If they insist, answer a large-ish figure (at least what it would take you to do that same thing in a language you know) and tell them that you will provide the actual numbers shortly.
Maybe your process could do with some help.. from your comments above i saw:
Step 1 -the PM has to communicate with client to build the project
plan...
Step 2- build the mock ups---
Step 3--get approval of those two documents from client and management
....
Step 4-- project starts
Where do the developers come in and estimate? If you're asking them at Step 4, it's too late as you've committed to some sort of schedule with your client and management.
To ensure everyone's expectations are correct, take along a trusted developer to Step 1. Before you present a plan just ask the dev; "how long could we build this with a team made up of n of our developers?"
This has a few advantages:
Better estimates
Sets more accurate expectations with both client and dev team
Increase commitment to those estimates from the dev team
1 and 2 should be obvious, but item 3 is important as people rarely like working to estimates set by someone else. While you may not be able to use the whole dev team in your estimating, use a trusted advisor.
I also do manage some small projects, some COBOL, some MS, mostly java.
I only really know java, and my skills need updating too.
We use a scope estimating tool, really just an excel sheet with fields the dev fills in to assess the impact. This helps the developers break down the problem into smaller pieces, it forces them to really think through the steps that need to get done and this gives us a more accurate estimate. Whatever helps the developer, helps you. :)
And then when we are done we compare the estimate vs actual and baseline it for future references. We define good estimates as having a variance of 10% or less.
Don't just blindly trust the developer's estimates - you don't know where he's basing that from, no one could ever know 100% of the technology/framework or data model or business rules or such. Know what he has factored in the estimates.
I believe trust is earned. If a developer has given bad estimates before, would you trust the estimates he'll be submitting next is adequate? I definitely won't, unless I see an improvement.
I've been a developer, and I have made quite a few bad estimates too. (Hhmm maybe that's why I'm less of a developer now and more of a manager.. )
The only way to get an accurate estimate is to break the task down into small units of work. The smaller and more focused the units of work, the more accurate the task estimate.
Getting the team together to discuss exactly what each task will involve is a great way to peer-review the proposed technical solution. Often a better technical solution is hatched by the team through detailed discussion of the task. This is a great use of time, and you'll easily recover the design-peer-review time once development starts.
If you sit in on these team discussions then you will start to understand the technology a bit better, and you will start to trust your programmers more as you understand the estimating challenges from their perspective. It is also a great way to cross-train the team, as you'll often hear the phrase "I didn't know you could do that" as developers share their knowledge. Make sure the team reviews are ego-free and friendly.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Like many here, I am a one-man development team. I'm responsible for everything from gathering project requirements, designing concept-screens, planning and developing databases, and writing all code.
Being a one-man team is nice, but has its negatives. I don't have the ability to quickly consult with other developers, I rarely get a second set of eyes for my code, and I'm sure you guys can come up with many other negatives too.
To make the most of my time, and commit myself most efficiently to my work, what tips or practices could I implement into my day-to-day routine to be the best one-man team possible?
Daily list of what I am going to do.
Remove as many distractions as possible to focus on tasks. Turn off
email, turn off IM, etc... even if
for a set period of time and then
during a break check them.
Take time to learn about other coding techniques, tools and programming wisdom. This I have found to be crucial to my development. It's to easy to just code away and feel productive. What about what could be if you just had some more knowledge / weaponry under your belt to bang out that next widget. I know this one really sounds counter productive but it really isn't. Knowledge/know how is our real currency. The more we know the more we can make a better decision about how something should be done and do it faster.
Take breaks and be aware of your
body. When we are tired we don't
think as well and will make more
mistakes, become frustrated more
easily, etc...
Learn to use the 80 / 20 rule to your
advantage. I don't mean skimp or be
lazy. Often though we will work our
tail off for that 20% when it wasn't
necessary.
Set goals for yourself (daily,
weekly, bi-weekly). Make sure the
goals are also in line with those you
are coding for or you may find you
have wasted some time.
From a technical aspect consider:
Consider Unit testing / TDD. I have found in
my own work that this actually saves
time. It takes a while to get the
hang of but with anything you will
get better.
Care for your code. Refactor it
(especially if you start unit
testing). The better your code is
the easier it is to maintain which
takes less time. The easier it is to
understand the faster you can change
/ implement features.
I'm learning to spend a lot more time planning out my day than I used to. This includes planning out projects, down to writing psuedo-code for the programming I need to do. I find that with all the interruptions in my schedule, it's difficult for me to get started at something. Having everything broken down into small tasks makes it much easier to start after an interruption.
According to operational research, shortest job first is the best scheduler to get most amount of things done.
I write and run integration and system tests, but no unit tests, because I've no need for early (pre-integration) testing: Should one test internal implementation, or only test public behaviour?
A corrolary of Conway's Law is that you need to test the internal software interfaces which separate/integrate developers, whereas a "one man army" don't need to explicitly test his internal interfaces in this way.
A lot of the other tips are good but they equally apply to developers working in a team as well as a lone developer.
I think the hardest thing as a one man team is effective communication with the rest of your company. You will always be a lone programmers voice in any meeting or discussion around how best to build software.
As a result I'd advise trying to improve negotiation skills and focus on improving the way you describe technical concepts in terms a non-programmer can understand. Reading books such as Getting to Yes and How to win friends and influence people are a good way to start.
When there is more than one person agreeing on a viewpoint, the viewpoint automatically gains credibility with those you are trying to convince. In the absence of this possiblity you need to work extra hard at preparing your arguments with well-researched evidence and a balanced view.
I'm in the same situation. There's already a lot of good advice above but one thing I'd add is find when your best coding times are and make sure you're coding during that time. I have a few hours in the morning that I seem to be at my best for coding. I try to keep that time free of all distractions. Plan things like meetings, writing documentation, testing (at least the tedious, repetitive stuff), and all that other stuff for your less productive time. Keep those coding hours when you're 2 to 5 times more productive for coding.
Make sure you refactor early and often. That serves almost like a second set of eyes (for me, at least).
Don't work insane hours (especially tricky if you're working from home). Actually, working less hours often proves more productive as the impending break/end of day pressure increases your efficiency.
You may want to look up Parkinson's Law for work/time management.
I use a text file to collect all the things I do every day. Every time I run into a problem or have a question or find a solution, I add it to my file. It's very low-tech but it provides a wealth of information, like "where am I spending most of my time?" or "how did I fix that problem before?". Also makes it super-quick to give your client a list of hours at the end of your billing cycle.
I also use another text file (per client) that contains all the work items on my plate, arranged in order of priority, and updated frequently. It helps both me and my clients focus on what I should be working on next, so the pump is always primed.
Eventually I'll move away from flat text files to using something like FogBugz, but for now I can't beat the price, or how easy it is to search, or how easy it is to e-mail.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have been in the IT industry for 10 years now but have worked in "traditionally" managed project teams (both well managed and badly managed ones).
I have heard of the "new" scrum or XP type of project management and yearned to be part of one (as s/w folks we always like anything new I guess) but have not got an opportunity.
My question is this - what are your experiences in moving to the "new" way - was it significantly better or worse or not any different? Has there been any project success rate improvement when using XP way of development or it is same as any well managed traditional projects?
This should not be a political question but just your experiences as you have moved to the new world or experienced at least once and back.
Thanks in advance
Before I ever heard of XP, I had a really good manager (Mike) at an early job I had. He was used to managing engineers and transitioned to managing software. After a few bad working experiences I looked back at his style versus typical project management I had before and after working with him.
Met with everyone at least once a day but gave us space to work
Used a whiteboard with two columns, people working and what they are working on anyone could look at that board and see if something had been done or was being done
Had everyone cross-train. I learned rcs and then cvs there and how to use make files
Ran productive "post mortum" when a task was completed. He would ask question like "would it have helped if X?" or "next time, can we try to..."
Kept everyone working on short tasks and managed our time so we always working on something but never had a ton of stuff piled up
Mike did everything on paper. He would keep notebooks and index cards with him. He insisted that anything asked of him by management be converted into manageable tasks, often written on note cards. He refused to have anyone work on anything that couldn't be clearly explained or had a clear objective. He would ask the VPs "what do you mean by faster?" "What kinds of metrics are the reports meant to show?" "Why should this be a priority?" He seemed to have near infinite patience in writing out what needed to be done and what was meant by "done"
When I first read the XP book, I was amazed by how much was familiar as "the way Mike worked"
It seems that Agile is just about implementing a set of best practices and evaluating how they work in your environment. When they don't work, change them. When they do work, stick to them.
I think the real problem with traditional project management is that more often than not, it doesn't really exist. I'm amazed by how many shops claim to use RUP or Code Complete or even Agile and don't actually have anything recognizable as project management. Sure, there are meetings. And people called project managers. But ask a simple question like "what has been done on project X" or "what is left to do on project Y" and no one has an answer. They have to dig though emails or point to a comically inaccurate MS project file.
If a person claimed to be on a diet and couldn't answer questions on what they were eating or how they were exercising; would you accept that they were really on a diet?
You take your old baggage with you when you go. Meaning that any project management bad practices you had before will still linger.
However, I will say that things improved greatly when we began to close the loop between us and the customer. Greater and more frequent feedback and prototyping with the customer means far fewer moments of the customer saying, "This is not what I wanted."
I've used (a slightly modified) Scrum before at work and here are my thoughts:
The daily meetings and burn-down provided motivation to make progress on tasks.
Our manager could talk to colleagues across the pond and show them "this is what we're working on this month."
You knew exactly what tasks you needed to get done, and had already estimated the time required to complete.
When priorities changed (new tasks, important bugs added), there was a well-defined process to handle adding them to the sprint or simply pushing them to the backlog.
These are lovely answers, but I think everyone's confusing project management with development/design methodologies.
I'm on a team that started Scrum a few months ago and we seem to be getting things done faster and with much less "waste" (projects that are scrapped). Just my observations from our small team (4 devs).
I've found the overall move to Agile/XP practices very positive, in many ways it front loads quality into the project/development process. You'll need buy-in from management and from the team to really see success...a few suggestions:
trial any change with a small project (2-3 people)
understand what areas your current team can most improve (quality? productivity? time-to-market?) and incorporate a few Agile/XP/Scrum (what ever) processes in...don't incorporate them all in at the same time and understand which processes address which issues prior to any change
if possible - track those areas you're looking to change and compare to another project running at the same time (the mere focus of improving something often is enough to improve it ,there's a study/term for this, but I forget what it is)
sometimes you'll see a dip in performance as you begin a new process, this is part of the learning curve
never assume that a good change today will remain a good change tomorrow, always review your project areas and be ready to change any process at any time
no change remains good forever, just like refactoring code, refactor your processes
ensure you get buy in from the team and management, you can't force success
I like some of the things the agile approaches do, but I also value some of the things traditional approaches do.
Both can work, as can a mixture of the two, which is what I find works best for my team now. I have implemented incremental development and it really helps us; iterative development is a little harder and we're still working on that. However, we have a variety of constituents, and many of our stakeholders (and PMs) prefer traditional artifacts and milestones. So we have to keep finding the right balance.
I have also found that even more important than the methodology is the people implementing it. Good people find a way to do good work and get things done regardless of the methodology, although certainly the methodology can have effects on efficiency (and morale :) ). Poorly aligned resources, however, can use the finest methodology and find ways to deliver poor results.
For developers, the great lessons of XP & Co. are shorter release cycles, and a more evolutionary approach - in the sense that change of requirements is accepted as a natural part of any project. Also, Customers suggest solutions, but designers and developers need to understand the problems.
Lessons for managers: Developers are not exchangable spec-to-code-converters, their individual strengths and weaknesses can make a productivity difference of 10 or more for a given topic. Knowledge and experience are the most valuable skills in your team, and developers can teach each oterh. Managers need not understand what developers do in order to enforce desired results.
XP & Co. are usually mixing solutions to these with the problem to make a company change. The heroic XP consultant singlehandledly saving a doomed, delayed and derailed project acts as large part as a buffer between development and management. But if you are looking at what to learn, you have to separate these aspects.
What I learnt in the recent years is that bugs aren't a personality fault, and that the sky doesn't fall when specs change. I've learnt that while design errors are still the most expensive to make, there isn't a single "perfect" design. Instead of getting one thing right we need to implement safeguards that of all the many details none goes wrong - and I've learnt to use the leeway between "right" and "not wrong" to our advantage.
My experience has been that I prefer to use Scrum over traditional approaches as it hasn't happened often that requirements could stay unchanged for the length of a project where usually projects seem to run at least 6 months to my current one that is over a year.
There can also be the case where there isn't any project management and everyone just scrambles to "make it work" so having some formal structure is good over nothing. There is something to the question of how well does the team come together and egos rarely appear as it isn't someone's code but rather the code of the team and there is a kind of group think where while each person has their view, no one tries to make everyone else see things that way.
At times it seems to me that some Scrum and Agile approaches I've used end up being like rapids instead of a big waterfall. What I mean is that the cycle of gather requirements - Analyse and Design - Implement - Test - Deploy and get updated requirements seems to be repeated over and over so that what comes out in the end would be extremely hard to state at the beginning of the project unless the project sponsor could give very detailed requirements that would never change.