1. One very important aspect of software methodology I am missing is how one should handle individual level of competence.

    This is something which is not specified in any methodology to my knowledge. You either practice something or you don’t. But what about the noobs and uneducated? Ignorance causes resistance, resistance causes friction, friction loses money. (And losing money leads to the dark side.)

    People need to be educated, but after spoon feeding a bunch of garble about a methodology you’re not there yet. Some people simply don’t care, they just want to code. Others would like to understand but the sheer volume of information is overwhelming. And then there are the happy campers who hear something and then just run with it, in the wrong direction that is.

    So how to handle this little problem? Quite often somekind of proces police is introduced. But you don’t learn a dog a new trick by beating it with a stick either. Any thoughts on that?

    Jeroen Leenarts

  2. Not that I have much experience in doing software projects. I’m still finishing school, but I one item to add to your list of things that can make a project successful.

    Having several small successes during a project can keep the motivation of teammembers high and can help finish a project sucessfully.

    I first noticed this during a project in which we set up the basics for a java based webportal for our school. Despite the fact that the project was short, we were having trouble keeping everyone motivated. Dividing up the project into several small parts helped to keep everyone motivated, as they had the feeling of success and the next success was within their grasp. Also when a release wasn’t very successful, they had a chance to be successful just around the corner.

    I think that projectmanagement is a lot of “Gezond boeren verstand” mixed with knowledge on how to increase chances of success.

    Willem Meints

  3. One of the things that is of vital importance is a member of the team who is responsible for the application of the chosen method. (In RUP it is called the Process Engineer) Coaching and reviewing plays an important part in getting Noobs started. But as long as there are developers who think that writing code is all you do, your project is toast. You will have to sanction them (lead them gently) in the right direction.

    Short term successes can be set by clearly defining the milestones or even the itteration targets in terms of functionality. Also the defining of tasks to be implemented (workitems) in terms of functionality will give a huge success boost when reached.


  4. Ah the “Process Engineer”, as I said these guys/girls are often the “process Police” I was talking about.

    Jeroen Leenarts

  5. Education and motivation is very important, and to me this means the “people quality” and “commitment” parts that can influence a projects success. Some methodologies actually have some basic practices for this. For instance, the process engineer in RUP, or pair programming in XP. Short term success is used heavily by Scrum for various purposes, as it relies on short sprints that produce working demo able software, divided in tasks that should be doable in a day.

    However, bridging the knowledge gap and keeping people motivated primarily requires a certain social culture which is supported by the organization. If everyone is on-board, then the practices may help you to get better faster. Without the right culture though, it’s just a gimmick without much lasting impact.

    Of course, methods cover more ground than I described in my single post. I tried however to pick some unique values that are kind of universal and just work if apply a method properly, regardless of culture, people quality or commitment issues. To some this may feel like “downplaying” the influence of a methodology a bit. I think it is interesting to separate where a method can really be a primary solution, and where you have to look at other aspects of your project. In my opinion, while methods often are seen/sold as a solution to all problems, it is more productive to say sometimes: no, my method is not _really_ going to solve this for me. In the case of quality for instance, I think it’s better to rely on a good coach (no method cop) and room in the planning to make education work, or bite the bullet and swap project members with people with more relevant skills. Let’s keep the discussion going. 🙂


Comments are closed.