Basically I have to choose a project methodology. The components are not big (we develop components mainly for SAP connecting), however the team is rather big , dislocated and and very unorganized. Besides how big is the team which other questions should be taken into consideration? Thank you

3

There are 3 answers

0
mmarschall On BEST ANSWER

I've made very good experiences with answering these questions first:

  • How does the team prioritize work? (I would recommend putting todos into a sequence building a backlog)
  • How does the team track what needs to be done? (I would recommend breaking things down step-by-step into User Stories and track them using a tool like PivotalTracker)
  • How can you make sure the team is self-organizing? (Let the team pull work from the backlog, run daily status meetings and a retrospective every couple of weeks)
  • How can you optimize how fast features get delivered in optimal quality? (This way of thinking should replace the idea of maximizing capacity utilization)
  • How can you make the work visible? (Visibility builds trust and momentum - you can start collecting metrics and putting up a screen showing all kinds of graphs)
0
Chris Walton On

One very useful question to assist in choosing any sort of method is "What projects can this not help me with?" It can be very difficult to obtain an answer; the usual way that supporters of a particular method respond is "of course method X can help you with any project." Thus they are saying either that all projects are the same, which is obviously not the case; or that they don't know what are the limitations of their method, and so will not be able to recognise when their method is not appropriate.

You say your teams are fairly unorganised. One of the best ways of introducing any new method is to provide tools - even very basic tools - that make it easier to follow the standards than not. An example of this was trying to improve the quality of development reports in a very large organisation - we provided a number of word processing templates, that made it easier to write a report using the templates (and hence the standards) than to write the report from scratch.

Personal note on my choice of language: I have worked with software development methods for many years, and to me "methodology" is the study and comparison of different methods. A particular way of, for example, managing a project, is a method, not a methodology.

0
Purplegoldfish On

I guess this really depends on a number of factors, for instance some contracts require you to use PRINCE project management which is rather complex.

If you dont have any external factors regarding the methodology you choose I would just do a bit of research and see which you think fits your team best.

I havent had chance to use Agile yet although I took a course on it and I liked what I heard, it seemed fairly straightforward which is a bonus.

One thing to remember though is you dont have to stick to one methodology if you find something isnt working for you then make changes.

Questions I would consider though would be the length of the project, Size of the team, Are the team each working on individual parts of the project or are there multiple people working on the same area, Time it will take to implement a methodology, Any costs involved?, Any training involved?