5 comments
Various 
Iterative/agile software development methods like IBM Rational Unified Process, XP and Scrum are very popular lately. To some, they are like a silver bullet, the 100% fail safe way to develop software. To others, software development methods are just fancy names for common sense stuff, and therefore a waste of time and money.
I don't think doing agile will guarantee success by itself. Inversely I don't think "our project failed because we did RUP" is a good argument either. Any software development method only deals with the parts of software development that are generic enough to capture in global guidelines and rules. That still leaves a huge area where no software development method will help you. Even the parts that are covered by a method can still go wrong. A method only gives some basic advice how to reach the right goals without getting burned by the wrong risks. However, no activity diagram in the world will tell you what the customer really wants or how a complicated algorithm is best implemented without scalability issues. The real work still needs to be done by the people involved in the project. Individual quality of the members and the team as a whole, the commitment of all stakeholders and realistic expectations ultimately decide whether the project succeeds.
However, I do think that a project team can use a development method as an effective tool. To me, a method provides the following important benefits:
- A common vocabulary: a method gives names to all kinds of things in a software development process. This makes it much easier to learn about certain topics, get started in an organisation and communicate about the process.
- Structuring work and responsibilities: knowing when who needs to do what, who needs to make certain decisions at what point in the project. A method helps you cover the important basics with minimal effort, in a way that is compatible with the overall intentions of the method.
- Risk and change detection: all methods provide some check points, test strategies, evaluation activities and registration policies to detect risks and changes to the project goals. Do not confuse "detection" with "management" though. Simply keeping a list of risks and changes is not enough.
- How to handle change: a central theme of every software development method is how to deal with change. The method takes a stand and tunes the rest of the method to match this strategy. In the past, most methods perceived change as a project risk because it could change project planning and -budgets and this would somehow cause chaos. Change was supposed to be prevented by making as many decisions up front as possible. Later on, people could use these decisions to deflect changes or at least point fingers at people to be "responsible for the change". In this context, change implied an error in a previous decision.
However, modern methods realize that change is something you should embrace instead of prevent. If there is a need for change, that means that either the problem is changed or better understood, or the solution can be improved. Not changing at all means holding on to the past, and doing nothing with the knowledge of today. Current methods like to delay decisions, be more flexible of when to do certain activities and use several safety nets (like automated testing and regular releases) when implementing a change.
Picking a method that matches your culture and needs is important. If you are not ready to embrace change, doing all-the-way XP may not be a good idea. Being in RUP projects myself mostly, I also get great ideas from other methods. Picking and choosing from methods and keeping a good balance is the game here. They even have a word for that in the RUP vocabulary! 🙂
5 comments
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
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
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.
ernow
Ah the “Process Engineer”, as I said these guys/girls are often the “process Police” I was talking about.
Jeroen Leenarts
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. 🙂
peterhe