It started from a tweet from @andreachiou I went down the memory lane, to the time I first heard of a guy named Gerald M. Weinberg from the book "Are your Lights On?". Up until that point, I was a rabid "Solution Seeker", jumping at every opportunity to propose solutions to problems. After that book, I was changed. I realized that it is more important to actually solve the root problem than to propose solutions. I became a "Problem Solver", who started to treat the illness instead of treating the symptoms.

And then, "Secrets of Consulting" happened.

That book opened a whole new world to me. The Orange Juice Rule, Rudy's Rutabaga Rule, The three laws of consulting, all of them simple principles with catchy names so I would never forget them. I still remember from that book the most  valuable lesson about "leading" people: "You can make buffaloes go anywhere, as long as they want to go there". Even the "bibliography" section is worth reading (and the books listed, useful). My toolbox grew, my opinion on some things changed, and overall I grew professionally.

Shortly after I bought the series that has brought more satisfaction and "stress" to my life than any other book: the "Quality Software Management" series. With them I started to understand how systems work (specially people systems), but most importantly I discover what congruency is, and what it is important to be congruent. It sank on me that we are all different, and why, and how understanding those differences make us better persons. It taught me to stop optimizing locally, and to look at the big picture for the long term benefit. It was my first look at the work of Virginia Satir.

"More Secrets of Consulting" gave me some useful tools to understand me, understand others and increase Self-esteem. Tools that I'm still learning how to use, a process I think will never end. Then "Psycology of a Computer Programmer" helped me understand why we are the way we are, and why it is difficult for other people to work with us. "Becoming a Technical Leader" gave me insights and advice on how to become one.

"Rethinking System Analysis and Design" taught me that most of the time, technology is neither the problem or the answer, and no "system" exist in isolation from the rest of the organization and their people, that there were good reasons at the time to do the things the way they did and that we technologist should not refuse to learn the "business" side of things.

"Weinberg on Writting: The Fieldstone method" changed both the way I write and the way I read. I joke sometimes that now I always see "stones" everywhere.

I discovered his fiction work and it appealed to the geek side of me. I really enjoyed them all, being the AREMAC Project, Freshman Murder and First Stringers my favorites.

The climax of my journey was the AYE conference of 2011 when I got to meet the man, among other authors that I deeply respect and admire (Johanna Rothman, Don Gray and Esther Derby). Words are not enough to describe the learning experience at that conference. I was a bit sad when I heard that AYE 2012 was the last one.

I revisit his book from time to time, discovering new things and rediscovering old things on each read. I talk about them all the time. The truth is that if you have know me for more than a year, chances are that I mentioned Jerry Weinberg to you at least once.

If I had to summarize the learnings in my journey with Jerry Weinberg, I just couldn't. At the very core  of what Jerry have taught me all these years are things that I already knew. I was changed as a person anyway, not because I learned things like "to help others you must help yourself first" but because I learned tools (like the Rutabaga Rule, the concept of congruence, the mirror and telescope) that helped me help me, then learned tools to understand others, and tools to help them if they want. It has been a slow and long process, but somehow satisfying.

I'm sure the journey is far from over. I'm yet to read "Perfect Software" and "Experiential Learning", and he keeps producing knowledge in his blog and tweets.

I you want to start your own journey with Jerry, head to his site, browse his books and pick the one that appeals you most. I'm sure you won't regret it.

Story Points have been one of the favorite method of estimation in the Agile circles (even if there is a group that ditched them altogether in favor of micro-sizing or continuous flow). But somehow they are a concept that is difficult to grasp to some, specially those entrenched in the Gantt field. The truth is that planning with Story Points is no much different than planning in hours, if we were planning properly (ie, using ranges or estimates, adding buffers to the critical chain and at the end of the proyect, etc,etc,etc).
Story Points provide a nice abstraction over hours/days, because it takes into account several things:
  • Estimates, at the time the Story Points are decided, may have a margin of error of as much as 100% (well, actually the margin would be +/- 50%)*. That's why we say that all 3 point story are roughly the same, even of one takes 1 day and other take 2 days. If one 3 point story takes1 day and another take 5 days then something went wrong, either in the estimation or in the execution.
  • When estimating in hours, a buffer needs to be put at the end of the plan just in case. By estimating in Story Points, the buffer is created when setting the initial Velocity of the team, and then adjusted on each iteration. 
  • Speed of team members are different. A 3 points story can be implemented in 1 day or 2 days depending on the people involved.

A 3 person team saying "we can deliver 12 story points per 2 week iteration", is the same as if they were saying "we can deliver these features that are estimated for a total of 150 hours work in 80 hours of duration, leaving 90 hours of buffer in case that the estimates are wrong or some problem comes along the way".

At the end, estimating in Story Points and estimating in hours has exactly the same basis: Both depends on Gut Feeling. But it is easier to sell Velocity than to sell buffers and estimates with confidence range. And it is a lot easier to think in the size of the task ("hmm, this may involve changing 3 modules, but the change is simple") than to think in the time to execute it ("hmm, this may take about a week").

This seemingly inocent question on twitter got me thinking a lot. 'Conventional Wisdom' and 'Common Sense' are often quoted to reject a novel idea, because we all know they cannot be wrong, right?

'Conventional Wisdom' is built the same way as traditions: over time, as a recollection of people experiences. And the same as traditions, they outlive their originator until nobody that quotes it knows the why's anymore. And that is the problem: conventional wisdom used to be true for someone, but some things are lost and it failed to evolve with time.

For example, it used to be Conventional Wisdom that if someone started coughing blood, dead would come pretty soon. Today, Conventional Wisdom says to bring the person to the hospital and will be recovered in no time ( or so we hope).

Another more radical example: 20 years ago, Conventional Wisdom said that cancer was a death sentence. Today, thanksfuly that is not true anymore.

Outside the realm of medicine, after the industrial revolution it was Conventional Wisdom that a worker should be busy 100% of the time. This belief have carried over the modern times. It used to make sense at the time for some factories, because demand was greather that the production capacity. It ceased to make sense as soon as the production capacity grew, surpacing the demand. But the Conventional Wisdom haven't catched up with modern times.

Does this mean that we should disregard 'Conventional Wisdom' as always wrong? I don't think so. We should understand the why's behind it, we may even learn something that may help us later on. And, who knows, it may even be right.

A here you have the tweets that inspired this post:

(with thanks to@YvesHanoulle and @tobi for the though provoking tweet)

A case of Blog Spam

Vote 0 Votes
This blog has been recently the target of a blog-spam attack. I'm shutting down the comments for all posts until further notice.

UPDATE: Futher notice :) Blog-spam attack contained, I'm reopening the comments again.

As I said somewhere else in this site, I'm passionate when it comes to programming, seeing it as a craft to be perfected. It is no surprise, then, that I became a confessed Agilist.

Something happened today that made me think about what I think is the meaning to be Agile. The quick answer would be "To value the Agile Manifesto", but somehow I felt that there is more to Agile than that. This is the end result of my musings

Johanna Rothman, in in her product development blog talks about when a spec should freeze. She basically said "specs never freeze, people communicate about what they want all the time".

What caught my eye was one commenter that said "There is always a point at which the spec must freeze; otherwise, either quality will suffer in some way, or the wrong functionality may not be delivered". That's kind of true, but the problem is not with the lack of spec freeze.