A Day in the Life of a Business Analyst at ThoughtWorks

A really enterprising individual got in touch with me a few weeks ago to help him understand the role of a Business Analyst, especially in the context of ThoughtWorks. He sent across a list of questions and I am posting them here along with my responses in the hope that other's might also find this helpful.

About me: In case you were wondering why he felt I would be able to answer his questions :-). I have been playing the role of a Business Analyst in multiple client engagements over the last 12+ years. Here is a link to my profile for more context.

--------------------------

What was your typical day like when you started as a Business Analyst in ThoughtWorks?

My typical day starts with preparing the physical story wall for my project, so that when the team sign’s up for the tasks for the day there are stack ranked story cards for them to address.

Then, we have the standup and team sign ups where the team shares any blockers they faced or are facing on their stories and any key lessons they picked up. If I have done a good job of explaining the business context of the stories in the backlog then the team sign-ups tends to be smooth and the team is able to sign-up for stories/tasks without much direction from my end.

You will notice that most of the activities are focussed at ensuring that we catch any issues upfront rather than later in the cycle, since the later they get caught the more costly it is to fix them, thereby accumulating waste which we want to limit as much as we can. The activities below occur on a daily basis in my world:

• Story kick-offs - When a dev pair (we follow pair programming in all our projects) picks up a new story for development it is my role to ensure that the pair understands the business context of the story and use as many visual means (workflows, wireframes, diagrams) as possible to ensure that this process is smooth. The quality analysts and feature owners (if any) are also mandatory participants in this activity. Generally, we invest around 15-20 mins in this activity for each story.
• BA volleyball - Once a dev pair has completed a story from their end we conduct a BA volleyball which is essentially a validation exercise where the same individuals what kicked off the story come together and we run though the main acceptance criteria of the story. If we observe any issues of bugs then the feedback is passed right there to the dev pair who work on resolving this issue before the QA’s can pick it up for automation testing.
• Backlog grooming - Another continuous task for me is to ensure that the feature/story backlog is analysed and detailed enough to provide uninterrupted work for the dev pairs. I generally work 2 iterations ahead of the dev pairs and consciously avoid going more in the future since business priorities are ever evolving and I don’t want to focus my effort on something that might get de-prioritised.
• Team huddles - Since we do not perform low level design of our applications upfront, the team gets into quick (15-20 min) huddles next to the work area to discuss problems and agree on a common direction, my role in these discussions would be to provide business context and also answer any business related queries. I would excuse myself (or be excused) if the discussion is purely technical, this is decided on a case to case basis.
• Customer interaction - I have daily catchups with my client counterpart, which is either a person in the role of a Business Analyst, Product Manager or direct user. These sessions are used to analyse the next set of features, continuously prioritise the backlog by evaluating/re-evaluating the value of a feature/story, and asking any open questions that may have popped up from the team or during my own analysis. We also use these sessions to review the stories that have been detailed by us to that we can get a sign-off and incorporate the feedback (if any)

I also get involved in the below activities but these may not occur as often as the ones above.

• Prioritization & Business Context - I use the Iteration Planning Meetings (IPM) to ensure that the team understand the current state of the project and the next level or priorities. I also use this session to ensure that the team understands the business context of the upcoming stories. I generally own and drive this meeting.
• Showcases - Ideally, we should be showcasing each story directly to the main user group as and when they get developed, however, owing to the distributed setup that we tend to work in or unavailability of business teams from their regular activities we plan for these at the end of the showcase. It is my responsibility to ensure that we have the right audience for the showcase and the team follows a structured approach to the showcase. The actual showcase is run by the individual team members through volunteered signups, 1-2 folks from the team sign up for each showcase.
• Retrospectives - This is again a shared responsibility but as a BA I take it upon myself to calling out when we have slipped up on this activity. The idea of this meeting is to have an open conversation about the areas of improvement and those actually going well so that we can improve as a group. You can learn more about retrospectives here.

What are the typical deliverables as a B.A?

