Ravindar Gujral's Posts - Agile Philly2024-03-28T23:32:34ZRavindar Gujralhttps://agilephilly.ning.com/profile/RavindarGujralhttps://storage.ning.com/topology/rest/1.0/file/get/1547941771?profile=RESIZE_48X48&width=48&height=48&crop=1%3A1https://agilephilly.ning.com/profiles/blog/feed?user=0obc1v8hlw9oz&xn_auth=noBuilding Trusttag:agilephilly.ning.com,2010-10-25:3783271:BlogPost:34102010-10-25T22:00:45.000ZRavindar Gujralhttps://agilephilly.ning.com/profile/RavindarGujral
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Building Trust as you work with a new team is crucial. To achieve a collaborative work environment, trust has to be built between all the involved parties be it team members or outside stakeholders. Trust helps teams function in a manner…</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Building Trust as you work with a new team is crucial. To achieve a collaborative work environment, trust has to be built between all the involved parties be it team members or outside stakeholders. Trust helps teams function in a manner where they can help each other without fear.</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Trust is all about letting go of human vulnerability. No one on a team wants to admit that they are wrong or they need help. You have to trust your team members and your management so that you can openly admit things you don’t know or understand. If building cross functional teams is important, having trust between team members is crucial to achieving cross functional teams. What you need to do is create a safe zone for the team members.</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;"><strong>Reasons for lack of Trust</strong></span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">There are many reasons for lack of trust on a team. Below is a small list of things I have seen in the past that contribute to lack of trust:</span></p>
<ul style="margin-top: 1.5em; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 2.2em;">
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Individualism (Selfishness leading to hidden agendas) and Lack of mutual respect</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Belief that teams become cohesive when they have an outside enemy, ex, Management is the root of all problems.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Politics</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Defensive Behavior leading to jumping the gun and blaming others or being aggressive.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Managers that are more into evaluating each individuals actions in a team than understand the reasons. This leads to Fear, fear to admit failure or lack of knowledge.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Unhealthy competitions</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Constant team member changes or not having dedicated team members.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Specialization leading to hiding information for the ensuring job security.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">A team leadership that has a know-it-all attitude and arrogance that goes with it.</span></li>
</ul>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">The above problems are, in no particular order, a small list of things you might notice on a team that can contribute to lack of trust. Although we understand that we have to collaborate to build software the issues list above can cause team members to retreat and thus not be part of a functioning team. One of the fundamental reasons leading to these kinds of behaviors is a lack of safety that team members perceive. I have been on teams where team members would confide to me that because of the volatile nature of things, they did not know how long they will have there jobs and so they were really careful in what they said, when they said it etc etc making them risk averse and defensive. This is an extreme case but shows what lack of safety can do. It is one thing to have incompetent team members and another when the management is constantly creating a culture of fear.</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;"><strong>Things you can do</strong></span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Below are some things that I think can help elevate issues due to lack of trust.</span></p>
<ul style="margin-top: 1.5em; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 2.2em;">
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Ensure that you as a coach or team member voice your concerns about lack of safety. If you have a team coach all the better because chances are that he/she will understand what you are saying and will start interfacing with Management and other leadership within the organization to change the culture of fear.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Creating a personal link is crucial to leading people through challenging times so ensure that team members build ties that involve a better understanding of each other. Maybe do exercises like Myers Briggs etc to help everyone in the team understand each other’s nature and behavior.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Establish a common purpose removing personal gain from the equation. Support individuals within and outside team that will help you achieve a more collaborative environment.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">If safety has been an issue set goals in collaboration with the team. You have to let them know that they their view points are important.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">When making decisions start by soliciting everyones buy-in, genuine buy-in, that is not done using brute force but by looking at facts. If you use facts team members will have a way to defend there decisions. I know this can make things slower but in the longer run it will help overall cohesiveness of the team. Also this will help individuals to build mutual respect as now they have to convince each other regarding a particular decision. If decisions are being made in a collaborative way you can be assured of this behavior “<em>Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this(decision) will not be forced upon you at all</em>” – Taiichi Ohno</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Have sessions where you help team members understand each other’s motives and what makes them tick. Deal with relationship issues within and outside team. Your attempt should be to create a cohesive unit not just within the team but with all the stakeholders.</span></li>
</ul>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Trust is the key ingredient to achieving a well functioning cross functional team.</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Cross Post from <a href="http://nostandardwork.com/2010/10/25/building-trust/">my Blog</a></span></p>QA Team Member as an Equaltag:agilephilly.ning.com,2010-08-24:3783271:BlogPost:31662010-08-24T22:30:44.000ZRavindar Gujralhttps://agilephilly.ning.com/profile/RavindarGujral
<div><span class="Apple-style-span" style="font-size: small;">Many organizations give a lot of weight to their developers but neglect their QA departments. There are many misconception about the role of QA. This happens more in bigger organizations where there is a greater emphasis on strict demarcation of responsibilities. This creates a culture of silos. It encourages developers to believe that they are not required to interact with QA. Most developers start thinking that they are better than…</span></div>
<div><span class="Apple-style-span" style="font-size: small;">Many organizations give a lot of weight to their developers but neglect their QA departments. There are many misconception about the role of QA. This happens more in bigger organizations where there is a greater emphasis on strict demarcation of responsibilities. This creates a culture of silos. It encourages developers to believe that they are not required to interact with QA. Most developers start thinking that they are better than QA and that all QA does is to nitpick at the beautiful software the developer has delivered.</span></div>
<div><span class="Apple-style-span" style="font-size: small;"><br/></span></div>
<div><span class="Apple-style-span" style="font-size: small;">Quality Assurance is more than defect recognition or Quality Control. A QA team member combines some unique skills, skills that embrace technical, process and, functional understanding of the system as well as a keen eye towards usability, especially critical for a UI-based system. Software QA (involving QC) is a craft, just like software development, and to think otherwise is to not understand software. Agile practices have helped reduce the misconceptions held regarding QA but there is a serious lack of understanding of the role of QA team members in most organizations, even the ones that adopt agile practices.</span></div>
<div><span class="Apple-style-span" style="font-size: small;"><br/></span></div>
<div><span class="Apple-style-span" style="font-size: small;">So let's review just some of what a QA team member brings to a team, especially an agile team:</span></div>
<div><ul>
<li><span class="Apple-style-span" style="font-size: small;">They interact with the customer and have an in-depth understanding of features being implemented. A good QA team member understands what the system does functionally. They illuminate dark areas of software.</span></li>
<li><span class="Apple-style-span" style="font-size: small;">They interact with the developers, understanding the technical implementation of a feature. They work with the developers to help write valid tests for features being implemented.</span></li>
<li><span class="Apple-style-span" style="font-size: small;">They help understand patterns of implementations and help improve process and consistency of software developed. They help with automation of tests, offering developers the rapid feedback that is necessary as they build software.</span></li>
<li><span class="Apple-style-span" style="font-size: small;">They help developers maintain the quality of the software features being delivered.</span></li>
</ul>
</div>
<div><span class="Apple-style-span" style="font-size: small;">Above points are but a few things that a QA team member provides to a team. If you find that your organization sidelines QA, remind them the importance of QA.</span></div>
<div><span class="Apple-style-span" style="font-size: small;"><br/></span></div>
<div><span class="Apple-style-span" style="font-size: small;">Every organization should put as much time into hiring a QA team member as they put in hiring a developer. QA is a craft that takes years of practice. Your brightest and the smartest team members should consider becoming QA. Also every developer should learn to respect QA team members and treat them as equals.</span></div>Local Motors- A story of integrated developmenttag:agilephilly.ning.com,2010-08-19:3783271:BlogPost:31602010-08-19T01:50:22.000ZRavindar Gujralhttps://agilephilly.ning.com/profile/RavindarGujral
This is a great story of a company that is trying to challenge the existing model of a mass producer building something that everyone consumes. Local Motors is an integrated and a more distributed mechanism to buying cars: <a href="http://www.local-motors.com/videos">http://www.local-motors.com/videos</a>. This company exemplifies the movement towards a more decentralized way of doing things, where you empower not just your employees but the client itself.<div><br></br></div>
<div>I have yet to see…</div>
This is a great story of a company that is trying to challenge the existing model of a mass producer building something that everyone consumes. Local Motors is an integrated and a more distributed mechanism to buying cars: <a href="http://www.local-motors.com/videos">http://www.local-motors.com/videos</a>. This company exemplifies the movement towards a more decentralized way of doing things, where you empower not just your employees but the client itself.<div><br/></div>
<div>I have yet to see a software company do it at this level. The concept is obviously that of ownership and decentralization. If you are part of the process from the start you feel ownership. Now if a manufacturing company can do this challenging an existing and well established industry, why are we in the software industry having such a hard time in letting the client get involved?</div>
<div><br/></div>
<div>I hope you all like this story. If this is a success, this would be a great example of a starfish organization. (Referencing the book: <a href="http://www.starfishandspider.com/">http://www.starfishandspider.com/</a>)</div>On Planningtag:agilephilly.ning.com,2010-05-18:3783271:BlogPost:28662010-05-18T16:33:50.000ZRavindar Gujralhttps://agilephilly.ning.com/profile/RavindarGujral
<p style="margin: 0.0px 0.0px 6.0px 0.0px; line-height: 18.0px; font: 12.5px Arial"></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Let me start this article with a story I heard listening to a presentation by Ricardo Semler: Gary Kasparov, the chess grandmaster, played a computer nicknamed “Deep Thought” sometime in the 1980’s and he won. Deep Thought could think many moves ahead,…</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; line-height: 18.0px; font: 12.5px Arial"></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Let me start this article with a story I heard listening to a presentation by Ricardo Semler: Gary Kasparov, the chess grandmaster, played a computer nicknamed “Deep Thought” sometime in the 1980’s and he won. Deep Thought could think many moves ahead, whereas Kasparov could only think 4-5 moves ahead. So it was concluded that to beat Kasparov, a more powerful computer had to be built that could think many more moves ahead. That’s exactly what IBM did creating “Deep Blue”. Guess what happened: Deep Blue lost. This race went on and on until 1997 when Deep(er) Blue was built. This new enhanced computer could think millions of moves ahead and had all the Grand Master games in its memory. Deep(er) Blue finally defeated Kasparov in a six game match with a score of three draws, two wins and one loss.</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">The simple question to ask is “Why did something that could plan so far ahead in so much detail lose to someone that could only plan 4-5 moves ahead, even if it was 1 game (and 3 draws)?” Maybe it’s intuition that the machine lacked. This matters, but I think a better question is “If planning in that much detail and that far ahead did not make Deep Blue win resoundingly, what makes us think that planning ahead in detail will give us the winning formula with all the variability we have?” Thought provoking, isn’t it?</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Shorter cycle is the solution: I will not go into details as to why short term planning and delivering on those plans is better. I am not saying you don’t need to know what you are trying to achieve (in case of Kasparov, winning a chess match), but the details? I am not sure. Briefly, what does shorter cycle do? A shorter delivery cycle:</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• teaches teams to focus on delivery of things that are really important to the customer</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• teaches removal of waste</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• teaches that one requires a team truly working together</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• requires teams of cathedral builders and not just stonecutters</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• gives you flexibility and agility</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• provides the ability to adapt/change as we learn more details</span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; text-align: justify; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Another reason for shorter cycle is because, to be honest, you can only predict accurately for a short timeframe with the limited set of changing variables that a short timeframe has. The number of variables that affect delivery over a long term is more than anyone can possibly fathom. And more often than not, your plan will be wrong. We all know this. So why waste the time creating a long-term detailed plan? So here are some questions to ask to see if we are getting the benefits that shorter cycles are supposed to deliver:</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• Do teams feel that planning every detail on a long-term basis is essential?</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• Do teams really focus and ensure their delivered software is what the customer really wants?</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• Does the delivered software run in the customer’s environment every month?</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• Are teams building software that will be used immediately in the customer’s business? If not, has the team stopped to ask why?</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e; min-height: 14.0px"><br/></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e; min-height: 14.0px">I guess building software on shorter cycle is important, but to truly change and gain speed, more needs to be done. There must be a change in how we view and think of everything we do. Change so that we do everything in shorter cycle with a rough idea of where we would like to be at the end. Shorter cycles can be assessed and we can make adjustments. We might think we have a complex communication challenge and that detailed planning is required. But maybe the solution is to simplify the challenge.</p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Maybe we need to go beyond software to help us start thinking in shorter cycle. Maybe we should focus on shorter review cycles for everyone. We know market forces are always changing the financial markets. So should we plan in more details? Instead of budgets that plan for a year, maybe we need shorter budget cycle. We have proven that planning a year of budget in advance is not accurate; if they were, we wouldn’t have final month drives at the end of the fiscal year to manage costs and reach financial targets.</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">So maybe we need to bring a shorter plan and shorter cycles in everything we do with a view to the longer term goals we want to achieve</span></p>
<p></p>On Teams- Forming, Changes and Stability: An Opinion piece.tag:agilephilly.ning.com,2009-11-08:3783271:BlogPost:17642009-11-08T04:36:56.000ZRavindar Gujralhttps://agilephilly.ning.com/profile/RavindarGujral
On Teams- Forming, Changes and Stability: An Opinion piece.<br />
<br></br>
Teams are a collection of individuals that come together as a cohesive unit to work on a shared common goal. The group understands that the shared goals and outcomes are achievable if everyone cooperates and works towards a solution as a team, much like being in a lifeboat together. When we are in that boat together we learn to deal with those who are different and to tolerate those we don't like.<br />
<br></br>
This is a basic,…
On Teams- Forming, Changes and Stability: An Opinion piece.<br />
<br/>
Teams are a collection of individuals that come together as a cohesive unit to work on a shared common goal. The group understands that the shared goals and outcomes are achievable if everyone cooperates and works towards a solution as a team, much like being in a lifeboat together. When we are in that boat together we learn to deal with those who are different and to tolerate those we don't like.<br />
<br/>
This is a basic, simplistic view of teams but it is very powerful. Changing teams and moving individuals from one team to another is like throwing people out of the lifeboat. Of course, some individuals like to move frequently, but most like a bit of stability.<br />
<br/>
This kind of change done often enough creates a difficult situation. Any addition or removal of team members creates stresses within the team. As many would agree that the team is effectively a new team if key members are moved frequently. And any new team takes time to become an effective and high performing cohesive group. If changes are made often to a team such that stability is never achieved we never get to the elusive “High Performing Team”. What we will have instead is constant churn. If team change is made every couple of months, we have 1) individuals who do not believe in the concept of team, 2) people who don’t feel that achieving a high performing team is within their grasp, and 3) teams that never settle into a workable rhythm. What we get is a gap between management expectation and reality.<br />
<br/>
One of the very basic understandings that we need to have when forming teams is that we need to “Respect People” and that at the end of the day it is about people. I like this explanation from the Poppendieck’s (<a href="http://www.poppendieck.com">http://www.poppendieck.com</a>):<br />
<br/>
<ul>
<li style="list-style: none"><i>Respect People: Engaged, thinking people provide the most sustainable competitive advantage.</i></li>
<li><i>Teams Thrive on Pride, Commitment, Trust, and Applause.</i> <br/> What makes a team? Members are mutually committed to achieve a common goal.</li>
<li><i>Provide Effective(situational) Leadership</i> <br/> Effective teams have effective leaders who bring out the best in the team.</li>
<li><i>Respect Partners</i><br/> Allegiance to the joint venture must never create a conflict of interest.</li>
</ul>
<br/>
Let us examine each point that is made above. If we respect people we should communicate fully and openly about decisions on team formation and destruction. We need to believe that everyone is a professional and an adult and if provided with information will understand the reasons for changes and decisions. We should also be willing to hear opposition if team members or entire teams disagree with a decision.<br />
<br/>
Teams thrive on pride, commitment, trust and applause. The two most important aspects of this are that teams are trusted to make the right decisions and that individuals trust each other when they are part of a team. Trust is the basis of any interaction within the team or between teams. Replacing trust based interaction with processes that calibrate and measure to ensure correctness of interaction creates an environment of fear where individuals feel that every judgment and decision is questioned. An environment that fosters trust allows individuals to support / accept decisions made by their team members as well as decisions made by others. Obviously trust alone is not enough. The team has to be committed to achieving a shared goal and have pride in what they are doing.<br />
<br/>
Providing Effective Leadership is also important, but the key is to recognize that leadership is situational. Different leaders surface in response to differing situations and circumstances. Thus, static, general-purpose leadership models are not based on reality, nor do they provide methods for shifting power and leadership organically based on the situation. As is very nicely put by Ricardo Semler the way to achieve situational leadership is to give up control. True situational leadership — flexible, effective, and evolutionary — can only arise from self-management, which means always giving up control.<br />
<br/>
Respecting everyone involved in a project whether they are part of your team or another team is the key to achieving a cohesive work unit. This is not to say that common interest or goals won’t cause friction, but that these common goals coupled with trust, effective (situational) leadership and a sense of belonging to a team will ensure that these frictions don’t become personal or become conflicts of interest.<br />
<br/>
The basis of all this is people and as an organization recognizing this aspect is the key. The quote below from Ricardo Semler sums up the recognition that any organization wanting to sustain itself should place on people: “it’s not what Semco makes…it’s the way the people of Semco make it” (1)<br />
<br/>
It is also important to point out that just having teams is not the end of the road, team composition is also important. Innovation and achievement cannot be realized without considering what types of individuals are being brought together as a team. As Jim Collins states in his book, Good to Great(2): “Get the right people on the bus”.<br />
<br/>
--Ravindar<br />
<br/>
PS: A quote I like, which does not really relate to the topic above, but probably will be a topic for my next blog post : "Does it take $600 million to stick another blade between the other two?".<br />
<br/>
<br/>
Reference:<br />
(1)Maverick by Ricardo Semler<br/>
(2)Good To Great by Jim Collins<br/>