<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>HCoder.org &#187; teams</title>
	<atom:link href="http://hcoder.org/tag/teams/feed/" rel="self" type="application/rss+xml" />
	<link>http://hcoder.org</link>
	<description>Just another WordPress weblog</description>
	<lastBuildDate>Thu, 09 Feb 2012 22:15:38 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Book summary: The Jazz Process (IV)</title>
		<link>http://hcoder.org/2011/01/19/book-summary-the-jazz-process-iv/</link>
		<comments>http://hcoder.org/2011/01/19/book-summary-the-jazz-process-iv/#comments</comments>
		<pubDate>Wed, 19 Jan 2011 23:42:39 +0000</pubDate>
		<dc:creator>emanchado</dc:creator>
				<category><![CDATA[Book summaries]]></category>
		<category><![CDATA[books]]></category>
		<category><![CDATA[jazz]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[project]]></category>
		<category><![CDATA[teams]]></category>

		<guid isPermaLink="false">http://hcoder.org/?p=797</guid>
		<description><![CDATA[This is the fourth (and last) part of my summary of &#8220;The Jazz Process&#8221; by Adrian Cho. See also parts one, two and three in this blog. This part will cover the rest of &#8220;Executing&#8221; and &#8220;Innovating&#8221;. Executing: stay healthy It&#8217;s often necessary to build instability to enable high performance (e.g. talented people with troubled [...]]]></description>
			<content:encoded><![CDATA[<p>This is the fourth (and last) part of my summary of &#8220;<a href="http://www.jazzprocess.com/">The Jazz Process</a>&#8221; by Adrian Cho. See also parts <a href="http://hcoder.org/2011/01/16/book-summary-the-jazz-process-i/">one</a>, <a href="http://hcoder.org/2011/01/17/book-summary-the-jazz-process-ii/">two</a> and <a href="http://hcoder.org/2011/01/18/book-summary-the-jazz-process-iii/">three</a> in this blog. This part will cover the rest of &#8220;Executing&#8221; and &#8220;Innovating&#8221;.</p>
<h2>Executing: stay healthy</h2>
<p>It&#8217;s often necessary to build instability to enable high performance (e.g. talented people with troubled personalities). The trick is managing instability so it doesn&#8217;t turn into unrecoverable or damaging situations.</p>
<p>Poor health has an effect on people&#8217;s impression and can create a positive feedback loop. If someone was hurting you or another person, you would tell them to stop immediately. That&#8217;s the reaction people inside a team should have. To stop a positive loop, do everything you can to stop the actions causing the loop; to stop hunting, increase the speed of reaction or increase friction by slowing down and relaxing.</p>
<p>On measuring health: compromised team stability/integrity or poor performance as a result of mistakes or failures indicates problems. It should be possible to create a useful measure of general health for any activity or system. E.g.: number of unresolved defects, number of  incomplete features, performance test results, etc. The problem with those reports is that they can be misused or misinterpreted, esp. if reduced to a traffic light-style of health. It&#8217;s important to take a strategic view and ensure that problems, not symptoms, are addressed.</p>
<h2>Innovating: exchange ideas</h2>
<p>Joy Paul Guilford, American psychologist, defined two types of thinking: convergent (associated to math/science: find a single solution to a problem) and divergent (arts, generating many possible solutions to a problem). The latter, Guilford associated to four skills: fluency (quickly produce large number of solutions), flexibility (simultaneously consider many solutions to the same problem), originality (produce solutions others haven&#8217;t thought of), elaboration (adding to/developing existing solutions).</p>
<p>Diversity can improve the success of innovation, either by producing more initial good ideas or by rejecting the poor ones at the end. Collaboration improves the success of innovation by leveraging free exchange of ideas. This is not always easy to achieve: it&#8217;s not a free-for-all or selecting what&#8217;s the best idea, it&#8217;s creating a common pool by listening, respecting, suspending and voicing (see William Isaacs and p.244).</p>
<p>Innovation is enabled by risk-taking, collaboration, diversity and exchange of ideas. Now, how do you create a culture of innovation? First, people must feel there&#8217;s room for it (not have all time committed to things that absolutely must be done). People often feel they don&#8217;t have the time or freedom (Google&#8217;s 20% time and such). They also must feel there&#8217;s room for mistakes.</p>
<blockquote><p>I&#8217;m so glad you made this mistake. Because I want to run a company where we are moving too quickly and doing too much, not being too cautious and doing too little. If we don&#8217;t have any of these mistakes, we&#8217;re just not taking enough risk.</p>
<p style="text-align: right;">Larry Page</p>
</blockquote>
<p>Also important is to allow/encourage people to form groups for those things and work in whatever they want: top-heavy approaches can stifle innovation, especially if execs aren&#8217;t tuned in or don&#8217;t have the time and become a bottleneck.</p>
<h2>Innovating: take measured risks</h2>
<p>Basic options for risk management: avoid, transfer, share, reduce/mitigate, accept, ignore, exploit. Perils of not enough diversity: one study found that across the entire universe of patients, the single largest indicator of treatment wasn&#8217;t symptoms or background, but the <em>doctor&#8217;s background</em>.</p>
<p>Specific risks of the jazz process principles:</p>
<ul>
<li>Use enough rules. Removing the wrong rules. Some rules guard against mistakes: in that case, compensate with skills or experience.</li>
<li>Employ top talent. Excessive individualism. Also, depending on highly talented people can be a problem if they leave. Another problem is overconfidence (top talent doesn&#8217;t guarantee victory). Finally, not using them wisely (ie. using them for routine tasks).</li>
<li>Putting the team first. Suffocating individualism, and amplifying bad behaviour/thinking (groupthink and polarisation).</li>
<li>Build trust and respect. Trust must be measured and not be blind (the need is proportional to the risk of the trust being misplaced). Always exercise caution and don&#8217;t be afraid to question things.</li>
<li>Leading on demand. Leadership should be granted to people who understand (and will keep) team stability. Also, define protocols for delegating, transferring and initiating leadership. Another risk is that no one will lead: have a default leader.</li>
<li>Act transparently. Early designs might put people off if they&#8217;re too early, and they might not give it a second chance. Transparency can be damaging, annoying or boring if it&#8217;s about the wrong things.</li>
<li>Make contributions count. The only real risk is being too reserved and contributing less.</li>
<li>Reduce friction. It may restrict performance (e.g. you could minimise social friction by repressing all dissenting opinions). It may be tempting to remove things causing friction, but it might be a bad idea: those things might have benefits, so it might be possible to reduce friction without eliminating them.</li>
<li>Stay healthy. The only risk is accepting too much outside help, or too quickly.</li>
<li>Exchange ideas. Focus might be lost, innovation attempts should be directed. When they are directed, the primary concern is introducing instability.</li>
</ul>
<h2>Final comments</h2>
<p>&#8220;The Jazz Process&#8221; is a very good book, recommended to anyone interested in how groups of people can achieve high performance in any activity. It also has many jazz references, which make the book even more interesting if you&#8217;re into jazz. If I had to say something bad about the book, I&#8217;d say that it could be easier to skim if you just want to get information from it (it&#8217;s written to be read from beginning to end, it seems). Of course, if you want to read it the &#8220;traditional way&#8221; it&#8217;s probably an advantage, because it&#8217;s fun reading about jazz and other fields and it makes the reading flow better.</p>
 <p><a href="http://hcoder.org/?flattrss_redirect&amp;id=797&amp;md5=93661de1663dce4de96d152dfbd2d344" title="Flattr" target="_blank"><img src="http://hcoder.org/wp-content/plugins/flattr/img/flattr-badge-large.png" alt="flattr this!"/></a></p>]]></content:encoded>
			<wfw:commentRss>http://hcoder.org/2011/01/19/book-summary-the-jazz-process-iv/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<atom:link rel="payment" href="http://hcoder.org/?flattrss_redirect&amp;id=797&amp;md5=93661de1663dce4de96d152dfbd2d344" type="text/html" />
	</item>
		<item>
		<title>Book summary: The Jazz Process (III)</title>
		<link>http://hcoder.org/2011/01/18/book-summary-the-jazz-process-iii/</link>
		<comments>http://hcoder.org/2011/01/18/book-summary-the-jazz-process-iii/#comments</comments>
		<pubDate>Tue, 18 Jan 2011 21:28:52 +0000</pubDate>
		<dc:creator>emanchado</dc:creator>
				<category><![CDATA[Book summaries]]></category>
		<category><![CDATA[books]]></category>
		<category><![CDATA[jazz]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[project]]></category>
		<category><![CDATA[teams]]></category>

		<guid isPermaLink="false">http://hcoder.org/?p=778</guid>
		<description><![CDATA[This is the third part of my summary of the book “The Jazz Process” by Adrian Cho. You can read parts one and two on this blog. This part will cover the rest of &#8220;Collaborating&#8221; and part of &#8220;Executing&#8221;. Collaborating: lead on demand Two surprising things about leadership: no widespread agreement for the definition and [...]]]></description>
			<content:encoded><![CDATA[<p>This is the third part of my summary of the book “The Jazz Process” by Adrian Cho. You can read parts <a href="http://hcoder.org/2011/01/16/book-summary-the-jazz-process-i/">one</a> and <a href="http://hcoder.org/2011/01/17/book-summary-the-jazz-process-ii/">two</a> on this blog. This part will cover the rest of &#8220;Collaborating&#8221; and part of &#8220;Executing&#8221;.</p>
<h2>Collaborating: lead on demand</h2>
<p>Two surprising things about leadership: no widespread agreement for the definition and we tend to think it&#8217;s the sole responsibility of a small group. The main point in leadership is taking initiative (within your roles or responsibilities). Successful leadership often has a domain, and it&#8217;s not valid in others.</p>
<blockquote><p>Jazz musicians simply cannot let leadership roles remain statically assigned if they want to create interesting, innovative music</p>
<p style="text-align: right;">Adrian Cho</p>
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/Blitzkrieg">Blitzkrieg</a> was successful because of decentralised leadership. Strict, centralised leadership inhibits creativity and agility: the path to success lies in giving up control. [However, have a look at the "<a href="http://en.wikipedia.org/wiki/Blitzkrieg#Controversy">Controversy</a>" section in Wikipedia—Esteban]</p>
<p>Issuing navigational commands is one of the most vital elements of leadership. Taking the first step along a different path is also critically important, and this duty must be shared. People should feel responsible for helping steer and maintain momentum. If any member of the team has ideas about how to improve performance, she should feel empowered to speak out.</p>
<p>Not everyone can lead at the same time, you have to balance individual creativity and team stability. Alternating between leader and follower helps broaden their perception, which results in better leaders <em>and</em> followers.</p>
<h2>Collaborating: act transparently</h2>
<p>Transparency in execution reduces the time for others to (1) observe your actions (and increases the likelihood of it happening), and (2) understand/interpret their impact (increasing accuracy of interpretations). Transparency potentially grows teams, communities and customer bases, as we appreciate honesty, openness and authenticity; we feel naturally curious to know what happens behind the scenes; and it can alleviate fears/concerns about the unknown.</p>
<p>Leaders sometimes assume employees will require only certain information. This is somewhat arrogant, and employees often feel they&#8217;re left in the dark. It also makes groupthink more likely. Openness makes people understand each other&#8217;s problems, important when failures or low performance strike.</p>
<p>A research on plane accidents showed that leaders are far more likely to make mistakes when rushing into action instead of waiting to obtain more information that often can be obtained from other team members. Further research on those results showed that pilots making the right choices routinely had open exchanges with other crew members. Besides, crew members who worked with leaders not promoting open culture were unwilling to intervene in potential accidents even if they had information about it.</p>
<p>Transparency in enabled by authenticity, openness, timeliness and clarity.</p>
<h2>Collaborating: make contributions count</h2>
<p>Recognising valuable contributions rewards and motivates. To make contributions more valuable, people should measure: (1) effort to make <em>and</em> integrating the contribution (not everyone requires the same effort for the value), (2) value of the contribution (the value of a contribution is a function of many things, including the other contributions), (3) impact of integrating the contribution (never underestimate the impact of integrating a contribution).</p>
<p>Making the most with available resources develops resilience in the team. Striving for perfection should not be above all else: mistakes in sports are common, but defeating your opponent is usually more important than an error-free game.</p>
<p>We have to contribute in a way that makes sense for us individually (examples in p.175). By focusing more on quality than quantity, we can spend more time in the observation phase of OODA. The most fundamental thing is that people listen to others and understand enough about the team&#8217;s collective efforts that they can identify and support important contributions. When individuals can measure effort, value and impact, they can time their contributions better.</p>
<h2>Executing: reduce friction</h2>
<p>Countless minor incidents combine to lower performance. Friction is the force that makes the apparently easy so difficult.</p>
<p>Reducing friction can take long. Instead, lubricants can be used: apologising/accepting blame for a mistake, acknowledging facts, making changes that demonstrate willingness to address a problem, giving credit where its due, downplaying mistakes others make.</p>
<p>Too much friction is bad, but too little is also a problem (can lead to hunting).</p>
<h2>Executing: maintain momentum</h2>
<p>Critical mass is enough momentum for an activity to be self-sustaining. To reach this state, considerable effort and resources must be placed, esp. if there&#8217;s resistance.</p>
<p>The most important element of momentum is regularity. People are drawn to the predictability of regular cycles (see &#8220;<a href="http://en.wikipedia.org/wiki/Entrainment_(physics)">entrainment</a>&#8220;, ie. two or more interacting oscillating systems falling into the same period). There are four elements that leverage people affinity to regular cycles:</p>
<ul>
<li>Form: Most activities that require commitment to a goal have a form or structure (examples in p.199). People use the predictability of the form to set goals, time deliveries and shape contributions. It helps coordinate efforts and increase synergy. It&#8217;s important to use a form appropriate for the situation (not too many/few checkpoints).</li>
<li>Tempo: Overall pace. If there are three months to release a feature, but the estimation was six, the team&#8217;s ability to adapt depends on their freedom to set their goals (like dropping parts or reducing performance). When setting a tempo, take into account the goals, abilities of individual team members and the flexibility of their processes.</li>
<li>Pulse: Like a heartbeat. It&#8217;s a constant event that drives and helps the team keep in sync with the tempo. It&#8217;s always a function of the tempo.</li>
<li>Groove: A function of the pulse. Set of essential, fundamental activities that are repeated with respect to the pulse (examples in p.207-209). It invites people to participate and align their contributions with it. It&#8217;s most effective when simple and clear to everyone.</li>
</ul>
<p>In software, a project manager may set all four (esp. the first two), and component team leaders define specific grooves inside their own teams.</p>
<p>Looking ahead for potential issues and addressing them before they become problems helps avoiding losing momentum, but strike a balance between planning and reacting. Other advice: (1) add weight to a contribution to give it greater significance, esp. in slower tempos; and (2) prepare an important contribution with a preceding smaller contribution.</p>
<p>And this is all for the third part. The next will be the last one, and will cover the rest of &#8220;Executing&#8221;, and &#8220;Innovating&#8221;.</p>
 <p><a href="http://hcoder.org/?flattrss_redirect&amp;id=778&amp;md5=040d1c7d1675c72446b273cbcc2d2288" title="Flattr" target="_blank"><img src="http://hcoder.org/wp-content/plugins/flattr/img/flattr-badge-large.png" alt="flattr this!"/></a></p>]]></content:encoded>
			<wfw:commentRss>http://hcoder.org/2011/01/18/book-summary-the-jazz-process-iii/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<atom:link rel="payment" href="http://hcoder.org/?flattrss_redirect&amp;id=778&amp;md5=040d1c7d1675c72446b273cbcc2d2288" type="text/html" />
	</item>
		<item>
		<title>Book summary: The Jazz Process (II)</title>
		<link>http://hcoder.org/2011/01/17/book-summary-the-jazz-process-ii/</link>
		<comments>http://hcoder.org/2011/01/17/book-summary-the-jazz-process-ii/#comments</comments>
		<pubDate>Mon, 17 Jan 2011 22:34:49 +0000</pubDate>
		<dc:creator>emanchado</dc:creator>
				<category><![CDATA[Book summaries]]></category>
		<category><![CDATA[books]]></category>
		<category><![CDATA[jazz]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[project]]></category>
		<category><![CDATA[teams]]></category>

		<guid isPermaLink="false">http://hcoder.org/?p=749</guid>
		<description><![CDATA[This is the second part of my summary of the book &#8220;The Jazz Process&#8221; by Adrian Cho. You can read part one on this blog. This part will cover the rest of &#8220;Working&#8221; and half of &#8220;Collaborating&#8221;. Working: build trust and respect Trust and respect are binding agents that keep a team together and help [...]]]></description>
			<content:encoded><![CDATA[<p>This is the second part of my summary of the book &#8220;<a href="http://www.jazzprocess.com/">The Jazz Process</a>&#8221; by Adrian Cho. You can read <a href="http://hcoder.org/2011/01/16/book-summary-the-jazz-process-i/">part one</a> on this blog. This part will cover the rest of &#8220;Working&#8221; and half of &#8220;Collaborating&#8221;.</p>
<h2>Working: build trust and respect</h2>
<p>Trust and respect are binding agents that keep a team together and help it maintain strong and healthy relationships. The mutual dependence that binds a team together requires that each member trust the other members to do their parts. This trust gives them freedom to work, and this freedom is especially important if their approach to a task differs from that of others. When people make great efforts, deliver under bad conditions or excel, they generate respect, and feeling respected makes them correct mistakes and take extra steps for a stand-out work.</p>
<p>The book &#8220;The Speed of Trust&#8221; explores the idea that trust affects the speed and cost of operations: things move faster and costs are lower. In activities where time can be sacrificed, there are delays (and often increased costs). When time is fixed, quality may suffer.</p>
<p>One way to build trust is with transparency, indicating intentions and actions clearly. Trust and respect can only be built with genuine, uncompromised communication. People can&#8217;t trust if they don&#8217;t know the <em>person</em> or its contributions to the team, and they&#8217;re less likely to trust the <em>team</em> if they don&#8217;t know how it&#8217;s going. For the latter, collecting metrics is useful, but they aren&#8217;t enough for themselves for building trust and respect, so personal messages are needed too. And those have to be genuine: company-wide broadcasts are often ignored. Being straight and direct (Warren Buffet examples on p.64,65) is important. Don&#8217;t try to make the company look good or hide mistakes.</p>
<p>Building trust and respect is hard, but losing it is easy. To avoid losing it or to restore it, accept accountability for mistakes and make it a priority to correct them whenever possible. Failing to do so may make the problem bigger. When mistakes are unavoidable, communicate the circumstances clearly to all parties. Accepting responsibility is not just apologising, you must acknowledge your understanding of the problem and you role in it. The worst kind of mistake is when the person making it doesn&#8217;t realise or (even worse) pretends it didn&#8217;t happen.</p>
<h2>Working: commit with passion</h2>
<p>Companies wonder why their employees aren&#8217;t more committed, when they should wonder what they can do to achieve a higher level of commitment from their employees. Top-talented people often have strong motivation. One has to try not to undermine that motivation. Nobody likes to work for an underperforming team or a failing project. It&#8217;s easy to contribute when there&#8217;s high level of activity. If you make a mistake, you have the team to back you up (examples in p.73).</p>
<p>Often companies use artificial means to motivate employees: team-building and inspirational speeches. They may help in short-term but not solve underlying problems in a team. Actually they may frustrate people.</p>
<h2>Essentials of execution (Intro to Collaborating)</h2>
<p>Feedback loop is the process in which part of output is fed to the input. A positive feedback loop is self-reinforcing or synergistic. Another interesting phenomenon is &#8220;hunting&#8221; (oscillating indefinitely when trying to correct a mistake):</p>
<ul>
<li><em>Hunting case 1: trying too hard</em>. Being nervous or overconcentrated in a goal causes us to fail, because of overzealous correction. Solution: back off, relax, avoiding trying too hard.</li>
<li><em>Hunting case 2: reacting too slowly</em>. When we take too long to react to feedback. When we react, the correction is not enough or valid.</li>
</ul>
<p>The <a href="http://en.wikipedia.org/wiki/OODA_Loop">OODA loop</a> was conceived by fighter pilot <a href="http://en.wikipedia.org/wiki/John_Boyd_(military_strategist)">John Boyd</a>: Observe (get data), Orient (analyse/synthesise it), Decide (determine course of action), Act (implement decision). He was convinced that success in <a href="http://en.wikipedia.org/wiki/Dogfight">dogfights</a> came from superior decisions and executing them more quickly: the pilot that goes through OODA in the shortest time wins.</p>
<p><a href="http://en.wikipedia.org/wiki/Blitzkrieg">Blitzkrieg</a> gave unit commanders more autonomy, improving agility. Instead of waiting for explicit orders, they knew the strategic intents and could use their creativity and initiative.</p>
<h2>Collaborating: listen for change</h2>
<p>The aim of observing is getting relevant data for decisions, and it begins with unimpeded field of view. We tend to limit ourselves (tunnel vision), must work on peripheral vision: beginning with the end in mind (example in p.105,106). To improve execution, expand your field of data, but learn how to filter the noise. Considerations for observing:</p>
<ol>
<li><em>Cognitive biases</em>. We see what we want to see (confirmation bias), avoid/discount information that contradicts our ideas (disconfirmation bias), pretend not to see things we rather not see (selection bias), interpret information to suit our needs (assimilation bias), take decisions based on previous experience that we don&#8217;t recall correctly (selective memory). These biases often result from <a href="http://en.wikipedia.org/wiki/Cognitive_dissonance">cognitive dissonance</a>, and aren&#8217;t only for individuals: groups can polarise (making more extreme decisions).</li>
<li><em>Thinking outside the box</em>. We are encouraged to expect the unexpected: that is really about being agile enough to respond to unexpected problems.</li>
</ol>
<p>One of the most important pieces of info in any situation is a score, a measure of how well you&#8217;re doing. Successful teams need to know how they&#8217;re doing, but beware of management by numbers (they should never be the only input for decision-making). The most important figures for management are unknown or unknowable. For a score to be useful, it must be consistent over time, everyone must agree that the score is useful and fair, limitations/caveats in it must be well documented, and the team must understand the relation between their efforts and the score.</p>
<p>Paths that lead to success change over time, keeping the same path is not good long-term.</p>
<p>And that&#8217;s it for now. Next part will cover the rest of &#8220;Collaborating&#8221; and part of &#8220;Executing&#8221;.</p>
 <p><a href="http://hcoder.org/?flattrss_redirect&amp;id=749&amp;md5=b524ff2ad35bbc1e5e8bbe466b4c406a" title="Flattr" target="_blank"><img src="http://hcoder.org/wp-content/plugins/flattr/img/flattr-badge-large.png" alt="flattr this!"/></a></p>]]></content:encoded>
			<wfw:commentRss>http://hcoder.org/2011/01/17/book-summary-the-jazz-process-ii/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		<atom:link rel="payment" href="http://hcoder.org/?flattrss_redirect&amp;id=749&amp;md5=b524ff2ad35bbc1e5e8bbe466b4c406a" type="text/html" />
	</item>
		<item>
		<title>Book summary: The Jazz Process (I)</title>
		<link>http://hcoder.org/2011/01/16/book-summary-the-jazz-process-i/</link>
		<comments>http://hcoder.org/2011/01/16/book-summary-the-jazz-process-i/#comments</comments>
		<pubDate>Sun, 16 Jan 2011 20:54:28 +0000</pubDate>
		<dc:creator>emanchado</dc:creator>
				<category><![CDATA[Book summaries]]></category>
		<category><![CDATA[books]]></category>
		<category><![CDATA[jazz]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[project]]></category>
		<category><![CDATA[teams]]></category>

		<guid isPermaLink="false">http://hcoder.org/?p=727</guid>
		<description><![CDATA[This is the first part of my summary of the book &#8220;The Jazz Process&#8221; by Adrian Cho (official website, Goodreads page), about high-performance teams. EDIT: see parts two, three and four. It has examples and stories from jazz, basketball, the military, and others. The book is divided into five sections: introduction, working, collaborating, executing and [...]]]></description>
			<content:encoded><![CDATA[<p>This is the first part of my summary of the book &#8220;The Jazz Process&#8221; by <a href="http://www.adriancho.com/">Adrian Cho</a> (<a href="http://www.jazzprocess.com/">official website</a>, <a href="http://www.goodreads.com/book/show/7759952-the-jazz-process">Goodreads page</a>), about high-performance teams. <strong>EDIT:</strong> <em>see parts <a href="http://hcoder.org/2011/01/17/book-summary-the-jazz-process-ii/">two</a>, <a href="http://hcoder.org/2011/01/18/book-summary-the-jazz-process-iii/">three</a> and <a href="http://hcoder.org/2011/01/19/book-summary-the-jazz-process-iv/">four</a></em>. It has examples and stories from jazz, basketball, the military, and others. The book is divided into five sections: introduction, working, collaborating, executing and innovating. Each section except the introduction has a series of &#8220;rules&#8221; that comprise the Jazz process.</p>
<p>This first part of the summary will cover the introduction and the first half of &#8220;Working&#8221;. Also, as this book has so many interesting quotes, I&#8217;m going to use some of them in this summary. They&#8217;re not part of the summary strictly speaking, so you can just skip them if you want.</p>
<h2>Introduction</h2>
<blockquote><p>I used to think that running an organisation was equivalent to conducting a symphony orchestra. But I don&#8217;t think that&#8217;s quite it; it&#8217;s more like jazz. There is more improvisation. Someone once wrote that the sound of surprise is jazz, and if there&#8217;s one thing that we must try to get used to in this world, it&#8217;s surprise and the unexpected. In this world of chaos, there&#8217;s no other way of doing things. Truly, we are living in a world where the only thing that&#8217;s constant is change.</p>
<p style="text-align: right;">Warren Bennis</p>
</blockquote>
<blockquote><p>The model of management that we have right now is the opera. The conductor of the opera has a very large number of different groups that he has to pull together. The soloists, the chorus, the ballet, the orchestra, all have to come together—but they have a common score. What we are increasingly talking about today are diversified groups that have to write the score while they perform.</p>
<p>What you need now is a good jazz group.</p>
<p style="text-align: right;">Peter Drucker</p>
</blockquote>
<p>People miss two things about jazz improvisation: it&#8217;s based on years of training and experience (it&#8217;s not just &#8220;making things up&#8221;) and the greater goal is to create something unique (innovate). This quest for innovation is always balanced against their responsibilities, like supporting the other musicians. The skill of improvisation should be as highly prized in business as in jazz. More than ever, responding to the unexpected is important.</p>
<blockquote><p>[Talking about basketball and jazz] the team&#8217;s performance emerges from a chain reaction of individual acts. So much of what makes jazz great is the unique chemistry among individual players [...]</p>
<p style="text-align: right;">R. Keith Sawyer</p>
</blockquote>
<blockquote><p>And if you want to have a really good jazz group, how large can it be? [...] You can use seven to nine people—maximum. If you get more, you have to score.</p>
<p style="text-align: right;">Peter Drucker</p>
</blockquote>
<p>Big groups make it hard to express yourself without appearing obviously non-conforming.</p>
<h2>Working: use just enough rules</h2>
<p>To maximise performance, you need <em>just enough</em> rules to afford autonomy, while avoiding chaos. Autonomy is the independence and freedom that enables people to act individually. It facilitates agility as it limits constraints. Individual expression is essential to improvisation and innovation. The goal when defining a process is allowing the team to be agile and innovative, while addressing the success factors of the team&#8217;s business.</p>
<p>Rarely a single set of rules apply equally to every situation and for every person. The exact set of rules or the importance of each one will vary over time (example in p.25). Thus, process <em>improvement</em> is critical to <em>long-term</em> success.</p>
<p>If there&#8217;s a strict rule,  people must have a very good reason to break it. But more important is understanding the implications of doing it: breaking the rule might not be a problem, but not knowing that you&#8217;re doing it or not being able to explain the need to do it, probably is. If a rule is consistently broken, maybe it should be a convention instead. If on top of that, breaking it doesn&#8217;t cause problems, maybe it should be removed.</p>
<h2>Working: employ top talent</h2>
<p>Experienced and skilled people can adapt to almost any situation, even in new teams. Established but fundamentally weak teams can be good in a given setting, but in front of the unexpected the weaknesses will be revealed.</p>
<p>Duke Ellington wrote his pieces for concrete players, not for &#8220;Trumpet 1&#8243; and &#8220;Trumpet 2&#8243;. Same with Shakespeare. They considered the unique strengths of the performers and wrote parts featuring their greatest talents. The individualism of the musicians, channelled through Duke Ellington is what give greatness and uniqueness to the composition.</p>
<p>Individuality is about self-expression and creativity, but also about playing a unique part without backup. The team is as strong as the weakest link.</p>
<p>One of the most important skills of highly effective people is their ability to allocate a good portion of their personal bandwidth to collaboration. Inventors rarely make discoveries in isolation. The more proficient we are at our routine tasks, the more aware we are of our surroundings.</p>
<p>When building a team, quality over quantity. In lean teams, the problem is that there&#8217;s no redundancy, each member is a more critical resource.</p>
<h2>Working: put the team first</h2>
<blockquote><p>In jazz, the musicians are accountable not only to the leader of the group, but to every person in the group and to the ensemble as a whole</p>
<p style="text-align: right;">Adrian Cho</p>
</blockquote>
<p>When a team has many strong individuals, each with distinctly specialised skills and experience, cross-fertilisation among individuals can unify the team. Special forces team members usually have a core speciality, but everyone in the team knows something about everyone else&#8217;s expertise. It&#8217;s the job of each specialist to conduct the training. This approach can both generate respect between team members and build redundancy that increases the robustness of the team.</p>
<p>The ability of every individual in the team to put the team first is often tested in a time of crisis (examples in p.50). The ability to absorb mistakes is one of the most important capabilities of an effective team: it succeeds and takes credit together, or fails and takes the blame together. No group ever becomes a team until it can hold itself accountable as a team. Another way to demonstrate cohesiveness is through willingness to tackle a challenge or traverse a risky path.</p>
<p>One potential problem of putting the team first is groupthink: abandoning individual creativity and critical thinking. The team may thus fail to innovate. This may be exacerbated by the tendency to self-select like-minded people and get rid of those who don&#8217;t think like the team. Ensure that people always feel empowered to speak out.</p>
<blockquote><p>It&#8217;s the group sound that&#8217;s important, even when you&#8217;re playing a solo. You not only have to know your own instrument, you must know the others and how to back them up at all times. That&#8217;s jazz.</p>
<p style="text-align: right;">Oscar Peterson</p>
</blockquote>
<p>Focusing on the team helps people recognise the value of everyone&#8217;s contributions. It&#8217;s important that leaders and stars that get the praise acknowledge the contributions of colleagues. Acknowledging everyday heroes builds trust and empowers every member of the team to achieve higher levels of performance.</p>
<p>When a high-performance team exists within larger teams or organisations that are less productive, there&#8217;s the danger of tension. Putting the team first is not just for the immediate team, but for the larger organisation.</p>
<blockquote><p>Nobody in the SAS [Special Air Service] looks down on any other unit of the army as being less important; no regiment in the entire army is so well aware of the essential attributes of what are often dismissed contemptuously as &#8220;administrative&#8221; troops.</p>
<p>The SAS man, the fighting soldier par excellence, suffers from no delusions about his own importance. He knows his role is vital but he knows that a cipher clerk, or a cartographer, or even the skill of the opposing general&#8217;s cook, may in fact be more important to the success of the campaign than quite a number of daring soldiers.</p>
<p style="text-align: right;">Philip Warner</p>
</blockquote>
 <p><a href="http://hcoder.org/?flattrss_redirect&amp;id=727&amp;md5=d9648b03d8b20ca10be6b8a5ac32cf42" title="Flattr" target="_blank"><img src="http://hcoder.org/wp-content/plugins/flattr/img/flattr-badge-large.png" alt="flattr this!"/></a></p>]]></content:encoded>
			<wfw:commentRss>http://hcoder.org/2011/01/16/book-summary-the-jazz-process-i/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		<atom:link rel="payment" href="http://hcoder.org/?flattrss_redirect&amp;id=727&amp;md5=d9648b03d8b20ca10be6b8a5ac32cf42" type="text/html" />
	</item>
		<item>
		<title>Feeling the pressure produces better code?</title>
		<link>http://hcoder.org/2009/12/06/feeling-the-pressure-produces-better-code/</link>
		<comments>http://hcoder.org/2009/12/06/feeling-the-pressure-produces-better-code/#comments</comments>
		<pubDate>Sun, 06 Dec 2009 16:10:00 +0000</pubDate>
		<dc:creator>emanchado</dc:creator>
				<category><![CDATA[Computers]]></category>
		<category><![CDATA[automated]]></category>
		<category><![CDATA[exploratory]]></category>
		<category><![CDATA[qa]]></category>
		<category><![CDATA[teams]]></category>
		<category><![CDATA[testing]]></category>
		<category><![CDATA[tests]]></category>
		<category><![CDATA[unit]]></category>

		<guid isPermaLink="false"></guid>
		<description><![CDATA[The other day I was in a conversation with some developer that was complaining about some feature. He claimed that it was too complex and that it had led to tons of bugs. In the middle of the conversation, the developer said that the feature had been so buggy that he ended up writing a [...]]]></description>
			<content:encoded><![CDATA[<p>The other day I was in a conversation with some developer that was complaining about some feature. He claimed that it was too complex and that it had led to tons of bugs. In the middle of the conversation, the developer said that the feature had been so buggy that he ended up writing a lot of unit tests for it. To be honest I don&#8217;t think there were a lot of bugs <em>after</em> those tests were written, so that made me think:</p>
<blockquote><p>Maybe the testers in his team are doing too good of a job?</p></blockquote>
<p>
Because, you know, if testers are finding enough of &#8220;those bugs&#8221; (the ones that should be caught and controlled by unit tests and not by testers <em>weeks</em> after the code was originally written), maybe some developers are just not &#8220;feeling the pressure&#8221; and can&#8217;t really get that they should be writing tests for their code. If testers are very good, things just work out fine in the end&#8230; sort of. And of course, the problem here is the trailing &#8220;sort of&#8221;.<br />
I know I&#8217;m biased, but in my view there is a <strong>ton</strong> of bugs that should never be seen by someone that is not the developer itself. Testers should deal with more complex, interesting, user-centred bugs. Non-trivial cases. Suboptimal UIs. Implementation disagreements between developers and stakeholders. That kind of thing. It&#8217;s simply a waste of time and resources that testers have to deal with silly, easy-to-avoid bugs on a daily basis. Not to mention that teams shouldn&#8217;t have to wait for days or weeks until they find <em>basic</em> bugs via exploratory testing. Or that a lot of those are much, much quicker to test with unit tests than having to create the whole fixture/environment for them to be found with exploratory testing.<br />
My current conclusion is that pushing on the UI/usability side is not only good for the user, but it&#8217;s likely to produce better code as it will be, on average, more complex and will have to be better controlled by QA (code review, less ad-hoc design, &#8230;) and automated tests. Maybe developers will start hating me for that, but hopefully <em>users</em> will thank me.</p>
 <p><a href="http://hcoder.org/?flattrss_redirect&amp;id=81&amp;md5=51f8ccaa005170cc7a643f0cb4c2a30c" title="Flattr" target="_blank"><img src="http://hcoder.org/wp-content/plugins/flattr/img/flattr-badge-large.png" alt="flattr this!"/></a></p>]]></content:encoded>
			<wfw:commentRss>http://hcoder.org/2009/12/06/feeling-the-pressure-produces-better-code/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<atom:link rel="payment" href="http://hcoder.org/?flattrss_redirect&amp;id=81&amp;md5=51f8ccaa005170cc7a643f0cb4c2a30c" type="text/html" />
	</item>
	</channel>
</rss>

