Building self-organizing team: Five key learnings

self_organizing_teamsThe 11th principle of Agile framework reads as ‘The best architectures, requirements and designs emerge from self-organizing teams’. Now the question comes what is a self-organizing team and how to build one? In simple words self-organization is about a team that self regulates, prioritizes and executes the work by keeping customer as the center of everything. Team members are supposed to be ‘responsible’ so that bottom-up culture is built instead of top-down ‘authoritative’ management approach. Based on my experience in working with multiple SCRUM teams, building self-organizing teams creates wonders for individuals, managers and customers. Here are my top-5 learnings.

  1. It takes time: Building self-organizing teams take a lot of time. Since it demands high technical capability and high behavioral skills, it’s hard to find individuals with mix of these two and still able to work together as a team. Personally I have spent significant amount of time to figure out right combination for the SCRUM team that has got potential to become self-organized.
  2. It demands maturity: Self organizing teams require very high self-regulation with the ability to ‘take-up’ higher set of responsibilities. On the other hand the manager / supervisor should be able to ‘give-up’ the control and feel comfortable with the team driving themselves. This requires very high amount of maturity from both the sides by giving up by feeling completely secure. It is easier said than done.
  3. Managing individual velocity: Agile talks about team velocity, which is about the ability of the team to churn out work volume. It is equally important to see that each member in the team is having similar velocity, failing which it will affect rhythm of the team. Regulating this requires a lot of focus and effort.
  4. Customer alignment: Ultimately the customer should be able to see the benefit of self-organizing teams, which requires customer alignment of the whole team. This means they should be able to understand the customer priorities, constantly deliver and build a strong relationship with them.
  5. Continuous improvement: Agile, at its core talks about having right mindset. During the journey of becoming a self-organized, tons of things that might go wrong. In such situations each member in the team should exhibit continuous improvement mindset. They should be able to critically retrospect and take focused action to keep improving. Ability to take feedback, being open and honest, keeping team and customer interest over individual interest are some of the attributes that team members should have in order to become truly self-organized.

In summary I see building self-organizing teams is the true testimony of leadership as it eventually makes the leader redundant for team functioning by demonstrating high amount of responsibility. After all who don’t want the team which drives itself without any external ‘push-pull’ from the manager 🙂

My talk on “Open Source and Embedded Systems”

Lounge47 is one of the new age entrepreneurial platform connecting Entrepreneurs, Ideas and Businesses. Couple of weeks back I got a chance to talk on the topic “Tracing the evolution – Open Source & Embedded Systems” among entrepreneurs, enthusiasts and seasoned professionals. The talk was for about 45 minutes followed by Q & A which triggered many interesting questions.

Here is the presentation slides:


Product discovery – what exactly you call as “product”?

For my related post on involving customers during product development by making them co-creator, one of the readers comment that the same approach will not work in every product development. By involving customers during product development, it might look like a “service” to the customers by taking example of Google v/s Apple way of building products. In case of Google, they work on a product discovery approach, whereas Apple has taken the approach of “Don’t ask the customer what they want, many of the times they themselves don’t know” approach.  In my opinion, major differentiation between these two approaches come from what we “refer” as a “product”. Buying a “box” product  from the store and experiencing  it with hands-on is way different from accessing an online product. This has a significant change the way products are developed. Let me explain this from my own experience.

I used to work in a firmware development team, which had very close traction with hardware. We made certain firmware changes specific to hardware, any further changes to it will result in re-manufacturing the whole PCB. Also product milestones, changes/defect fixes were controlled (ex: All level-1 severity defects should be fixed before manufacturing release, which is the final release). Later point I moved to other team, where we were building cloud solutions from the scratch. Our first major launch was two days away where we had at-least a dozen level-1 bugs were open. When I asked how we can make the release, the product manager replied “We can go ahead and launch then regularly roll-in patch releases by observing customer usage. If customers are not facing any issues, it is fine. After all for this flexibility only we are moving to cloud”.  Well, this fundamental elementary thinking of how we look at defect fixing itself different when it comes to looking into products as something.

