Monthly Archives: August 2007

Organizational Intelligence

By | Published on

Organizational intelligence is the measure of an organization’s ability to comprehend and conclude knowledge relevant to its purpose. In simple terms it is the performance of a group or organization measured as a whole. For example, Basketball and Hockey require a high-degree of organizational intelligence in order for a team to win. The success of the team depends greatly on the team’s ability to work together, rather than based only on individual performance.

For software development, and most business organizations, the goal of an organization is to function at the highest levels of competency across all individuals. Unfortunately, a low organizational intelligence means that an organization is only as smart as the combined incompetence of all individuals. The net effect is that simple problems are harder for the organization to solve than they would be for a single individual.

Consider the following overly simplified skill summary:

In this situation, there are three developers and a single project manager. Of the three developers, one is a database developer, one an application developer and the other a WEB/UI developer. This represents a fairly standard cross-functional team, though greatly simplified.

In order to achieve the goal this group must perform at their combined strengths. This creates a positive emergent behavior where the group dynamic is able to achieve something that no one individual on the team could perform. This is a case of positive emergence and assumes a well-functioning team with a high degree of organizational intelligence:

On the other hand, the team could be functioning in an overly competitive or chaotic manner leading to a negative emergent behavior where the group dynamic is only as competent as the combined incompetence of all individuals:

This type of scenario is fairly common in software development and engineering. Concepts such as Analysis Paralysis, Design by Committee, and Feature Creep usually result in a low organization intelligence with a negative emergent behavior.

Emergent Behavior is the result of simple entities forming more complex behaviors as a collective. The complex behavior of the group is not a property of any single entity. Group/Organization behavior is often emergent, not the fault or credit of any one individual but the dynamic formed by the group itself.

Typically smaller teams like the one in the charts perform more on the positive side than the negative. However, as teams scale the challenges quickly become less about specific skill sets but instead more about understanding and exploiting the emergent behavior of the organization in order to achieve the desired business goals.

Consider the overly simplified version:

The individuals possess the correct skills necessary to achieve the goals of the organization and ideally will surpass those goals through a positive emergent behavior of team. On the other hand, the areas of incompetence are drastic enough that given a negative emergent behavior the team will surely fail despite individual efforts to the contrary.

Illusion of Stability

By | Published on

Sometimes we plant our feet firmly in hope for stability. Kids, mortgage, bills; the excuses are endless. Yet for all our static behavior life has a tendency to knock us right on our ass. If you’re alive and breathing, then there is no such thing as stability. Not only can your life change at any moment, it’s changing at every moment.

But what about all of the compromises? As stability becomes a value in life, where do we rank that with our other values? Everyone has a ranking of values. Some people will maintain honesty as a value even over friendship. Other people value friendship more and will gladly lie to preserve their friends favor. So what values are we willing to compromise for stability?

Maybe you’re a few months from vesting or just a couple of years from retiring? When do you stop rocking the boat and hope things settle down?

I hope the answer is never. The boat is always rocking whether you want it to or not. The water is guaranteed not to stay calm. Stability often appears as an imaginary value. The problem is not stability itself, but with the values that you compromised for something imaginary.

In my own life and in the lives of people around me, I’ve seen compromises that sacrifice integrity, competence, and honesty all for that illusive stability. I’ve watched good people do bad things, and observed my own bad behavior to make compromises in order to maintain a deceitful status quo. A lifetime of compromising your values and it’s no surprise where otherwise good people with well-intentioned values become bad people based on the ease with which they act out against their own principles.

I can’t speak of a perfect solution. It’s difficult if not impossible to just simply erase stability from our core values. The irony is, we want stability to protect ourselves and the people around us, but as we compromise in favor of stability we end up hurting ourselves and the people around us. My idea is to instead focus your life on the process and not the outcome.

We tend to focus on what we want and our minds fill with imaginary outcomes. Some people want kids and a house, and once they get them they want to preserve them, they want stability. I’ve seen people sacrifice happiness (which in my opinion should be the highest order value of them all) in search for stability. Try instead to focus on the process; on living in your home and raising your children rather than outcomes like kids, house, and bills. Or focus on living a good life rather than imagining a future retirement. Perhaps then we won’t compromise our values and our actions will reflect our good intentions.


Like waking from a slumber
I open my eyes and see clearly
The world around me
My place in it
The present
Where have I been?

Goodbye Qualcomm

By | Published on

It’s been just under two years and after a whirlwind of experience and excitement at Qualcomm I have decided to move on.

This was my first foray into the private sector and it was a blast! The academics had it completely wrong. I was warned that I’d be a cog in a machine. Not even close. The academic machine is a rusty axe compared to the shiny chainsaw of the corporate world. Each has its cogs. You know who you are.

There’s an old saying that originated from the Soviet Union: Initiative is Punishable (“Initsiativa Nakazuima”, thanks Katya!). I’ve learned in my career that this is true. Initiative is punishable, but as a friend of mine pointed out and looking at my own career I’d say that this same initiative has been rewarding.