The following become the key deliverables that come as part of my job:

• User stories -  Well analysed, with as many visual representations as possible and well rounded AC’s. Ideally these should always be peer reviewed if you have another BA on the team, you can refer to some tips on pairing for BA’s here.
• Feature overview - I generally create a powerpoint deck or mindmap when I get into discussions with the business stakeholders to get more details on the next set of features to be picked up. This becomes a document of reference as we build on the feature and again having visual representations on this is key for structured discussions with business stakeholders.
• IPM/Showcase decks - When having iteration planning meetings or showcases with the customers I generally use a deck and this again becomes an important deliverable.

What do you love and hate(if any) most about your job?

I love:

• Interacting with customers and solving the complex problems that they throw at us.
• To break down complex problems and present them in an easy to understand language/format.
• Getting to dab into multiple business domains and understanding the modus operandi of different companies/business processes.
• Working with high performing teams and watching people grow in their careers, and if I have a small contribution in their evolution then I am even more thrilled.
• Being challenged by co-workers and them setting the bar higher for me on a continuous basis.

I hate:

When the project comes to the end of its lifecycle and the complex problems tend to come by once in awhile.

Is it necessary that you know enterprise applications to be able to offer a solution to a problem? Or do you get help from others? Who?

Generally, the enterprise applications exist to support business processes, in my discussions with business stakeholders I try to focus my questions on the business processes rather than the systems. However, if I need to understand the enterprise systems since they are intrinsic to me solving the problem then I would get into understanding the system using the following approach:

• I would use the help from the key SME who knows about the system and then sit with them to get an overview.
• I would also get myself access to a test environment where I can play around different scenarios to build my understanding.
• I would document my questions and then approach the SME for answers.

