Assorted Thoughts on Agilism X Traditionalism - Part II

Back to Basics

Management has three basic functions: Planning, Execution, and Control. We can summarize the basic differences between traditional methods and agilism/lean in a table:

Philosophy	Planning	Execution	Control
Traditional	-Based on effort metrics to plan the whole project -Change is a “risk”	-Design = models -Try to automate programming -Centralized decision-making -Quality a posteriori, by annotation, and responsibility of a specific team	-Centralized -Try to be static (follow the original plan)
Agile/Lean	-Based on collective evaluation and on measuring the current development velocity -Plan for the next period -Embrace changes	-Design = code -Automate repetitive tasks -Decentralized decision-making -Quality a priori, automated, responsibility of producers	-Decentralized -Try to be dynamic (follow the demand)

In my opinion, the difference is basically one: Agile and Lean seeks to be dynamic, Traditional seeks to be static.

Assorted Thoughts on Agilism X Traditionalism - Part I

Some days ago I took part on a debate on Agilism X Traditionalism for Software Quality Assurance. Firstly I accepted to take part of it after its organizers changed the original name: "Agilism X Software Quality", as if Agilism were against Quality! Yes, there's still people that thinks that Agilism means non-organized, low-quality development, simply because agilists don't like to take a lot of notes or of using a lot of models. It reminds me of the early days of Free/Open Source, when most people that were against it never took part of a FOSS project, or even "touched" any open source software.

I read somewhere that Agilism (like Lean Thinking) means a change in the mindset. That's why, IMHO, that many people cannot understand how Agilism works. The bureaucratic mindset cannot understand how a technique that doesn't use a lot of annotations, long meetings, change management boards, hierarchical planning etc can work.

That's the same mindset found on USA's automobile industry in the 60's and 70's that was defeated by Japanese car builders. USA industry couldn't understand how a plant controlled by paper cards could work better than the enormous management structure they had, which was matured on top of decades of experience in building car - after all, they had Ford!

But the Japanese did.

And they still do, in spite of the current Toyota's quality crisis, its followers still reign in the automobilistic industry. I see people from the traditional methods in software industry with the same arguments:

-Agile doesn't scale = JIT doesn't scale.
-You need to plan in detail beforehand* = JIT has no planning tools.
-You need to take notes of everything you do otherwise you will loose control = for JIT taking notes is considered waste most of times, do things in a way you don't need to take notes.
-How can quality be controlled by developers, instead of a separate group = how can workers control quality, instead of Quality Control Department.
-etc

*(although detailed and accurate plans for software development are unfeasible in real word)

The truth is that things like automated testing, continuous integration, refactoring, and all other modern development techniques were born in the Agile cradle. These are Product related tools. Traditionalists still play with Process related tools, repeating the "if the process is good the product will be good" mantra. Yes, we need a good process, sure, however, you must try to avoid become mesmerized by the beauty of complex project management processes. Instead of putting a lot of people to take notes of a lot of stuff and correct your planning all the time, try to avoid problems, instead of trying to correct them. The focus must be on the product, therefore, product related tools will bring much value to your production chain than process related tools.

I believe that the only really scientific way of producing software is through Formal Methods (FM), because it represents the use of Mathematical principles for building software. If someone can use the term Software Engineering, are the "FM guys". The problem with FM is that they are still quite hard to understand and apply, and there are only a few people really capable of using them to produce software. While FM doesn't produce things like the tables that engineers use to simplify their calculations, FM won't reach the mainstream. FM methods are still dependent on developing "ad-hoc" mathematical models, and the ordinary developer doesn't have the skills for that - like the ordinary engineer, who doesn't develop mathematical models, instead, make use of them. Maybe when FM become usable by the ordinary developer we will be able to (really) do Software Engineering.

Therefore, we must, at least, be the closest to FM we can. Now, tell me what's more formal:
-Running code.
-Drawing models and using manual annotations to connect them to code*?

*(code generation is mostly limited to skeletons, someone will write algorithms anyway, therefore you will need to connect things by hand in the end).

You must agree with me that running code is much more formal than models and annotations, simply because the first is the thing of what software is done. So, please don't tell me that MDD is "more scientific than Agile because has the same principles of the other Engineering disciplines"... Running code means a functional machine, and that's the basic principle of... Engineering!

ps.: Like in the (hard) industry, Agilism automates repetitive tasks, such as testing and building, and this automation provides safer software verification. The other "end", Validation, is provided by BDD.

Effort Metrics Sophisma - Part IV

This a summarization and translation to English of a presentation prepared by me and an associated researcher in 2008. It was used to support our arguments against detailed one-year plans, a demand from the management of a big and interesting project we've been taking part since 2006.


So, what's the point?
The point is that the starting point is wrong! When people from the software development area sought for references in planning in the industry they thought it was obvious to check the techniques used by the custom production industry - where each product represents a different production project, and therefore, design is done product by product - not from the repetitive production industry, after all, software development is custom production, instead of reproduction of the same design in large quantities.

However, the reality is not that simple. While custom production runs under a low uncertainty environment (given that the product design was done beforehand), repetitive production usually runs under uncertainty - demand uncertainty.

Demand uncertainty is what happens to software. I not saying uncertainty in quantity, but uncertainty in building effort. Therefore, although we are talking here about a custom product, the techniques that apply to its production planning activities are the ones related to repetitive production.

In my opinion, those related to Lean Thinking... I am going to talk about this in future posts, now let's go to our third and last logical chaining.

