Will Crew or Military Models(for team formation) work in Software Development Projects?

Dave Snowden in his address on Social Computing & KM during the KM India summit brought about a point on how current organizational structures are not suited for creating social networks and hinder performance. Dave explained this with the Matrix Organizational Structure where people have multiple reporting relationships and no one is sure which way their loyalties should be.

Dave talked about the “Crew or Military Model” of team formation which he termed as more adaptive in nature based on the concepts of  “Role” & “Expectation of role”. He explained this with an example of how teams are formed in airlines or ships. People who may or may not have worked before come together to form a team and work as a team based on an understanding of what each persons role is and what to expect from that role.

In the IT industry this model, in intent, is a model that most software development organizations ‘aspire’ to implement while creating teams for developing software. I believe that in theory this is a good concept but there are several questions that need to answered and various soft aspects thought.

• “Crew” model would work for teams where the tasks are repeatable, tasks which have little room for variation and have to be done “the same as before way” on time. Tasks which have the procedures defined and the job of the person doing is to just follow the procedures and do it.   For example;  airline crew. pilot, co-pilot, air hostess, stewards, checkin counter assistants. The kind of tasks involved are routine, repeatable, well documented, and need to be performed with precision every time.

• In the software industry, for example each development project is unique and the development life-cycle is ‘not predictable‘ to say the least.  To compound matters, skills required may not be available and training may have to done while on the job. This is not the case in crew model where almost all the times things are predictable and follow a predictable sequence.  For example, in an airplane you can predict what would happen from the time you take a boarding pass and go to your seat to the time you get down from the flight. It is all very very predictable, linear & sequential. There is no room for variation — unless it is a private chartered russian flight

• Though one may say that even in software development we have roles like PM, Technical Leads, DBA’s etc etc and we know what is expected of that role. However, the reality is that software development is an iterative, some what chaotic, emergent process. There is a complex interplay between all stake holders to create the ‘intangible’ software that people want. Now by very nature of their business, airlines/ships can’t have an iterative, some what chaotic, emergent process to the nature of work that teams do there. Imagine a team of  air hostess emulating an iterative, some what chaotic, emergent process to serve the passengers.!!!

• Another important element is the “customer engagement” in the whole development life-cycle itself where requirements are fluid and can keep changing. Now one could argue that even in a ship or a airplane there is engagement required with the customers, but that engagement and the choices available and hence the options that the crew can exercise are from a limited set that is almost well known in advance.  It would be only in an adverse situation of a ship capsizing or a plane mishap (e.g. hi-jack) that the engagement model between all the participants becomes fluid and relatively unknown.

• The most important aspect I feel is the “nature of work” itself.  By very nature, software engineering calls for continuous learning & updation of skills while on the job. This is not necessarily true for airline or ship teams. Not to say that they don’t need to learn or improve their skills but that is within a very narrow band and at a slow pace than in software engineering. This aspect leads to totally different  behavioral, motivational, aspirational & emotional factors within individuals that then influence people, teams & how they work.

• I also think that teams in crew models the teams need to “coordinate” with each other to perform the task whereas in software development teams need to “collaborate” with each other to perform the task. These two things may look similar but call for totally different actions, engagement models within teams.

The above are just some of the many questions out there. What do you think?

Would ‘Crew or Military’ models of team formation work effectively in software developments? What could be other challenges and opportunities?

Wisdom of crowds did not work. Is it something to do with software engineers?

Quite a few experiments, like counting the number of coins in a jar & guessing the weight of the cake have been conducted to test out the ‘wisdom of crowds’ concept. Recently I got a chance to conduct an experiment at a gathering of approximately 150 people — all software/computer professionals

We put up a jar filled with éclairs and asked the audience to guess the number of éclairs in the jar and note it down on a piece of paper and hand it over to us. Obviously, we were excited to know the results – if the experiment worked, did someone guess the correct number?

Here are the results:

We had responses ranging from 25 éclairs to 786 éclairs. The actual number of éclairs in the jar was 204. Out of the 134 responses, only 1 person got the number right. The average, the ‘collective wisdom’ of the ‘crowd’ was 161.4 – an accuracy % of 79.14.

The results have left me wondering as to why did the results not concur with the ‘wisdom of crowds’ theory. After all, the following elements of ‘wisdom of crowds’ were present in the experiment:

• There was enough diversity among the participants. even though all the participants were software engineers, they came from different project teams, had varying levels of experience, roles etc.

• Each person was making his/her own independent choice and was not influenced by any other member

• There was means for us to collect and aggregate the responses.

The fourth element ‘Decentralization — people being able to specialize and draw on local knowledge’ can be debated to be missing from the experiment. How can we assume that there were people specializing in guessing the number of éclairs in a jar? How could they draw on local knowledge?