I was wondering, what books, articles or courses helped you the most in preparing to be a Business Analyst?(I've already read BABOK 2.0, and many articles online)

I think the general lessons I learnt in my MBA helped me a lot in understanding business contexts and keeping my focus in that area. Apart from this, I would recommend a few books which would hopefully help provoke some thoughts:

• User stories applied

• Agile Retrospectives

• The Goal - I really liked this book since it explains a lot of important concepts of how work should flow in a very lucid manner.

• The Phoenix Project - This is similar to 'the goal' but deals with concepts in the IT world and explains how a well-oiled IT set-up should look like for large enterprises, again explained in a very fun novel-like format.

• Crucial Conversations Tools for Talking When Stakes Are High - This book has helped me deal with conversations both in the personal and professional space. I recommend it to everyone! As a BA you are expected to keep the team and the customer in good humor and some of the tips in this book, practised over a period of time, will really help you deal with difficult situations.

• Lean start-up - Developing new products or enhancing existing ones is becoming very different now and this books explains the techniques Product Managers are using to make decisions. It's important to understand this because as a BA you will be working closely with client Product managers or even in some situations playing the role of a product manager in the absence of one.

What type of work samples or portfolio should I be trying to develop as I try to move into this career?

Areas where you are solving complex business problems by using a mixture of systems and human thinking should help you make a case for moving into this career.

What kind of exercises would you recommend that I can engage to better practice being a B.A?

Solving case studies that look to improve the business process for an organisation could help, also, presenting such case studies and their solutions in an easy to understand format will also help.

In a case study for a Business Analyst, what is usually being asked as a deliverable?

This is what I would look for:

• Ability to ask questions to understand the complete breadth of the problem. (Who are your customers, how will you reach out to them, what is your revenue model, what is your differentiator, what is your budget, what backend systems/operations have you put in place, how soon do you want this to happen, what is the state of your current IT systems, how did you do this so far etc.)
• Based on the above the ability to break down the problem so that everyone is on the same page (draw it out or bring clarity in your speech)
• Provide a realistic solution or options based on the inputs you have received and also the ability to think on your feet it you see any constraints.

The solution is not the most important thing that is being judged, the structured approach that was taken to reach till the solution is generally the clincher.

Is it necessary for me to learn Agile if I want to be a B.A in ThoughtWorks?

You need to understand the essence of agile, but it is not important for you to be a seasoned practitioner, we understand that agile practices differ across various organisations and you will undergo training programs once you join to help you understand our brand of agile.

Is there anything you thought I'd ask that I didn't? Anything else you'd like to share?

I'll just share my thoughts on how the role has evolved for me over the last few years and what I believe this role is about:

• Central force - In my view, a Business Analyst invariably tends to be the central force around whom the team revolves, and in self organizing teams they could also double up as a Project Manager, this means that you need to be on the top of you game at all times. You need to understand not only the stories and backlog but also be the one that can push the team in the right direction when the focus wavers, you need to take ownership when you feel that we are not continuously improving.
• Build a Self organizing, high performing team - If you are going to achieve a team goal it is important that there is collective ownership in the team and you need to ensure that the team members are continuously enhancing their skills. This requires you to set clear goals for folks on your team and helping them work through their feedback.
• Make yourself redundant - As a seasoned BA on a team I see my role as making myself redundant, which means that I am mentoring other BAs to take on the higher responsibilities and improving themselves. This is the only way I have figured out that I am going to elevate my learning and growth curve.
• Continue to learn - This is definitely cliched so I am not going to spend a lot of time one it but mention it here since this is the only way to remain relevant. I wish I could do better at this everyday!

The Most Important (yet ignored) Asset

I learnt this lesson during my management course and it immediately struck a chord and has always stuck on. The course was called "Services Management" and our professor used a simulation game to explain a very simple point about the services industry. In the simulation game we began with a set budget and the players had to invest that amount in various components like Marketing, Sales, Research & Development, Operations, Human Resources, etc so that the overall business could flourish. The traditional mindset is to create a stellar product and market it well, this should settle you as the winner. However, in a services-oriented business the players who invested smartly in their Human resources (a.k.a People) would end up on the winning side since happy and empowered employees will provide the clinching customer experience. In other words, "people" are the most important asset for a service-oriented business and how you invest in recruiting, training, rewarding, and empowering your employees will have a direct impact on your bottom & top line.

I know that this may not be a eureka moment for most of the readers and they would have read/heard this before, some may even argue that we are already following this, haven't you seen our Mission/Vision statement we have mentioned "employee satisfaction" in bold and even our tax friendly benefits structure should tell you how much we value our employees. Some others may also point out that they have a dedicated human resources department and also provide free cola and snacks in the pantry. What else do you want!!?

While doing the above is important, in today's workplace they are merely hygiene factors. On a day-to-day basis your people interact with their peers, managers and customers, and it is this environment that generally lacks the "people" focus it needs. Therefore, it's imperative that we continue to avoid the following pitfalls and foster the kind of environment that might end up being your USP.

Before we begin this, the underlying assumption is that as an organization you have spent a considerable amount of time in hiring the "right" people i.e. people who possess the raw (or finished) ingredients suited for your business, and not just another "body" to fill the manpower targets.

Stop treating people like a resource - Technically, people are resources but are very different from the other resources that you would encounter in a traditional manufacturing scenario. They have ambitions, moods, personal issues, quirks etc. and all this needs to figure in our thinking especially when we take calls on planning their career paths and while staffing them on assignments. Moving people from one project to another cannot be played out like it does with machines on the shop floor of a manufacturing unit. Do that more often than once and you are playing with fire. Remember, if the person isn't happy or convinced about what he/she is getting into then it is more than likely that this will impact the manner in which they service the client. At ThoughtWorks, in order to ensure that we are addressing people's interests, we take inputs from people about the kind of software projects we should be targeting. This helps ensure that we atleast have a buy-in from (majority of) folks on the ground and moving across projects is not a big deal since each project has something unique to offer.

"Empowerment" is the word - Interacting with clients and across internal teams, employees need to feel empowered and trusted to bring out the best in them. Managers constantly feel the need to micro-manage people to fulfill the needs of the demanding customer, this creates further distrust and frustration in the team. If you have hired the right people then have the guts to trust and back them, and they will deliver whatever is within the realm of "possible" or maybe even beyond that. Yes, they might make the occasional mistake but the value of an employee that feels that he/she can take ownership will soon surpass any losses. The practice of constantly pushing people by offering superficial rewards might only work temporarily, in my experience the employees who feel trusted and empowered will get the job done and still be satisfied.

The World is "Flat" - Flat hierarchies are not a new concept but even though a lot of companies have been able to move towards a flatter hierarchical structure and realize the benefits, there still are tons out there that enforce the almost military-like command and control structure. The only people who can actually change this are the senior level managers, but I guess if you have worked hard for so many years to climb the corporate ladder you want to feel privileged and you want to have your own office and you want people to address you as 'sir' (atleast on your face). No sir, sorry to have to tell you this but get your priceless *** out of that closed door office and sit where the rest of your folks sit. This one move in itself will send a very strong message to your people and further enforce the feeling of trust and empowerment that is key. It will also help you sense the pulse of the people without having to do meaningless point based employee satisfaction surveys every year. Use a meeting room for all the "closed" door discussions that you want to have.

Why are people leaving?  - Don't fool yourself to think that people are leaving just because they want to start their own venture or because you just couldn't offer a higher salary package. Bad managers and short-sighted people practices are still a big reason for people quitting, whereas compensation is the last reason most people leave. Is that true for your firm too?

EXTREME ANALYSIS - Pairing for Business Analysts

Extreme Analysis in action

Pair programming has been used by software developers in most progressive software companies to help churn out quality products and to ensure that context is shared across the teams. For the uninitiated, traditional pair programming (in short) is a practice where 2 programmers work on developing a piece of software functionality in tandem. 
This practice helps improve code quality since you have 2 sets of eyes and brains trying to solve the problem and as one person writes the code, the other continuously reviews it, thereby eliminating the need to have separate code review sessions. Also, if the pair has worked efficiently then any mistakes in design have been caught upfront, thereby eliminating any waste caused by defects which would have been discovered at a later stage. This concept has mostly been applied to the working of software developers and other roles have not quite adapted it, as yet.

Why is this important? - Business Analysts (in general) are used to working in an individual capacity since most team's have a single BA, and a lot of analysts find it hard to work with other analysts in an amicable manner. My guess is that since there is a dearth of opportunities to work with other's, the skills to work with others does not get the opportunity to blossom.

“Business Analysts, User Experience (UX) Analysts, Project Managers, and (to  a lesser degree) Quality Analysts are used to working alone, and may need to work out how to deal with situations where they too need to collaborate among the community, and deliver.”

My primary role is of a Business Analyst, and I had wanted to share my experiences on the projects that I executed at ThoughtWorks, where I was able to pair with the other BAs with some level of success. This piece is my attempt to not only share some of those lessons and experiences, but hopefully also generate some healthy debate/discussions.

The Basics

Before we go into any specifics of how to pair as Business Analysts we need to first get some basics right. 

Any successful working relationship needs to have these elements at the core, the absence of these will render any attempt at pairing to be futile.

• Commitment to work from the individuals in question
• Mutual Respect
• Equal sharing of tasks and responsibilities
• Leverage on each others strengths and work around the rough edges.
• Willingness to take feedback from each other and work towards improvement
• Helping each other through personal time-offs by temporarily taking ownership of tasks
• Ability to share a laugh and work through stressful situations
• Personal Hygiene, since the expectation is for both to sit in reasonably close proximity to each other, personal hygiene will be an important factor. :-P

Pairing Practices

When we look at Business analysis in an agile project the following tasks would generally have to be undertaken on a day-to-day basis. I hope to tie the practices we used and make my case for "EXTREME ANALYSIS".

Daily Sign-ups - The day generally starts with a stand-up where the entire team participates and thereafter programmers, quality analyst and Business analysts sign-up for their tasks. Its important that the BAs get together and list down the tasks that they intend to pick during the course of the day and sign-up for them based on an equal distribution.

This activity is important since there can be multiple things (other than story detailing) that need to be addressed during the day like responding to emails sent by the customer, escalating blockers, reviewing analysed stories etc. And these tasks need to be identified and responded to as a team.

Tools/Practices: When the BAs are co-located then it makes sense to sit next to each other and list the tasks on a notebook or stickies and striking them off as they get done. However, when the BAs are working in different timezones (or geographies) then apart from a 15-30 min daily catch-up the sign-ups can be managed via a lightweight task list manager like Trello. Its web-based, free to use, and simple as hell.

Story Detailing - This is the most significant task that BAs undertake and pairing here can help to set a mutually agreed direction that the BA detailing the story can take. 

Tools/Practices: The tool being used here is the most effective one i.e. conversations. The BA who has taken the ownership of a feature will explain in brief the approach that he/she plans to take and solicit inputs from the other BAs. This ensures that context is shared and also helps build a better story right upfront (fail fast).

Story Review (Internal) - In Extreme Programming, programmers use peer review to ensure that the coding practices are being followed. Keeping in mind the same principles, Business Analysts should get their stories reviewed by another set of eyes just to make sure that all the bases are covered.

Tools/Practices: Ensuring that all stories (especially the complex ones) are peer reviewed by atleast one Business Analyst to capture any obvious omissions/errors.

Story Review (with Customer) - Stories need to be signed-off by customers before they can be picked up by programmers and these meetings can be managed better if you work as a team. If the BAs have followed the earlier steps they will take a uniform message and present a unified voice to the customer.  

Tools/Practices: Having feature kick-offs, where as a team you present the outline of the requirement and get inputs from the customer.

Iteration Planning - The stories that need to be picked in the forthcoming iterations need to be planned and communicated to the customer. Its important that this activity takes into account the dependencies and priorities that are associated with the stories and features.

Tools/Practices: Rotate the responsibility of creating the iteration plan among the BAs and then review the plan that has been set forth as a team. Again this helps get inputs from a larger group and in the absence of one of the BAs the others can take over the Iteration planning meeting with the team and/or customer.

Difficult conversations - When we talk about scope and prioritization with customers there is always the possibility of conversations turning hostile, especially if the team is set-up in the onsite-offshore model. Added to this is the fact that customers can be very direct, demanding and (sometimes) just plain uncooperative. All this could lead to frustrating conversations which can test the BA's patience, communication, and negotiation skills.

Tools/Practices: If one of the BA's is feeling particularly frustrated and bogged down by the conversations and not able to respond in a calm and composed manner, which is a perfectly natural feeling to have in such tense situations (Maybe it's just not their day). The other BA should have the ability to sense this and attempt to bring the calmness and logic back into the conversations. This obviously means that the BA who is not able to respond in a calm manner should back-off and let the other BA lead the discussion this time around. Good teamwork requires people to understand the personality (and mood) of their colleagues and support them adequately.

