Tuesday, February 1st, 2011
Traditionally, in many product companies, a few senior people at the “top” did most of the “creative” thinking/planning and the majority of the workers actually just follow their directions to build the products or deliver the services decided by the creative types.
This style of centrally managed Cathedral model management where each successive layer of management informes the next level down is rapidly falling apart. More and more companies are moving towards a flatter organization. Towards a Bazaar model. This is true since more and more people are doing the cognitive work rather than manual work. Smarter workforces needs empowerment and hence need fewer managers and fewer levels between themselves and the “boss”. They demand the cognition be distributed and people on the ground make decision close to the context.
To some extent, the open source model has paved the way for this style of org. structure in the software world. Also various collaboration and social interaction tools have emerged over the last decade which really help to scale a flat organization.
It will be interesting to watch how giant companies will structure themselves to compete with the Start-ups.
Saturday, June 19th, 2010
This morning I got hooked to a new band. I’ve heard the band before and I’ve had others praise the band. It was only this morning, when I stumbled upon a particular song by the band and started enjoying it. After that I went and explore the whole album and other albums. Its been 8 hours and I’ve been tripping on their music.
To think about it, software is kind of same. Usually its one sticky (killer) feature that gets people hooked to a new software. Once they experience that feature, without much push, they discover all kinds of interesting features and innovative ways to use them.
As someone building a new product how do you figure out what that feature would be?
I’m aware of 2 approaches that have worked in the past:
- Agile/Lean-start-up philosophy: Build sketches (quick and dirty versions) of a few features, put it in the hands of real users and see what might click.
- Open Source/Eat your own dog food philosophy: Build something that addresses your personal itch and see if others have the same itch.
What other approaches have you seen work?
Sunday, May 23rd, 2010
There is something very powerful about online education (eLearning). Assuming that one can create really good courses, it enables any individual to start competing with the large Universities. (Many Universities have seen the benefit of online education and they have certainly started offering their courses online.) Students can be located anywhere around the world and they can learn things at their own pace. With social media one can even achieve a very high collaboration between the students (peers) and teachers. This can scale very well and since the class capacity is infinite, we can completely remove the barrier to entry. Finally education can be made very affordable, since the cost of running an online course is extremely low compared to the bureaucratic Universities. Thus it helps in “Bringing quality education to everyone“.
One of the real problems we run into with this approach is, how do you “certify” the student? Coz these individual educators won’t have the credibility like a University nor will they be able to give an acceptable degree/certificate as a “proof of learning”. The question is can social media/web fill the void?
The Social Media/Web is still at a very nascent stage, evolving rapidly. Today people don’t really use it to validate someone’s credibility online. As of today “Certificates” have more value.
Globally, using social web to certify people has not taken off. LinkedIn is trying. I’m (or should I say, I was) trying something similar with the Agile Alliance LinkedIn Group. Lot of other people like http://www.wevouchfor.org and http://www.workingwithrails.com/ have tried.
To think about it, Open Source (being a committer/contributor on an open source project) helps you build social credibility. This model has certainly worked for a lot of developers.
Things like http://www.topcoder.com/ and http://www.codechef.com/ are taking off very well. But they are different, not so much social media.
Imagine “real” people on the web can vouch for your experience, knowledge and skill. You can demonstrate the same with applications/tools you’ve built. Your social status speaks for you and you can completely do away with the traditional certification model. I certainly see us moving in that direction. Decentralize and distribute the ability to certify people.
Sunday, February 1st, 2009
Programming is “the action or process of writing computer programs”.
Programming by definition encompasses analysis, design , coding, testing, debugging, profiling and a whole lot of other activities. Beware Coding is NOT Programming. Depending on which school of thought you belong to, you will define the relationship and boundaries between these various activities.
- In a waterfall world, each activity is a phase and you want a clear sign-off between each phases. Also these phases are sequential by nature with very limited or no feedback. Hence you are expected to have the full design in place before you can code. Else, what do you code?
- In RUP (so-called Iterative and Incremental model) even though it follows a spiral model with some feedback cycle every 3 months or so, one is expected to have the overall architecture of the project and a documented design (in UML notation) of the subset of use cases planned for the current spiral ready before the construction (coding) phase.
- In the unconventional model (where we don’t have process & tool servants and team members can do what they think is most appropriate in the given context), we fail to understand these sequential, rigid processes. We have burnt our fingers way too many times trying to retrofit ourselves into this sequential, well-defined process boundaries guarded by process police. So we have given up the hope that we’ll ever be as smart as the rest of the “coding community” and have chosen a different route.
So how do we design systems then?
- Some of us start with a test (not all, but just one) to understand/clarify what we are trying to build.
- While others might write some prototype code (read it as throw away code) to understand what needs to be build.
- Some teams also start by building a paper prototype (low-fidelity prototype) of what they plan to build and jump straight to the keyboard to validate their thought process (at least once very few hours).
- Yet some others use plain old index cards to model the system and start writing a test to put their thoughts in an assertive medium.
This is just the tip of the iceberg. There are a million ways people program systems. We seem to use a lot of these practices in conjunction (because they are not mutually exclusive practices and can actually be done in parallel).
People who are successful in this model have recognized that they are dealing with a complex adaptive system (CAS) and not a complicated system, where you can define rigid boundaries and be successful. In a CAS, there are multiple ways to do something and if someone makes a claim that you always have to do X before Y, we can sense the desire of putting rigid constraints which by nature are fragile. This is the same reason why there is no such thing called Best Practices in our dictionary. Instead we keep an eye on emerging patterns. If we want to see a particular pattern impact the system, we introduce attractors. But if we don’t want a pattern to impact our system we disrupt that pattern. (rip-off from Dave Snowden, creator of the Cynefin model and leading personality in Knowledge Management Community)
The open source community in general, is yet another classic example which fits into the unconventional category. I’ve never been on an open source project where we had a design phase. People live and breath evolutionary design. At best you might have a simple wiki defining some guidelines.
Anyway, I’m not saying that upfront design is bad. All I’m saying is, don’t tell me that one always has to design first. In CAS, you tend to “Probe-Sense-Respond” and not “Analyze-Respond”. In software development “Action precedes Clarity”, almost always.
Thursday, December 18th, 2008
Today I’ve decied to leave an old friend behind. I really cannot keep up with SF’s speed any more. Its time to move on. I’m slowly going to move all my open source projects to Google Code or GITHub.
Saturday, September 20th, 2008
In my last post, Open Space (OST) and Open Source(OSS), I’ve highlighted some core fundamentals (values) of OST and OSS. After reading it, you might be thinking, boy, I really want my software project to be built on these fundamentals. Agile Software Development is really a step in this direction. A lot of people including myself have talked/presented about OSS and Agile. There are lots of similarities between them.
When Deb and I were organizing the first Agile Coach Camp conference, we invited John Engle to facilitate the open space. During our discussion about theme and target audience, we were explaining John how Agile works and he was surprised how fundamentally (at the values level), both Agile and OST were similar.
At the Agile 2008 Conference in Toronto, Dennis Byrne and I facilitated a panel on Agile and Open Source. It was a slight twist on this topic. Our panel was proposed under the “Questioning Agile” stage. Our panel was titled “Successful open source projects with little or no Agile”. We were really questioning if Agile is the only way to build software? Agile Software methods like Scrum and XP are getting more and more bloated. Checklists and templates have emerged. God knows what all crazy stuff folks have come up with in the name of Agile. But one thing that no one talks about really, came out of the panel. While there is some amount of volunteerism built into Agile, it has a long way to go compared to OSS or OST. Agile projects can be structured around Volunteerism and my belief is it’s really going to help.
In some organizations I’ve worked, we have had good success with corporate sourcing model. Once various project teams get into the rhythm and start building their products, the next issue they hit is to collaborate with other teams across the organization. I call this, the teams are being good tribesman. But now they need to be good citizens also. In corporate sourcing model, the core team acts as committers on the project, while anyone in the company can suggest features or contribute code patches. Volunteerism comes in because people have freedom to work on other projects that really interests them. In companies like Google, its a little more structures. They have the 80-20 rule. Where in your 20% time you can work on stuff you like. Another way to encourage volunteerism.
A lot of companies have a big problem, because they have some existing projects and they have some new projects. Most developers want to work on new, green field projects. Rarely anyone wants to maintain existing projects. But those projects are very critical to the company and the company cannot move all developers on new projects. What do you do in this situation? Morale of tea members maintaining existing projects is really low. But they do have some spare time and tons of idea which can really help new product development. The way I have seen some companies solve this problem is, they either set up a rotation program where team members from maintenance projects can choose which project they want to work for on a rotation basis. In some other companies, I have see, team members are allowed to contribute code patches or suggest new features to the new projects in their spare time.
There are various ways to encourage volunteerism in your organization. Not just at project level, but in other ares as well. If someone is interested in marketing or sales or training or recruitment, companies can use their valuable contributions. In most cases this creates a win-win situation. This also helps folks to shape their career and become all rounded individuals. More the number of roles a person can play, that much more valuable they become to the organization. So remember, volunteerism in very important not just in your project but also at your organization level.
Saturday, September 20th, 2008
Both, Open Space Technology (OST)* and Open Source Software (OSS) are structured around volunteerism (.i.e people are the center of the universe). They really encourage people to step up and help. Volunteerism applies at many levels.
- you can author a piece of software and put it out to help others OR
- you can join an existing project and contribute to it.
- you can use the software and give feedback to the authors. Filling in a bug report or requesting an enhancement is a great way to participate in this movement. There are million ways to contribute to OSS, you can write some user document for the project or give a demo to your local user group.
Similarly in OST, you can propose a topic and be a facilitator or participate in a topic proposed by someone else or blog about your thoughts.
With Volunteerism comes responsibilities and rights. You have the right to participate and contribute. If you don’t like the direction in which its going, you have the right to leave or spawn off something that is how you would like it. This very behavior leads to exploration and discovery. Hence leads to innovation. While the participants have all these rights, they are generally good citizens and are very responsible & self-disciplined. You can really see a touch of craftsmanship in their work.
In my experience both these approaches are amazing at how they can involve/engage people. In OST we say,
“Who ever comes it the right people and whatever happens is the best that can happen”.
This holds true for OSS projects as well. You can’t really force somebody to contribute. Based on my experience the core for both is passionate people.
From the outside, both OST and OSS looks very chaotic in nature. One has to act, sense and respond. When someone throws open a piece of software, they have no idea how it would evolve or even if it will interest anyone. They have to act first by putting it out there. After that based on the feedback from the community (sense), the author/s have to respond. Project which are able to do this, see a big user community around it and hence innovation. Same holds good for OST topics.
Even though we try to put some (very limited) structure around them, both OST and OSS by nature are very self-organizing, self-emerging and self-adjusting or self-correcting. They also have a self-filtering nature. Its easy to leave non-passionate and undisciplined people behind. Nor are these hero-centric systems. Also the moment we try to put too much structure or process around them, they tend to break down. They don’t necessarily fail, but evolve into something very different in nature and the kind of people around it. In OST we say,
“It starts when it starts, it ends when it ends”.
Topics in OST and features in OSS evolve over a period of time. One thing influences another and another influences some third thing. This very nature makes it very adaptive. Adaptive systems are here to stay, rigid systems will soon be extinct.
* Don’t get confused with the word Technology in OST. In this context Technology means tool. Its really a meeting/conference format.