Third Logical Chaining
From the second chaining:
Knowledge based production AND intangible good → there is no physical metrics
Non physical metrics → inaccurate estimates
We have:
Inaccurate estimates  → high uncertainty in the production process
AND
Custom Production → low uncertainty in the production process is expected
Then:
Although software development is custom production, it is not reasonable to use industry's custom production planning methods because they expect low uncertainty in the production process, but what we have is high uncertainty !!!


Now that I have shown, with some formality, that the current effort metrics don't work for software, I feel more comfortable to go forward and explain how to use Agile and Lean Thinking methods for software development planning.

Effort Metrics Sophisma - Part III

This a summarization and translation to English of a presentation prepared by me and an associated researcher in 2008. It was used to support our arguments against detailed one-year plans, a demand from the management of a big and interesting project we've been taking part since 2006.


The (Tough) Software Reality
Unfortunately, software is an intangible good, produced by knowledge workers. An intangible product means that it is not possible to measure its physical features, such as weight or diameter. Production based on knowledge is also hard to measure, because it isn't repetitive: there isn't something like the industry's "medium operation leadtime". Moreover, software development is highly dependent of people*, with all their specificities, problems, way of thinking etc.


(*If MDD were really able to drastically reduce the need for programming, organizations would no longer be hiring lots of programmers ...)


In other words, uncertainty in software development comes from:
- Non-repetitive and creativity-based work.
- Constant changes in technology.
- Some tasks considered as simple behave as complex.
- Frequent changes in requirements.
- Necessity to learn about the domain area during the development
(the above arguments are also valid for defending iterative & incremental cycles...)

Second Logical Chaining
Software → intangible good, non-physical
Software → knowledge based production, knowledge is a non-physical resource
Knowledge based production AND intangible good → there is no physical metrics (by definition)
Non physical metrics → inaccurate estimates
From the first chaining:
Detailed planning needs → detailed estimates
However
Software → inaccurate estimates
Inaccurate estimates → non detailed estimates
Then
Non detailed estimates → Non detailed planning

In other words, it is not feasible to produce detailed planning for software, even when using waterfall cycles !!!!!

The central point for reaching this sad conclusion is
Non physical metrics → inaccurate estimates

I leave this hook here so that people can try to dismantle our arguments: if you prove that you can have accurate estimates without having physical metrics, the argument here is broken.

More Conclusions
Detailed planning works in the hard industry, however some people try to transplant it to the software development industry in carelessly ways. Many organizations insist in this broken model, bringing high costs to the control and (re)planning functions, and in the end the goal is not to deliver a good quality product ontime anymore, but to create a false notion of control and of showing that managers are able of "thinking ahead" (although this "ahead" is unknown in the real word...).

For business people, not being able to create a detailed plan for months ahead is something like signing up a "proof of incompetency", many prefer to create plans that need strict control and even so, their baselines change all the time. At this point, the tail starts to wag the dog...

Effort Metrics Sophisma - Part II

This a summarization and translation to English of a presentation prepared by me and an associated researcher in 2008. It was used to support our arguments against detailed one-year plans, a demand from the management of a big and interesting project we've been taking part since 2006.


Interruption


I will interrupt a bit this series because I have just bumped into an "old" article on software metrics, about which I would like to comment briefly: Jones, C. Software Metrics: Good, Bad and Missing, Computer, vol. 27, no. 9, pp. 98-100, Sept. 1994.
Its abstract says
"

The software industry is an embarrassment when it comes to measurement and metrics. Many software managers and practitioners, including tenured academics in software engineering and computer science, seem to know little or nothing about these topics. Many of the measurements found in the software literature are not used with enough precision to replicate the author's findings-a canon of scientific writing in other fields. Several of the most widely used software metrics have been proved unworkable, yet they continue to show up in books, encyclopedias, and refereed journals.
"

Although it was published 16 years ago, I think the problems listed on this paper are still valid, and the paragraph above manifests my opinion on the use of metrics for planning in software: they only work under certain conditions and may have worked for a given sample of projects, but may not work for my project. In my humble opinion, the current metrics don't present a sufficient level of determinism so that we can  use them seriously for planning.

As I said in this series' first post, if I produce a brick here in Brazil, it will present the same size and weight in China, for instance. If I use the correct Engineering units and calculations, someone will reproduce "my experiment" of using these bricks anywhere in the Globe*. But the same doesn't occur with software requirements and thus with source code. I can send the same requirements for different people and they will implement them using different languages, paradigms, algorithms...

*(before someone say that bricks done in Brazil can present different plastic behavior in other regions of the Globe, I say that Materials Science has already developed methods to deal with this, while Software "Engineering" is still far away from doing the same for software.)

It is amazing how people use those constants found in some metrics (such as the one found in Use Case Points, which still gives 47,000 hits in Google...) without thinking that they maybe be not applicable to their specific project!

Therefore, if "So long as these invalid metrics are used carelessly, there can be no true software engineering, only a kind of amateurish craft that uses rough approximations instead of precise measurement.", I prefer to use experience and short iterations for planning.

ps. 1: the cited paper defends the use of Function Points, which I think is not applicable to Iterative & Incremental cycles.

ps. 2: I will repost a previous remark on UCP: Tell me how can you use it in an (really) Iterative & Incremental project (remember that real I&I cycles only details Use Cases when needed, so how are you going to count the number of steps for every use case and then get a "precise" effort estimation?). In spite of this, many teachers still teach UCP and I&I cycles in the same package...