Women Empowerment: Moving Beyond Lip Service

Almost all progressive new age organisations and their leaders would publicly support higher participation from women in their workplace, some even boasting how women have occupied senior management positions in their company. 

Generally this boils down to a 3 month paid leave on maternity, additional security during late night drops, and a few "women groups/forums". Although all this is welcome and much needed, there still is a need to up the ante when it comes to actual Women Empowerment.

In my view ThoughtWorks has tried to change the game through the following initiatives and as we try to continuously improve and innovate I am sure there will be more such attempts in the future.

Target 50% women hires during campus placements - ThoughtWorks has set itself a target of fulfilling 50% of their annual campus hires with women. This is done without compromising quality and without ignoring an equally capable male candidate. How? By targeting women only colleges and holding focused recruitment drives.
There is no doubt that this is challenging and a tough ask from all involved, especially if you consider the dwindling number of women in software. But the intent (to enable 50% of the population) is there and the team has worked really hard to attain this goal.

In-office day care - A very significant number of women are forced to give up their careers to support and raise their children. Mostly this is due to lack of a support system (nuclear families), lack of good quality and reliable day care options, or the overwhelming feeling of guilt about leaving your child in their most vulnerable and cute phase. In my opinion it is this guilt which either comes from the family or is self-inflicted, that leads to most women choosing to stay at home.
In an attempt to enable its employees (men or women) and quell the guilt, ThoughtWorks Bangalore office offers in office day care facilities to employees. I'll let the expert let you know more about this (click the link).
Although other offices don't have a dedicated day care facility (as yet) they have always allowed parents to bring in their young ones along with a nanny if they are very young. The offices also have a small children room to help parents. Personally I am rooting for a day care facility to be set-up in my home office of Gurgaon as well, so that I can spend more time with my daughter (guilt free!). 

