Hi!
I'm doing master thesis about defining software development methdod/process to my company. I'm very in the beginning in this but I have decided to concentrate on so called 'agile methods'.
But now I'm asking does someone knows good source material where is described implementation of some kind of agile method? How company can take the method in use? What problems occur etc.
-Robert-
www.ronin-intl.com
You will get some useful material on how a software development methodology is adopted (based on EUP)
However, what I suggest is to study the current process of your company first. There are operational, HR and other factors involved to adopt a new process (agile or otherwise).
A lot of people could give you insights into this kind of adoptions, however, from my side I could say, which ever methodology you adopt, you will have to custom fit and blend it in your organization.
Ironluca
Here are some resources to get you started:
http://www.agilealliance.com/home (Agile Alliance)
http://www.extremeprogramming.org/ (XP)
http://www.controlchaos.com/ (Scrum)
http://crystalmethodologies.org/ (Crystal)
http://www.eos.dk/jaooslides/session_ron_crocker_Grizzly.pdf (Grizzly)
http://www.featuredrivendevelopment.com/ (Feature Driven Development)
http://www.iturls.com/English/TechHotspot/TH_e.asp (Aspect oriented programming)
http://www.dsdm.org (DSDM)
Hopefully these will get you started.
Jonathan House
Yes I aware that I have to study our current enviroment and mode of action.
One thing that is sure is that actually we don't have any defined process to software development (that was one reason why i started this project). The development is more ad hoc style, each developer does his own way and the results are variable.
Do you think it's easier to adopt development process to this kind of "land", when there is no preceding defined process. I think, and I have discussed with the developers, that developers would be glad if somebody defines common process. Then it is clear for all what to do and when.
-Robert-
I would say that yes, it is easier to convert to a new methodology when you are not currently practicing one. It's the old "can't teach an old dog new tricks" scenario - if your team is experienced in another methodology it is that much harder to re-train yourself to a new one.
If you are planning on adapting an agile methodology I would suggest that you do it in stages. For instance, pick one or two of the common agile principle practices and incorporate them. Once you have worked with them for a while and have seen improvement, then incorporate a few more. It also would not hurt to find a mentor that can guide your team to the adoption of a methodology - you can avoid quite a bit of pain and confusion with a good mentor.
If you find that one of the practices that you are incorporating isn't working, take the time to find out why. There are many different reasons that a practice can fail - everything from the developers don't like it to the technology does not support it. Just remember that changing how your team works is usually a difficult process and can cause a lot of anxiety and frustration in your development team.
Jonathan House
Good tips all. One thing I have considered is how to convince other project managers and the company bosses?
E.g. once one of our project manager (not especially software oriented, although he itself thinks so) heard somewhere about iterative development and managing that kind of project. She complained that it brings too much overhead when you have to plan the the project several times (iterations) and have to do the project plan multiple times.
How to correct her misunderstanding?
Your statement is a clear indication of the fact that the manager in question doesn't really understand how Agile methodologies really work.
There are a couple of things you can try. First of all, point her to a few good case studies of teams that made the switch and the benefits they incurred. I'm just guessing here, but it seems like your best bet would be to find case studies heavier on numbers and "how we did it" type stories - to have greater impact on your manager.
Second, go looking for a local Agile support group. We have a strong one that meets monthly in Salt Lake City - as a matter of fact, Alistair Cockburn chairs the meeting (can't get much better than that). My impression is that there are more XP groups out there than generic Agile groups, but I'm sure you'll find something if you take a look.
Third, arrange for an experienced agile project manager to come in and speak with the team - have it centered around a "brown bag" type lunch. If you pitch it to management as a informal type of training session they might spring for the lunch.
Fourth, you can always hire me at my exorbitant hourly rate to come over and browbeat your manager until she concedes that there is no other methodology than Agile approaches. If you have multiple managers I offer volume discounts ;-)
Jonathan House
> I would suggest that you do it in stages. For instance,
> pick one or two of the common agile principle
> practices and incorporate them. Once you have worked
> with them for a while and have seen improvement, then
> incorporate a few more.
and.
> If you find that one of the practices that you are
> incorporating isn't working, take the time to find out
> why. There are many different reasons that a practice
> can fail - everything from the developers don't like
> it to the technology does not support it. Just
> remember that changing how your team works is usually
> a difficult process and can cause a lot of anxiety and
> frustration in your development team.
I would go further and suggest that a good way of addressing these two issues is to during any process re-enginnering is to first attempt to address the percieved main problem areas in the existing process, this makes gaining real adoption is much easier.