Our lives, whether at a job or elsewhere, are filled with challenges. Sometimes we win, sometimes we don’t, but we should never lose focus of our ideals and our integrity. It is our ideals that inspire innovation. And it is integrity that keeps us on the right path. Often times we find ourselves so lost in details that we forget this larger context.

For anyone reading this far and finding any sense to this post: remember that we are defined not by our words but by our actions, and all too often the dissonance between our mouth and hands is the real source of our stress.

The Good, The Bad and the Ugly of Scrum

By | Published on

We all hear about and we all love it: the Rugby-inspired software development methodology known as Scrum. It’s fast becoming an industry buzz-word and causing many project managers to question their Gantt charts. For all the hype, what is the reality of Scrum?

Scrum is an agile-based software development methodology for project management. It is characterized by a prioritized product backlog that lists new features. Work is completed and delivered in time-boxed iterations known as sprints (e.g., two week iterations). Scrum teams are cross-functional and typically number 3-7 people each. Iterations begin with an iteration planning meeting and end with a retrospective to review what worked and what didn’t.

During a sprint each scrum team gathers for a daily stand up, which is a short meeting where each person describes what they did since the previous meeting, what they’re planning to do now, and any impediments. The team is self-organizing leveraging our instinctive behavior to work in small groups. The Scrum process is facilitated by a Scrum Master. That title is a bit of a misnomer since the Scrum Master carries no authority and is instead responsible for blocking any distracting influences that could disrupt the teams progress.

The principles of Scrum are well defined in the wikipedia article as well as in the book Agile Project Management with Scrum by Ken Schwaber. You can also shell out ten grand for an in-person experience with Ken. There is nothing like an expert talking about the work that you should be doing. As some of my friends and co-workers like to hear me say: Get back to work!

What’s so Good about Scrum?

Delivering working software. Working software is where Scrum really shines. It’s proving to be an excellent implementation of Agile Software Development with core values such as customer satisfaction and individual interaction.

There are four core values to the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

These are all valid principles that are easy to ignore and have proven to be hard learned lessons despite how obvious they may seem. Projects typically fail when they ignore these principles. Good documentation has never compensated for crap software. Try telling the upset customers that you gave them exactly what they contractually signed in the Service Level Agreement. The principles of the Agile Manifesto should be held as software engineering law.

Scrum provides a very effective methodology that ensures these principles through an empirical approach to software development that embraces and encourages change.

If it’s so great, what’s the Bad news?

No one likes to admit this, especially not Scrum advocates like myself, but Scrum fundamentally conflicts with traditional PMO. It’s an interesting round of cognitive dissonance to watch a PMI-certified project manager attempt to rationalize Scrum. There are of course several ways to deal effectively with this dissonance but understand: these are fundamental differences which are not philosophically compatible.

Scrum will go far in delivering working software, but what about managing roadmaps? Better yet, what about resource allocation and God-forbid budget forecasts that are needed before a project starts? We need money and people to start a project and we’d like to know roughly how much something will cost before we agree to invest. In a perfect world we would know these answers and we wouldn’t need Scrum. But Scrum exists out of necessity from the failures of so many software development projects and reminds us that the entire enterprise of software engineering is often times more like scientific discovery than building construction (which is where PMI originated, and rightfully so).

The Ugly

Scrum delivers working software in chaotic environments. At the same time Scrum is a symptom of a larger problem in software engineering such that many software projects cannot be managed like construction projects else they face increasing technical debt, unhappy customers, declining quality, going over budget, and missing deadlines.

Migrating to a Scrum methodology typically has an effect of providing early visibility to problems. The wisdom being that it’s better to know that you’re failing one or two months into a project rather than years. While this makes sense and this transparency is a very valuable aspect of Scrum the reality is very ugly.

Transparency to critical problems often times stems from the fundamental conflict of traditional PMO and Scrum. These are problems that are unfortunately outside of the realm of Scrum or software engineering. In this situation it is easy to attack the symptom (Scrum) than it is to address the underlying issue, which is unifying project management (roadmaps, budgets, resource allocation) with the software development.

Visibility? Be careful what you ask for! If a project is going to fail, maybe it’s better to let it fail naturally than to induce ulcers in the Scrum Masters and the development staff. Remember: a good Scrum Master will be a burned out Scrum Master in most environments.

This isn’t an easy problem to solve, but done wrong Scrum can create an emergent failure. Take the following anecdotal quote from Brad Wilson:
Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

On the other hand: Scrum, done right, has the potential for an emergent success given iterative and continuous improvement. A potential method for solving the real problem is to exploit the emergent behavior of a system.

Emergent behaviors are difficult to track, but analyze the existing software, processes, and development and determine whether or not they are evolving appropriately. A successful development process should continually improve the same way the code itself should continually improve. The process itself should be agile, responding to change to better produce working software.

Better yet, the individuals and interactions should be agile. It is the people that must respond to change.