Thanks to advancement in cloud technology, tons of mobile and internet products are getting built every day by following the discovery process. They can release, iterate and then improve their products depending on how customers are responding to it.  Recently there was an article about Amazon’s product building which talks about similar approach. On contrast, when you are building anything that is closer to the hardware, taking this approach might create more problems. For example, given a trial a customer might say he wants infrared interface in it, which might result in months of time to tape out and re-design a new board. Whereas in case of web, if the customer wants a button to be changed, probably it can be done in few hours.

In conclusion, I would say product development largely depends on what exactly we call it as product. The development methodology should change and be in sync with it.

Product quality as an experience

“It’s in Apple’s DNA that technology alone is not enough — it’s technology married with liberal arts, married with the humanities, that yields us the result that makes our heart sing and nowhere is that more true than in these post-PC devices,” –  Steve Job’s statement during iPad 2 release

I was able to relate well to his statement, which is visible in terms of user experience when it comes to Apple products. I still remember the day when my mother (60+ year old) was seamlessly able to listen to music from iPod when I handed over to her for the first time, even though she didn’t had any previous idea about using any sort of gadgets. The same was true with iPhone, where I felt immense amount of joy owning it. Till date I don’t think any organizations or products can beat Apple when it comes to the seamless experience of integrating software, hardware and user experience.

Purely taking a software view, I could say the excellent user experience achieved because of the high quality software. Professionally I have been handling multiple software programs and projects, mainly focusing on quality which has multiple elements like quality control, quality assurance and metrics based project management. Often as a project manager, one gets into so much bogged down in meeting project metrics, often customer and his experience goes out of window. For example, having a lower priority defect in user interface v/s higher priority defect in corner case scenario resulting in device crash. From the defect density or defect index perspective, it will look better to have lower priority defect open but imaging the impact of it from user perspective.

In such cases I feel metrics based project management should be abandoned and quality should take user experience route. All design and measurement mechanisms for project should be attuned to ensure users get a great experience, which is what Agile or Lean software development is trying to advocate. Perpetual beta, demo releases, iterative development are better ways to do this I also wonder what Apple should be doing in their software development method to ensure such a high quality with on time releases.

After all no customer talks about defect density while using iPhones!

Ten types of Innovation – Concluding notes

With article on Bigbasket, the ten part innovation series comes to an end. When I understood the innovation types (created by Doblin) way back in 2011, my idea was to apply it from Indian context and make case studies fitting various types. It took two long years for me to complete this series with decent satisfaction.

Innovation has gone beyond building a particular product or service. By building something different doesn’t guarantee a business success, whereas ensuring customer derives value will. India, unlike some of the developed countries, is in the cusp of transformation where we have both traditional old school thinking and new school of thinking co-existing with each other. This made my inquiry to innovation all the more interesting. As and when I observed some innovative way to serve customers, I started mapping them back to Doblin’s model and came up with this whole series spanning across industries.

Please find URLs to individual posts as follows:

The importance of hanging in there when things dont necessarily go your way

Nothing succeeds like success they say… There is an incredible “High” that success brings to you and your team. Everyone has a spring in their stride, the energy levels are high and there is spotlight that your team is basking on. Even as a manager, you are able to more easily keep your team motivated and also get better cross functional support for your initiatives.

However, things don’t always go or remain hunky dory in business. The best strategized and executed products do sometime fail, best planned projects sometimes don’t get delivered on time. The team starts feeling the pressure, there could be growing cynicism, dropping shoulders and an executive team that is focusing on your initiative more than you really care for.

How efficiently leaders and teams respond when they have their backs to the wall is a critical quality. As a Product Manager you need to be able to communicate though words, and more importantly, your body language that of you and your team are in charge.

