3

I'm working in a little firm about 10 developpers, we are working a kind of agile way but knowledgeless and without formalism. I think be aware of what are agile method, what can they afford to us, may render more productive our products. However there is a lot of agile method, which could be the simplest to "learn"?

  • Rapid Application Development
  • Dynamic systems development method
  • Scrum
  • Feature Driven Development
  • Extreme programming
  • Adaptive software development
  • Test Driven Development
  • Crystal clear
Improve this question
4
  • ok I will move my issue, can you explain me why there still agile-project-management tag? Commented Nov 17, 2011 at 13:31
  • @ChristopheDebove: it's historical, programmers.se.com was created after this site. Commented Nov 17, 2011 at 15:06
  • This wires into all of them and I love to start teams with a framework and then open everything up to changing at a later time personally.... Dictatorial Democracy Commented Nov 17, 2011 at 18:21
  • You may also get more fruitful answers on pm.stackexchange.com. More specifically: pm.stackexchange.com/questions/2998/… Commented Nov 17, 2011 at 21:48

4 Answers 4

Reset to default
4

I think scrum is probably the most widely practiced methodology currently, probably because it doesn't prescribe the details of writing software, just how to manage your process. Then you cherry pick what makes sense for your team from the more programming-specific methodologies like XP. Scrum also contains a retrospective after every iteration, where you can talk about what you like and don't like about the process and make adjustments to make it fit your team better. Even the other scrum teams at our company do things somewhat differently than ours, even though we are all practicing "scrum" and started our first iterations very similar to each other.

Improve this answer
2
  • I fully endorse process tailoring and I can't think of why anyone would argue against it, but there is something to be aware of. Scrum purists (including at least one of the creators, although I don't remember which one) will argue that once you drop things mandated by Scrum, it's no longer Scrum and shouldn't be called Scrum. Tailoring is fine, as long as you call your process what it is. It kind of nitpicky, but something to be aware of, especially if you are looking to hire people who have experience with Scrum - some might call you out on it. Commented Nov 17, 2011 at 15:41
  • On the same line of thought, if you're to try Scrum out, I'd say that it's wise to do it strictly by the book until you have some significant experience with it. Start tailoring the process before you understand all the ins and outs of it, and you'll easily fall back into old habits. Commented May 14, 2012 at 7:17
2

I would suggest that you don't use get stuck to a particular methodology. Instead, pick and choose practices that help you and add them into your existing work.

I would look at

  • Just explore web sites, see if there is a practice that might help you, try it out
  • Technical practices like unit testing, automated tests, continuous integration are v. useful. Investigate these.
  • Regularly (about twice a month) sit down and see what you did well and where you can improve
  • Work feature by feature. What I mean is, implement one feature, test it, deploy it. Then start with the next feature. Dont work on many features at once
  • Try to spread around knowledge. Let different people work on different parts of the application. Don't have a situation where only certain people always work on the same components everytime
  • Focus on feedback. Try to have access to a customer or user or domain expert who can look at what you are doing and give you feedback often
Improve this answer
3
  • -1 It is rarely the programmers who actually get to make these decisions. Advising this to management who will look at those aspects that save money and reject those parts that increase costs to implement is a recipe for disaster for the AD Group. Commented Nov 17, 2011 at 19:17
  • 1
    I agree with you for a big company. In a big company transition, I do recommend that you choose a particular methodology. The original poster says that its a small firm with 10 developers in all. For such a context, developers usually have more freedom and my preferred approach is for the team to pick and choose. Commented Nov 18, 2011 at 4:16
  • 1
    In my company Developpers are managers, because the real manager (the boss), doesn't have technical background. Commented Nov 18, 2011 at 8:31
0

Agile should be a set of tools that you can use to make better software not a set of rules that must be followed. Pick what works for your team. Do trial periods to see what works and what does not. Keep reviewing those and you will be doing Agile Agile project management...

Improve this answer
0

See "A Guide to Selecting Software Development Methodologies" by Hamid Faridani, available somewhere out there in the www. (Google's giving me only very long ugly URLs at the moment.)

The main choice is "heavy" or "light" and depends on: team size, expected rate of changes to the system, the primary goal of the project, how requirements are managed, the relationship with the customer (i.e. is a formal business contract involved), and the customer's business culture.

The paper provides a good summary of the main ideas of the biggest methodologies, suitable for someone new to that world, yet not watered down to still be of useful guidance to experienced development teams. (So some say; I'm new to that whole area.)

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.