Must read about another initiative "Vapasi" being run at ThoughtWorks to bring technical women back to work.

The Lateral's guide to the ThoughtWorks Way

Since the time I started blogging I wanted to do a piece on my ThoughtWorks journey but had to put those thoughts to rest once I read Pat Kua's piece. (It's a tough act to follow). So I thought I'll try to put something with a slightly different twist.

I came to ThoughtWorks (TW) after spending 5 years with the likes of the Satyam's and Wipro's and with the strong belief that all IT companies are the same and there is absolutely no hope to find a satisfactory work environment.
I have been with TW for almost 3 years and it took the best part of that time to get acquainted and finally inducted into the culture and I am LOVING IT. 

The thoughts shared below are from my perspective and though these could apply to laterals or freshers my experiences may resound more with the former. 

1. Be ready to be challenged - If you come from one of the typical IT companies you might be used to sharing your thoughts with developers or testers and getting an acceptance with minimal or no questions asked. That's not what you'll get here and be prepared to be challenged about your suggestions and decisions whether you are an MD, Delivery Manager, Customer or any other role. 
2. Be ready to stand up for what you think is right - If you believe that you have the right opinion then don't be afraid to share it (even if it opposes your tech lead/manger) but be ready to back it up with some relevant points because I would hate to take you back to point no. 1.
3. Be ready to share your thoughts, expertise and experience - We believe that knowledge grows through effective sharing so be prepared to be urged and nudged to share your experiences on a project or in life within or outside the company. 
4. Be ready to be heard - The thing I love most about ThoughtWorks is the freedom I have to express my thoughts and opinions without fear of rebuke or reprimand. The only caveat to this would be to ensure that these thoughts/opinions don't offend any community or individual.
5. Get involved or get out - This may sound harsh but there comes a time when you will need to shed your baggage and take a really deep dive into the culture. If you don't, then eventually you'll get fed up and leave.
6. Be ready to own and drive - If you are passionate about something and are willing to back it up with hard work and commitment then you will get all the possible support from TWers including the management. There are many examples of this within TW, the STEP program definitely comes to mind.
7. Be ready to innovate - There is always a different and in many cases better way of carrying out tasks and you need to keep yourself abreast with the latest and continously think about questioning the status quo.
8. Be ready to Introspect and accept - Following the principles of continuous improvement at TW we try to look back at our performances and think about the things that went well and those that didn't so that we can identify the areas to work on and improve ourselves.
9. Be patient - You've probably spent many years learning the wrong way and it will take some time before you truly adapt to the 'ThoughtWorks Way', so be patient.
10. Be ready to think beyond the pay check - This is probably the hardest one to get around and many TWers find this a hard pill to swallow. However, the logic is simple, we want people who are really passionate about what they do or want to achieve and money is not the only thing that gets their motor running. In the end we all work for money but if that's the ONLY thing that motivates you then this may not be the place you'll hang around for too long. 
    
    
    
