Thursday, January 14, 2016

Software development teams organization laws

Today, I would like to dedicate my post to the management side of the software development process, and especially to the team organization laws.
I was inspired by a post on an IT specialized website which I follow. I was impressed about the usefullness of these laws and the concise flow of the presentation.
At the end of the artile, the source was mentioned, a book in progress by Alan Kelly, entitled: "Xanpan book 2: The means of production".
I find the way these laws are presented very nice and tidy, so I thought that sharing this, or at least backing this up as a later "Must read" for myself is a very good idea.

Instead of copying what is mentioned in the article, or in the book (which you can read online for free, at least at the time of this post creation), I thought it would be nice to have it in a format like this:
  1. Law name
  2. Statement
  3. Source (wikipedia)
  4. Optional short explanation/example
So, you can find below a very concise presentation of these laws.
Also, if you want more info on the topic, feel free to access links below the post.

Basic Laws of constructing development teams:

1. Brooks'law:claim about software project management according to which "adding manpower to a late software project makes it later".

2. Conway's law: organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

3. Dunbar's number: is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships (150 max).
Proponents assert that numbers larger than this generally require more restrictive rules, laws, and enforced norms to maintain a stable, cohesive group.

4. Miller's law, 7 +- 2: the number of objects an average human can hold in working memory is 7 ± 2.
Practical example: It is recommended that a Scrum team match the number 7+-2. Teams with more than 9 people create too many coordination problems.
This rule does not include Scrum master and Product Owner, except if they are not included in the sprint to reduce delay.

5. Parkinson's law: the work expands so as to fill the time available for its completion.
Practical example: a sufficiently large bureaucracy will generate enough internal work to keep itself 'busy' and so justify its continued existence without commensurate output.

6. Hofstadter's law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Practical example: difficulty of accurately estimating the time it will take to complete tasks of substantial complexity. You might estimate more than you think, and even this might not be enough

7. Kelly's first law of Project Complexity: Project scope will always increase in proportion to resources
Concise example: Putting more people to work will have an inverse effect on the results and more probably not fulfill expectations.

8. Kelly's second law of Project Complexity: Inside every large project there is a small one struggling to get out
Explanation: If you have a project with lots of resources, the original project will get lost inside of it.

9. Gall's law: Complex working system is always created from simple working systems. A complex system built from scratch will never work.
Explanation: Start the project small, and grow up gradually.

Interesting fact: If you by mistake (as I did) search instead of Gall's law, Hall's law, you will, very likely end up reading this Wikipedia article.
Strange as it might seem, but one might find a tight connection between Gall's law and what this inventor John Hall did, not counting the coincidence in First Name!