You have to sell "agile" to management, they are receptive but have zero knowledge or understanding of modern application development techniques. Which ONE book do you give them as a set text?
It must cover a few different methodologies (XP, Scrum etc) and give a flavour of the benefits AND problems. It must be understandable to people who don't read code at all.
It must be short... so it actually gets read!
Is there one that fits?
I should think a software development book will be wasted on most managers, who won't have the time or inclination to read through it.
Rather, why not provide a concise argument for why you believe you should adopt agile development methods?
If you want to convince them on the usefulness of agile methodologies, you presumably already know why - summarise it for them.
http://www.objectmentor.com/omSolutions/agile_why.html looks like a starting point. Google something like "why agile" for more.
When you summarize it, a big part of your summary should revolve around why and how agile will save the company money short term and long term. At the end of the day, that is what will matter most in their choice to adopt... Especially if the company is funded or public.
Let them know it gives them more control over the destiny of the products.
Also tell them it raises quality whilst reducing costs. That should get their attention!
I don't use the name 'Agile' rather implement only the practices at my work place. Therefore people do not resist, and easy to spread when they see the benefits. Managers are also happy when the product is delivered on time. You don't need to convince managers but let them see the outcomes once you implement the things like pair programming, release often release early etc.
It is hard to change the religion but always easy to alter the day to day practices.
Good Luck
I agree with bigpresh; managers have no time to read.
[Joseph Juran] [http://en.wikipedia.org/wiki/Joseph_M._Juran] found that the only way to get top management to pay attention to quality, was to speak their language, which was dollar$.
Convince them with examples of what can be achieved through implementing agile methodologies; early returns, customer requirement misunderstandings, etc. Choose the methodology you prefer and pitch that one. Or deflect them from a "yes/no" choice with a "do you want or Scrum or Extreme?" :-)
OP here, something crazy has happened with my openid login!
In this case the management is enthused by "Agile" and have made it a requirement for certain externaly developed projects. However they don't understand what it is (and it seems the company has been economical with the truth over their internal methods) so they are having staged releases (2 a year!) and they seem to have some user stories, but the close contact between customer and developer is not there.
I am not so expert that I feel I could make a realistic presentation of the pros and cons, and no one internaly is currently doing anything remotely agile. I am a fresh faced youngling (no webcams here right?!) so will have to start small with the team I am currently in, but it really sounds like there is management interest and for unrelated reasons I currently have the ear of some of the project managers that exist at much higher level than me.
I tried to keep the question general but I feel that my specific case may be a bit unusual :D
Thanks for your thoughts!
I can't help you with books, but I've had a few experiences with 'agile' which I'll attempt to sum up.
My understanding of 'core' of agile is this:
There are a ton of other processes/things you can add around the edges, like XP, scrum, or whatever, but essentially they're all just flavouring for the main course.
In my experience, this works very well when you have a specific customer who you can communicate with regularly. The ideal situation is as a contract developer team, working on a specific piece of software for a third party. Unsurprisingly, this is the situation that Kent Beck and co were in when they came up with the agile methodology.
However, a lot of software development doesn't actually work like this.
If you're a software shop developing something new that you can sell, you don't have any 'customers' that you can go to for direction. I've seen some attempts to rectify this by 'pretending' to have clients using feedback groups/business analysts etc, but having been on a team that tried this, it doesn't work.
If you're working on in-house software, for example developing a CMS for your company to use, you often don't have any clear cut point of contact. You will instead have 50 different managers and potential users, all with their own agendas and ideas. Your product gets 'steered' in 50 different directions at once.
In saying that though, there are a lot of good ideas that come out of agile. IMHO the most important one you can have is that your main codebase should always work.
Even if you don't have any customers that you have to present a working product to every 2 weeks, operating under the assumption that you might have to release every 2 weeks causes you to treat your code differently (for the better).
Also, a lot of the 'practices' that came out of agile are great, for example continuous builds, unit testing, etc, and are fast becoming things that everyone should be doing regardless of what religion methodology they subscribe to :-)
The way that is working for me is to simply run the project with agile (in my case User Stories). Its easier to get forgiveness than permission, if you have the freedom to do so. Let them see the benefits for themselves as you transparently run the project.
They will probably eat up the predictability of the release burndowns, and your customers will love the transparency as well; and management will see that.
Aside from that, address their questions/concerns as they come up. The Mike Cohn book referenced above is the one book I would use.
HTH, Steve
The practices our company feels are essential to Agile are these:
If you're interested in reading more, you can check out what the CEO of our company has to say on the matter here. We use all four of those practices (and more) in our development work, and it enables us to match or exceed the productivity and quality of teams double or triple our size.
If you already have buy-in from project managers (and they actually have time to read a book), recommend Agile Project Management to them. The author (Jim Highsmith) created the Adaptive Software Development methodology, so he's a well-recognized authority in the area.
Automated unit testing is the practice you can adopt right away that will help you and your development team. If you're a .NET or Java developer, I recommend the Pragmatic Unit Testing books (C# with NUnit, Java with JUnit). Your code quality will improve.
Who in your organisation is responsible (accountable) for the way software gets produced?
In my experience, this key responsibility is often owned by no-one, or (rarely) by the developers themselves, more or less collectively.
A little reflection might suggest that:
a) If no-one owns the issue, it's unlikely to get resolved
b) If someone does own the issue, they should (must?) have the skills and experience to understand the value of e.g. Agile and not need educating.
c) If that someone doesn't understand already, they're so the wrong person for the job - which speaks volumes to the competence of those who appointed him/her. In which case I'd advise you to polish the old resume and start looking for somewhere with competent senior management.