In a Yoga course that I once attended, the teacher taught me the ability to say, and more importantly feel, “So what! What next?”. If you can truly get into that mode, the “What next?” allows you to divert your thinking and therefore your energy on exploring the next set of opportunities. The idea is to basically compartmentalize the “So what” and the “What next”. The former bringing to a realization that you are where you are – basically screwed; and the latter letting you focus on the steps to move ahead – do we need to pivot / do we need to re-look the strategy for this product / should we put in better processes. ALWAYS look for the next set of opportunities. They are around, if only you can compartmentalize and look hard.

Even in your hiring of critical positions, its a good idea for you to check how the person responded to an adverse situation and what it taught her. A recent very popular blog on Harvard Business Review was a good one on these lines – http://blogs.hbr.org/cs/2011/12/why_i_hire_people_who_fail.html

Interestingly this holds as good in sports as in business. We have all seen crickets teams that drop catches / miss run out chances / show fraying tempers when the chips are down and then we have seen teams that are keeping up the pressure even when things don’t go their ways and show a spirit which conveys, “We just need to break THIS partnership, and we’ll be back in the game”. The second mentioned team might still not break that partnership and possibly go on to lose, but that very attitude of always backing themselves puts them in a great position to get right back into the game.

– NWritings

Focus on the effort… as much as the result – Another perspective

This is the second part of my earlier blog “Focus on the effort… as much as the result” – http://jwritings.com/?p=562. In case you have not read that, I would suggest that you do before proceeding to read this.
While that blog presents a good picture of a project with high stakes, riveting rush by the team culminating in a nice photo finish (almost cinematic), there are some disturbing questions too. Why did it take until 2:00 pm on the release date to figure out that there was a long list pending? Shouldnt there have been appropriate checks and balances in place (especially since this was a release that multiple regions were looking forward to)? Shouldnt the stakeholders (folks who had made commitments to customers) been sounded off earlier that there could be a slip (in which case they could at least fore-warn the customers that there MIGHT be a delay)? What if the release had not happened even after all the effort?

Is this similar to our infamous Commonwealth Games experience where weeks before the games were scheduled to start the supervising committee found stinking toilets and unpainted stadiums and deplorable athlete village? Isnt it interesting that even a senior Indian official compared the whole Commonwealth Games fiasco to Indian weddings where things are chaotic right up till the last moment before miraculously falling in place in the nick of time? Has our Indian psyche trained us to see this whole episode as a “victory from the jaws of defeat” rather than a “last minute frenzy to barely manage to deliver after screwing up all along”. Even in this case, wasnt it passion and a heroic slog by the highly charged team that delivered the win rather than a methodical and systematic process?

Now if I have to weigh both sides and choose which of these two set of qualities – passionate and heroic sloggers vs methodical and process driven marchers, I would lay more emphasis on, I would much rather pick the former. Now I am not talking about these as mutually exclusive traits, but more as the dominant characteristics of the two sides.

Here is the reasons for my choice:

Software product development is inherently unpredictable. While you can do a reasonable job of approximations earlier during the development cycle, hard release dates pretty much “emerge” during the later stages of development. After about 12 years in product development, with 8 of those as a Product Manager, I have very rarely released a product exactly on the planned release date – and I have never felt bad about it. One of the best part of this job is the opportunity to say, “I dont mind if this product is launched a few days later, but I want the wow effect”. There are always last minute changes – enhancement that you want to add for the “wow” effect or a database query optimization that’s going to deliver faster customer response times – that you did not plan for when you wrote the specs 4 months back, but want it now!!!

This is especially true in case of start ups where priorities change fast, demands from a large customer can require you to rejig or do a course correction and you are constantly trying to do more with less resources and shorter time.

With best checks and balances and processes in place, you will still have your share of “2:00 pm on release day with a long pending list” days (the frequency pretty much depends on the pace of your business)…. and on those days, you’re seriously better off with a team that’s willing to go the extra mile than a team that’s dissecting what went wrong with the process or how many times the requirements changed.

NWritings

Focus on the effort… as much as the result