11. Be ready to start at the bottom - It would be really hard for a lateral hire to take a senior or management role and expect to get immersed in the TW way without getting an opportunity to work closely with one (or multiple) of the project teams and experience the madness first hand. Don't let go of this experience since its probably the only way to quicken the learning curve.
12. Fortune 500's are overrated - We work with the more known brands in the world, but are always more than willing to solve the real life problems for the lesser fortunate. The learnings (via innovative thinking) and experience that you would derive from building a solution that helps children from war ravaged territories reunite with their guardians is immense.
13. Be ready to put on weight - In between all the team outings, ice cream meter redemptions and an over stuffed pantry its literally impossible to avoid putting on a few (too many) pounds.
    The team outings (apart from the food and fun) are the best way to build lasting bonds with your team, so don't miss out. This also seems like the appropriate time for me to market my blog about weight management. :-P
14. We are not laid back - A couple of people looking to join TW have told me that they believe TW is a "laid back" company. Yes, we don't take life as seriously as a lot of people do and that's just because we're a happier bunch but by no means are we laid back. And if that's the impressions that you are going to carry then you are in for a big surprise.
15. We all did the best with the knowledge, expertise and time - We speak our minds and share our thoughts but we always keep the following principle in mind.
    

    "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

The Roy effect

I have been with ThoughtWorks for a little over 2 years and in the many conversations and introspections surrounding the "secret ingredient" of ThoughtWorks, we have concluded that it has been the people who work at ThoughtWorks that have been the driving force. This obviously is true (why would I disagree with this appreciation which also includes me) and the pain and sacrifices that we make in hiring the "right" folks and the efforts we put in to give our best to our customers has played a very important role in making ThoughtWorks what it is. However, there is another element in the mix that deserves a lot of credit for making ThoughtWorks a truly unique organization, an organization that we all are proud to be part of, and that is our founder and chairman Roy Singham. 