In Galton’s experiments, there were people who were butchers and farmers who one can assume to be specializing in ox/cattle. In ‘Guess the weight of the Cake’ experiment, people could feel the cake in their hands, there were people who were traders and hence one can assume that ‘knowing the weight of an object’ was something that they were familiar with.

The ‘guess the number of coins’ experiment was an online experiment and had no option for people to see, to feel the jar, hold it in their hands. Similar aspects were present in the experiment we conducted – we just showed people the jar filled with éclairs. We did not have people holding the jar, touching it, feeling it. Could such seemingly insignificant things allow people to make more informed choice? I don’t know.

BTW, ‘Guess the weight of the cake’ experiment was 99% successful even though it had just 120 participants whereas ‘guess the number of coins’ experiment was just 88% successful even though it had 1760 participants. This indicates that while the sample size could be a factor, but it does not seem so in the above examples.

I am wondering if aspects of ‘cognition, cooperation, coordination’ are present in such experiments?

What about the sample composition itself – all software/computer professionals? Do they bring diversity or are software professionals just not the right sample for any kind of experiment?

Using Open Source to create monopolies

Having seen open source from close quarters and a long enough time, I am beginning to believe that monopolies [or near monopolies] do exist in the open source world also and the business complexities, rules, strategies similar to the ‘other world’ are prevalent & relevant here. In fact a lot of smart people, organizations, communities have realized this aspect of open source and are quietly moving ahead — making full use of open source to create monopolies while many people are still debating the moral, legal, aspects.

Open Source promotes competition and diversity.

Yes, it does promote and provide opportunity for diversity & competition. But only in some areas areas, products and not in all areas. The ‘fundamental’ building blocks for the success of an open source [or a proprietary one] remain similar if not same.

Let’s take the classic example of ‘http’ server — Apache. Is it a monopoly? How many other open source http servers are out there that are popular and adopted by the world? hardly any..

For an open source product, the community that it is able to create for itself and leverage gives it the muscle power to ‘consciously or unconsciously’ create a monopoly. The larger the community, the larger the adoption, and hence the larger is the barrier to entry for other open source solutions.

However; it is true that open source does cause disruption within open source monopolies itself. for example: STRUTS was the de-facto framework for java based web development and had a near monopoly. other frameworks never stood a chance. Then comes spring and creates a whole new paradigm. So now it is spring that is on the verge of creating a monopoly. Then we have jBoss app server as an example. It is the defacto monopoly in the java middleware market.. It’s amazing that how jBoss has used the power of the community to effectively build a monopoly. Then think of eclipse.. the whole ecosystem it has been able to create around eclipse is amazing..

I think that in areas that are fundamentally ‘protocol/standards based’, open source products, solutions, frameworks is a sure shot way to create a monopoly and in areas where the differentiator is based on features, implementation etc, there will always be several open source products competing in the marketplace — competing for adoption, competing for building a community etc.

I think the smart companies will soon realize this and use open source for their business advantage to create huge barriers of entry, and near monopolies. The challenge is that it the fundamental requirement in this equation is to create a vibrant, robust and engaged community around the open source product. While commercial organizations are expert in creating brands/marketing etc, creating communities is not something that comes naturally to them. The key to success would lie there in my opinion..Maybe time for a CCN [Chief Community Nurturer] role within organizations..

A Disclaimer: I am a huge believer in open source and have been involved in this world for more than 10 years.

Why Wikipedia is the biggest threat to Organizational Wiki Adoption

Strange as it may sound, I believe that Wikipedia is one of the biggest ‘threat’ or issue when rolling out a wiki initiative in an organization.

I was at KAMP — a KM unconference and asked the partcipants on how many used Wikipedia as a refence, as an example for introducing Wiki to people within an organization. Almost all raised their hands and agreed.

What’s wrong with that.. you may think.. well what’s happening here is that you are sending a subtle message to people that it is a Wikipedia equivalent that we are trying to build within an organization and people seem confused on why would you want to do that.

KM professionals need to stress the ‘underlying principles’ of Wikipedia more that wikipedia itself when trying to start a wiki initiative and clearly mention that we will be using these principles to use the power of wiki in our organizational context.

So my advice to people is.. beware when you use Wikipedia as an example of wiki..

This is the presentation i used to illustrate some key ponts we need to be aware of while rolling out a wiki initiative

What can Wiki be used for?

In any organization, the work gets done through teams — sales teams, project teams etc.. Is their work suited for Wiki? What information within their work would lend itself nicely to wiki?

For example — software projects. Is wiki relevant in execution of software projects? How? what are the challenges? How to overcome those challenges?

Starting with the bread-and-butter documents, documents that need to be maintained within a project anyway are a good means of starting to use wiki. Evolving these documents in a Wiki instead of a word document is a quick win and will show the team the power of Wiki….

Things like project overview, roles & responsibility, infrastructure details, release & build processes, tips & tricks, Faqs, what to when.. etc etc..