A few years back, my team was preparing for a big product release which was widely anticipated across multiple regions of the organization. Many customers had committed that the product would be available on a certain date. One advantage that many Indian companies are grateful for is that IST is almost 13 hours ahead of pacific time (where many of the customers we had promised to were based out of). So, if you had committed delivery on 15th April to the customer, you could deliver it at end of day IST. In fact you could even deliver it before end of day pacific time 🙂

At 2 pm IST on the release date we realized that a few components that would make up the release had not yet converged. I got the entire team into a war room and it was all hands on board. The whiteboard listed out the pending items and were being ticked off as and when things moved ahead. The list at 2:00 pm looked pretty long for comfort. We also put in place a process of hourly updates on the rush towards the release that I as the PM would send out to the functions that were anticipating the release. It was all hands on board and the team was pretty pumped up to do the release that day, Whatever it took. I was convinced that the team would go for it even if it took well past dinner that day, or even after breakfast the next morning!!!!

The activity over the next several hours was pretty hectic and by close to midnight  the hourly updates showed good momentum towards the finish. the next day 2:00 am update announced that it was all ready to ship and the final builds would be available in the next hour or so. But trouble was right around the corner!!!

One critical use case broke minutes after the 2:00 am update I decided that we would not ship it with that bug – we would fix it. The team, weary as they were after more than 17 hours of non stop slogging, was no mood to back out – not after all the effort. We chalked out the plan to fix the stuff. No one from the team had left.

My CEO who was around that day at 2:30 am for some other meeting strolled into the war room and asked, “So, we’re all set???”. I said, “We are not!!! We have identified a critical bug that I would want to release the product with and have turned the release status from GREEN as of 2:00 am to YELLOW sometime back. I’m confident we will fix it in the next hour or so”. I will never forget his response, “AWESOME!!!! Go for it guys” and walked off. I knew he didn’t not mean it sarcastically.

The fixes converged over the next hour or so and we did make the release at 4:45 am (still early afternoon in bay area), but the CEOs response was interesting. No trace of disappointment, no lectures about why things were left to the last minute (even if there were, its best addressed another day). The commitment of the team, right from PM to the newest intern, was good enough for him to be convinced that this set of guys would make it happen.

As the CEO of my earlier company often said, “You cannot assure success… but you can sure deserve it”

NWritings

BOOK REVIEW : The Long Tail

 

Price: 275 INR

Author: Chris Anderson

The Business world has gone through disruptive changes during the past decade – one of the main reasons being content (ex: music, books, photos) is created, maintained and consumed. Internet was instrumental for fueling this change, thanks to digitization of anything and everything. The new ‘digital’ way has literally changed (in some cases ruined) many traditional business models, which is been working for decades together. One classic example is Apple iTunes, which has democratized the way music is created and shared across billions of people across the world. Another major aspect of digitization is about providing equal opportunity for niche players by connecting them with niche audience, which did not exist previously. As the digital infrastructure can be scaled overnight (that too with global availability), many innovative models are emerging around it.

In his book ‘The Long Tail’ author Chris Anderson introduces a new model which he calls as ‘endless choices creating unlimited demand’. He explains it with the power law graph (see image on the right). The left side of the graph is about ‘hits’, which has maximum number of non-niche customers. The right hand side is about ‘non-hits’ which reaches niche customers, which also has a huge number, at least comparable to mainstream non-niche customers. The ‘Long Tail’ of business is about selling to niche customers, aided by digital infrastructure.

Let us take an example of creating and distributing rock music in the form of albums. During earlier days, a particular rock band will create an album and approach some or the other major music distributors for making a production (in form of CD/DVD) and distribution out of it. From the distributor’s point of view, they will take a very stringent approach for short-listing these bands as they want to really ensure that the album becomes a hit. This is mainly because the distributor needs to make an upfront investment of creating the physical network (CD/DVD creation, distribution to channel partners/retailers, staff expenses etc…). While this ‘hit’ based world/approach still exists, the niche based items also gaining high importance due to the digital transformation. Today any rock band can still create the music, edit is using freely available tools, make an album out of it and upload into the Internet (ex: MySpace). By doing this, they are completely getting rid of traditional distributors, thereby targeting niche audience who are bored with popular bands and interested to explore something new.