Roy Singham

It is again obvious that he in his role as founder and chairman has been instrumental in shaping this organization but I truly appreciated his contributions when I reflected back on what he shared during his recent visit to the Gurgaon office. Mind you, I am not a person who gets swayed very easily and the thoughts that follow have accumulated over the last couple of years hearing and observing Roy.

Roy's ability to articulate his thoughts and beliefs and his passion and energy are enough to stir the human inside you. It's quite difficult to walk out from one of his sessions and not question your own thoughts and beliefs (some of which you may have nurtured for many years).
Roy has always been very passionate and vocal about our contributions to the underprivileged across the globe and has been actively involved in helping out on issues ranging from women and children health in the African subcontinent to the systematic oppression from the power hungry politicians and capitalists across the globe. 

Most of us within ThoughtWorks have heard him on these issues, the interesting part for me is that I have recently realized the vision that he brings to the business and operations of ThoughtWorks. To share a few examples, during his talk where he also shared the roadmap for the coming year he talked about the following:

• Diversify - Diversifying the business (geographically) is by no means a radical thought but one that has been around for a long time and practiced by many organizations. However, in the context of ThoughtWorks and how we hire and engage with our customers (a separate subject on its own) it takes courage to diversify into new territories especially if the new locations are in underdeveloped/developing nations of Africa, Asia and South America.
• Write-offs are not bad - Majority of businesses would target zero write-offs, its natural to expect payment for your services and avoid any form of losses like the plague. As an organization we strive to deliver our best and fulfill our commitments to our customers but we also want to make sure that every once in a while we make a bet on a customer who has an ambitious idea and help it take shape. Its a bet that we need to take and till the time we are able to control our losses we would have gained a lesson that success can never impart.
• Tackle incompetence not the ability to generate numbers - Businesses are run and measured on the Monthly/quarterly/annual revenues and profits they are able to generate. We at ThoughtWorks also care about how we are performing and whether we are running a healthy and sustainable business, but do we only need numbers to measure that? If we hire the right people and are able to motivate and engage them then numbers tend to loose their significance.

Roy Singham

The examples that I shared above are just a few of many that underline Roy's role in making ThoughtWorks what it is. Also, I do realize that most of these points are debatable and we can't be sure of their long-term effectiveness, but what I do realize is that I feel privileged to have been a part of this journey, whatever the end result.

