Ideas on Enterprise Information Systems Development

This blog is devoted to ideas on Enterprise Information Systems (EIS) development. It focuses on Lean Thinking, Agile Methods, and Free/Open Source Software, as means of improving EIS development and evolution, under a more practical than academical view. You may find here a lot of "thinking aloud" material, sometimes without scientific treatment... don't worry, this is a blog!
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.

Thursday, December 9, 2010

Assorted Thoughts on Agilism X Traditionalism - Part V

Am I against UP, PMBoK, UML, and Certification?
(a post that summarizes some opinions of mine)

No, I am against the way these techniques were transformed by some people. I call it the Plague of 40-hours-courses: people hear about some "new" and fashionable technique, and rush to attend to some expensive one-week course on this technique. They don't try to learn from other sources, at most they buy some book to glance sometimes. Usually, they buy expensive tools that "make your process adherent to something-fashionable"*, believing that if they use the tool correctly, everything will work fine.

If you don't practice, if you don't try things, if you don't drink from different fountains, you won't have a nice process, because organizations differs from each other, and there isn't something like the Lapis Philosophorum, which will turn any development process into gold.

The typical managers' answer to the advice above is " we don't have time for experimentation", and then they buy packaged courses and tools, which won't work well many times, making managers go to the next phase of the project for process improvement, which is either blaming the team, either blaming the technique. Others start doing bad things, using the new technique to justify them.

Managers shouldn't waste time controlling small things, but studying better ways of making things self-controlled, on making their teams work more productively and with more quality, or, in other words, becoming the facilitator of good practices. Things like checking if everyone is filling their daily working time in some "project management" tool does not aggregates value to clients. In fact, doesn't aggregate value to you and your team. What all this has to do with the theme of this post? The answer is that if managers used their times to understand and adapt techniques to their process, instead of acting as controllers, they would use these techniques in better ways.

The way people transform good ideas into waste-generation machines is amazing! So, people transformed
(i) UP phases into waterfall cycle.
(ii) PMBoK into a heavy and expensive annotation effort.
(iii) Modeling into the main software development activity.
(iv) Certification into a reason for not evolving processes.

Regarding these techniques, I think that
(i) UP is a nice list of "things to worry about during product construction". But you don't have to use all of its workflows exactly how they are presented. UP is a framework, therefore, it exists to be adapted.
(ii) Similar to UP, PMBoK is a nice list of "things to worry about your process management", but you don't need to use all of its documents. PMBoK is a framework, therefore, it exists to be adapted.
(iii) Modeling is for understanding the domain area and also for communication. The users' demands are the focus, and users need running code, not models. Check out Martin Fowler's UML as Sketch principles.
(iv) Certification is a moment to review and document your practices, but you should never forget of continuous improvement. More important than saying to others that you work well is actually working well! IMHO, certification would be a process of checking the quality of products and of asking the clients about your service. Snapshots of the documents used in your process don't provide any real guarantee of quality in the long, or even the medium, term.

*In fact, worse than the Plague of 40-hours-courses is the Plague-of-Tools-That-Make-Your-Process-Adherent-to-Some-Fashionable-Technique. Some years ago I heard a happy colleague saying that "could finally understand object orientation", after attending a course on an UML case tool...


  1. In my opinion, software development is one complex engineering task, that demands adaptation of concepts and learning tools. As developers we need to learn about different domains in order to develop software that represents real values for different organizations. So our engineering is very distant of civil, mechanical, or many other engineerings where the objetct and the environment are more stable. Our tools and framework must be flexible and powerfull and that's why they are so complex. The full utilization of this tools is an pattern created by Ford, trying to obtain maximum value from machines and people woring 24/7 and imagining that quality is behind super utilization.

  2. I agree with your comments about the use of Project Management and Certification (CMMI), which I have already had experience in the past. IT companies sometimes impose certain standards about PMBoK and Certification and it results in low productivity and displeasing the client.

    It is very important to know how to use these tools that are very good, and the managers need to be flexible and must have good sense to practice them in order to have the best results.

  3. Yes, however, usually people think that being compliant to some standard means to implement everything in every situation. Besides that, the process is the means to obtain the product. Some managers have difficulty to understand this and follow on the "tail that weaves the dog" phenomenon - check the On Certification and Tribal Culture post.