According to Chris the ‘Long Tail’ is created because of three factors:

  • Democratization of tools for production (MySpace online tools)
  • Democratization of tools for distribution (Internet)
  • Connecting the demand and supply (MySpace social networking platform)

The similar model can be extended to other industries, using which organizations like Apple (iTunes music, iPhone Apps), Amazon (Online retailing, which can literally list infinite number of items), Google (Ad-sense, Ad-words), Wikipedia (democratic content ecosystem) has become a global success by leveraging Long Tail customers. From the consumer side, the behavior has changed as they are expecting more and more choices which can be met only by such system.

Throughout the book, author explains above mentioned aspects in detail across different chapters, thereby giving complete perspective to readers. In few chapters I felt he repeated same information multiple times, but he takes examples from different industries makes it an interesting read.  In order to understand the recent business changes, aided by Digitized Internet, Chris Anderson’s Long Tail provides an excellent framework where one can put things into perspective.

Innovation – Type6 – Product system [Case: Amul]

As a part of Innovation series, let us take a look into the brand Amul under the ‘product system’ innovation category.  By taking the basic product (milk in this case), Amul is able to innovate by creating a suite of food products around it. We all know, today Brand Amul stands much beyond milk!

Amul - Taste of India
Amul - Taste of India

Let us take a sip of history before considering the innovation aspects.  It all started 65 years ago in the state of Gujarat a bunch of angry farmers wanted to do ‘something’ against the malpractices followed by middle-men in the milk supply chain. Like in many industries the middle-men were creating a ‘loose-loose’ situation for both milk producers and consumers by manipulating around the system. Strongly supported by Sardar Vallabhbhai Patel, they decided to get rid of the middle-men by forming their own co-operative society which will own the complete milk production chain, ranging from procurement to marketing. Thanks to strong leadership provided by visionaries like Verghese Kurien the Gujarat Cooperative Milk Marketing Federation Ltd. (GCMMF) was formed in a small town Anand during 1946.

From this humble beginning, GCMMF created incremental innovations around milk, which eventually lead to ‘white revolution’ in the country. The Amul brand name strongly emerged out of this revolution, which a house hold name in today. Eventually the Amul model was replicated in different states in different names – Nandini (Karnataka), Aavin(Tamilnadu). This co-operative model has multiple innovative aspects, let us take a systems perspective.

As the milk production increased significantly over the years, the direct consumption of milk is a single dimension of the whole market and it’s potential. As the milk processing also saw multiple innovations, Amul introduced whole lot of bi- products which created a whole new system of products:

  • Butter (Cooking & low-fat varieties)
  • Cheese (Processed cheese & Paneer varieties)
  • Sweets (Shrikhand, Amrakhand)
  • Flavored milk (Kool milk)
  • Ghee (Cooking and Infant varieties)
  • Milk powders (Amulya Dairy Whitener)
  • Curd products (Masti Dahi, Lassee, Spiced butter milk)
  • Ice-creams
  • Chocolate (Milk, Fruit & Nut)

Amul introduced new channels to sell the above mentioned products by creating  ‘kiosks’. These kiosks, created in a franchise model come in five different sizes (preferred outlets, ice-cream parlours, railway parlours, kiosks and Café Amul) depending on the investment size. For an end consumer a suite of products available from a single kiosk which is of high quality and low cost. Looking from Indian context, Amul is a great innovative example for creating a system around milk.

Related link:

BOOK REVIEW: I too had a Dream [Autobiography of Dr. Kurien]

[Introduction to ten types of Innovation] [Innovation – Type 1 – RangDe] [Innovation – Type 2 – RedBus] [Innovation – Type 3 – Narayana Hrudhayalaya] [Innovation – Type 4 – Mumbai Dabbawalas] [Innovation – Type 5 – Reva Electric Car]