Now, considering that ThoughtWorks aims to be a 100 year organization the one part that does bother me a bit and was the original motivation about writing this piece, is the future. Do we have someone who can uphold the same principles and bring a similar vision, passion, energy and clarity of thought?

Global Service Jam - 2012

The weekend of Feb 26th, 2012 Thoughtworks hosted the Global Service Jam @ Bangalore,  Pune and Gurgaon. 

Being part of the organizing team at the Gurgaon event, I thought I'll share our experiences about this new and rather unique event.

What is Global Service Jam (GSJ) all about?
GSJ is a event held globally on an annual basis (actually this is just their 2nd year) which aims to build upon the concept of service design and give the participants a real world flavor of this concept. GSJ is not a conference and neither is it meant only for techies, for most of us in the IT space service tends to webservices; Service Design is much bigger and better. 

What is Service Design?
Service Design (my borrowed perspective) is a concept that guides and facilitates the management of resources in such a manner that provides a unique and satisfying experience to the consumers of a service. View the better explanation.

What or who is the driving force behind GSJ?
GSJ is run and promoted as a non-profit volunteer activity. The parent organization has virtually no staff and budget. They are just driven to spread the message and get your creative juices flowing.

Ok!!!...but what is this jam sham business???
Well to put this simply you get a group of motivated people with diverse backgrounds and divide them into teams, then you give them a (abstract) theme and 48 hours to brainstorm and prototype a real-life service around the theme. Jammers (aka. participants) are expected to experiment, innovate and cooperate all along the way.

Who would be interested in something like that??
26 in Gurgaon, 80 odd in Bangalore, and 30 odd in Pune. They were furniture designers, Phd scholars, design specialists, product managers, students and even retired individuals. Sadly Thoughtworkers (atleast from Gurgaon) were in short attendance.

Hmmm.. In that case I bet the prizes must have been really Exciting!!
Yes, if you think that interacting with people from different spheres of life to imagine and create innovative solutions and expanding your mental capabilities is worth anything.

What was the outcome?

Day 1 

We started the event in the evening with a keynote address where we focussed on educating the participants on the GSJ, basic concepts of Service Design, and some basic rules of he game. We figured that the since we as organizers were new to the concept we needed to educate the participants. Ice breaker. We planned a fun ice breaker to get the Jammers into the groove and it worked out really well (some people still insist on calling me Just-Mast Jagbir). 
The Jammers were then divided into 3 teams of 8-9, we wanted to keep the numbers high on each team to ensure that the teams could work even if some people opted out. Since this was a first of its kind in India we were not really sure about its uptake till the end. The theme & the ideas This years theme was "Hidden Treasure" and after the initial brainstorming sessions each of the teams were asked to share their ideas with the entire group. The ideas were really impressive and so was the approach taken by the teams to determine them. We ended day 1 here to come back and start afresh. 

Day 2

As mentioned earlier we (organizers) were a little worried about the turnout after the teams had experienced the initial brainstorming sessions. However, response from the Jammers was fantastic and our eyes and hearts brightened with the energy they brought along. We started the day with a small presentation on what was expected from the teams and shared the Business Model Canvas and the prototyping methods to help guide them. We also shared the various concepts from the previous years to help them understand the concept development and prototyping aspects. To our benefit showing the previous years concepts also served as a nice break for the participants. Again the energy and dedication of the Jammers was amazing through out the day and this was visible in their outputs.

Day 3

I had planned to skip the event on Sunday (the wife had a long list of chores lined up) but the enthusiasm of the participants was infectious and I was tempted to see the shape their ideas took. The teams had a bit of a mad dash in the end to finish their prototypes but they just about made it in the end. The quality of their ideas was reflected in their prototypes as well and they once again managed to leave us spell bound. 

To sum it up we loved the energy, enthusiasm, cooperative attitude, excellent quality ideas and their execution. We learnt, we laughed, we mingled,and were left asking for more.... 

 View final presentations here.