Team-Topologies-references-Endnote.xml

<?xml version="1.0" encoding="UTF-8"?>
<xml><records><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Sosa, Manuel E.</author><author>Eppinger, Steven D.</author><author>Rowles, Craig M.</author></authors></contributors><titles><title>The Misalignment of Product Architecture and Organizational Structure in Complex Product Development</title><secondary-title>Management Science</secondary-title></titles><periodical><full-title>Management Science</full-title><abbr-1>Management Science</abbr-1></periodical><pages>1674-1689</pages><volume>50</volume><number>12</number><issue>12</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>2004</year><pub-dates><date>December 1, 2004</date></pub-dates></dates><isbn>0025-1909</isbn><electronic-resource-num>10.1287/mnsc.1040.0289</electronic-resource-num><abstract>Product architecture knowledge is typically embedded in the communication patterns of established development organizations. While this enables the development of products using the existing architecture, it hinders the organization's ability to implement novel architectures, especially for complex products. Structured methods addressing this issue are lacking, as previous research has studied complex product development from two separate perspectives: product architecture and organizational structure. Our research integrates these viewpoints with a structured approach to study how design interfaces in the product architecture map onto communication patterns within the development organization. We investigate how organizational and system boundaries, design interface strength, indirect interactions, and system modularity impact the alignment of design interfaces and team interactions. We hypothesize and test how these factors explain the existence of the following cases: (1) known design interfaces not addressed by team interactions, and (2) observed team interactions not predicted by design interfaces. Our results offer important insights to managers dealing with interdependences across organizational and functional boundaries. In particular, we show how boundary effects moderate the impact of design interface strength and indirect team interactions, and are contingent on system modularity. The research uses data collected from a large commercial aircraft engine development process.</abstract><remote-database-name>pubsonline.informs.org (Atypon)</remote-database-name><urls><web-urls><url>https://pubsonline.informs.org/doi/abs/10.1287/mnsc.1040.0289</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\LFX4UP2D\Sosa et al. - 2004 - The Misalignment of Product Architecture and Organ.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\HX3KUJAM\mnsc.1040.html</url></text-urls></urls><access-date>2018-11-03 21:47:13</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>McChrystal, General Stanley</author><author>Silverman, David</author><author>Collins, Tantum</author><author>Fussell, Chris</author></authors></contributors><titles><title>Team of Teams: New Rules of Engagement for a Complex World</title><short-title>Team of Teams</short-title></titles><pages>304</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>26 Nov. 2015</date></pub-dates></dates><pub-location>New York, NY</pub-location><publisher>Portfolio Penguin</publisher><isbn>978-0-241-25083-9</isbn><abstract>As commander of Joint Special Operations Command (JSOC), General Stanley McChrystal discarded a century of management wisdom and pivoted from a pursuit of mechanical efficiency to organic adaptability. In this book, he shows how any organization can make the same transition to act like a team of teams - where small groups combine the freedom to experiment with a relentless drive to share their experience.Drawing on a wealth of evidence from his military career and sources as diverse as hospital emergency rooms and NASA's space program, McChrystal frames the existential challenge facing today's organizations, and presents a compelling, effective solution.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Team-Teams-Rules-Engagement-Complex/dp/0241250838</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Dunbar, R. I. M.</author></authors></contributors><titles><title>Neocortex size as a constraint on group size in primates</title><secondary-title>Journal of Human Evolution</secondary-title></titles><periodical><full-title>Journal of Human Evolution</full-title><abbr-1>Journal of Human Evolution</abbr-1></periodical><pages>469-493</pages><volume>22</volume><number>6</number><issue>6</issue><keywords><keyword>behavioural ecology</keyword><keyword>body size</keyword><keyword>brain size</keyword><keyword>grooming</keyword><keyword>social intellect</keyword><keyword>TT refs</keyword></keywords><dates><year>1992</year><pub-dates><date>June 1, 1992</date></pub-dates></dates><isbn>0047-2484</isbn><electronic-resource-num>10.1016/0047-2484(92)90081-J</electronic-resource-num><abstract>Two general kinds of theory (one ecological and one social) have been advanced to explain the fact that primates have larger brains and greater congnitive abilities than other animals. Data on neocortex volume, group size and a number of behavioural ecology variables are used to test between the various theories. Group size is found to be a function of relative neocortical volume, but the ecological variables are not. This is interpreted as evidence in favour of the social intellect theory and against the ecological theories. It is suggested that the number of neocortical neurons limits the organism's information-processing capacity and that this then limits the number of relationships that an individual can monitor simultaneously. When a group's size exceeds this limit, it becomes unstable and begins to fragment. This then places an upper limit on the size of groups which any given species can maintain as cohesive social units through time. The data suggest that the information overload occurs in terms of the structure of relationships within tightly bonded grooming cliques rather than in terms of the total number of dyads within the group as a whole that an individual has to monitor. It thus appears that, among primates, large groups are created by welding together sets of smaller grooming cliques. One implication of these results is that, since the actual group size will be determined by the ecological characteristics of the habitat in any given case, species will only be able to invade habitats that require larger groups than their current limit if they evolve larger neocortices.</abstract><remote-database-name>ScienceDirect</remote-database-name><urls><web-urls><url>http://www.sciencedirect.com/science/article/pii/004724849290081J</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\DBXXV44R\004724849290081J.html</url></text-urls></urls><access-date>2018-11-02 19:19:54</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Casella, Karen</author></authors></contributors><titles><title>Improving Team Productivity by Reducing Context Switching | LinkedIn</title><secondary-title>LinkedIn Pulse</secondary-title></titles><periodical><full-title>LinkedIn Pulse</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016-10-26</date></pub-dates></dates><urls><web-urls><url>https://www.linkedin.com/pulse/improving-team-productivity-reducing-context-karen-casella/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\NSUUWJMW\improving-team-productivity-reducing-context-karen-casella.html</url></text-urls></urls><access-date>2017-10-09 19:53:52</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Skelton, Matthew</author></authors></contributors><titles><title>Icebreaker for Agile Retrospectives – Empathy Snap</title><secondary-title>Matthew Skelton</secondary-title></titles><periodical><full-title>Matthew Skelton</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>2012-11-15T19:35:56+00:00</date></pub-dates></dates><abstract>I was invited by one of our London dev teams to facilitate their retrospective yesterday. I’m far from an expert in facilitating retros, although I enjoy it, and I find that I learn a huge amount f…</abstract><language>en</language><urls><web-urls><url>http://empathysnap.com/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\3WUB82YS\icebreaker-for-agile-retrospectives-empathy-snap.html</url></text-urls></urls><access-date>2018-10-30 22:13:47</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Kelly, Allan</author></authors></contributors><titles><title>Conway's Law v. Software Architecture</title><secondary-title>dzone.com</secondary-title></titles><periodical><full-title>dzone.com</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2013</year><pub-dates><date>14 March 2013</date></pub-dates></dates><abstract>I've written about Conway's Law before (Return to Conway’s Law (2006) and a Focus Group I ran at EuroPLoP “What do we think of Conway’s Law Now?”) But I make no...</abstract><language>en</language><urls><web-urls><url>https://dzone.com/articles/conways-law-v-software</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\LXVJPATG\conways-law-v-software.html</url></text-urls></urls><access-date>2018-10-30 18:01:56</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Neumark, Peter</author></authors></contributors><titles><title>DevOps &amp; Product Teams - Win or Fail?</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>29 June 2015</date></pub-dates></dates><abstract>Peter Neumark found a new world when he moved from a DevOps infrastructure team to a Lean product team.How to experiment frequently while keeping operational performance? Platform teams to the rescue!</abstract><urls><web-urls><url>https://www.infoq.com/articles/devops-product-teams</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\XFCDAPW2\devops-product-teams.html</url></text-urls></urls><access-date>2016-08-11 19:04:29</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Snowden, Dave</author></authors></contributors><titles><title>The rule of 5,15 &amp; 150</title><secondary-title>Cognitive Edge</secondary-title></titles><periodical><full-title>Cognitive Edge</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2006</year><pub-dates><date>2006-12-10T15:21:31+00:00</date></pub-dates></dates><abstract>Recognise it? Well of course, it’s the best-fit reduced major axis regression equation between neocortex…</abstract><urls><web-urls><url>http://cognitive-edge.com/blog/logn-0-093-3-389-logcr-1-r20-764-t3410-35-p0-001/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\SWFX2CGN\logn-0-093-3-389-logcr-1-r20-764-t3410-35-p0-001.html</url></text-urls></urls><access-date>2016-08-11 19:16:07</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Ingles, Paul</author></authors></contributors><titles><title>Convergence to Kubernetes</title><secondary-title>Paul Ingles</secondary-title></titles><periodical><full-title>Paul Ingles</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-06-18T20:48:10.012Z</date></pub-dates></dates><abstract>Standardisation to Scale</abstract><urls><web-urls><url>https://medium.com/@pingles/convergence-to-kubernetes-137ffa7ea2bc</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\Q3NGIXLX\convergence-to-kubernetes-137ffa7ea2bc.html</url></text-urls></urls><access-date>2018-10-29 22:42:29</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Humble, Jez</author><author>Farley, David</author></authors></contributors><titles><title>Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation</title><short-title>Continuous Delivery</short-title></titles><pages>512</pages><edition>01 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2010</year><pub-dates><date>27 July 2010</date></pub-dates></dates><pub-location>Upper Saddle River, NJ</pub-location><publisher>Addison Wesley</publisher><isbn>978-0-321-60191-9</isbn><abstract>Winner of the 2011 Jolt Excellence Award!Getting software released to users is often a painful, risky, and time-consuming process.This groundbreaking new book sets out the principles and technical practices that enablerapid, incremental delivery of high quality, valuable new functionality to users. Throughautomation of the build, deployment, and testing process, and improved collaboration betweendevelopers, testers, and operations, delivery teams can get changes released in a matter of hours―sometimes even minutes–no matter what the size of a project or the complexity of its code base. Jez Humble and David Farley begin by presenting the foundations of a rapid, reliable, low-riskdelivery process. Next, they introduce the “deployment pipeline,” an automated process formanaging all changes, from check-in to release. Finally, they discuss the “ecosystem” needed tosupport continuous delivery, from infrastructure, data and configuration management to governance. The authors introduce state-of-the-art techniques, including automated infrastructure managementand data migration, and the use of virtualization. For each, they review key issues, identify bestpractices, and demonstrate how to mitigate risks. Coverage includes • Automating all facets of building, integrating, testing, and deploying software• Implementing deployment pipelines at team and organizational levels• Improving collaboration between developers, testers, and operations• Developing features incrementally on large and distributed teams• Implementing an effective configuration management strategy• Automating acceptance testing, from analysis to implementation• Testing capacity and other non-functional requirements• Implementing continuous deployment and zero-downtime releases• Managing infrastructure, data, components and dependencies• Navigating risk management, compliance, and auditing Whether you’re a developer, systems administrator, tester, or manager, this book will help yourorganization move from idea to release faster than ever―so you can deliver value to your businessrapidly and reliably.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/ref=asap_bc?ie=UTF8</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Humble, Jez</author><author>Molesky, Joanne</author><author>O'Reilly, Barry</author></authors></contributors><titles><title>Lean Enterprise: How High Performance Organizations Innovate at Scale</title><short-title>Lean Enterprise</short-title></titles><pages>352</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>3 Jan. 2015</date></pub-dates></dates><pub-location>Beijing</pub-location><publisher>O'Reilly Media</publisher><isbn>978-1-4493-6842-5</isbn><abstract>How well does your organization respond to changing market conditions, customer needs, and emerging technologies when building software-based products? This practical guide presents Lean and Agile principles and patterns to help you move fast at scale—and demonstrates why and how to apply these methodologies throughout your organization, rather than with just one department or team.Through case studies, you’ll learn how successful enterprises have rethought everything from governance and financial management to systems architecture and organizational culture in the pursuit of radically improved performance. Adopting Lean will take time and commitment, but it’s vital for harnessing the cultural and technical forces that are accelerating the rate of innovation.Discover how Lean focuses on people and teamwork at every level, in contrast to traditional management practicesApproach problem-solving experimentally, by exploring solutions, testing assumptions, and getting feedback from real usersLead and manage large-scale programs in a way that empowers employees, increases the speed and quality of delivery, and lowers costsLearn how to implement ideas from the DevOps and Lean Startup movements even in complex, regulated environments</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Lean-Enterprise-Performance-Organizations-Innovate/dp/1449368425</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Skelton, Matthew</author></authors></contributors><titles><title>Your team's API includes: - code: REST endpoints, libraries, clients, UI, etc. - wiki / docs - especially "How To" guides - your approach to team chat tools (Slack/Hipchat) - anything else which other teams need to use to interact with your team It's not just about code. #DevEx</title><secondary-title>@matthewpskelton</secondary-title></titles><periodical><full-title>@matthewpskelton</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-07-25T14:30</date></pub-dates></dates><language>en</language><urls><web-urls><url>https://twitter.com/matthewpskelton/status/1022111880423395329</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\LNZMUFKB\1022111880423395329.html</url></text-urls></urls><access-date>2018-10-29 16:12:06</access-date><misc2>Tweet</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Cottmeyer, Mike</author></authors></contributors><titles><title>Things to Consider When Structuring Your Agile Enterprise</title><secondary-title>LeadingAgile</secondary-title></titles><periodical><full-title>LeadingAgile</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>2014-02-05T08:58:42-04:00</date></pub-dates></dates><abstract>There are a lot of unique challenges that large organizations face when hey are trying to form Agile Teams. In this post, Mike Cottmeyer breaks down the ins and outs of Agile organizational structure.</abstract><language>en-US</language><urls><web-urls><url>https://www.leadingagile.com/2014/02/structure-agile-enterprise/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\337AQ9GA\structure-agile-enterprise.html</url></text-urls></urls><access-date>2018-10-29 13:19:36</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Shibata, Kenichi</author></authors></contributors><titles><title>How to build a platform team now! the secrets to successful engineering</title><secondary-title>Hacker Noon</secondary-title></titles><periodical><full-title>Hacker Noon</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-09-29T11:22:41.039Z</date></pub-dates></dates><abstract>TLDR; Scaling teams are hard. A platform team done right can help ease the hardships.</abstract><urls><web-urls><url>https://hackernoon.com/how-to-build-a-platform-team-now-the-secrets-to-successful-engineering-8a9b6a4d2c8</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\9DYTS98U\how-to-build-a-platform-team-now-the-secrets-to-successful-engineering-8a9b6a4d2c8.html</url></text-urls></urls><access-date>2018-10-29 13:09:08</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Perri, Melissa</author></authors></contributors><titles><title>Escaping the Build Trap</title></titles><pages>175</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>30 Nov. 2018</date></pub-dates></dates><pub-location>S.l.</pub-location><publisher>O′Reilly</publisher><isbn>978-1-4919-7379-0</isbn><abstract>To remain innovative in today's market, companies have to adopt a culture of learning and customer-centric practices that are focused on outcomes rather than outputs. This book provides product managers with a practical process that focuses on finding opportunities to solve customer problems and achieve business goals. Author Melissa Perri provides a toolbox of product management principles that can be applied to any company, big or small. By understanding the secrets to communicating and collaborating within a company structure, you'll learn how to overcome product development roadblocks and build products that benefit both the business and the customer.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Escaping-Build-Trap-Melissa-Perri/dp/149197379X/ref=sr_1_1?ie=UTF8&amp;qid=1540817239&amp;sr=8-1&amp;keywords=The+Build+Trap</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Marshall, Bob</author></authors></contributors><titles><title>A team is not a group of people who work together. A team is a group of people who each put the team before themselves.</title><secondary-title>@flowchainsensei</secondary-title></titles><periodical><full-title>@flowchainsensei</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-10-29T09:20</date></pub-dates></dates><language>en</language><urls><web-urls><url>https://twitter.com/flowchainsensei/status/1056838136574152704</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\VQT2LZHI\1056838136574152704.html</url></text-urls></urls><access-date>2018-10-29 10:42:45</access-date><misc2>Tweet</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Karlgaard, Rich</author><author>Malone, Michael S.</author></authors></contributors><titles><title>Team Genius: The New Science of High-Performing Organizations</title><short-title>Team Genius</short-title></titles><pages>304</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>13 Aug. 2015</date></pub-dates></dates><pub-location>New York, NY</pub-location><publisher>HarperBusiness</publisher><isbn>978-0-06-230254-0</isbn><abstract>A groundbreaking book that sheds new light on the vital importance of teams as the fundamental unit of organization and competition in the global economy.Teams—we depend on them for both our professional success and our personal happiness. But isn't it odd how little scrutiny we give them? The teams that make up our lives are created mostly by luck, happenstance, or circumstance—but rarely by design. In trivial matters—say, a bowling team, the leadership of a neighborhood group, or a holiday party committee—success by serendipity is already risky enough. But when it comes to actions by fast-moving start-ups, major corporations, nonprofit institutions, and governments, leaving things to chance can be downright dangerous.Offering vivid reports of the latest scientific research, compelling case studies, and great storytelling, Team Genius shows managers and executives that the planning, design, and management of great teams no longer have to be a black art. It explores solutions to essential questions that could spell the difference between success and obsolescence. Do you know how to reorganize your subpar teams to turn them into top performers? Can you identify which of the top-performing teams in your company are reaching the end of their life span? Do you have the courage to shut them down? Do you know how to create a replacement team that will be just as effective—without losing time or damaging morale? And, most important, are your teams the right size for the job?Throughout, Rich Karlgaard and Michael S. Malone share insights and real-life examples gleaned from their careers as journalists, analysts, investors, and globetrotting entrepreneurs, meeting successful teams and team leaders to reveal some "new truths":  The right team size is usually one fewer person than what managers think they need.  The greatest question facing good teams is not how to succeed, but how to die.  Good "chemistry" often makes for the least effective teams.  Cognitive diversity yields the highest performance gains—but only if you understand what it is.  How to find the "bliss point" in team intimacy—and become three times more productive.  How to identify destructive team members before they do harm.  Why small teams are 40 percent more likely to create a successful breakthrough than a solo genius is.  Why groups of 7 (± 2), 150, and 1,500 are magic sizes for teams.Eye-opening, grounded, and essential, Team Genius is the next big idea to revolutionize business.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Team-Genius-Science-High-Performing-Organizations/dp/006230254X/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1540762849&amp;sr=1-1&amp;keywords=team+genius</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Burgess, Mark</author></authors></contributors><titles><title>Thinking in Promises</title></titles><pages>194</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>6 July 2015</date></pub-dates></dates><pub-location>Sebastopol, California</pub-location><publisher>O'Reilly Media</publisher><isbn>978-1-4919-1787-9</isbn><abstract>Imagine a set of simple principles that could help you to understand how parts combine to become a whole, and how each part sees the whole from its own perspective. If such principles were any good, it shouldn’t matter whether we’re talking about humans on a team, birds in a flock, computers in a datacenter, or cogs in a Swiss watch. A theory of cooperation ought to be pretty universal, so we should be able to apply it both to technology and to the workplace.Such principles are the subject of Promise Theory, and the focus of this insightful book. The goal of Promise Theory is to reveal the behavior of a whole from the sum of its parts, taking the viewpoint of the parts rather than the whole. In other words, it is a bottom-up, constructionist view of the world. Start Thinking in Promises and find out why this discipline works for documenting system behaviors from the bottom-up.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Thinking-Promises-Mark-Burgess/dp/1491917873/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1540762796&amp;sr=1-1&amp;keywords=thinking+in+promises</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Narayan, Sriram</author></authors></contributors><titles><title>Agile IT Organization Design: For Digital Transformation and Continuous Delivery</title><short-title>Agile IT Organization Design</short-title></titles><pages>302</pages><edition>01 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>14 Jun. 2015</date></pub-dates></dates><pub-location>New York</pub-location><publisher>Addison-Wesley Professional</publisher><isbn>978-0-13-390335-5</isbn><abstract>Design IT Organizations for Agility at Scale   Aspiring digital businesses need overall IT agility, not just development team agility. In Agile IT Organization Design, IT management consultant and ThoughtWorks veteran Sriram Narayan shows how to infuse agility throughout your organization. Drawing on more than fifteen years’ experience working with enterprise clients in IT-intensive industries, he introduces an agile approach to “Business–IT Effectiveness” that is as practical as it is valuable.   The author shows how structural, political, operational, and cultural facets of organization design influence overall IT agility—and how you can promote better collaboration across diverse functions, from sales and marketing to product development, and engineering to IT operations. Through real examples, he helps you evaluate and improve organization designs that enhance autonomy, mastery, and purpose: the key ingredients for a highly motivated workforce.   You’ll find “close range” coverage of team design, accountability, alignment, project finance, tooling, metrics, organizational norms, communication, and culture. For each, you’ll gain a deeper understanding of where your organization stands, and clear direction for making improvements. Ready to optimize the performance of your IT organization or digital business? Here are practical solutions for the long term, and for right now.   Govern for value over predictability  Organize for responsiveness, not lowest cost  Clarify accountability for outcomes and for decisions along the way  Strengthen the alignment of autonomous teams  Move beyond project teams to capability teams  Break down tool-induced silos  Choose financial practices that are free of harmful side effects  Create and retain great teams despite today’s “talent crunch”  Reform metrics to promote (not prevent) agility  Evolve culture through improvements to structure, practices, and leadership—and careful, deliberate interventions</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Agile-Organization-Design-Transformation-Continuous/dp/0133903354</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Urquhart, James</author></authors></contributors><titles><title>Communications and Conway’s Law</title><secondary-title>Digital Anatomy</secondary-title></titles><periodical><full-title>Digital Anatomy</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016-09-28T05:21:41.025Z</date></pub-dates></dates><abstract>In my last post, I described what I see as a disruption in the way digital businesses will operate in the future:</abstract><urls><web-urls><url>https://medium.com/digital-anatomy/communications-and-conways-law-6a1a9deae32</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\P5SAHF4I\communications-and-conways-law-6a1a9deae32.html</url></text-urls></urls><access-date>2018-10-27 07:07:36</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Newspaper Article">23</ref-type><contributors><authors><author>Urquhart, James</author></authors></contributors><titles><title>IT operations in a cloudy world</title><secondary-title>CNET</secondary-title></titles><periodical><full-title>CNET</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2010</year><pub-dates><date>15 Sept 2010</date></pub-dates></dates><abstract>Understanding how cloud computing and data center virtualization are forcing change in IT operations is important to understanding how to take advantage of cloud's disruptive nature.</abstract><language>en</language><urls><web-urls><url>https://www.cnet.com/news/it-operations-in-a-cloudy-world/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\S6PI5EAQ\it-operations-in-a-cloudy-world.html</url></text-urls></urls><access-date>2018-10-27 06:44:13</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Dunbar, Professor Robin</author></authors></contributors><titles><title>How Many Friends Does One Person Need?: Dunbar's Number and Other Evolutionary Quirks</title><short-title>How Many Friends Does One Person Need?</short-title></titles><pages>320</pages><edition>Main edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2010</year><pub-dates><date>4 Feb. 2010</date></pub-dates></dates><pub-location>London</pub-location><publisher>Faber &amp; Faber</publisher><isbn>978-0-571-25342-5</isbn><abstract>We are the product of our evolutionary history and this history colours our everyday lives - from why we kiss to how religious we are. In How Many Friends Does One Person Need? Robin Dunbar explains how the distant past underpins our current behaviour, through the groundbreaking experiments that have changed the thinking of evolutionary biologists forever. He explains phenomena such as why 'Dunbar's Number' (150) is the maximum number of acquaintances you can have, why all babies are born premature and the science behind lonely hearts columns. Stimulating, provocative and highly enjoyable, this fascinating book is essential for understanding why humans behave as they do - what it is to be human.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Many-Friends-Does-Person-Need/dp/0571253423/ref=tmm_hrd_swatch_0?_encoding=UTF8&amp;qid=&amp;sr=</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Wastell, Katherine</author></authors></contributors><titles><title>What we mean when we talk about service design at the Co-op</title><secondary-title>Co-op Digital Blog</secondary-title></titles><periodical><full-title>Co-op Digital Blog</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-10-25T15:29:51+00:00</date></pub-dates></dates><abstract>I wanted to write this post to explain what service design is at the Co-op. Service design helps build more inclusive teams as well as products and services that meet user and business needs. What …</abstract><language>en</language><urls><web-urls><url>https://digitalblog.coop.co.uk/2018/10/25/what-we-mean-when-we-talk-about-service-design-at-the-co-op/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\FV9LB3CI\what-we-mean-when-we-talk-about-service-design-at-the-co-op.html</url></text-urls></urls><access-date>2018-10-26 16:02:14</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Hall, Jon</author></authors></contributors><titles><title>ITSM, DevOps, and why three-tier support should be replaced with Swarming.</title><secondary-title>Medium</secondary-title></titles><periodical><full-title>Medium</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016-12-17T00:23:59.072Z</date></pub-dates></dates><abstract>The 3-tier support structure is ubiquitous in ITSM, but it is fundamentally at odds with DevOps principles. Swarming is a better answer.</abstract><urls><web-urls><url>https://medium.com/@JonHall_/itsm-devops-and-why-the-three-tier-structure-must-be-replaced-with-swarming-91e76ba22304</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\42HW7BFA\itsm-devops-and-why-the-three-tier-structure-must-be-replaced-with-swarming-91e76ba22304.html</url></text-urls></urls><access-date>2018-10-26 15:54:30</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Kitson, Jon</author></authors></contributors><titles><title>Squad Health Checks</title><secondary-title>Sky Betting &amp; Gaming Technology Blog</secondary-title></titles><periodical><full-title>Sky Betting &amp; Gaming Technology Blog</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>1 Feb 2017</date></pub-dates></dates><abstract>Enabling Continuous Improvement through regular introspection by the teams themselves.</abstract><urls><web-urls><url>https://technology.skybettingandgaming.com/2017/02/01/squad-health-checks/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\VTL5ZZEK\squad-health-checks.html</url></text-urls></urls><access-date>2018-10-26 12:00:18</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Overeem, Barry</author></authors></contributors><titles><title>How I Used the Spotify Squad Health Check Model – Barry Overeem – The Liberators</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>7 August 2015</date></pub-dates></dates><language>en-US</language><urls><web-urls><url>http://www.barryovereem.com/how-i-used-the-spotify-squad-health-check-model/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\VCL7UFWI\how-i-used-the-spotify-squad-health-check-model.html</url></text-urls></urls><access-date>2018-10-26 11:58:53</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Kniberg, Henrik</author></authors></contributors><titles><title>Squad Health Check model – visualizing what to improve</title><secondary-title>Labs</secondary-title></titles><periodical><full-title>Labs</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>2014-09-16T07:45:43+00:00</date></pub-dates></dates><abstract>(Download the cards &amp; instructions as PDF or PPTX) (Translations of this article: Chinese, French) What is a squad health check model? A lot of companies experiment with ways of measuring and visualizing how their teams are doing. They’re usually called “maturity models”, and involve some sort of progression through different levels. The intent of these…</abstract><language>en</language><urls><web-urls><url>https://labs.spotify.com/2014/09/16/squad-health-check-model/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\AY6BREM7\squad-health-check-model.html</url></text-urls></urls><access-date>2018-10-26 11:59:00</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Davies, Rachel</author><author>Sedley, Liz</author></authors></contributors><titles><title>Agile Coaching</title></titles><pages>250</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2009</year><pub-dates><date>7 Sept. 2009</date></pub-dates></dates><pub-location>Raleigh, N.C</pub-location><publisher>Pragmatic Bookshelf</publisher><isbn>978-1-934356-43-2</isbn><abstract>Discover how to coach your team to become more Agile. Agile Coaching de-mystifies agile practices--it's a practical guide to creating strong agile teams. Packed with useful tips from practicing agile coaches Rachel Davies and Liz Sedley, this book gives you coaching tools that you can apply whether you are a project manager, a technical lead, or working in a software team.To lead change, you need to expand your toolkit, and this book gives you the tools you need to make the transition from agile practitioner to agile coach. Agile Coaching is all about working with people to create great agile teams. You'll learn how to build a team that produces great software and has fun doing it. In the process, you'll grow a team that's self-sufficient and skillful.This book provides you with deeper knowledge of how agile practices work and how to inspire your team to improve. Discover how to coach your team through the agile lifecycle, from planning to writing software. Learn the secrets of running effective agile meetings and how to get your team following a consistent approach to creating software. You'll find chapters dedicated to introducing Test-Driven Development, designing Retrospectives, and making progress visible. Find out what works and what to avoid when introducing agile practices to your team. Throughout the book the authors share their personal coaching stories from experience with real teams, giving you insights into what works and what to avoid. Each chapter also covers hurdles that you and your team may face and what to do to clear them.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Agile-Coaching-Rachel-Davies/dp/1934356433/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1540553472&amp;sr=1-1&amp;keywords=rachel+davies+agile+coaching</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Adkins, Lyssa</author></authors></contributors><titles><title>Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition</title><short-title>Coaching Agile Teams</short-title></titles><pages>342</pages><edition>01 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2010</year><pub-dates><date>18 May 2010</date></pub-dates></dates><pub-location>Upper Saddle River, NJ</pub-location><publisher>Addison-Wesley Professional</publisher><isbn>978-0-321-63770-3</isbn><abstract>The Provocative and Practical Guide to Coaching Agile Teams  As an agile coach, you can help project teams become outstanding at agile, creating products that make them proud and helping organizations reap the powerful benefits of teams that deliver both innovation and excellence. More and more frequently, ScrumMasters and project managers are being asked to coach agile teams. But it’s a challenging role. It requires new skills―as well as a subtle understanding of when to step in and when to step back. Migrating from “command and control” to agile coaching requires a whole new mind-set. In Coaching Agile Teams, Lyssa Adkins gives agile coaches the insights they need to adopt this new mind-set and to guide teams to extraordinary performance in a re-energized work environment. You’ll gain a deep view into the role of the agile coach, discover what works and what doesn’t, and learn how to adapt powerful skills from many allied disciplines, including the fields of professional coaching and mentoring. Coverage includesUnderstanding what it takes to be a great agile coach Mastering all of the agile coach’s roles: teacher, mentor, problem solver, conflict navigator, and performance coach Creating an environment where self-organized, high-performance teams can emerge Coaching teams past cooperation and into full collaboration Evolving your leadership style as your team grows and changes Staying actively engaged without dominating your team and stunting its growth Recognizing failure, recovery, and success modes in your coaching Getting the most out of your own personal agile coaching journey Whether you’re an agile coach, leader, trainer, mentor, facilitator, ScrumMaster, project manager, product owner, or team member, this book will help you become skilled at helping others become truly great. What could possibly be more rewarding?</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Coaching-Agile-Teams-ScrumMasters-Addison-Wesley/dp/0321637704</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Skelton, Matthew</author></authors></contributors><titles><title>Tech Talks for Beginners</title></titles><edition>1</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018</date></pub-dates></dates><pub-location>Leeds, UK</pub-location><publisher>Conflux Digital</publisher><isbn>978-1-912058-85-3</isbn></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Morgan-Smith, Victoria</author><author>Skelton, Matthew</author></authors></contributors><titles><title>Internal Tech Conferences</title></titles><edition>1</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2019</year><pub-dates><date>2019</date></pub-dates></dates><pub-location>Leeds, UK</pub-location><publisher>Conflux Digital</publisher><isbn>978-1-912058-97-6</isbn></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Audiovisual Material">3</ref-type><contributors><authors><author>Kitagawa, Justin</author></authors></contributors><titles><title>Platforms at Twilio: Unlocking Developer Effectiveness</title><short-title>Platforms at Twilio</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>18 October 2018</date></pub-dates></dates><abstract>Justin Kitagawa talks about Twilio’s DevOps culture of “You build it, you run it”, and how its internal Platform has evolved to reduce their engineer’s cognitive load by providing a unified self-service, declarative platform to build, deliver, and run the thousands of global microservices that make up Twilio. He discusses the evolution, tenets, and lessons learned of Twilio’s internal Platform.</abstract><urls><web-urls><url>https://www.infoq.com/presentations/twilio-devops</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\XGL6886I\Kitagawa - 2018 - Platforms at Twilio Unlocking Developer Effective.pdf</url></pdf-urls></urls><access-date>2018-10-24 21:17:18</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Rother, Mike</author></authors></contributors><titles><title>Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results</title><short-title>Toyota Kata</short-title></titles><pages>336</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2009</year><pub-dates><date>16 Oct. 2009</date></pub-dates></dates><pub-location>New York</pub-location><publisher>McGraw-Hill Education</publisher><isbn>978-0-07-163523-3</isbn><abstract>"Toyota Kata gets to the essence of how Toyota manages continuous improvement and human ingenuity, through its improvement kata and coaching kata. Mike Rother explains why typical companies fail to understand the core of lean and make limited progress―and what it takes to make it a real part of your culture."―Jeffrey K. Liker, bestselling author of The Toyota Way"[Toyota Kata is] one of the stepping stones that will usher in a new era of management thinking."―The Systems Thinker"How any organization in any industry can progress from old-fashioned management by results to a strikingly different and better way."―James P. Womack, Chairman and Founder, Lean Enterprise Institute"Practicing the improvement kata is perhaps the best way we've found so far for actualizing PDCA in an organization."―John Shook, Chairman and CEO, Lean Enterprise InstituteThis game-changing book puts you behind the curtain at Toyota, providing new insight into the legendary automaker's management practices and offering practical guidance for leading and developing people in a way that makes the best use of their brainpower.Drawing on six years of research into Toyota's employee-management routines, Toyota Kata examines and elucidates, for the first time, the company's organizational routines--called kata--that power its success with continuous improvement and adaptation. The book also reaches beyond Toyota to explain issues of human behavior in organizations and provide specific answers to questions such as:How can we make improvement and adaptation part of everyday work throughout the organization?How can we develop and utilize the capability of everyone in the organization to repeatedly work toward and achieve new levels of performance?How can we give an organization the power to handle dynamic, unpredictable situations and keep satisfying customers? Mike Rother explains how to improve our prevailing management approach through the use of two kata: Improvement Kata--a repeating routine of establishing challenging target conditions, working step-by-step through obstacles, and always learning from the problems we encounter; and Coaching Kata: a pattern of teaching the improvement kata to employees at every level to ensure it motivates their ways of thinking and acting.With clear detail, an abundance of practical examples, and a cohesive explanation from start to finish, Toyota Kata gives executives and managers at any level actionable routines of thought and behavior that produce superior results and sustained competitive advantage.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Toyota-Kata-Managing-Improvement-Adaptiveness/dp/0071635238</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Pivotal</author></secondary-authors></contributors><titles><title>Microservices: Organizing Large Teams for Rapid Delivery</title><short-title>Microservices</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016</date></pub-dates></dates><abstract>SpringOne Platform 2016&#xD;Speakers: Patricia Anderson; Senior Consultant, Credera. Micah Blalock; Senior Architect, Credera. Jason Goth; Principal Architect, Credera.&#xD;&#xD;A microservice architecture is pattern that is most commonly associated with larger organizations where services and teams are organized around separate business capabilities. In a project our team recently completed, we used a microservice architecture to allow us to organize a large team to develop a large analytics platform at speeds that would not have been possible using a more typical service-oriented architecture.&#xD;&#xD;In this session, we discuss the organizational structure and communication and development strategies and tools to allow teams to work in parallel without drowning in process overhead and coordination costs.</abstract><work-type>Technology</work-type><urls><web-urls><url>https://www.slideshare.net/Pivotal/microservices-organizing-large-teams-for-rapid-delivery</url></web-urls></urls><access-date>2018-10-19 11:21:48</access-date><misc2>Technology</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Forsgren, Nicole</author><author>Humble, Jez</author></authors></contributors><titles><title>Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations</title><short-title>Accelerate</short-title></titles><pages>156</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>30 April 2018</date></pub-dates></dates><pub-location>Portland, Oregon</pub-location><publisher>Trade Select</publisher><isbn>978-1-942788-33-1</isbn><abstract>Accelerate your organization to win in the marketplace. How can we apply technology to drive business value? For years, we've been told that the performance of software delivery teams doesn't matter that it can't provide a competitive advantage to our companies. Through four years of groundbreaking research, Dr. Nicole Forsgren, Jez Humble, and Gene Kim set out to find a way to measure software delivery performance and what drives it using rigorous statistical methods. This book presents both the findings and the science behind that research, making the information accessible for readers to apply in their own organizations. Readers will discover how to measure the performance of their teams, and what capabilities they should invest in to drive higher performance. This book is ideal for management at every level.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Roberts, John</author></authors></contributors><titles><title>The Modern Firm: Organizational Design for Performance and Growth</title><short-title>The Modern Firm</short-title></titles><pages>334</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2007</year><pub-dates><date>11 Oct. 2007</date></pub-dates></dates><pub-location>Oxford</pub-location><publisher>Oxford University Press, USA</publisher><isbn>978-0-19-829375-0</isbn><abstract>Business firms around the world are experimenting with new organizational designs, changing their formal architectures, their routines and processes, and their corporate cultures as they seek to improve their current performance and their growth prospects. In the process they are changing the scope of their business operations, redrawing their organization charts, redefining the allocation of decision-making authority and responsibility, revamping the mechanisms for motivating and rewarding people, reconsidering which activities to conduct in-house and which to out-source, redesigning their information systems, and seeking to alter the shared beliefs, values and norms that their people hold. In this book, John Roberts argues that there are predictable, necessary relationships among these changes that will improve performance and growth. The organizations that are successful will establish patterns of fit among the elements of their organizational designs, their competitive strategies and the external environment in which they operate and will go about this in a holistic manner. The Modern Firm develops powerful conceptual frameworks for analyzing the interrelations between organizational design features, competitive strategy and the business environment. Written in a non-technical language, the book is nevertheless based on rigorous modeling and draws on numerous examples from eighteenth century fur trading companies to such modern firms such as BP and Nokia. Finally the book explores why these developments are happening now, pointing to the increase in global competition and changes in technology.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Modern-Firm-Organizational-Performance-Management/dp/0198293755</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Degrandis, Dominica</author></authors></contributors><titles><title>Making Work Visible: Exposing Time Theft to Optimize Workflow</title><short-title>Making Work Visible</short-title></titles><pages>376</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>2 Nov. 2017</date></pub-dates></dates><pub-location>Portland, OR</pub-location><publisher>IT Revolution Press</publisher><isbn>978-1-942788-15-7</isbn><abstract>If someone stole your wallet, you'd notice it. So why don't people notice when they are robbed of something much more valuable than their wallet--time?Today's workers are drowning: nonstop requests for time, days filled to the brim with meetings, and endless nights spent heroically fixing the latest problems. This churn and burn is creating a workforce constantly on the edge of burnout. In this timely book, IT time management expert Dominica DeGrandis reveals the real crime of the century--time theft, one of the most costly factors impacting enterprises in their day-to-day operations. Through simple solutions that make work visible, DeGrandis helps people round up the five thieves of time and take back their lives with time-saving solutions. Chock-full of exercises, takeaways, real-world examples, colorful diagrams, and an easy-going writing style, readers will quickly learn effective practices to create high-performing workflows within an organization. The technology world--and indeed the whole business world--is moving at a pace faster than ever before, and it shows no signs of slowing down. Instead of consigning ourselves to the pressure cooker of the modern world, it's time to elevate how we work. It's time to level up our game. It's time to make work visible.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Making-Work-Visible-Exposing-Optimize/dp/1942788150</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Stanford, Naomi</author></authors></contributors><titles><title>The Economist Guide to Organisation Design 2nd edition: Creating high-performing and adaptable enterprises</title><short-title>The Economist Guide to Organisation Design 2nd edition</short-title></titles><pages>352</pages><edition>2 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>26 Feb. 2015</date></pub-dates></dates><pub-location>London</pub-location><publisher>Economist Books</publisher><isbn>978-1-78125-310-6</isbn><abstract>Thousands of established businesses fail every year because of the way they are organised, or re-organised. Business survival can depend not only on whether its structures and reporting lines meet the needs of the market, but also whether they can adapt in the face of a rapidly changing business environment. Yet managers seldom talk coherently about structuring or restructuring their operations, let alone take a systematic approach to this vital issue. Too often, companies are restructured for the wrong reasons - for example, because a new CEO wants to make an impact, or to work around a new IT system. This revised and updated Economist Guide shows how leaders should think about and implement the design of a company, using five easy-to-use guiding principles: - Design a company around its strategy and the operating context, not for ulterior or non-business reasons; - Think holistically - don't restructure just one division without taking into account other operations;- Consider future markets, customers and trends, not just what works best now;- Invest time and resources: - a redesign can be complicated to implement and must be done without disrupting daily activities; and - Go back to the basics of how the company operates and its market position; this is not a repair job to fix a short-term problem.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://smile.amazon.co.uk/Economist-Guide-Organisation-Design-high-performing/dp/1781253102/ref=pd_sbs_14_1?_encoding=UTF8&amp;pd_rd_i=1781253102&amp;pd_rd_r=ec9050b3-d180-11e8-b159-3974f32f437e&amp;pd_rd_w=V0Xre&amp;pd_rd_wg=Udpfi&amp;pf_rd_i=desktop-dp-sims&amp;pf_rd_m=A3P5ROKL5A1OLE&amp;pf_rd_p=18edf98b-139a-41ee-bb40-d725dd59d1d3&amp;pf_rd_r=BH8EGR56GCY11FY8710V&amp;pf_rd_s=desktop-dp-sims&amp;pf_rd_t=40701&amp;psc=1&amp;refRID=BH8EGR56GCY11FY8710V</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Audiovisual Material">3</ref-type><contributors><authors><author>IT Revolution</author></authors></contributors><titles><title>DevOps Over Coffee - Adidas</title></titles><keywords><keyword>adidas</keyword><keyword>devops</keyword><keyword>devops enterprise summit</keyword><keyword>devops training</keyword><keyword>devops tutorial</keyword><keyword>does18</keyword><keyword>does18 london</keyword><keyword>does18 uk</keyword><keyword>enterprise</keyword><keyword>fernando cornago</keyword><keyword>london</keyword><keyword>markus rautert</keyword><keyword>summit</keyword><keyword>TT refs</keyword><keyword>uk</keyword><keyword>what is devops</keyword></keywords><dates><year>2018</year><pub-dates><date>3 July 2018</date></pub-dates></dates><remote-database-name>YouTube</remote-database-name><urls><web-urls><url>https://www.youtube.com/watch?v=oOjdXeGp44E&amp;feature=youtu.be&amp;t=1071</url></web-urls></urls><access-date>2018-10-16 13:41:14</access-date><custom3>1923 seconds</custom3></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Humble, Jez</author></authors></contributors><titles><title>There's No Such Thing as a "Devops Team" - Continuous Delivery</title><secondary-title>Continuous Delivery</secondary-title></titles><periodical><full-title>Continuous Delivery</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>19 October 2012</date></pub-dates></dates><urls><web-urls><url>https://continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\UC6XPKB2\theres-no-such-thing-as-a-devops-team.html</url></text-urls></urls><access-date>2018-10-15 20:07:11</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Mihaljov, Timo</author></authors></contributors><titles><title>Having a dedicated DevOps person who does all the DevOpsing is like having a dedicated collaboration person who does all the collaborating.</title><secondary-title>@noidi</secondary-title></titles><periodical><full-title>@noidi</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>2017-04-14T14:43</date></pub-dates></dates><language>en</language><urls><web-urls><url>https://twitter.com/noidi/status/852879869998501889</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\BKWL4T64\852879869998501889.html</url></text-urls></urls><access-date>2018-10-15 20:04:19</access-date><misc2>Tweet</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Beal, Helen</author></authors></contributors><titles><title>The Industry Just Can't Decide about DevOps Teams</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>Oct 26, 2017</date></pub-dates></dates><abstract>The incidence of DevOps teams is on the rise according to reports, but the industry remains divided on whether a DevOps team should even exist. Some are wary of creating additional silos, or are of the opinion that DevOps is a methodology that everyone should subscribe to in an organisation; others point to DevOps teams as an effective way of transitioning to a new way of working.</abstract><urls><web-urls><url>https://www.infoq.com/news/2017/10/devops-teams-good-or-bad</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\FYUNDLSG\devops-teams-good-or-bad.html</url></text-urls></urls><access-date>2018-10-15 20:00:45</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Munns, Chris</author></secondary-authors></contributors><titles><title>Chris Munns, DevOps @ Amazon: Microservices, 2 Pizza Teams, &amp; 50 Mill…</title><short-title>Chris Munns, DevOps @ Amazon</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2 May 2016</date></pub-dates></dates><urls><web-urls><url>http://www.slideshare.net/TriNimbus/chris-munns-devops-amazon-microservices-2-pizza-teams-50-million-deploys-a-year</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\ZDUED6WE\Munns - 2016 - Chris Munns, DevOps @ Amazon Microservices, 2 Piz.pdf</url></pdf-urls></urls><access-date>2016-08-12 02:36:19</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Pink, Daniel H.</author></authors></contributors><titles><title>Drive</title></titles><pages>256</pages><edition>Main edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2011</year><pub-dates><date>13 Jan. 2011</date></pub-dates></dates><pub-location>Edinburgh</pub-location><publisher>Canongate Books Ltd</publisher><isbn>978-1-84767-769-3</isbn><abstract>A BOOK THAT WILL CHANGE HOW YOU THINK AND TRANSFORM HOW YOU LIVEForget everything you thought you knew about how to motivate people - at work, at school, at home. As Daniel H. Pink explains in this paradigm-shattering book, the true secret to high performance and satisfaction in today's world is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and the world.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Drive-Daniel-H-Pink/dp/184767769X</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Pais, Manuel</author></authors></contributors><titles><title>Prezi's CTO on how to remain a lean startup after 4 years</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>Oct 05, 2012</date></pub-dates></dates><abstract>Peter Halacsy, CTO of Prezi, spoke today at DevOps Days in Rome about the evolution of the company in the past 3 years as a lean startup. He discussed how embracing failure is the only way to grow and improve the business. These principles affected all aspects of the company, from its structure to people recruitment, responsibility, technology stack and mostly the culture.</abstract><urls><web-urls><url>https://www.infoq.com/news/2012/10/Prezi-lean-startup</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\XBSSQZH6\Prezi-lean-startup.html</url></text-urls></urls><access-date>2018-10-15 19:35:23</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Newspaper Article">23</ref-type><contributors><authors><author>Bauernberger, Joachim</author></authors></contributors><titles><title>DevOps in Telecoms – is it possible?</title><secondary-title>Telecom Tech News</secondary-title></titles><periodical><full-title>Telecom Tech News</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>01 October 2014</date></pub-dates></dates><abstract>In telecoms, the adoption of DevOps is much higher than generally believed and it seems most are willing to extend their existing agile methodologies.</abstract><urls><web-urls><url>http://www.telecomstechnews.com/news/2014/oct/01/devops-telecoms-it-possible/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\7ZII52A2\devops-telecoms-it-possible.html</url></text-urls></urls><access-date>2016-07-06 20:39:48</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Netflix Technology Blog</author></authors></contributors><titles><title>The Netflix Simian Army</title><secondary-title>Netflix TechBlog</secondary-title></titles><periodical><full-title>Netflix TechBlog</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2011</year><pub-dates><date>2011-07-19T07:00:00.000Z</date></pub-dates></dates><abstract>Keeping our cloud safe, secure, and highly available</abstract><urls><web-urls><url>https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\XZZSL7UH\the-netflix-simian-army-16e57fbab116.html</url></text-urls></urls><access-date>2018-10-15 08:42:29</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Bryson, Brandon</author></authors></contributors><titles><title>Architects Should Code: The Architect's Misconception</title><secondary-title>InfoQ</secondary-title><short-title>Architects Should Code</short-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>Aug 06, 2015</date></pub-dates></dates><abstract>The responsibility of an architect reaches far past design and business concerns. Their design's implementation is ultimately their only measure of success; they should get their hands dirty and help.</abstract><urls><web-urls><url>https://www.infoq.com/articles/architects-should-code-bryson</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\TKCX2LFH\architects-should-code-bryson.html</url></text-urls></urls><access-date>2018-10-15 08:36:19</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Adams, Paul</author></authors></contributors><titles><title>Scaling Product Teams: How to Build and Structure for Hypergrowth</title><secondary-title>Inside Intercom</secondary-title><short-title>Scaling Product Teams</short-title></titles><periodical><full-title>Inside Intercom</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-01-28T16:45:00+01:00</date></pub-dates></dates><abstract>There’s been lots written about how Internet businesses should build software, from books like The Lean Start-Up, and posts from...</abstract><language>en-US</language><urls><web-urls><url>https://www.intercom.com/blog/how-we-build-software/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\REPVWSJQ\how-we-build-software.html</url></text-urls></urls><access-date>2018-10-15 07:51:26</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Magazine Article">19</ref-type><contributors><authors><author>Hastie, Shane</author></authors></contributors><titles><title>An interview with Sam Guckenheimer on Microsoft's Journey to Cloud Cadence</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>Oct 17, 2014</date></pub-dates></dates><abstract>At the recent Agile 2014 conference Sam Guckenheimer gave the opening keynote on Microsoft Developer Division's transition to a continuous delivery model. After the talk he sat down with InfoQ to discuss what it takes to achieve operational agility and cloud cadence.</abstract><urls><web-urls><url>https://www.infoq.com/articles/agile2014-guckenheimer</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\ILDAF4FE\agile2014-guckenheimer.html</url></text-urls></urls><access-date>2018-10-15 07:38:51</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Kniberg, Henrik</author></secondary-authors></contributors><titles><title>Real-Life Agile Scaling</title><secondary-title>Agile Tour Bangkok</secondary-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>21 November 2015</date></pub-dates></dates><pub-location>Bangkok</pub-location><urls><web-urls><url>http://blog.crisp.se/wp-content/uploads/2015/11/Real-life-agile-scaling.pdf</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\FC76KA3I\Real-life-agile-scaling.pdf</url></pdf-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>innolution</author></authors></contributors><titles><title>Feature Team Definition | Innolution</title></titles><keywords><keyword>TT refs</keyword></keywords><dates/><urls><web-urls><url>https://innolution.com/resources/glossary/feature-team</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\CSL5ASPY\feature-team.html</url></text-urls></urls><access-date>2018-10-14 22:06:28</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Beyer, Betsy</author><author>Petoff, Jennifer</author><author>Jones, Chris</author><author>Murphy, Niall Richard</author></authors></contributors><titles><title>Site Reliability Engineering</title></titles><pages>552</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>8 April 2016</date></pub-dates></dates><pub-location>Beijing ; Boston</pub-location><publisher>O′Reilly</publisher><isbn>978-1-4919-2912-4</isbn><abstract>The overwhelming majority of a software system’s lifespan is spent in use, not in design or implementation. So, why does conventional wisdom insist that software engineers focus primarily on the design and development of large-scale computing systems?In this collection of essays and articles, key members of Google’s Site Reliability Team explain how and why their commitment to the entire lifecycle has enabled the company to successfully build, deploy, monitor, and maintain some of the largest software systems in the world. You’ll learn the principles and practices that enable Google engineers to make systems more scalable, reliable, and efficient—lessons directly applicable to your organization.This book is divided into four sections:Introduction—Learn what site reliability engineering is and why it differs from conventional IT industry practicesPrinciples—Examine the patterns, behaviors, and areas of concern that influence the work of a site reliability engineer (SRE)Practices—Understand the theory and practice of an SRE’s day-to-day work: building and operating large distributed computing systemsManagement—Explore Google's best practices for training, communication, and meetings that your organization can use</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Site-Reliability-Engineering-Betsy-Beyer/dp/149192912X</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Dogan, Jaana B.</author></authors></contributors><titles><title>The SRE model</title><secondary-title>JBD</secondary-title></titles><periodical><full-title>JBD</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>2017-07-31T04:48:56.534Z</date></pub-dates></dates><abstract>Cindy Sridharan’s fantastic article on why everyone is not ops makes you rethink of the relationship between your development and…</abstract><urls><web-urls><url>https://medium.com/@rakyll/the-sre-model-6e19376ef986</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\YBCLU3NT\the-sre-model-6e19376ef986.html</url></text-urls></urls><access-date>2018-10-14 15:43:48</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Rensin, Dave</author></authors></contributors><titles><title>Introducing Google Customer Reliability Engineering</title><secondary-title>Google Cloud Blog</secondary-title></titles><periodical><full-title>Google Cloud Blog</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>October 10, 2016</date></pub-dates></dates><abstract>In the 25 years that I’ve been in technology nearly everything has changed. Computers have moved out of the labs and into our pockets. They’re connected to</abstract><urls><web-urls><url>https://cloud.google.com/blog/products/gcp/introducing-a-new-era-of-customer-support-google-customer-reliability-engineering/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\8TF4ZA2H\introducing-a-new-era-of-customer-support-google-customer-reliability-engineering.html</url></text-urls></urls><access-date>2018-10-14 15:33:55</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Weinberg, Gerald M.</author></authors></contributors><titles><title>An Introduction to General Systems Thinking</title></titles><pages>279</pages><edition>25 Silver anniversary ed edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2001</year><pub-dates><date>1 Jan. 2001</date></pub-dates></dates><pub-location>New York</pub-location><publisher>Dorset House Publishing Co Inc.,U.S.</publisher><isbn>978-0-932633-49-1</isbn><abstract>For more than twenty-five years, An Introduction to General Systems Thinking has been hailed as an innovative introduction to systems theory, with applications in computer science and beyond. Used in university courses and professional seminars all over the world, the text has proven its ability to open minds and sharpen thinking.  Originally published in 1975 and reprinted more than twenty times over a quarter century—and now available for the first time from Dorset House Publishing—the text uses clear writing and basic algebraic principles to explore new approaches to projects, products, organizations, and virtually any kind of system.  Scientists, engineers, organization leaders, managers, doctors, students, and thinkers of all disciplines can use this book to dispel the mental fog that clouds problem-solving. As author Gerald M. Weinberg writes in the new Preface to the Silver Anniversary Edition, "I haven't changed my conviction that most people don't think nearly as well as they could had they been taught some principles of thinking."  Now an award-winning author of nearly forty books spanning the entire software development life cycle—including The Psychology of Computer Programming: Silver Anniversary Edition and Exploring Requirements (with Donald C. Gause)—Weinberg had already acquired extensive experience as a programmer, manager, university professor, and consultant when this book was originally published.  With helpful illustrations, numerous end-of-chapter exercises, and an appendix on a mathematical notation used in problem-solving, An Introduction to General Systems Thinking may be your most powerful tool in working with problems, systems, and solutions.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Introduction-General-Systems-Thinking/dp/0932633498</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Scaled Agile</author></authors></contributors><titles><title>System Team – Scaled Agile Framework</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015</date></pub-dates></dates><abstract>SAFe for Lean Enterprises</abstract><language>en-US</language><urls><web-urls><url>https://www.scaledagileframework.com/system-team/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\MBRRIA76\system-team.html</url></text-urls></urls><access-date>2018-10-14 06:50:00</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>O'Connor, Debra</author><author>Johnson, Tristan</author></authors></contributors><titles><title>UNDERSTANDING TEAM COGNITION IN PERFORMANCE IMPROVEMENT TEAMS: A META ANALYSIS OF CHANGE IN SHARED MENTAL MODELS</title><short-title>UNDERSTANDING TEAM COGNITION IN PERFORMANCE IMPROVEMENT TEAMS</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>October 13, 2018</date></pub-dates></dates><abstract>Team cognition is comprised of several factors including shared knowledge or shared mental models (SMM). As there is little agreement about best methods for measuring SMM, this study utilized data from four previous studies and the ACSMM methodology for analysis of data. Findings about SMM in Performance Improvement teams indicate that changes in SMM take place during team task performance and that the changes are similar from one PI team to another. 1 Background</abstract><remote-database-name>ResearchGate</remote-database-name><urls><text-urls><url>https://www.researchgate.net/publication/238589980_UNDERSTANDING_TEAM_COGNITION_IN_PERFORMANCE_IMPROVEMENT_TEAMS_A_META_ANALYSIS_OF_CHANGE_IN_SHARED_MENTAL_MODELS</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><tertiary-authors><author>Salas, Eduardo</author><author>Fiore, Stephen M.</author></tertiary-authors></contributors><titles><title>Team Cognition: Understanding the Factors That Drive Process and Performance</title><short-title>Team Cognition</short-title></titles><pages>264</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2004</year><pub-dates><date>31 Mar. 2004</date></pub-dates></dates><pub-location>Washington, DC</pub-location><publisher>American Psychological Assoc</publisher><isbn>978-1-59147-103-5</isbn><abstract>Given the increased reliance on teams in many organizational settings, it is critical that all those who are interested in improving training and performance better understand team dynamics. During the past decade, cognitive science has substantially influenced the study of team performance and has helped develop the field of team cognition. The contributors to this volume describe the many ways in which team cognition is being used as an organizing framework to guide research into factors that affect team coordination. Nowadays, team cognition must be considered not only within ""conventional"" teams, but also across time and space in distributed teams, and - because of increased use of artificial team members (e.g., intelligent agents) - across people and machines. All of these complicating factors are considered, along with methodological issues that surround the process of measuring and defining team cognition. The unique blend of theory and data in this multidisciplinary book will be of value to psychologists and academics interested in cognition and organizational behavior, to team researchers and practitioners in Industry and the military, and to graduate students Interested in group processes and performance.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Team-Cognition-Understanding-Factors-Performance/dp/1591471036</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Jo Pearce</author></secondary-authors></contributors><titles><title>Hacking Your Head : Managing Information Overload (extended)</title><short-title>Hacking Your Head</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>29 April 2016</date></pub-dates></dates><abstract>There are limits on our ability to learn and process information.</abstract><work-type>Technology</work-type><urls><web-urls><url>https://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-extended</url></web-urls></urls><access-date>2018-10-13 06:41:28</access-date><misc2>Technology</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Personal Communication">26</ref-type><contributors><authors><author>Sinha, Harsh</author></authors></contributors><titles><title>Harsh Sinha on Building Culture at TransferWise</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>19 February 2018</date></pub-dates></dates><abstract>In this podcast Shane Hastie, Lead Editor for Culture &amp; Methods, spoke to Harsh Sinha, CTO of TransferWise, about deliberately designing organisational culture.</abstract><urls><web-urls><url>https://www.infoq.com/podcasts/Harsh-Sinha-transferwise-building-culture</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\385WSC2A\Harsh-Sinha-transferwise-building-culture.html</url></text-urls></urls><access-date>2018-10-12 10:24:17</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Eckstein, Jutta</author></authors><secondary-authors><author>Dingsøyr, Torgeir</author><author>Moe, Nils Brede</author><author>Tonelli, Roberto</author><author>Counsell, Steve</author><author>Gencel, Cigdem</author><author>Petersen, Kai</author></secondary-authors></contributors><titles><title>Architecture in Large Scale Agile Development</title><tertiary-title>Lecture Notes in Business Information Processing</tertiary-title></titles><periodical><full-title>Agile Methods. Large-Scale Development, Refactoring, Testing, and Estimation</full-title></periodical><pages>21-29</pages><keywords><keyword>agile methods</keyword><keyword>architect</keyword><keyword>change</keyword><keyword>chief architect</keyword><keyword>community of practice</keyword><keyword>complexity</keyword><keyword>emergent architecture</keyword><keyword>large-scale agile software development</keyword><keyword>project management</keyword><keyword>software engineering</keyword><keyword>technical consulting team</keyword><keyword>technical service team</keyword><keyword>TT refs</keyword><keyword>uncertainty</keyword></keywords><dates><year>2014</year><pub-dates><date>2014</date></pub-dates></dates><publisher>Springer International Publishing</publisher><isbn>978-3-319-14358-3</isbn><abstract>In order to welcome changing requirements (even late in development) agile development should enable the architecture to incorporate these changes and therefore to emerge over time. This implies not finalizing the architecture upfront. Moreover, in small agile teams it is assumed that there is no dedicated role for an architect – instead the whole team should be responsible for the architecture. In large-scale agile development the requirement for an emergent architecture still holds true. However, it is unrealistic to ask members of e.g. ten teams to be equally responsible for the architecture. Moreover, the role and support for the architecture depends not only on the degree of the size but as well on the degree of complexity. In this paper I report on the experience using different models for supporting emergent architecture in large environments that take the degree of complexity into account.</abstract><remote-database-name>Springer Link</remote-database-name><language>en</language><urls><pdf-urls><url>C:\Users\matth\Zotero\storage\JE895XXZ\Eckstein - 2014 - Architecture in Large Scale Agile Development.pdf</url></pdf-urls></urls><custom3>Agile Methods. Large-Scale Development, Refactoring, Testing, and Estimation</custom3></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Eckstein, Jutta</author></authors></contributors><titles><title>Agile Development in the Large: Diving into the Deep</title><short-title>Agile Development in the Large</short-title></titles><pages>234</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2004</year><pub-dates><date>1 Jan. 2004</date></pub-dates></dates><pub-location>New York</pub-location><publisher>Dorset House Publishing Co Inc.,U.S.</publisher><isbn>978-0-932633-57-6</isbn><abstract>Agile or "lightweight" processes have revolutionized the software development industry. They're faster and more efficient than traditional software development processes. They enable developers to   * embrace requirement changes during the project  * deliver working software in frequent iterations  * focus on the human factor in software development  Unfortunately, most agile processes are designed for small or mid-sized software development projects—bad news for large teams that have to deal with rapid changes to requirements. That means all large teams!  With Agile Software Development in the Large, Jutta Eckstein—a leading speaker and consultant in the agile community—shows how to scale agile processes to teams of up to 200. The same techniques are also relevant to teams of as few as 10 developers, especially within large organizations.  Topics include   * the agile value system as used in large teams  * the impact of a switch to agile processes  * the agile coordination of several sub-teams  * the way project size and team size influence the underlying architecture  Stop getting frustrated with inflexible processes that cripple your large projects! Use this book to harness the efficiency and adaptability of agile software development.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Agile-Development-Large-Diving-into/dp/0932633579/ref=tmm_pap_title_0?_encoding=UTF8&amp;qid=&amp;sr=</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Deming, W. Edwards</author></authors></contributors><titles><title>Out of the Crisis</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>1986</year><pub-dates><date>1986</date></pub-dates></dates><pub-location>Cambridge, Mass.</pub-location><publisher>Massachusetts Institute of Technology</publisher><isbn>978-0-262-54115-2</isbn><remote-database-name>Amazon</remote-database-name><urls><text-urls><url>https://www.amazon.co.uk/Out-Crisis-W-Edwards-Deming/dp/B0016JQVWA/ref=dp_ob_title_bk</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Jay, Graylin</author><author>Hale, Joanne</author><author>Smith, Randy</author><author>Hale, David</author><author>Kraft, Nicholas</author><author>Ward, Charles</author></authors></contributors><titles><title>Cyclomatic Complexity and Lines of Code: Empirical Evidence of a Stable Linear Relationship</title><secondary-title>JSEA</secondary-title><short-title>Cyclomatic Complexity and Lines of Code</short-title></titles><periodical><full-title>JSEA</full-title></periodical><pages>137-143</pages><volume>2</volume><keywords><keyword>TT refs</keyword></keywords><dates><year>2009</year><pub-dates><date>January 1, 2009</date></pub-dates></dates><electronic-resource-num>10.4236/jsea.2009.23020</electronic-resource-num><abstract>Researchers have often commented on the high correlation between McCabe's Cyclomatic Complexity (CC) and lines of code (LOC). Many have believed this correlation high enough to justify adjusting CC by LOC or even substituting LOC for CC. However, from an empirical standpoint the relationship of CC to LOC is still an open one. We undertake the largest statistical study of this relationship to date. Employing modern regression techniques, we find the linearity of this relationship has been severely underestimated, so much so that CC can be said to have absolutely no explanatory power of its own. This research presents evidence that LOC and CC have a stable practically perfect linear relationship that holds across programmers, languages, code paradigms (procedural versus object-oriented), and software processes. Linear models are developed relating LOC and CC. These models are verified against over 1.2 million randomly selected source files from the SourceForge code repository. These files represent software projects from three target languages (C, C++, and Java) and a variety of programmer experience levels, software architectures, and development methodologies. The models developed are found to successfully predict roughly 90% of CC's variance by LOC alone. This suggest not only that the linear relationship between LOC and CC is stable, but the aspects of code complexity that CC measures, such as the size of the test case space, grow linearly with source code size across languages and programming paradigms.</abstract><remote-database-name>ResearchGate</remote-database-name><urls><pdf-urls><url>C:\Users\matth\Zotero\storage\ZBXI8CGR\Jay et al. - 2009 - Cyclomatic Complexity and Lines of Code Empirical.pdf</url></pdf-urls><text-urls><url>https://www.researchgate.net/publication/220204439_Cyclomatic_Complexity_and_Lines_of_Code_Empirical_Evidence_of_a_Stable_Linear_Relationship</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Magazine Article">19</ref-type><contributors><authors><author>Lowe, Steven A.</author></authors></contributors><titles><title>How to use event storming to achieve domain-driven design</title><secondary-title>TechBeacon</secondary-title></titles><periodical><full-title>TechBeacon</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-10-15</date></pub-dates></dates><abstract>Event storming is a fast, lightweight group modeling technique you can use to accelerate developer productivity and facilitate domain-driven design.</abstract><language>en</language><urls><web-urls><url>https://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\ML8SIA37\introduction-event-storming-easy-way-achieve-domain-driven-design.html</url></text-urls></urls><access-date>2018-10-10 19:36:51</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Tune, Nick</author></authors></contributors><titles><title>Domain-Driven Architecture Diagrams</title><secondary-title>Nick Tune’s Tech Strategy Blog</secondary-title></titles><periodical><full-title>Nick Tune’s Tech Strategy Blog</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-08-15T14:57:00.000Z</date></pub-dates></dates><abstract>Domain-Driven Design is about creating shared understanding of the problem space that is reinforced ubiquitously via conversations, code and diagrams. DDD’s Shared understanding enhances synergy and…</abstract><urls><web-urls><url>https://medium.com/nick-tune-tech-strategy-blog/domain-driven-architecture-diagrams-139a75acb578</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\U72BQYKC\domain-driven-architecture-diagrams-139a75acb578.html</url></text-urls></urls><access-date>2018-10-10 19:39:14</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Magazine Article">19</ref-type><contributors><authors><author>Brandolini, Alberto</author></authors></contributors><titles><title>Strategic Domain Driven Design with Context Mapping</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2009</year><pub-dates><date>25 November 2009</date></pub-dates></dates><abstract>Many approaches to object oriented modeling tend not to scale well when the applications grow in size and complexity. Context Mapping technique can be used to manage the complexity in large software development projects. In this article, author Alberto Brandolini discusses the many sides of bounded contexts and how to use them to build a context map to support key decisions in a software project.</abstract><urls><web-urls><url>https://www.infoq.com/articles/ddd-contextmapping</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\H7AZU2ME\ddd-contextmapping.html</url></text-urls></urls><access-date>2018-10-10 19:35:52</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Wiley, Evan</author></authors></contributors><titles><title>Scaling XP Through Self-Similarity at Pivotal Cloud Foundry</title><secondary-title>Agile Alliance</secondary-title></titles><periodical><full-title>Agile Alliance</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-07-28T02:40:26Z</date></pub-dates></dates><abstract>RESOURCES Author: Please Note: You must be logged in as a Member to download this content. Download (PDF)</abstract><language>en-US</language><urls><web-urls><url>https://www.agilealliance.org/resources/experience-reports/scaling-xp-through-self-similarity-at-pivotal-cloud-foundry/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\W9EPDT2L\scaling-xp-through-self-similarity-at-pivotal-cloud-foundry.html</url></text-urls></urls><access-date>2018-10-10 14:00:02</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Blalock, Micah</author></authors></contributors><titles><title>Of Mustard Seeds and Microservices</title><secondary-title>Credera</secondary-title></titles><periodical><full-title>Credera</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-05-06T08:58:43-05:00</date></pub-dates></dates><abstract>Does your current architecture encourage or impede the development of a rhizomatic culture of autonomy, responsibility, collaboration, speed, and rapid course correction?</abstract><urls><web-urls><url>https://www.credera.com/blog/technology-insights/java/mustard-seeds-microservices/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\6JI5YJ7G\mustard-seeds-microservices.html</url></text-urls></urls><access-date>2018-10-10 10:14:05</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Nygard, Michael</author></authors></contributors><titles><title>The Perils of Semantic Coupling - Wide Awake Developers</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-04-29T06:03:21-05:00</date></pub-dates></dates><abstract>On the subject of maneuverability, many organizations run into trouble when they try to enter new lines of business, create a partnership, or merge with another company. Updating enterprise systems becomes a large cost factor in these business initiatives, sometimes large enough to outweigh the benefits case. This is a terrible irony: our automation provides efficiency, but removes flexibility.  If you break down the cost of such changes, you'll find it comes in equal parts from changes to individual systesm and changes to integrations across systems.</abstract><language>en</language><urls><web-urls><url>http://michaelnygard.com/blog/2015/04/the-perils-of-semantic-coupling/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\KNS9WLXC\the-perils-of-semantic-coupling.html</url></text-urls></urls><access-date>2018-10-10 09:34:50</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Long, Josh</author></authors></contributors><titles><title>GARY (go ahead, repeat yourself)</title><secondary-title>@starbuxman</secondary-title></titles><periodical><full-title>@starbuxman</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016-05-25T20:19</date></pub-dates></dates><language>en</language><urls><web-urls><url>https://twitter.com/starbuxman/status/735550836147814400</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\RVUS2JYV\735550836147814400.html</url></text-urls></urls><access-date>2018-10-10 10:01:45</access-date><misc2>Tweet</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Generic">13</ref-type><contributors><authors><author>Pivotal</author></authors></contributors><titles><title>The Essential Elements of Enterprise PaaS</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2 December 2016</date></pub-dates></dates><publisher>Pivotal</publisher><urls><web-urls><url>https://content.pivotal.io/white-papers/the-essential-elements-of-enterprise-paas</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\F9JCGQDA\Pivotal - 2016 - The Essential Elements of Enterprise PaaS.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\RCQ2W9CL\the-essential-elements-of-enterprise-paas.html</url></text-urls></urls><access-date>2018-10-09 20:41:04</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>MacCormack, Alan</author><author>Rusnak, John</author><author>Baldwin, Carliss Y.</author></authors></contributors><titles><title>Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code</title><secondary-title>Management Science</secondary-title><short-title>Exploring the Structure of Complex Software Designs</short-title></titles><periodical><full-title>Management Science</full-title></periodical><pages>1015-1030</pages><volume>52</volume><number>7</number><issue>7</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>2006</year><pub-dates><date>07/2006</date></pub-dates></dates><isbn>0025-1909, 1526-5501</isbn><electronic-resource-num>10.1287/mnsc.1060.0552</electronic-resource-num><remote-database-name>Crossref</remote-database-name><language>en</language><urls><web-urls><url>http://pubsonline.informs.org/doi/abs/10.1287/mnsc.1060.0552</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\MKYPAY52\MacCormack et al. - 2006 - Exploring the Structure of Complex Software Design.pdf</url></pdf-urls></urls><access-date>2018-10-09 19:35:59</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Cohn, Mike</author></authors></contributors><titles><title>Nine Questions To Assess Scrum Team Structure</title><secondary-title>Mountain Goat Software</secondary-title></titles><periodical><full-title>Mountain Goat Software</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2010</year><pub-dates><date>9 March 2010</date></pub-dates></dates><abstract>Scrum Team structure is critical for the success of any scrum project.  Mike Cohn explains why and gives nine questions to assess scrum team structure.</abstract><language>en</language><urls><web-urls><url>https://www.mountaingoatsoftware.com/blog/nine-questions-to-assess-team-structure</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\UW4ULGGM\nine-questions-to-assess-team-structure.html</url></text-urls></urls><access-date>2018-10-09 19:20:04</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Minick, Eric</author><author>Yanko, Curtis</author></secondary-authors></contributors><titles><title>Creating a DevOps Team that Isn't Evil</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>26 Feb 2015</date></pub-dates></dates><urls><web-urls><url>http://www.slideshare.net/Urbancode/creating-a-devops-team-that-isnt-evil</url></web-urls></urls><access-date>2016-08-11 16:27:06</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Minick, Eric</author></authors></contributors><titles><title>The goal for a "DevOps Team" should be to put itself out of business by enabling the rest of the org.</title><secondary-title>@ericminick</secondary-title></titles><periodical><full-title>@ericminick</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>8:27 am - 1 Oct 2014</date></pub-dates></dates><urls><web-urls><url>https://twitter.com/ericminick/status/517335119330172930</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\6PQZQN46\517335119330172930.html</url></text-urls></urls><access-date>2016-08-11 16:21:31</access-date><misc2>microblog</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Morris, Kief</author></authors></contributors><titles><title>Infrastructure as Code: Managing Servers in the Cloud</title><short-title>Infrastructure as Code</short-title></titles><pages>250</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>30 Jun. 2016</date></pub-dates></dates><publisher>O'Reilly Media</publisher><isbn>978-1-4919-2435-8</isbn><abstract>This book explains how to take advantage of technologies like cloud, virtualization, and configuration automation to manage IT infrastructure using tools and practices from software development. These technologies have decoupled infrastructure from the underlying hardware, turning it into data and code. "Infrastructure as Code" has emerged alongside the DevOps movement as a label for approaches that merge concepts like source control systems, Test Driven Development (TDD) and Continuous Integration (CI) with infrastructure management.Virtualization and cloud make it easy to rapidly expand the size of infrastructure, but the habits and practices we used in the past with hardware-based infrastructure don't keep up. Teams end up with hundreds of servers, all a bit different, and find themselves unable to fully automate their infrastructure.The book will go through the challenges and problems created by all these wonderful new tools, and the principles and mindset changes that a team needs to make to use them effectively. It describes patterns, practices, and ideas that have been adopted from software development, especially Agile concepts, and brought into the IT Ops world as part of the DevOps movement. These ways of working have been proven in many organizations, including well known names like Netflix, Amazon, and Etsy, and also in more established organizations including publishers, banks, and even the British government.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Infrastructure-Code-Managing-Servers-Cloud/dp/1491924357</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Drew Hoskins</author></authors></contributors><titles><title>What is it like to be part of the Infrastructure team at Facebook? - Quora</title><secondary-title>Quora</secondary-title></titles><periodical><full-title>Quora</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>16 Feb 2015</date></pub-dates></dates><urls><web-urls><url>https://www.quora.com/What-is-it-like-to-be-part-of-the-Infrastructure-team-at-Facebook</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\EHRJFKTA\What-is-it-like-to-be-part-of-the-Infrastructure-team-at-Facebook.html</url></text-urls></urls><access-date>2016-08-11 12:54:10</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Brown, Simon</author></authors></contributors><titles><title>Are You a Software Architect?</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2010</year><pub-dates><date>09 Feb 2010</date></pub-dates></dates><abstract>The line between development and architecture is tricky. Some say it's fake, that architecture is an extension of the design process undertaken by developers; others say it's a chasm that can only be crossed by lofty developers who believe you must abstract your abstractions and not worry about implementation details. There's a balance in the middle, but how do you move from one to the other?</abstract><urls><web-urls><url>https://www.infoq.com/articles/brown-are-you-a-software-architect</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\RNDQZFWK\brown-are-you-a-software-architect.html</url></text-urls></urls><access-date>2016-08-11 10:56:49</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Cockcroft, Adrian</author></secondary-authors></contributors><titles><title>Goto Berlin - Migrating to Microservices (Fast Delivery)</title><secondary-title>GOTO Berlin</secondary-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>15 November 2014</date></pub-dates></dates><pub-location>Berlin</pub-location><urls><web-urls><url>http://www.slideshare.net/adriancockcroft/goto-berlin</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\SMCI33X3\Cockcroft - 2014 - Goto Berlin - Migrating to Microservices (Fast Del.pdf</url></pdf-urls></urls><access-date>2016-08-11 09:53:04</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Skelton Thatcher Consulting</author></authors></contributors><titles><title>DevOps Topologies</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016</date></pub-dates></dates><abstract>The primary goal of any DevOps setup within an organisation is to improve the delivery of value for customers and the business, not in itself to reduce costs, increase automation, or drive everything from configuration management; this means that different organisations might need different team structures in order for effective Dev and Ops collaboration to take place.</abstract><urls><web-urls><url>http://web.devopstopologies.com</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\7GUPBTVE\web.devopstopologies.com.html</url></text-urls></urls><access-date>2016-08-09 19:33:06</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Personal Communication">26</ref-type><contributors><authors><author>Edwards, Damon</author></authors><secondary-authors><author>Pais, Manuel</author></secondary-authors></contributors><titles><title>Damon Edwards: DevOps is an Enterprise Concern</title><short-title>Damon Edwards</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>31 May 2014</date></pub-dates></dates><abstract>Damon argues DevOps is most needed in the enterprise world, and suggests starting with self-service provisioning interfaces, service oriented mentality, designing tool chains and meaningful metrics. All based on his own experience on the field as a DevOps consultant.</abstract><urls><web-urls><url>https://www.infoq.com/interviews/interview-damon-edwards-qcon-2014</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\SCZ4F8ZC\interview-damon-edwards-qcon-2014.html</url></text-urls></urls><access-date>2016-08-09 08:13:49</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Kniberg, Henrik</author></authors></contributors><titles><title>Crisp's Blog » Scaling Agile @ Spotify with Tribes, Squads, Chapters &amp; Guilds</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>2012</date></pub-dates></dates><urls><web-urls><url>http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\NR8C3XAE\SpotifyScaling.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\RHQEXQGX\scaling-agile-at-spotify.html</url><url>C:\Users\matth\Zotero\storage\V83UY4D8\Scaling-Agile-at-Spotify.png</url></text-urls></urls><access-date>2016-07-06 22:44:45</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Bennett, Drake</author></authors></contributors><titles><title>The Dunbar Number, From the Guru of Social Networks</title><secondary-title>Bloomberg.com</secondary-title></titles><periodical><full-title>Bloomberg.com</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2013</year><pub-dates><date>2013-01-11</date></pub-dates></dates><abstract>How a technophobic Oxford primatologist became Silicon Valley’s social networking guru</abstract><urls><web-urls><url>http://www.bloomberg.com/news/articles/2013-01-10/the-dunbar-number-from-the-guru-of-social-networks</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\8PHP365X\the-dunbar-number-from-the-guru-of-social-networks.html</url></text-urls></urls><access-date>2016-07-27 15:26:07</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Clegg, Chris W</author></authors></contributors><titles><title>Sociotechnical principles for system design</title><secondary-title>Applied Ergonomics</secondary-title></titles><periodical><full-title>Applied Ergonomics</full-title><abbr-1>Applied Ergonomics</abbr-1></periodical><pages>463-477</pages><volume>31</volume><number>5</number><issue>5</issue><keywords><keyword>INFORMATION technology</keyword><keyword>Management practices</keyword><keyword>New ways of working</keyword><keyword>Sociotechnical principles</keyword><keyword>system design</keyword><keyword>TT refs</keyword></keywords><dates><year>2000</year><pub-dates><date>October 2, 2000</date></pub-dates></dates><isbn>0003-6870</isbn><electronic-resource-num>10.1016/S0003-6870(00)00009-0</electronic-resource-num><abstract>This paper offers a set of sociotechnical principles to guide system design, and some consideration of the role of principles of this kind. The principles extend earlier formulations by Cherns (1976, Human Relations, 29, 783–792; 1987, Human Relations, 40, 153–162). They are intended to apply to the design of new systems, including those incorporating new information technologies and a range of modern management practices and ways of working. They attempt to provide a more integrated perspective than is apparent in existing formulations. The principles are of three broad types: meta, content and process, though they are highly interrelated. They are for use by system managers, users and designers, and by technologists and social scientists. They offer ideas for debate and provide devices through which detailed design discussions can be elaborated. The principles are most likely to be effective if they are relatively freestanding, but supported by relevant methods and tools. The principles are necessary but not sufficient to make a substantial contribution to design practice.</abstract><remote-database-name>ScienceDirect</remote-database-name><urls><web-urls><url>http://www.sciencedirect.com/science/article/pii/S0003687000000090</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\QUPTPE4K\Sociotechnical_principles_for_system_des20160604-19668-qecuzw.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\TFBJBNEA\S0003687000000090.html</url></text-urls></urls><access-date>2016-07-15 13:33:27</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Zambonelli, Franco</author></authors></contributors><titles><title>Toward sociotechnical urban superorganisms</title><secondary-title>Computer</secondary-title></titles><periodical><full-title>Computer</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>2012</date></pub-dates></dates><abstract>Sooner or later, we’ll all become part of an urban superorganism, &#xD;putting our ICT devices and unique human capabilities to use for &#xD;the good of both ourselves and society.</abstract><remote-database-name>Google Scholar</remote-database-name><urls><web-urls><url>http://spartan.ac.brocku.ca/~tkennedy/COMM/Zambonelli2012.pdf</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\N74FQ7UK\Zambonelli2012.pdf</url></pdf-urls></urls><access-date>2016-07-15 13:28:37</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Cherns, Albert</author></authors></contributors><titles><title>The principles of sociotechnical design</title><secondary-title>Human Relations</secondary-title></titles><periodical><full-title>Human Relations</full-title></periodical><pages>783-792</pages><volume>29</volume><number>8</number><issue>8</issue><keywords><keyword>*Organizational Development</keyword><keyword>organizational structure</keyword><keyword>TT refs</keyword></keywords><dates><year>1976</year><pub-dates><date>1976</date></pub-dates></dates><isbn>1741-282X(Electronic);0018-7267(Print)</isbn><electronic-resource-num>10.1177/001872677602900806</electronic-resource-num><abstract>Discusses 9 principles which should be considered in the development of a sociotechnical system: compatibility, minimal critical specification, the sociotechnical criterion, the multifunctional principle or organism vs mechanism, boundary location, information flow, support congruence, and incompletion. The role of employees and union officials in the development of sociotechnical systems is discussed.</abstract><remote-database-name>APA PsycNET</remote-database-name><urls><pdf-urls><url>C:\Users\matth\Zotero\storage\DCJUESVN\Human Relations-1976-Cherns-783-92.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\QXTIKRH7\1977-04533-001.html</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Chaudhary, Mukesh</author></authors></contributors><titles><title>Working with Component Teams: How to Navigate the Complexity - Scrum Alliance</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>5 September 2012</date></pub-dates></dates><urls><web-urls><url>https://www.scrumalliance.org/community/articles/2012/september/working-with-component-teams-how-to-navigate-the-c</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\T27TFI9R\working-with-component-teams-how-to-navigate-the-c.html</url></text-urls></urls><access-date>2016-07-06 23:27:45</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Leffingwell, Dean</author></authors></contributors><titles><title>Feature Teams Vs. Component Teams (continued)</title><secondary-title>Scaling Software Agility</secondary-title></titles><periodical><full-title>Scaling Software Agility</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2011</year><pub-dates><date>2011-05-02T01:22:20+00:00</date></pub-dates></dates><abstract>My friend and agile “ninja” Chad Holdorf ( just put up a nice post with a video and graphic explanation of the value of organizing around Features, rather than Components. For context, Chad is usin…</abstract><urls><web-urls><url>https://scalingsoftwareagility.wordpress.com/2011/05/02/feature-teams-vs-component-teams-continued/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\QVSUHN7J\feature-teams-vs-component-teams-continued.html</url></text-urls></urls><access-date>2016-07-06 23:21:21</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Leffingwell, Dean</author></authors></contributors><titles><title>Organizing at Scale: Feature Teams vs. Component Teams – Part 3</title><secondary-title>Scaling Software Agility</secondary-title><short-title>Organizing at Scale</short-title></titles><periodical><full-title>Scaling Software Agility</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2009</year><pub-dates><date>2009-07-22T00:57:37+00:00</date></pub-dates></dates><abstract>As the title indicates, in the last two posts (Part 1 and Part 2 – and also be sure and check the comments from others) I’ve described the conundrum of organizing agile teams at scale, …</abstract><urls><web-urls><url>https://scalingsoftwareagility.wordpress.com/2009/07/22/organizing-agile-at-scale-feature-teams-versus-component-teams-part-3/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\GGR6V5IC\organizing-agile-at-scale-feature-teams-versus-component-teams-part-3.html</url></text-urls></urls><access-date>2016-07-06 23:04:25</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Leffingwell, Dean</author></authors></contributors><titles><title>Scaling Software Agility: Best Practices for Large Enterprises</title><short-title>Scaling Software Agility</short-title></titles><pages>384</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2007</year><pub-dates><date>March 8, 2007</date></pub-dates></dates><pub-location>Upper Saddle River, NJ</pub-location><publisher>Addison-Wesley Professional</publisher><isbn>978-0-321-45819-3</isbn><abstract>“Companies have been implementing large agile projects for  a number of years, but the ‘stigma’ of ‘agile only works for small  projects’ continues to be a frequent barrier for newcomers and a  rallying cry for agile critics. What has been missing from the agile  literature is a solid, practical book on the specifics of developing  large projects in an agile way. Dean Leffingwell’s book  Scaling Software Agility   fills this gap admirably. It offers a practical guide to large project  issues such as architecture, requirements development, multi-level  release planning, and team organization. Leffingwell’s book is a  necessary guide for large projects and large organizations making the  transition to agile development.” –Jim Highsmith, director, Agile Practice, Cutter Consortium, author of Agile Project Management  “There’s  tension between building software fast and delivering software that  lasts, between being ultra-responsive to changes in the market and  maintaining a degree of stability. In his latest work,  Scaling Software Agility,   Dean Leffingwell shows how to achieve a pragmatic balance among these  forces. Leffingwell’s observations of the problem, his advice on the  solution, and his description of the resulting best practices come from  experience: he’s been there, done that, and has seen what’s worked.” –Grady Booch, IBM Fellow  Agile  development practices, while still controversial in some circles, offer  undeniable benefits: faster time to market, better responsiveness to  changing customer requirements, and higher quality. However, agile  practices have been defined and recommended primarily to small teams.  In  Scaling Software Agility,  Dean Leffingwell describes how agile methods can be applied to enterprise-class development.  Part I provides an overview of the most common and effective agile methods. Part II describes seven best practices of agility that natively scale to the enterprise level. Part  III describes an additional set of seven organizational capabilities  that companies can master to achieve the full benefits of software  agility on an enterprise scale.  This  book is invaluable to software developers, testers and QA personnel,  managers and team leads, as well as to executives of software  organizations whose objective is to increase the quality and  productivity of the software development process but who are faced with  all the challenges of developing software on an enterprise scale.     Foreword    Preface    Acknowledgments    About the Author   Part I: Overview of Software Agility  Chapter 1: Introduction to Agile Methods  Chapter 2: Why the Waterfall Model Doesn’t Work  Chapter 3: The Essence of XP Chapter 4: The Essence of Scrum  Chapter 5: The Essence of RUP  Chapter 6: Lean Software, DSDM, and FDD  Chapter 7: The Essence of Agile  Chapter 8: The Challenge of Scaling Agile  Part II: Seven Agile Team Practices That Scale  Chapter 9: The Define/Build/Test Component Team  Chapter 10: Two Levels of Planning and Tracking Chapter 11: Mastering the Iteration  Chapter 12: Smaller, More Frequent Releases  Chapter 13: Concurrent Testing  Chapter 14: Continuous Integration  Chapter 15: Regular Reflection and Adaptation  Part III: Creating the Agile Enterprise Chapter 16: Intentional Architecture  Chapter 17: Lean Requirements at Scale: Vision, Roadmap, and Just-in-Time Elaboration  Chapter 18: Systems of Systems and the Agile Release Train  Chapter 19: Managing Highly Distributed Development  Chapter 20: Impact on Customers and Operations  Chapter 21: Changing the Organization  Chapter 22: Measuring Business Performance  Conclusion: Agility Works at Scale   Bibliography   Index</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.com/Scaling-Software-Agility-Practices-Enterprises/dp/0321458192?ie=UTF8&amp;adid=0YJHJHSXJNA4EENGM7N5&amp;camp=14573&amp;creative=327641&amp;creativeASIN=0321458192&amp;linkCode=as1&amp;tag=wwwleffingwel-20</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Rubin, Kenneth S.</author></authors></contributors><titles><title>Essential Scrum: A Practical Guide to the Most Popular Agile Process</title><short-title>Essential Scrum</short-title></titles><pages>504</pages><edition>01 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>26 July 2012</date></pub-dates></dates><pub-location>Upper Saddle River, NJ</pub-location><publisher>Addison Wesley</publisher><isbn>978-0-13-704329-3</isbn><abstract>A Practical Guide to the Most Popular Agile Process The Single-Source, Comprehensive Guide to Scrum for All Team Members, Managers, and Executives If you want to use Scrum to develop innovative products and services that delight your customers, Essential Scrum is the complete, single-source reference you’ve been searching for. Leading Scrum coach and trainer Kenny Rubin illuminates the values, principles, and practices of Scrum, and describes flexible, proven approaches that can help you implement it far more effectively.  Whether you are new to Scrum or years into your use, this book will introduce, clarify, and deepen your Scrum knowledge at the team, product, and portfolio levels. Drawing from Rubin’s experience helping hundreds of organizations succeed with Scrum, this book provides easy-to-digest descriptions enhanced by more than two hundred illustrations based on an entirely new visual icon language for describing Scrum’s roles, artifacts, and activities.  Essential Scrum will provide every team member, manager, and executive with a common understanding of Scrum, a shared vocabulary they can use in applying it, and practical knowledge for deriving maximum value from it.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Essential-Scrum-Practical-Addison-Wesley-Signature/dp/0137043295</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Cusumano, Michael A.</author></authors></contributors><titles><title>Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets and Manages People: How the World's Most Powerful ... Technology, Shapes Markets and Manages People</title><short-title>Microsoft Secrets</short-title></titles><pages>532</pages><edition>1st Touchstone Ed edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>1988</year><pub-dates><date>15 Aug. 1988</date></pub-dates></dates><pub-location>New York</pub-location><publisher>Simon and Schuster</publisher><isbn>978-0-684-85531-8</isbn><abstract>PREFACE TO THE PAPERBACK EDITIONIt gives us great pleasure to write this special preface to the paperback edition of "Microsoft Secrets, " which we originally published in October 1995. The book has been translated into fourteen foreign languages and has been on best-seller lists around the world, in markets ranging from the United States and Japan to Germany, Brazil, and China. The personal computer software industry moves very quickly, and much has happened to Microsoft in the past three years. The strategies and principles discussed in "Microsoft Secrets" still appear to be guiding the company forward. "The Internet: " The most important change has been the rise of the Internet and the World Wide Web. When we were writing this book, Microsoft was almost totally focused on finishing Windows 95 (which shipped in August 1995), revising Office and some other applications to go with its new operating system, and launching the proprietary online network, Microsoft Network. Not until December 1995 did Bill Gates and other Microsoft executives become truly serious about the Internet, even though they did ship a basic browser, Internet Explorer 1.0, with Windows 95.Since that time, Microsoft has changed most of its product plans and products to make sure that they took advantage of the Internet's enormous capabilities. Microsoft now has 40 percent of the browser market (compared to 60 percent for Netscape). Microsoft also has a strong and growing position in server software based on Windows NT Plans for Microsoft Network did not work out as expected, although Microsoft has remade much of this system into a Web-based service.Microsoft has made maade their operating systems andapplications software. Microsoft Office had about 90 percent of the desktop applications market and had become a standard in corporations. Windows NT and Microsoft BackOffice (which includes servers and database software) were also growing rapidly in market share. These corporate products had higher profit margins than products sold to individuals and guaranteed that Microsoft's profits would probably grow faster than its revenues. "Antitrust: " Perhaps the biggest concern about Microsoft was antitrust. The federal government, individual state governments, and governments in Japan and Europe were all concerned that Microsoft was too powerful. We saw these same concerns when we published "Microsoft Secrets" in 1995. Government scrutiny of Microsoft seemed more intense in 1998, however. The scrutiny was not so much with regard to acquisitions but with Microsoft potentially using its position in operating systems to extend its dominance to other areas, such as Web-based Internet commerce.The most recent serious debate has involved features or products that Microsoft is bundling into new versions of Windows. The browser that comes with Windows 98, for example, is much more tightly integrated into the operating system than in Windows 95. Microsoft also continued to include the browser at no extra charge (which forced Netscape to make its browser available for free also, even to companies that previously had paid for it). The problem: Microsoft has allegedly pressured computer manufacturers not to load competitors' products, such as Netscape's Navigator/Communicator browser. The browser is no longer a revenue source in itself, but it is critical as a "port al" to the Web. Both Netscapeand Microsoft, for example, use their browsers to draw customers to their Web sites, from which point customers can purchase various products and services, such as books, news, and travel reservations. Furthermore, in Windows 98, Microsoft is including the Web TV software "for free" and is encouraging computer manufacturers to include hardware to support this technology. Web TV makes it possible to combine TV advertisements and programming with Internet-based sales.Not all of Microsoft's initiatives will succeed. The company can misjudge markets, as it did with the Microsoft Network. Microsoft also has more competition in Internet markets than in operating systems or desktop software. But the possibilities are limitless for Internet commerce. And Bill Gates has clearly put Microsoft in a superb position strategically and technically to thrive in this new age of the Internet. "Product Development Process: " To build new Internet and enterprise products, Microsoft has continued to use the same principles and organization for product development that we talked about in "Microsoft Secrets." The company has made some minor changes, however, that we feel are important to note. For example, in Internet groups that want to move especially fast from ideas to final products, Microsoft developers sometimes take the lead in proposing feat</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Microsoft-Secrets-Powerful-Software-Technology/dp/0684855313</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>John, Wolfgang</author></authors></contributors><titles><title>DevOps for Service Providers - next generation tools</title><secondary-title>Ericsson Research Blog</secondary-title></titles><periodical><full-title>Ericsson Research Blog</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-12-07T12:07:17+00:00</date></pub-dates></dates><abstract>SP-DevOps Toolkit for next generation telco managment, recently released by EU FP7 project Unify.</abstract><urls><web-urls><url>https://www.ericsson.com/research-blog/cloud/devops-for-service-providers-next-generation-tools/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\ZSH3A2MJ\devops-for-service-providers-next-generation-tools.html</url></text-urls></urls><access-date>2016-07-06 20:42:25</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Skelton, Matthew</author></authors></contributors><titles><title>How Different Team Topologies Influence DevOps Culture</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-09-02</date></pub-dates></dates><abstract>There are many different team topologies that can be effective for DevOps. Each topology comes with a slightly different culture, and a team topology suitable for one organisation may not be suited to another organisation, even in a similar sector. This article explores the cultural differences between team topologies for DevOps, to help you choose a suitable DevOps topology for your organisation.</abstract><urls><web-urls><url>https://www.infoq.com/articles/devops-team-topologies</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\DRCWAG2S\devops-team-topologies.html</url></text-urls></urls><access-date>2016-07-06 07:49:39</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Westrum, R</author></authors></contributors><titles><title>A typology of organisational cultures</title><secondary-title>Quality &amp; safety in health care</secondary-title></titles><periodical><full-title>Quality &amp; safety in health care</full-title><abbr-1>Qual Saf Health Care</abbr-1></periodical><pages>ii22-ii27</pages><volume>13</volume><number>Suppl 2</number><issue>Suppl 2</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>2004</year><pub-dates><date>2004-12</date></pub-dates></dates><isbn>1475-3898</isbn><electronic-resource-num>10.1136/qshc.2003.009522</electronic-resource-num><abstract>There is wide belief that organisational culture shapes many aspects of performance, including safety. Yet proof of this relationship in a medical context is hard to find. In contrast to human factors, whose contributions are many and notable, culture's impact remains a commonsense, rather than a scientific, concept. The objectives of this paper are to show that organisational culture bears a predictive relationship with safety and that particular kinds of organisational culture improve safety, and to develop a typology predictive of safety performance. Because information flow is both influential and also indicative of other aspects of culture, it can be used to predict how organisations or parts of them will behave when signs of trouble arise. From case studies and some systematic research it appears that information culture is indeed associated with error reporting and with performance, including safety. Yet this relationship between culture and safety requires more exploration before the connection can be considered definitive.</abstract><remote-database-name>PubMed Central</remote-database-name><urls><web-urls><url>http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1765804/</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\9JR9XQE6\Westrum - 2004 - A typology of organisational cultures.pdf</url></pdf-urls><text-urls><url>http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1765804/</url></text-urls></urls><access-date>2016-07-05 21:53:28</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Luo, Jiao</author><author>Van de Ven, Andrew H.</author><author>Jing, Runtian</author><author>Jiang, Yuan</author></authors></contributors><titles><title>Transitioning from a hierarchical product organization to an open platform organization: a Chinese case study</title><secondary-title>Journal of Organization Design</secondary-title><short-title>Transitioning from a hierarchical product organization to an open platform organization</short-title></titles><periodical><full-title>Journal of Organization Design</full-title><abbr-1>Journal of Organization Design</abbr-1></periodical><pages>1</pages><volume>7</volume><keywords><keyword>China</keyword><keyword>Corporate venture</keyword><keyword>Micro-enterprise</keyword><keyword>Organization design</keyword><keyword>Strategy and structure</keyword><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>January 5, 2018</date></pub-dates></dates><isbn>2245-408X</isbn><electronic-resource-num>10.1186/s41469-017-0026-x</electronic-resource-num><abstract>Organizations around the world are designing new forms of organizing in order to deal with the challenges of advances in information technology and digitization that promote increases in customization and innovation in the face of global competition. This paper presents a case study examining the challenges experienced by a large multinational firm as it transforms from a hierarchical product organization to an open platform network organization. We show that (a) role confusion, (b) control imbalance, and (c) staffing mismatches are key challenges associated with organizational redesign. The main lessons drawn from this case are discussed.</abstract><remote-database-name>BioMed Central</remote-database-name><urls><web-urls><url>https://doi.org/10.1186/s41469-017-0026-x</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\EMZQWB62\Luo et al. - 2018 - Transitioning from a hierarchical product organiza.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\HB97XQVK\s41469-017-0026-x.html</url></text-urls></urls><access-date>2018-02-02 20:06:18</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Gothelf, Jeff</author><author>Seiden, Josh</author></authors></contributors><titles><title>Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously</title><short-title>Sense and Respond</short-title></titles><pages>256</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>7 Feb. 2017</date></pub-dates></dates><pub-location>Boston, Massachusetts</pub-location><publisher>Harvard Business Review Press</publisher><isbn>978-1-63369-188-9</isbn><abstract>The End of Assembly Line ManagementWe're in the midst of a revolution. Quantum leaps in technology are enabling organizations to observe and measure people's behavior in real time, communicate internally at extraordinary speed, and innovate continuously. These new, software-driven technologies are transforming the way companies interact with their customers, employees, and other stakeholders.This is no mere tech issue. The transformation requires a complete rethinking of the way we organize and manage work. And, as software becomes ever more integrated into every product and service, making this big shift is quickly becoming the key operational challenge for businesses of all kinds. We need a management model that doesn't merely account for, but actually embraces, continuous change. Yet the truth is, most organizations continue to rely on outmoded, industrial-era operational models. They structure their teams, manage their people, and evolve their organizational cultures the way they always have.Now, organizations are emerging, and thriving, based on their capacity to sense and respond instantly to customer and employee behaviors. In Sense and Respond, Jeff Gothelf and Josh Seiden, leading tech experts and founders of the global Lean UX movement, vividly show how these companies operate, highlighting the new mindset and skills needed to lead and manage them and to continuously innovate within them.In illuminating and instructive business examples, you'll see organizations with distinctively new operating principles: shifting from managing outputs to what the authors call  outcome-focused management"; forming self-guided teams that can read and react to a fast-changing environment; creating a learning-all-the-time culture that can understand and respond to new customer behaviors and the data they generate; and finally, developing in everyone at the company the new universal skills of customer listening, assessment, and response.This engaging and practical book provides the crucial new operational and management model to help you and your organization win in a world of continuous change. ‘The book impresses not only by its advocacy for changing the culture of companies and management processes, but also the practical details the authors advocate…Food for thought, but then added to that, plenty of sensible advice. Just what a business book should offer.’ Business Traveller, January 26, 2017 by Tom Otley  "Thanks to concrete examples, this book highlights the tools, methods and practices that businesses today need to flourish in a constantly changing world."  Business Digest (France)</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Sense-Respond-Successful-Organizations-Continuously/dp/1633691888/ref=pd_sim_14_60?_encoding=UTF8&amp;psc=1&amp;refRID=61RF25M4AK9G580DFX56</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Edmondson, Amy</author></authors></contributors><titles><title>Psychological Safety and Learning Behavior in Work Teams</title><secondary-title>Administrative Science Quarterly</secondary-title></titles><periodical><full-title>Administrative Science Quarterly</full-title><abbr-1>Administrative Science Quarterly</abbr-1></periodical><pages>350-383</pages><volume>44</volume><number>2</number><issue>2</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>1999</year><pub-dates><date>June 1, 1999</date></pub-dates></dates><isbn>0001-8392</isbn><electronic-resource-num>10.2307/2666999</electronic-resource-num><abstract>This paper presents a model of team learning and tests it in a multimethod field study. It introduces the construct of team psychological safety—a shared belief held by members of a team that the team is safe for interpersonal risk taking—and models the effects of team psychological safety and team efficacy together on learning and performance in organizational work teams. Results of a study of 51 work teams in a manufacturing company, measuring antecedent, process, and outcome variables, show that team psychological safety is associated with learning behavior, but team efficacy is not, when controlling for team psychological safety. As predicted, learning behavior mediates between team psychological safety and team performance. The results support an integrative perspective in which both team structures, such as context support and team leader coaching, and shared beliefs shape team outcomes.</abstract><remote-database-name>SAGE Journals</remote-database-name><language>en</language><urls><web-urls><url>http://journals.sagepub.com/doi/abs/10.2307/2666999</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\U432RN48\Edmondson - 1999 - Psychological Safety and Learning Behavior in Work.pdf</url></pdf-urls></urls><access-date>2017-02-07 16:13:55</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Sweller, John</author></authors></contributors><titles><title>Cognitive load during problem solving: Effects on learning</title><secondary-title>Cognitive science</secondary-title><short-title>Cognitive load during problem solving</short-title></titles><periodical><full-title>Cognitive science</full-title></periodical><pages>257–285</pages><volume>12</volume><number>2</number><issue>2</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>1988</year><pub-dates><date>1988</date></pub-dates></dates><remote-database-name>Google Scholar</remote-database-name><urls><web-urls><url>http://onlinelibrary.wiley.com/doi/10.1207/s15516709cog1202_4/abstract</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\JWB7B8RM\s15516709cog1202_4.pdf</url></pdf-urls></urls><access-date>2016-10-19 09:59:39</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Sweller, John</author></authors></contributors><titles><title>Cognitive Load Theory, Learning Difficulty, and Instructional Design</title><secondary-title>Learning and Instruction</secondary-title></titles><periodical><full-title>Learning and Instruction</full-title></periodical><pages>295-312</pages><volume>4</volume><keywords><keyword>TT refs</keyword></keywords><dates><year>1994</year><pub-dates><date>1994</date></pub-dates></dates><abstract>This paper is concerned with some of the factors that determine the difficulty of material that needs to be learned. It is suggested that when considering intellectual activities, schema acquisition and automation are the primary mechanisms of learning. The consequences of cognitive load theory for the structuring of information in order to reduce difficulty by focusing cognitive activity on schema acquisition is briefly surmnarixed. It is pointed out that cognitive load theory deals with learning and problem solving difticulty that is artificial in that it can be manipulated by instructional design. Intrinsic cognitive load in contrast, is constant for a given area because it is a basic component of the material. Intrinsic cognitive load is characterized in terms of element interactivity. The lements of most schemas must be learned simultaneously because they interact and it is the interaction that is critical. If, as in some areas, interactions between many elements must be learned, then intrinsic cognitive load will be high. In contrast, in different areas, if elements can be learned successively rather than ~~tan~~ly because they do not interact, intrinsic cognitive load will be low. It is suggested that extraneous cognitive load that interferes with learning orily is a problem under conditions of high cognitive load caused by high element interactivity. Under conditions of low element interactivity, re-designing instruction to reduce extraneous cognitive load may have no appreciable consequences. In addition, the concept of element interactivity can be used to explain not only why some material is difficult to learn but also, why it can be difficult to understand. Understanding becomes relevant when high element interactivity material with a naturally high cognitive load must be learned.</abstract><urls><pdf-urls><url>C:\Users\matth\Zotero\storage\ZMPZVHDU\cognitive_load_theory_sweller.pdf</url></pdf-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Pearce, Jo</author></authors></contributors><titles><title>Day 3: Managing Cognitive Load for Team Learning</title><secondary-title>12 Devs of Xmas</secondary-title><short-title>Day 3</short-title></titles><periodical><full-title>12 Devs of Xmas</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-12-28T00:00:35+00:00</date></pub-dates></dates><abstract>On the third day of Xmas, Jo Pearce explores our methods of learning as developers and how the ever-increasing complexity of our field can sometimes cause stress and anxiety. In this article Jo sho…</abstract><urls><web-urls><url>http://12devsofxmas.co.uk/2015/12/day-3-managing-cognitive-load-for-team-learning/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\3VJAWGR7\day-3-managing-cognitive-load-for-team-learning.html</url></text-urls></urls><access-date>2016-10-06 10:11:46</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Fan, Xiaocong</author><author>Chen, Po-Chun</author><author>Yen, John</author></authors></contributors><titles><title>Learning HMM-based cognitive load models for supporting human-agent teamwork</title><secondary-title>Cognitive Systems Research</secondary-title></titles><periodical><full-title>Cognitive Systems Research</full-title></periodical><pages>108–119</pages><volume>11</volume><number>1</number><issue>1</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>2010</year><pub-dates><date>2010</date></pub-dates></dates><remote-database-name>Google Scholar</remote-database-name><urls><web-urls><url>http://www.sciencedirect.com/science/article/pii/S1389041708000405</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\55DBTU28\ICCM07-124.pdf</url></pdf-urls></urls><access-date>2016-10-06 10:07:24</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Seiter, Courtney</author></authors></contributors><titles><title>We've Changed Our Product Team Structure 4 Times: Here's Where We Are Today</title><secondary-title>Open</secondary-title><short-title>We've Changed Our Product Team Structure 4 Times</short-title></titles><periodical><full-title>Open</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-10-20T08:00:09-05:00</date></pub-dates></dates><abstract>Here's a look at how we're evolving one of our teams---Buffer's product team---and creating a blueprint for the future of teams at Buffer.</abstract><urls><web-urls><url>https://open.buffer.com/product-team-evolution/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\KSKGV7DS\product-team-evolution.html</url></text-urls></urls><access-date>2016-08-11 23:36:26</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Almeida, Thiago</author></authors></contributors><titles><title>DevOps Lessons Learned at Microsoft Engineering</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>22 May 2016</date></pub-dates></dates><abstract>Thiago Almeida from Microsoft shares how adopting DevOps practices resulted in better engineering and happier teams, and the lessons learned in that journey.</abstract><urls><web-urls><url>https://www.infoq.com/articles/devops-lessons-microsoft</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\GNAZZU5E\devops-lessons-microsoft.html</url></text-urls></urls><access-date>2016-08-12 02:22:54</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Hoff, Todd</author></authors></contributors><titles><title>Amazon Architecture - High Scalability -</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2007</year><pub-dates><date>18 Sept 2007</date></pub-dates></dates><abstract>This is a wonderfully informative Amazon update based on Joachim Rohde's discovery of an interview...</abstract><urls><web-urls><url>http://highscalability.com/blog/2007/9/18/amazon-architecture.html</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\Z7KVSICF\amazon-architecture.html</url></text-urls></urls><access-date>2016-08-12 01:40:22</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Bright, Peter</author></authors></contributors><titles><title>How Microsoft dragged its development practices into the 21st century</title><secondary-title>Ars Technica</secondary-title></titles><periodical><full-title>Ars Technica</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>6/8/2014</date></pub-dates></dates><abstract>In the Web era of development, Waterfalls are finally out. Agile is in.</abstract><urls><web-urls><url>http://arstechnica.com/information-technology/2014/08/how-microsoft-dragged-its-development-practices-into-the-21st-century/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\IWAF3DUM\3.html</url></text-urls></urls><access-date>2016-08-12 01:28:40</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Cooley, Faith</author></secondary-authors></contributors><titles><title>Organizational Design for Effective Software Development</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>12 Nov 2014</date></pub-dates></dates><abstract>A Presentation by Faith Cooley on Organizational Design for Effective Software development. Check out this deck to see some of the leading changes we've seen in companies that need to get their software to market faster and more efficiently. Org Design and Agile/Continuous Delivery work hand in hand to tune your process effectively.</abstract><urls><web-urls><url>http://www.slideshare.net/Dev9Com/organizational-design-for-effective-software-development</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\BIGXMMTG\Cooley - 2014 - Organizational Design for Effective Software Devel.pdf</url></pdf-urls></urls><access-date>2016-08-11 22:11:09</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book Section">5</ref-type><contributors><authors><author>Bosch, Jan</author></authors><secondary-authors><author>Nord, Robert L.</author></secondary-authors></contributors><titles><title>On the Development of Software Product-Family Components</title><secondary-title>Software Product Lines</secondary-title><tertiary-title>Lecture Notes in Computer Science</tertiary-title></titles><periodical><full-title>Software Product Lines</full-title></periodical><pages>146-164</pages><number>3154</number><keywords><keyword>Computers and Society</keyword><keyword>Management of Computing and Information Systems</keyword><keyword>Software engineering</keyword><keyword>Software Engineering/Programming and Operating Systems</keyword><keyword>TT refs</keyword></keywords><dates><year>2004</year><pub-dates><date>2004/08/30</date></pub-dates></dates><publisher>Springer Berlin Heidelberg</publisher><isbn>978-3-540-22918-6 978-3-540-28630-1</isbn><abstract>Several approaches to the development of shared artefacts in software product families exist. Each has advantages and disadvantages, but there is no clear framework for selecting among these alternatives. As a consequence, mismatches between the optimal approach and the one currently used by an organization may lead to several problems, such as a high degree of erosion, mismatches between product needs and shared components, organizational “noise” and inefficient knowledge management. This paper (1) presents the problems resulting from the aforementioned mismatch, (2) presents the relevant decision dimensions that define the space of alternatives, (3) discusses the advantages and disadvantages of each alternative and (4) presents a framework for selecting the best alternative for each decision dimension based on a three-stage adoption model.</abstract><remote-database-name>link.springer.com</remote-database-name><language>en</language><urls><web-urls><url>http://link.springer.com/chapter/10.1007/978-3-540-28630-1_9</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\T5IBNSK5\splc2004-bosch.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\MXDMHGGR\10.html</url></text-urls></urls><access-date>2016-08-11 21:49:19</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Newspaper Article">23</ref-type><contributors><authors><author>Coutu, Diane</author></authors></contributors><titles><title>Why Teams Don’t Work</title><secondary-title>Harvard Business Review</secondary-title></titles><periodical><full-title>Harvard Business Review</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2009</year><pub-dates><date>2009-05-01T04:00:00Z</date></pub-dates></dates><abstract>A leading organizational psychologist explains the five critical conditions that make the difference between success and failure.</abstract><urls><web-urls><url>https://hbr.org/2009/05/why-teams-dont-work</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\8C277GFW\why-teams-dont-work.html</url></text-urls></urls><access-date>2016-08-11 20:00:38</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Crawford, Jason</author></authors></contributors><titles><title>Amazon's “two-pizza teams”: The ultimate divisional organization • Uncharted Territory</title><secondary-title>Uncharted Territory on Svbtle</secondary-title><short-title>Amazon's “two-pizza teams”</short-title></titles><periodical><full-title>Uncharted Territory on Svbtle</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2013</year><pub-dates><date>30 July 2013</date></pub-dates></dates><abstract>Amazon’s “two-pizza teams” are well-known; they’ve been written about in Fast Company and the WSJ. But almost everyone misses the point. They aren’t about team size—they’re about autonomy and accountability. For context, here’s a succinct... | Jason Crawford | Co-Founder &amp;amp; CEO, Fieldbook</abstract><urls><web-urls><url>http://blog.jasoncrawford.org/two-pizza-teams</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\GC5ZF858\two-pizza-teams.html</url></text-urls></urls><access-date>2016-08-11 19:49:53</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Ben Linders</author></authors></contributors><titles><title>Scaling Teams to Grow Effective Organizations</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>11 Aug 2016</date></pub-dates></dates><abstract>When organizations are growing fast it can be a challenge to keep them sane and to achieve what you actually want to achieve by hiring more people: getting more done. Alexander Grosse talked about how you scale teams to build an effective organization at Spark the Change London 2016. He explored the five domains of scaling teams: Hiring, People Management, Organization, Culture, and Communication.</abstract><urls><web-urls><url>https://www.infoq.com/news/2016/08/scaling-teams?utm_campaign=rightbar_v2&amp;utm_source=infoq&amp;utm_medium=news_link&amp;utm_content=link_text</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\6S65RK8Z\scaling-teams.html</url></text-urls></urls><access-date>2016-08-11 19:29:48</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>David Mole</author></authors></contributors><titles><title>Drive: How we Used Daniel Pink’s Work to Create a Happier, More Productive Work Place</title><secondary-title>InfoQ</secondary-title><short-title>Drive</short-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>10 Sept 2015</date></pub-dates></dates><abstract>The story of using Daniel Pink’s principles of Autonomy, Mastery and Purpose to create a happier and more productive workplace. We actively translated his principles into real strategies, trials and experiments which we carried out across the organisation. Some things worked and somethings didn’t, but overall we significantly increased motivation and saw remarkable rises in productivity.</abstract><urls><web-urls><url>https://www.infoq.com/articles/drive-productive-workplace</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\H2AFN2U8\drive-productive-workplace.html</url></text-urls></urls><access-date>2016-08-11 19:25:02</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Kramer, Staci D.</author></authors></contributors><titles><title>The Biggest Thing Amazon Got Right: The Platform</title><short-title>The Biggest Thing Amazon Got Right</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2011</year><pub-dates><date>2011-10-12</date></pub-dates></dates><abstract>Google (NSDQ: GOOG) engineer Steve Yegge was trying to start a robust internal discussion, not post a viral hit, when he published a 4,570-w…</abstract><language>en-US</language><urls><web-urls><url>https://gigaom.com/2011/10/12/419-the-biggest-thing-amazon-got-right-the-platform/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\WA965K4D\419-the-biggest-thing-amazon-got-right-the-platform.html</url></text-urls></urls><access-date>2019-06-05 10:43:50</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Greenleaf, Robert K.</author></authors></contributors><titles><title>The Servant as Leader</title></titles><edition>rev Edition edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>September 30, 2015</date></pub-dates></dates><publisher>The Greenleaf Center for Servant Leadership</publisher><isbn>978-0-9822012-2-0</isbn><abstract>This is the essay that started it all. Powerful, poetic and practical. The Servant as Leader describes some of the characteristics and activities of servant-leaders, providing examples which show that individual efforts, inspired by vision and a servant ethic, can make a substantial difference in the quality of society. Greenleaf discusses the skills necessary to be a servant-leader; the importance of awareness, foresight and listening; and the contrasts between coercive, manipulative, and persuasive power. A must-read.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.com/Servant-as-Leader-Robert-Greenleaf/dp/0982201222</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Webber, Emily</author></authors></contributors><titles><title>Building Successful Communities of Practice</title></titles><pages>80</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>18 Feb 2016</date></pub-dates></dates><pub-location>London, UK</pub-location><publisher>Blurb</publisher><isbn>978-0-9574919-3-9</isbn><abstract>Connecting with other people, finding a sense of belonging and the need for support are natural human desires. Employees who don't feel supported at work don't stay around for long - or if they do, they quickly become unmotivated and unhappy. At a time when organisational structures are flattening and workforces are increasingly fluid, supporting and connecting people is more important than ever. This is where organisational communities of practice come in. Communities of practice have many valuable benefits. They include accelerating professional development; breaking down organisational silos; enabling knowledge sharing and management; building better practice; helping to hire and retain staff; and making people happier. In this book, Emily Webber shares her learning from personal experiences of building successful communities of practice within organisations. And along the way, she gives practical guidance on creating your own.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Building-Successful-Communities-Practice-Webber/dp/095749193X</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Reinertsen, Donald G.</author></authors></contributors><titles><title>The Principles of Product Development Flow: Second Generation Lean Product Development</title><short-title>The Principles of Product Development Flow</short-title></titles><pages>294</pages><keywords><keyword>Business &amp; Economics / Management</keyword><keyword>Business &amp; Economics / Office Management</keyword><keyword>TT refs</keyword></keywords><dates><year>2009</year><pub-dates><date>2009</date></pub-dates></dates><publisher>Celeritas</publisher><isbn>978-1-935401-00-1</isbn><abstract>A hot, new management approach called Lean Product Development is emerging. It challenges the current management orthodoxy, enabling companies to achieve 5 to 10 times improvement in product development speed, quality and efficiency. This third book by a best-selling product development author lucidly explains the principles behind these new methods and shows readers how to apply them. Winner of a 2009 Best Books Award. quite simply the most advanced product development book you can buy.</abstract><remote-database-name>Google Books</remote-database-name><language>en</language><urls><text-urls><url>https://books.google.co.uk/books?id=1HlPPgAACAAJ</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Doorley, Scott</author><author>Witthoft, Scott</author><author>University, Hasso Plattner Institute of Design at Stanford</author><author>Kelley, David</author></authors></contributors><titles><title>Make Space: How to Set the Stage for Creative Collaboration</title><short-title>Make Space</short-title></titles><pages>272</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>27 Jan. 2012</date></pub-dates></dates><pub-location>Hoboken, N.J</pub-location><publisher>John Wiley &amp; Sons</publisher><isbn>978-1-118-14372-8</isbn><abstract>"If you are determined to encourage creativity and provide a collaborative environment that will bring out the best in people, you will want this book by your side at all times." Bill Moggridge, Director of the Smithsonian's Cooper-Hewitt National Design Museum "Make Space is an articulate account about the importance of space; how we think about it, build it and thrive in it." James P. Hackett, President and CEO, Steelcase An inspiring guidebook filled with ways to alter space to fuel creative work and foster collaboration. Based on the work at the Stanford University d.school and its Environments Collaborative Initiative, Make Space is a tool that shows how space can be intentionally manipulated to ignite creativity. Appropriate for designers charged with creating new spaces or anyone interested in revamping an existing space, this guide offers novel and non-obvious strategies for changing surroundings specifically to enhance the ways in which teams and individuals communicate, work, play--and innovate. Inside are: Tools--tips on how to build everything from furniture, to wall treatments, and rigging Situations--scenarios, and layouts for sparking creative activities Insights--bite-sized lessons designed to shortcut your learning curve Space Studies--candid stories with lessons on creating spaces for making, learning, imagining, and connecting Design Template--a framework for understanding, planning, and building collaborative environments Make Space is a new and dynamic resource for activating creativity, communication and innovation across institutions, corporations, teams, and schools alike. Filled with tips and instructions that can be approached from a wide variety of angles, Make Space is a ready resource for empowering anyone to take control of an environment.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Make-Space-Stage-Creative-Collaboration/dp/1118143728</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Betz, Charles</author></authors></contributors><titles><title>Managing Digital</title></titles><pages>612</pages><keywords><keyword>Education / General</keyword><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018</date></pub-dates></dates><publisher>Van Haren</publisher><isbn>978-94-018-0348-9</isbn><abstract>About This BookThis book, &amp;quot;Managing Digital: Concepts and Practices&amp;quot;, is intended to guide a practitioner through the journey of building a digital-first viewpoint and the skills needed to thrive in the digital-first world. As such, this book is a bit of an experiment for The Open Group; it isn’t structured as a traditional standard or guide. Instead, it is structured to show the key issues and skills needed at each stage of the digital journey, starting with the basics of a small digital project, eventually building to the concerns of a large enterprise. So, feel free to digest this book in stages — the section Introduction for the student is a good guide.The book is intended for both academic and industry training purposes.  This book seeks to provide guidance for both new entrants into the digital workforce and experienced practitioners seeking to update their understanding on how all the various themes and components of IT management fit together in the new world.About The Open Group PressThe Open Group Press is an imprint of The Open Group for advancing knowledge of information technology by publishing works from individual authors within The Open Group membership that are relevant to advancing The Open Group mission of Boundaryless Information Flow™. The key focus of The Open Group Press is to publish high-quality monographs, as well as introductory technology books intended for the general public, and act as a complement to The Open Group Standards, Guides, and White Papers. The views and opinions expressed in this book are those of the author, and do not necessarily reflect the consensus position of The Open Group members or staff.</abstract><remote-database-name>Google Books</remote-database-name><language>en</language><urls><text-urls><url>https://books.google.co.uk/books?id=tPB4DwAAQBAJ</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Womack, James P.</author><author>Jones, Daniel T.</author></authors></contributors><titles><title>Lean Thinking: Banish Waste And Create Wealth In Your Corporation</title><short-title>Lean Thinking</short-title></titles><pages>396</pages><edition>New Ed edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2003</year><pub-dates><date>7 July 2003</date></pub-dates></dates><pub-location>London</pub-location><publisher>Simon &amp; Schuster / Free Press</publisher><isbn>978-0-7432-3164-0</isbn><abstract>Lean Thinking was launched in the fall of 1996, just in time for the recession of 1997. It told the story of how American, European, and Japanese firms applied a simple set of principles called 'lean thinking' to survive the recession of 1991 and grow steadily in sales and profits through 1996. Even though the recession of 1997 never happened, companies were starving for information on how to make themselves leaner and more efficient. Now we are dealing with the recession of 2001 and the financial meltdown of 2002. So what happened to the exemplar firms profiled in Lean Thinking? In the new fully revised edition of this bestselling book those pioneering lean thinkers are brought up to date. Authors James Womack and Daniel Jones offer new guidelines for lean thinking firms and bring their groundbreaking practices to a brand new generation of companies that are looking to stay one step ahead of the competition.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/gp/product/0743231643/ref=ppx_od_dt_b_asin_title_s00?ie=UTF8&amp;psc=1</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Manns, Mary Lynn</author><author>Rising, Linda</author></authors></contributors><titles><title>Fearless Change: patterns for introducing new ideas</title><short-title>Fearless Change</short-title></titles><pages>304</pages><edition>01 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2004</year><pub-dates><date>4 Oct. 2004</date></pub-dates></dates><pub-location>Boston</pub-location><publisher>Addison Wesley</publisher><isbn>978-0-201-74157-5</isbn><abstract>“All that have ever tried to impose change in their organization will immediately recognize and truly value the in-depth knowledge and experience captured in this book. It contains a collection of eye-openers that is a treasure chest for pioneers of new organizational ideas, A fantastic toolbox for use in future missions!”―Lise B. Hvatum, product development manager, Schlumberger “If you have need of changing your organization, and especially of introducing new techniques, then you want to understand what is in this book. It will help you avoid common pitfalls that doom many such projects and will show you a clear path to success. The techniques are derived from the experience of many individuals and organizations. Many are also fun to apply. This stuff is really cool―and really hot.”―Joseph Bergin, professor of computer science, Pace University, New York“If change is the only guarantee in life, why is it so hard to do? As this book points out, people are not so much resistant to change itself as they are to being changed. Mary Lynn and Linda have successfully used the pattern form to capture and present the recurring lessons of successful change efforts and have placed a powerful knowledge resource in the hands of their readers.”―Alan O'Callaghan, researcher, Software Technology Research Laboratory, De Montfort University, United Kingdom“The most difficult part of absorbing patterns, or any technology, into an organization is overcoming the people issues. The patterns in this book are the documentation of having gone through that experience, giving those that dare push the envelope a head start at success.”―David E. DeLano, IBM Pervasive Computing“If you have ever wondered how you could possibly foster any cultural changes in your organization, in this book you will find a lot of concrete advice for doing so. I recommend that everyone read this book who has a vast interest in keeping his or her organization flexible and open for cultural change.”―Jutta Eckstein, Independent Consultant, Objects In Action Author of Agile Software Development in the Large48 Patterns for Driving and Sustaining Change in Your OrganizationChange. It's brutally tough to initiate, even harder to sustain. It takes too long. People resist it. But without it, organizations lose their competitive edge. Fortunately, you can succeed at making change. In Fearless Change, Mary Lynn Manns and Linda Rising illuminate 48 proven techniques, or patterns, for implementing change in organizations or teams of all sizes, and show you exactly how to use them successfully. Find out how toUnderstand the forces in your organization that drive and retard change Plant the seeds of change Drive participation and buy-in, from start to finish Choose an "official skeptic" to sharpen your thinking Make your changes appear less threatening Find the right timing and the best teaching moments Sustain your momentum Overcome adversity and celebrate successInspired by the "pattern languages" that are transforming fields from software to architecture, the authors illuminate patterns for every stage of the change process: knowledge, persuasion, decision, implementation, and confirmation. These flexible patterns draw on the experiences of hundreds of leaders. They offer powerful insight into change-agent behavior, organizational culture, and the roles of every participant. Best of all, they're easy to use―and they work!</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Fearless-Change-patterns-introducing-ideas/dp/0201741571</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book Section">5</ref-type><contributors><authors><author>Kim, Dr Kyung Hee</author><author>Pierce, Robert A.</author></authors><secondary-authors><author>Carayannis, Elias G.</author></secondary-authors></contributors><titles><title>Convergent Versus Divergent Thinking</title><secondary-title>Encyclopedia of Creativity, Invention, Innovation and Entrepreneurship</secondary-title></titles><periodical><full-title>Encyclopedia of Creativity, Invention, Innovation and Entrepreneurship</full-title></periodical><pages>245-250</pages><keywords><keyword>Business and Management, general</keyword><keyword>Entrepreneurship</keyword><keyword>TT refs</keyword></keywords><dates><year>2013</year><pub-dates><date>2013</date></pub-dates></dates><publisher>Springer New York</publisher><isbn>978-1-4614-3857-1 978-1-4614-3858-8</isbn><abstract>Definitions - Convergent and divergent thinking are two poles on a spectrum of cognitive approaches to problems and questions (Duck 1981). On the divergent end, thinking seeks multiple perspectives and multiple possible answers to questions and problems. On the other end of the spectrum, convergent thinking assumes that a question has one right answer and that a problem has a single solution (Kneller 1971). Divergent thinking generally resists the accepted ways of doing things and seeks alternatives. Convergent thinking, the bias of which is to assume that there is a correct way to do things, is inherently conservative; it begins by assuming that the way things have been done is the right way. Divergent thinkers are better at finding additional ideas, whereas convergent thinkers have a more difficult time finding additional ideas. Convergent thinkers run out of ideas before divergent thinkers. However, convergent thinking strengthens the ability to bring closure and to conclude ...</abstract><remote-database-name>link.springer.com</remote-database-name><language>en</language><urls><web-urls><url>http://link.springer.com/referenceworkentry/10.1007/978-1-4614-3858-8_22</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\DF95WT6W\10.html</url></text-urls></urls><access-date>2016-08-09 22:44:30</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><tertiary-authors><author>Smith, Steve</author><author>Skelton, Matthew</author></tertiary-authors></contributors><titles><title>Build Quality In</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2015-02-27</date></pub-dates></dates><pub-location>Leeds, UK</pub-location><publisher>Conflux Digital</publisher><isbn>978-1-912058-55-6</isbn><urls><web-urls><url>http://buildqualityin.com/</url></web-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Phillips, Amy</author></secondary-authors></contributors><titles><title>Testing Observability</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>05 April 2018</date></pub-dates></dates><pub-location>InfoQ</pub-location><abstract>Amy Phillips discusses the impact of observability on testing, from new techniques, greater Dev and Ops involvement, right through to whether testing is needed anymore.</abstract><urls><web-urls><url>https://www.infoq.com/presentations/observability-testing</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\BI5F3XKW\observability-testing.html</url></text-urls></urls><access-date>2018-11-13 20:56:21</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Fowler, Martin</author></authors></contributors><titles><title>bliki: BoundedContext</title><secondary-title>martinfowler.com</secondary-title><short-title>bliki</short-title></titles><periodical><full-title>martinfowler.com</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>15 January 2014</date></pub-dates></dates><abstract>Don't try to build a single, unified model for a large domain. Instead DDD advises us to divide such a domain into many bounded contexts with explicit relationships between them.</abstract><urls><web-urls><url>https://martinfowler.com/bliki/BoundedContext.html</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\RFTJY7DL\BoundedContext.html</url></text-urls></urls><access-date>2018-11-13 20:50:47</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Evans, Eric</author></authors></contributors><titles><title>Domain-Driven Design: Tackling Complexity in the Heart of Software</title><short-title>Domain-Driven Design</short-title></titles><pages>560</pages><edition>01 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2003</year><pub-dates><date>20 Aug. 2003</date></pub-dates></dates><pub-location>Boston</pub-location><publisher>Addison Wesley</publisher><isbn>978-0-321-12521-7</isbn><abstract>“Eric Evans has written a fantastic book on how you can make the design of your software match your mental model of the problem domain you are addressing.  “His book is very compatible with XP. It is not about drawing pictures of a domain; it is about how you think of it, the language you use to talk about it, and how you organize your software to reflect your improving understanding of it. Eric thinks that learning about your problem domain is as likely to happen at the end of your project as at the beginning, and so refactoring is a big part of his technique.  “The book is a fun read. Eric has lots of interesting stories, and he has a way with words. I see this book as essential reading for software developers—it is a future classic.” —Ralph Johnson, author of Design Patterns   “If you don’t think you are getting value from your investment in object-oriented programming, this book will tell you what you’ve forgotten to do. “Eric Evans convincingly argues for the importance of domain modeling as the central focus of development and provides a solid framework and set of techniques for accomplishing it. This is timeless wisdom, and will hold up long after the methodologies du jour have gone out of fashion.” —Dave Collins, author of Designing Object-Oriented User Interfaces    “Eric weaves real-world experience modeling—and building—business applications into a practical, useful book. Written from the perspective of a trusted practitioner, Eric’s descriptions of ubiquitous language, the benefits of sharing models with users, object life-cycle management, logical and physical application structuring, and the process and results of deep refactoring are major contributions to our field.” —Luke Hohmann, author of Beyond Software Architecture    “This book belongs on the shelf of every thoughtful software developer.”—Kent Beck   “What Eric has managed to capture is a part of the design process that experienced object designers have always used, but that we have been singularly unsuccessful as a group in conveying to the rest of the industry. We've given away bits and pieces of this knowledge...but we've never organized and systematized the principles of building domain logic. This book is important.” —Kyle Brown, author of Enterprise Java™ Programming with IBM® WebSphere®   The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process.   Domain-Driven Design fills that need. This is not a book about specific technologies. It offers readers a systematic approach to domain-driven design, presenting an extensive set of design best practices, experience-based techniques, and fundamental principles that facilitate the development of software projects facing complex domains. Intertwining design and development practice, this book incorporates numerous examples based on actual projects to illustrate the application of domain-driven design to real-world software development.   Readers learn how to use a domain model to make a complex development effort more focused and dynamic. A core of best practices and standard patterns provides a common language for the development team. A shift in emphasis—refactoring not just the code but the model underlying the code—in combination with the frequent iterations of Agile development leads to deeper insight into domains and enhanced communication between domain expert and programmer. Domain-Driven Design then builds on this foundation, and addresses modeling and design for complex systems and larger organizations.Specific topics covered include:  Getting all team members to speak the same language Connecting model and implementation more deeply Sharpening key distinctions in a model Managing the lifecycle of a domain object Writing domain code that is safe to combine in elaborate ways Making complex code obvious and predictable Formulating a domain vision statement Distilling the core of a complex domain Digging out implicit concepts needed in the model Applying analysis patterns Relating design patterns to the model Maintaining model integrity in a large system Dealing with coexisting models on the same project Organizing systems with large-scale structures Recognizing and responding to modeling breakthroughs With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/dp/0321125215/ref=asc_df_032112521556843925/?tag=googshopuk-21&amp;creative=22110&amp;creativeASIN=0321125215&amp;linkCode=df0&amp;hvadid=310831942794&amp;hvpos=1o1&amp;hvnetw=g&amp;hvrand=16735669080936913765&amp;hvpone=&amp;hvptwo=&amp;hvqmt=&amp;hvdev=c&amp;hvdvcmdl=&amp;hvlocint=&amp;hvlocphy=9044939&amp;hvtargid=pla-449269547899&amp;th=1&amp;psc=1</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Fowler, Martin</author></authors></contributors><titles><title>bliki: MicroservicePrerequisites</title><secondary-title>martinfowler.com</secondary-title><short-title>bliki</short-title></titles><periodical><full-title>martinfowler.com</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>28 August 2014</date></pub-dates></dates><abstract>There are certain things you need to get sorted out before you can put your first microservices system into production: monitoring, provisioning, and a devops culture.</abstract><urls><web-urls><url>https://martinfowler.com/bliki/MicroservicePrerequisites.html</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\HTC39TXX\MicroservicePrerequisites.html</url></text-urls></urls><access-date>2018-11-13 20:48:17</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Newman, Sam</author></authors></contributors><titles><title>Building Microservices</title></titles><pages>280</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>20 Feb. 2015</date></pub-dates></dates><pub-location>Beijing Sebastopol, CA</pub-location><publisher>O'Reilly Media</publisher><isbn>978-1-4919-5035-7</isbn><abstract>Distributed systems have become more fine-grained in the past 10 years, shifting from code-heavy monolithic applications to smaller, self-contained microservices. But developing these systems brings its own set of headaches. With lots of examples and practical advice, this book takes a holistic view of the topics that system architects and administrators must consider when building, managing, and evolving microservice architectures.Microservice technologies are moving quickly. Author Sam Newman provides you with a firm grounding in the concepts while diving into current solutions for modeling, integrating, testing, deploying, and monitoring your own autonomous services. You’ll follow a fictional company throughout the book to learn how building a microservice architecture affects a single domain.Discover how microservices allow you to align your system design with your organization’s goalsLearn options for integrating a service with the rest of your systemTake an incremental approach when splitting monolithic codebasesDeploy individual microservices through continuous integrationExamine the complexities of testing and monitoring distributed servicesManage security with user-to-service and service-to-service modelsUnderstand the challenges of scaling microservice architectures</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Building-Microservices-Sam-Newman/dp/1491950358</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Simenon, Stefan</author><author>Roos, Wiebe de</author></secondary-authors></contributors><titles><title>Transforming CI/CD at ABN AMRO to Accelerate Software Delivery and Im…</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>Mar 27, 2018</date></pub-dates></dates><abstract>ABN AMRO is using continuous integration/continuous delivery to help to</abstract><work-type>Technology</work-type><urls><web-urls><url>https://www.slideshare.net/DevOpsWebinars/transforming-cicd-at-abn-amro-to-accelerate-software-delivery-and-improve-security</url></web-urls></urls><access-date>2018-11-13 20:40:34</access-date><misc2>Technology</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Magazine Article">19</ref-type><contributors><authors><author>Cunningham, Ward</author></authors></contributors><titles><title>Understand the High Cost of Technical Debt by Ward Cunningham - DZone Agile</title><secondary-title>dzone.com</secondary-title></titles><periodical><full-title>dzone.com</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2013</year><pub-dates><date>24 August 2013</date></pub-dates></dates><abstract>A week or two ago, I got into a conversation on Twitter about technical debt, and someone shared this superb video by Ward Cunningham (youtube). Here is Ward’s...</abstract><language>en</language><urls><web-urls><url>https://dzone.com/articles/understand-high-cost-technical</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\VE9N7LJD\understand-high-cost-technical.html</url></text-urls></urls><access-date>2018-10-01 16:12:28</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Tuckman, Bruce W.</author></authors></contributors><titles><title>Developmental sequence in small groups</title><secondary-title>Psychological Bulletin</secondary-title></titles><periodical><full-title>Psychological Bulletin</full-title></periodical><pages>384-399</pages><volume>63</volume><number>6</number><issue>6</issue><keywords><keyword>Cognitive Development</keyword><keyword>Group Dynamics</keyword><keyword>Interpersonal Interaction</keyword><keyword>Social Interaction</keyword><keyword>TT refs</keyword></keywords><dates><year>1965</year><pub-dates><date>1965</date></pub-dates></dates><isbn>1939-1455(Electronic),0033-2909(Print)</isbn><electronic-resource-num>10.1037/h0022100</electronic-resource-num><abstract>50 articles dealing with stages of group development over time are separated by group setting: therapy-group studies, T-group studies, and natural- and laboratory-group studies. The stages identified in these articles are separated into those descriptive of social or interpersonal group activities and those descriptive of group-task activities. 4 general stages of development are proposed, and the review consists of fitting the stages identified in the literature to those proposed. In the social realm, these stages in the developmental sequence are testing-dependence, conflict, cohesion, and functional roles. In the task realm, they are orientation, emotionality, relevant opinion exchange, and the emergence of solutions. There is a good fit between observed stages and the proposed model. (62 ref.) (PsycINFO Database Record (c) 2016 APA, all rights reserved)</abstract><remote-database-name>APA PsycNET</remote-database-name><urls><text-urls><url>C:\Users\matth\Zotero\storage\VEKJKXSP\1965-12187-001.html</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Axelrod, Robert A.</author></authors></contributors><titles><title>Complexity of Cooperation: Agent-Based Models of Competition and Collaboration</title><short-title>Complexity of Cooperation</short-title></titles><pages>248</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>1997</year><pub-dates><date>7 Sept. 1997</date></pub-dates></dates><pub-location>Princeton, N.J</pub-location><publisher>Princeton University Press</publisher><isbn>978-0-691-01567-5</isbn><abstract>Robert Axelrod is widely known for his groundbreaking work in game theory and complexity theory. He is a leader in applying computer modeling to social science problems. His book The Evolution of Cooperation has been hailed as a seminal contribution and has been translated into eight languages since its initial publication. The Complexity of Cooperation is a sequel to that landmark book. It collects seven essays, originally published in a broad range of journals, and adds an extensive new introduction to the collection, along with new prefaces to each essay and a useful new appendix of additional resources. Written in Axelrod's acclaimed, accessible style, this collection serves as an introductory text on complexity theory and computer modeling in the social sciences and as an overview of the current state of the art in the field. The articles move beyond the basic paradigm of the Prisoner's Dilemma to study a rich set of issues, including how to cope with errors in perception or implementation, how norms emerge, and how new political actors and regions of shared culture can develop. They use the shared methodology of agent-based modeling, a powerful technique that specifies the rules of interaction between individuals and uses computer simulation to discover emergent properties of the social system. The Complexity of Cooperation is essential reading for all social scientists who are interested in issues of cooperation and complexity</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Complexity-Cooperation-Agent-Based-Competition-Collaboration/dp/0691015678</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Stompff, Guido</author></authors></contributors><titles><title>Facilitating Team Cognition: How designers mirror what NPD teams do</title><secondary-title>ResearchGate</secondary-title><short-title>(PDF) Facilitating Team Cognition</short-title></titles><periodical><full-title>ResearchGate</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>September 2012</date></pub-dates></dates><abstract>PDF | Products are developed by large multi-disciplinary teams. The teams deal with many topics requiring the expertise of several specialists simultaneously. They have to decide together if something is a problem; propose multi-disciplinary solutions; and align their activities...</abstract><language>en</language><urls><web-urls><url>https://www.researchgate.net/publication/254831689_Facilitating_Team_Cognition_How_designers_mirror_what_NPD_teams_do</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\UR5Q8EWE\Stompff - 2012 - Facilitating Team Cognition How designers mirror .pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\QKF88A9J\254831689_Facilitating_Team_Cognition_How_designers_mirror_what_NPD_teams_do.html</url></text-urls></urls><access-date>2018-11-12 10:57:06</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Wiener</author></authors></contributors><titles><title>Cybernetics: or Control and Communication in the Animal and the Machine</title><short-title>Cybernetics</short-title></titles><pages>212</pages><edition>second edition edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>1961</year><pub-dates><date>1 Jan. 1961</date></pub-dates></dates><pub-location>Cambridge, Mass</pub-location><publisher>MIT Press</publisher><isbn>978-0-262-73009-9</isbn><abstract>Acclaimed one of the "seminal books... comparable in ultimate importance to... Galileo or Malthus or Rousseau or Mill," Cybernetics was judged by twenty-seven historians, economists, educators, and philosophers to be one of those books published during the "past four decades," which may have a substantial impact on public thought and action in the years ahead.-Saturday Review</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Cybernetics-Control-Communication-Animal-Machine/dp/026273009X</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Skelton, Matthew</author><author>Thatcher, Rob</author></authors></contributors><titles><title>Team Guide to Software Operability</title><secondary-title>Team Guide series</secondary-title></titles><number>1</number><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016-09-15</date></pub-dates></dates><pub-location>Leeds, UK</pub-location><publisher>Conflux Books</publisher><isbn>978-1-912058-71-6</isbn><abstract>Learn how a focus on software operability helps to increase system reliability, reduce problems in Production, and reduce total cost of ownership (TCO).</abstract><urls><web-urls><url>http://operabilitybook.com/</url></web-urls></urls><misc1>1</misc1></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Sussna, Jeff</author></authors></contributors><titles><title>Designing Delivery: Rethinking IT in the Digital Service Economy</title><short-title>Designing Delivery</short-title></titles><pages>232</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>17 July 2015</date></pub-dates></dates><pub-location>Beijing</pub-location><publisher>O'Reilly Media</publisher><isbn>978-1-4919-4988-7</isbn><abstract>Now that we’re moving from a product economy to a digital service economy, software is becoming critical for navigating our everyday lives. The quality of your service depends on how well it helps customers accomplish goals and satisfy needs. Service quality is not about designing capabilities, but about making—and keeping—promises to customers.To help you improve customer satisfaction and create positive brand experiences, this pragmatic book introduces a transdisciplinary approach to digital service delivery. Designing a resilient service today requires a unified effort across front-office and back-office functions and technical and business perspectives. You’ll learn how make IT a full partner in the ongoing conversations you have with your customers.Take a unique customer-centered approach to the entire service delivery lifecycleApply this perspective across development, operations, QA, design, project management, and marketingImplement a specific quality assurance methodology that unifies those disciplinesUse the methodology to achieve true resilience, not just stability</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Designing-Delivery-Rethinking-Digital-Service/dp/1491949880</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>O'Dell, Chris</author></authors></contributors><titles><title>You build it, You run it (Why developers should also be on call)</title><secondary-title>Skelton Thatcher</secondary-title></titles><periodical><full-title>Skelton Thatcher</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>2017-10-18T08:17:58+00:00</date></pub-dates></dates><abstract>It’s all about Feedback Loops The Continuous Delivery Pipeline is familiar to most developers.  It’s a collaborative process built upon loops of feedback at every stage.  A new feature will defined between a Product Manager, a Developer and a Quality Analyst.  A pair of Developers will work together on the implementation following a Test Driven...</abstract><language>en-GB</language><urls><web-urls><url>https://skeltonthatcher.com/blog/build-run-developers-also-call/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\9HCJVFEC\build-run-developers-also-call.html</url></text-urls></urls><access-date>2018-11-06 10:16:00</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Magazine Article">19</ref-type><contributors><authors><author>Wardley, Simon</author></authors></contributors><titles><title>An introduction to Wardley 'Value Chain' Mapping</title><secondary-title>CIO UK</secondary-title></titles><periodical><full-title>CIO UK</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>March 19, 2015</date></pub-dates></dates><abstract>What is Wardley Mapping? This is about my journey, from a newly-minted yet confused CEO caught like a rabbit staring helpless into the...</abstract><urls><web-urls><url>https://www.cio.co.uk/it-strategy/introduction-wardley-value-chain-mapping-3604565/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\R9KY5A45\introduction-wardley-value-chain-mapping-3604565.html</url></text-urls></urls><access-date>2018-11-05 20:52:23</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Holliday, Ben</author></authors></contributors><titles><title>A ‘service-oriented’ approach to organisation design</title><secondary-title>FutureGov</secondary-title></titles><periodical><full-title>FutureGov</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-09-25T08:41:01.264Z</date></pub-dates></dates><abstract>At FutureGov we help build organisations fit for the future. Working side by side with our clients and partners, we use service design to…</abstract><urls><web-urls><url>https://blog.wearefuturegov.com/a-service-oriented-approach-to-organisation-design-1e075be7f578</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\P9IU6HYJ\a-service-oriented-approach-to-organisation-design-1e075be7f578.html</url></text-urls></urls><access-date>2018-09-27 08:32:33</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Schwarz, Mark</author><author>Cox, Jason</author><author>Snyder, Jonathan</author><author>Rendell, Mark</author><author>Nambiar, Chivas</author><author>Kapadia, Mustafa</author></authors></contributors><titles><title>Thinking Environments</title></titles><pages>67</pages><edition>1</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016</date></pub-dates></dates><pub-location>Portland, OR</pub-location><publisher>IT Revolution Press</publisher><abstract>While the traditional IT organization is structured into functional silos, DevOps relies on empowered, cross-functional teams. Is it possible to blend the two approaches and work within the traditional structure? Or do you need to restructure your organization to support DevOps? This paper discusses ways to approach organization with DevOps in mind.</abstract><language>English</language><urls><web-urls><url>https://itrevolution.com/book/thinking-environments/</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\TIGHXKJG\Schwarz et al. - 2016 - Thinking Environments.pdf</url></pdf-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Audiovisual Material">3</ref-type><contributors><authors><author>Lewis, James</author></authors></contributors><titles><title>Microservices and the Inverse Conway Manoeuvre - James Lewis</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>16 Feb 2017</date></pub-dates></dates><remote-database-name>YouTube</remote-database-name><urls><web-urls><url>https://www.youtube.com/watch?v=uamh7xppO3E</url></web-urls></urls><access-date>2018-11-05 14:43:10</access-date><custom3>3477 seconds</custom3></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Allen, Thomas J.</author></authors></contributors><titles><title>Managing the Flow of Technology</title></titles><pages>334</pages><edition>New Ed edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>1984</year><pub-dates><date>4 Jan. 1984</date></pub-dates></dates><pub-location>Cambridge, Mass.</pub-location><publisher>MIT Press</publisher><isbn>978-0-262-51027-1</isbn><abstract>The original edition of this book summarized more than a decade of work on communications flow in science and engineering organizations, showing how human and organizational systems could be restructured to bring about improved productivity and better person-to-person contact. While many studies have been done since then, few of them invalidate the general conclusions and recommendations Allen offers. In a new preface he points out - new developments, noting areas that need some modification, elaboration, or extension, and directing readers to the appropriate journal articles where the findings, are reported. The first three chapters provide an overview of the communication system in technology, present the author's research methods, and describe differences in the career paths and goals of engineers and scientists that cause special problems for organizations. The book then discusses how technological information is acquired by the R &amp; D organization, shows how critical technical communication within the laboratory is for R &amp; D performance, and originates the idea of the "gatekeeper," the person who links his or her organization to the world at large. Concluding chapters take up the influence of formal and informal organization and of architecture and office layouts on communication. Many of these ideas have been successfully incorporated by architects and managers in the design of new R &amp; D facilities and complexes.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Managing-Flow-Technology-MIT-Press/dp/0262510278</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Paper">47</ref-type><contributors><secondary-authors><author>Evans, William</author></secondary-authors></contributors><titles><title>The Need for Speed: Enabling DevOps through Enterprise Architecture |…</title><short-title>The Need for Speed</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>02 November 2016</date></pub-dates></dates><abstract>This is a talk presented at the DevOps Enterprise Summit, 2016 by Mark Landy</abstract><work-type>Business</work-type><urls><web-urls><url>https://www.slideshare.net/willevans/the-need-for-speed-enabling-devops-through-enterprise-architecture</url></web-urls></urls><access-date>2018-11-04 10:06:20</access-date><misc2>Business</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Allspaw, John</author></authors></contributors><titles><title>Blameless PostMortems and a Just Culture</title><secondary-title>Code as Craft</secondary-title></titles><periodical><full-title>Code as Craft</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>2012-05-22T16:45:11+00:00</date></pub-dates></dates><abstract>Last week, Owen Thomas wrote a flattering article over at Business Insider on how we handle errors and mistakes at Etsy. I thought I might give some detail on how that actually happens, and why. An…</abstract><urls><web-urls><url>https://codeascraft.com/2012/05/22/blameless-postmortems/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\89P3SX3B\blameless-postmortems.html</url></text-urls></urls><access-date>2018-11-04 09:13:01</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Report">27</ref-type><contributors><authors><author>Google</author></authors></contributors><titles><title>re:Work - Guide: Understand team effectiveness</title><short-title>re</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>17 November 2015</date></pub-dates></dates><abstract>Fostering psychological safety can help teams perform and innovate, Google found while trying to understand what makes team great.</abstract><urls><web-urls><url>https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/define-team/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\NNWCJFKC\define-team.html</url></text-urls></urls><access-date>2017-10-09 19:29:18</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Rozovsky, Julia</author></authors></contributors><titles><title>re:Work - The five keys to a successful Google team</title><short-title>re</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>17 November 2015</date></pub-dates></dates><abstract>Pod. Work group. Committee. Autonomous collective. Whatever you call it, you’re part of one at Google and probably wherever you work: a team. So if we know what makes managers great, why don’t we know what makes a team great?</abstract><language>en</language><urls><web-urls><url>https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\EDF8NLYU\five-keys-to-a-successful-google-team.html</url></text-urls></urls><access-date>2018-11-04 09:00:55</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Nygard, Michael T.</author></authors></contributors><titles><title>Release It! Design and Deploy Production-Ready Software</title></titles><pages>376</pages><edition>2nd ed. edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2 Feb. 2018</date></pub-dates></dates><pub-location>Raleigh, North Carolina</pub-location><publisher>O′Reilly</publisher><isbn>978-1-68050-239-8</isbn><abstract>A single dramatic software failure can cost a company millions of dollars - but can be avoided with simple changes to design and architecture. This new edition of the best-selling industry standard shows you how to create systems that run longer, with fewer failures, and recover better when bad things happen. New coverage includes DevOps, microservices, and cloud-native architecture. Stability antipatterns have grown to include systemic problems in large-scale systems. This is a must-have pragmatic guide to engineering for production systems. If you're a software developer, and you don't want to get alerts every night for the rest of your life, help is here. With a combination of case studies about huge losses - lost revenue, lost reputation, lost time, lost opportunity - and practical, down-to-earth advice that was all gained through painful experience, this book helps you avoid the pitfalls that cost companies millions of dollars in downtime and reputation. Eighty percent of project life-cycle cost is in production, yet few books address this topic. This updated edition deals with the production of today's systems - larger, more complex, and heavily virtualized - and is the first book to cover chaos engineering, the discipline of applying randomness and deliberate stress to reveal systematic problems. Build systems that survive the real world, avoid downtime, implement zero-downtime upgrades and continuous delivery, and make cloud-native applications resilient. Examine ways to architect, design, and build software - particularly distributed systems - that stands up to the typhoon winds of a flash mob, a Slashdotting, or a link on Reddit. Take a hard look at software that failed the test and find ways to make sure your software survives.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Release-Design-Deploy-Production-Ready-Software/dp/1680502395</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Coplien, James O.</author><author>Harrison, Neil</author></authors></contributors><titles><title>Organizational Patterns of Agile Software Development</title></titles><pages>436</pages><keywords><keyword>Computers / Programming / General</keyword><keyword>Computers / Software Development &amp; Engineering / General</keyword><keyword>TT refs</keyword></keywords><dates><year>2005</year><pub-dates><date>2005</date></pub-dates></dates><publisher>Pearson Prentice Hall</publisher><isbn>978-0-13-146740-8</isbn><abstract>This book covers the human and organizational dimension of the software improvement process and software project management - whether based on the CMM or ISO 9000 or the Rational Unified Process.</abstract><remote-database-name>Google Books</remote-database-name><language>en</language><urls><text-urls><url>https://books.google.co.uk/books?id=6K5QAAAAMAAJ</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Kelly, Allan</author></authors></contributors><titles><title>Return to Conway’s Law</title><secondary-title>Allan Kelly Associates</secondary-title></titles><periodical><full-title>Allan Kelly Associates</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2006</year><pub-dates><date>2006-01-17T12:53:00+00:00</date></pub-dates></dates><abstract>Are software architectures copies of the organizations that create them? Often this is true but is it always true? And more importantly is it a good thing? In 1968 Melvin Conway wrote a paper that discussed this topic. It has since been passed down as developer folk law that. “If you have 4 developers writing … Continue reading Return to Conway’s Law</abstract><language>en-GB</language><urls><web-urls><url>https://www.allankellyassociates.co.uk/archives/1169/return-to-conways-law/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\4IN6I3UZ\return-to-conways-law.html</url></text-urls></urls><access-date>2018-10-09 18:30:36</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Skelton, Matthew</author></authors></contributors><titles><title>What Team Structure is Right for DevOps to Flourish?</title><secondary-title>Matthew Skelton</secondary-title></titles><periodical><full-title>Matthew Skelton</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2013</year><pub-dates><date>2013-10-22T00:21:50+00:00</date></pub-dates></dates><abstract>Update (2018): I am co-authoring a book – Team Topologies – that adds brand new material to the DevOps Topologies patterns. See teamtopologies.com and follow us on Twitter at @TeamTopol…</abstract><language>en</language><urls><web-urls><url>https://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\24HZBGR4\what-team-structure-is-right-for-devops-to-flourish.html</url></text-urls></urls><access-date>2018-10-05 14:27:01</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Skulmowski, Alexander</author><author>Rey, Günter Daniel</author></authors></contributors><titles><title>Measuring Cognitive Load in Embodied Learning Settings</title><secondary-title>Frontiers in Psychology</secondary-title></titles><periodical><full-title>Frontiers in Psychology</full-title><abbr-1>Front. Psychol.</abbr-1></periodical><volume>8</volume><keywords><keyword>Cognitive Load</keyword><keyword>Cognitive Load Theory</keyword><keyword>Embodied Cognition</keyword><keyword>Learning</keyword><keyword>Measurement</keyword><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>2017</date></pub-dates></dates><isbn>1664-1078</isbn><electronic-resource-num>10.3389/fpsyg.2017.01191</electronic-resource-num><abstract>In recent years, research on embodied cognition has inspired a number of studies on multimedia learning and instructional psychology. However, in contrast to traditional research on education and multimedia learning, studies on embodied learning (i.e., focusing on bodily action and perception in the context of education) in some cases pose new problems for the measurement of cognitive load. This review provides an overview over recent studies on embodied learning in which cognitive load was measured using surveys, behavioral data, or physiological measures. The different methods are assessed in terms of their success in finding differences of cognitive load in embodied learning scenarios. At the same time, we highlight the most important challenges for researchers aiming to include these measures into their study designs. The main issues we identified are: (1) Subjective measures must be appropriately phrased to be useful for embodied learning; (2) recent findings indicate potentials as well as problematic aspects of dual-task measures; (3) the use of physiological measures offers great potential, but may require mobile equipment in the context of embodied scenarios; (4) meta-cognitive measures can be useful extensions of cognitive load measurement for embodied learning.</abstract><remote-database-name>Frontiers</remote-database-name><language>English</language><urls><web-urls><url>https://www.frontiersin.org/articles/10.3389/fpsyg.2017.01191/full</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\H3U68H93\Skulmowski and Rey - 2017 - Measuring Cognitive Load in Embodied Learning Sett.pdf</url></pdf-urls></urls><access-date>2018-10-01 20:15:31</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>DeMarco, Tom</author><author>Lister, Timothy</author></authors></contributors><titles><title>Peopleware: Productive Projects and Teams</title><short-title>Peopleware</short-title></titles><pages>245</pages><edition>2nd Revised edition edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>1999</year><pub-dates><date>1 Jan. 1999</date></pub-dates></dates><pub-location>New York, NY</pub-location><publisher>Dorset House Publishing Co Inc.,U.S.</publisher><isbn>978-0-932633-43-9</isbn><abstract>Two of the computer industry's best-selling authors and lecturers return with a new edition of the software management book that started a revolution.  With humor and wisdom drawn from years of management and consulting experience, DeMarco and Lister demonstrate that the major issues of software development are human, not technical -- and that managers ignore them at their peril.  Now, with a new Preface and eight new chapters, the authors enlarge upon their previous ideas and add fresh insights, examples, and anecdotes.  Discover dozens of helpful tips on - putting more quality into a product - loosening up formal methodologies - fighting corporate entropy - making it acceptable to be uninterruptible  Peopleware, 2nd ed. shows you how to cultivate teams that are healthy and productive. The answers aren't easy -- just incredibly successful.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Peopleware-Productive-Projects-Tom-DeMarco/dp/0932633439</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Ancona, Deborah Gladstein</author><author>Caldwell, David F.</author></authors></contributors><titles><title>Demography and Design: Predictors of New Product Team Performance</title><secondary-title>Organization Science</secondary-title><short-title>Demography and Design</short-title></titles><periodical><full-title>Organization Science</full-title><abbr-1>Organization Science</abbr-1></periodical><pages>321-341</pages><volume>3</volume><number>3</number><issue>3</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>1992</year><pub-dates><date>August 1, 1992</date></pub-dates></dates><isbn>1047-7039</isbn><electronic-resource-num>10.1287/orsc.3.3.321</electronic-resource-num><abstract>The increasing reliance on teams in organizations raises the question of how these teams should be formed. Should they be formed completely of engineers or should they include a range of specialists? Should they be made up to people who have long tenure in the organization, or those with a wide range of experience? As teams increasingly get called upon to do more complex tasks and to cross functional boundaries within the organization, conventional wisdom has suggested that teams be composed of more diverse members. This study suggests that the answer may not be so simple.Using 409 individuals from 45 new product teams in five high-technology companies, this study investigates the impact of diversity on team performance. We found that functional and tenure diversity each has its own distinct effects. The greater the functional diversity, the more team members communicated outside the team's boundaries. This communication was with a variety of groups such as marketing, manufacturing, and top management. The more the external communication, the higher the managerial ratings of innovation.Tenure diversity had its impact on internal group dynamics rather than external communications. Tenure diversity is associated with improved task work such as clarifying group goals and setting priorities. In turn, this clarity is associated with high team ratings of overall performance.Yet diversity is not solely positive. While it does produce internal processes and external communications that facilitate performance, it also directly impedes performance. That is, overall the effect of diversity on performance is negative, even though some aspects of group work are enhanced. It may be that for these teams diversity brings more creativity to problem solving and product development, but it impedes implementation because there is less capability for teamwork than there is for homogeneous teams.These research findings suggest that simply changing the structure of teams (i.e. combining representatives of diverse function and tenure) will not improve performance. The team must find a way to garner the positive process effects of diversity and to reduce the negative direct effects. At the team level, greater negotiation and conflict resolution skills may be necessary. At the organization level, the team may need to be protected from external political pressures and rewarded for team, rather than functional, outcomes.</abstract><remote-database-name>pubsonline.informs.org (Atypon)</remote-database-name><urls><web-urls><url>https://pubsonline.informs.org/doi/abs/10.1287/orsc.3.3.321</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\HGX84C9S\orsc.3.3.html</url></text-urls></urls><access-date>2018-10-01 19:07:59</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Lim, Beng-Chong</author><author>Klein, Katherine J.</author></authors></contributors><titles><title>Team mental models and team performance: a field study of the effects of team mental model similarity and accuracy</title><secondary-title>Journal of Organizational Behavior</secondary-title><short-title>Team mental models and team performance</short-title></titles><periodical><full-title>Journal of Organizational Behavior</full-title></periodical><pages>403-418</pages><volume>27</volume><number>4</number><issue>4</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>2006</year><pub-dates><date>2006-06-01</date></pub-dates></dates><isbn>1099-1379</isbn><electronic-resource-num>10.1002/job.387</electronic-resource-num><abstract>We conducted a field study of 71 action teams to examine the relationship between team mental model similarity and accuracy and the performance of real-world teams. We used Pathfinder to operationalize team members' taskwork mental models (describing team procedures, tasks, and equipment) and teamwork mental models (describing team interaction processes) and examined team performance as evaluated by expert team assessment center raters. Both taskwork mental model and teamwork mental model similarity predicted team performance. Team mental model accuracy measures were also predictive of team performance. We discuss the implications of our findings and directions for future research. Copyright © 2006 John Wiley &amp; Sons, Ltd.</abstract><remote-database-name>Wiley Online Library</remote-database-name><language>en</language><urls><web-urls><url>https://onlinelibrary.wiley.com/doi/abs/10.1002/job.387</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\YN7ACFL5\job.html</url></text-urls></urls><access-date>2018-10-01 19:02:19</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Driskell, James E.</author><author>Salas, Eduardo</author></authors></contributors><titles><title>Collective Behavior and Team Performance</title><secondary-title>Human Factors</secondary-title></titles><periodical><full-title>Human Factors</full-title><abbr-1>Hum Factors</abbr-1></periodical><pages>277-288</pages><volume>34</volume><number>3</number><issue>3</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>1992</year><pub-dates><date>June 1, 1992</date></pub-dates></dates><isbn>0018-7208</isbn><electronic-resource-num>10.1177/001872089203400303</electronic-resource-num><abstract>Modern complex systems require effective team performance, yet the question of which factors determine effective teams remains to be answered. Group researchers suggest that collective or interdependent behavior is a critical component of team interaction. Furthermore, anecdotal evidence suggests that some team members are less collectively oriented than others and that the tendency to ignore task inputs from others is one factor that contributes to poor team performance. In this study we develop a procedure for differentiating collectively oriented versus egocentric team members. Experimental results confirm that collectively oriented team members were more likely to attend to the task inputs of other team members and to improve their performance during team interaction than were egocentric team members.</abstract><remote-database-name>SAGE Journals</remote-database-name><language>en</language><urls><web-urls><url>https://doi.org/10.1177/001872089203400303</url></web-urls></urls><access-date>2018-10-01 18:49:51</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Carayon, Pascale</author></authors></contributors><titles><title>Human factors of complex sociotechnical systems</title><secondary-title>Applied Ergonomics</secondary-title></titles><periodical><full-title>Applied Ergonomics</full-title><abbr-1>Applied Ergonomics</abbr-1></periodical><pages>525-535</pages><volume>37</volume><number>4</number><issue>4</issue><keywords><keyword>Complex work system</keyword><keyword>Computer and information system security</keyword><keyword>Health care and patient safety</keyword><keyword>Macroergonomics</keyword><keyword>Organizational design and management (ODAM)</keyword><keyword>Sociotechnical system</keyword><keyword>TT refs</keyword></keywords><dates><year>2006</year><pub-dates><date>July 2006</date></pub-dates></dates><isbn>0003-6870</isbn><electronic-resource-num>10.1016/j.apergo.2006.04.011</electronic-resource-num><abstract>Increasingly products and services result from interactions among people who work across organizational, geographical, cultural and temporal boundaries. This has major implications for human factors and ergonomics (HFE), in particular, challenging the limits of the systems to be designed, and widening the range of system elements and dimensions that we need to consider. The design of sociotechnical systems that involve work across multiple boundaries requires better integration of the various sub-disciplines or components of HFE, as well as increased collaboration with other disciplines that provide either expertise regarding the domain of application or expertise in concepts that can enrich the system design.&#xD;&#xD;In addition, ‘customers’ contribute significantly to the ‘co-production’ of products/services, as well as to their quality/safety. The design of sociotechnical systems in collaboration with both the workers in the systems and the customers requires increasing attention not only to the design and implementation of systems, but also to the continuous adaptation and improvement of systems in collaboration with customers.&#xD;&#xD;This paper draws from research on human factors in the domains of health care and patient safety and of computer security.</abstract><remote-database-name>ScienceDirect</remote-database-name><urls><web-urls><url>http://www.sciencedirect.com/science/article/pii/S0003687006000585</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\8S9VA9PN\S0003687006000585.html</url></text-urls></urls><access-date>2016-07-15 13:36:13</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Johnston, Joan H.</author><author>Fiore, Stephen M.</author><author>Smith, C.A.P.</author></authors></contributors><titles><title>Application of Cognitive Load Theory to Developing a Measure of Team Decision Efficiency</title><secondary-title>Military Psychology</secondary-title></titles><periodical><full-title>Military Psychology</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2002</year><pub-dates><date>2002</date></pub-dates></dates><abstract>Improving human systems integration through technologically advanced training and&#xD;performance aids has become increasingly important to military transformation. Measures of&#xD;improved cognitive and coordination processes arising from the employment of transformational&#xD;tools are necessary to guide the refinement and future development of such technologies. In this&#xD;paper we describe a Cognitive Load Theory approach to developing a combinatory measure of&#xD;individual workload and team performance following an experimental intervention involving&#xD;training and a Decision Support System. We discuss how indicators of what we term team&#xD;decision efficiency can improve assessing the effectiveness of transformational processes and&#xD;technologies.</abstract><urls><web-urls><url>http://www.dtic.mil/dtic/tr/fulltext/u2/a525820.pdf</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\2BVLRPG8\Johnston et al. - 2002 - Application of Cognitive Load Theory to Developing.pdf</url></pdf-urls></urls><access-date>2016-05-20</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Ilgen, Daniel</author><author>R. Hollenbeck, John</author></authors></contributors><titles><title>Effective Team Performance Under Stress and Normal Conditions: An Experimental Paradigm, Theory and Data for Studying Team Decision Making in Hierarchical Teams with Distributed Expertise</title><short-title>Effective Team Performance Under Stress and Normal Conditions</short-title></titles><pages>85</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>1993</year><pub-dates><date>August 1, 1993</date></pub-dates></dates><abstract>The report describes a program of research addressing decision making in hierarchical teams with distributed expertise. A theory of such decision making is presented along with empirical research related to the theory. Then a team simulation exercise was developed to address team decision for four person teams. This exercise presents teams with problems that require gathering and sharing information prior to reaching a team decision and also allow for the assignment of team members to roles that differ in areas of expertise. This exercise, performed on four networked computers, allows for the assessment of a large number of team behaviors. Along with the exercise, repeated measures regression is used as a means of analyzing team data by taking advantage of the statistical power available at various levels of analysis. Several studies were conducted to assess the viability of theory and to look at a number of other issues of decision making. Team decision making, Distributed expertise, Group dynamics, Hierarchical teams, Levels analysis of teams</abstract><remote-database-name>ResearchGate</remote-database-name><urls><pdf-urls><url>C:\Users\matth\Zotero\storage\UFKMNWWN\Ilgen and R. Hollenbeck - 1993 - Effective Team Performance Under Stress and Normal.pdf</url></pdf-urls><text-urls><url>https://www.researchgate.net/publication/235122945_Effective_Team_Performance_Under_Stress_and_Normal_Conditions_An_Experimental_Paradigm_Theory_and_Data_for_Studying_Team_Decision_Making_in_Hierarchical_Teams_with_Distributed_Expertise</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Malan, Ruth</author></authors></contributors><titles><title>Conway’s Law</title><secondary-title>traceinthesand.com Blog</secondary-title></titles><periodical><full-title>traceinthesand.com Blog</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2008</year><pub-dates><date>13 February 2008</date></pub-dates></dates><urls><web-urls><url>http://traceinthesand.com/blog/2008/02/13/conways-law/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\RZJXHU7G\conways-law.html</url></text-urls></urls><access-date>2018-10-01 14:08:05</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Driskell, James</author><author>Salas, Eduardo</author><author>Johnston, Joan</author></authors></contributors><titles><title>Does Stress Lead to a Loss of Team Perspective?</title><secondary-title>Group Dynamics: Theory, Research, and Practice</secondary-title></titles><periodical><full-title>Group Dynamics: Theory, Research, and Practice</full-title></periodical><pages>291-302</pages><volume>3</volume><keywords><keyword>TT refs</keyword></keywords><dates><year>1999</year><pub-dates><date>December 1, 1999</date></pub-dates></dates><electronic-resource-num>10.1037/1089-2699.3.4.291</electronic-resource-num><abstract>One of the more well-established findings in the research literature is that stress leads to a restriction or narrowing of attentional focus. In the present study, we extend this research to the group context. We propose that, in a team environment, the narrowing of attention induced by stress may result in a shift in perspective from a broad team perspective to a more narrow or individualistic self-focus, and this loss of team perspective may result in degraded team performance. The results of an empirical study found that stress resulted in a narrowing of team perspective and that team perspective was a significant predictor of team performance. Moreover, when the effects of team perspective were controlled, the effects of stress on team performance were substantially weakened. These results suggest that one way in which stress impacts team performance is by narrowing or weakening the team-level perspective required for effective team behavior. (PsycINFO Database Record (c) 2012 APA, all rights reserved)</abstract><remote-database-name>ResearchGate</remote-database-name><urls><pdf-urls><url>C:\Users\matth\Zotero\storage\VW4NHM2W\Driskell et al. - 1999 - Does Stress Lead to a Loss of Team Perspective.pdf</url></pdf-urls><text-urls><url>https://www.researchgate.net/publication/232517202_Does_Stress_Lead_to_a_Loss_of_Team_Perspective</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Meadows, Donella</author></authors></contributors><titles><title>Leverage Points: Places to Intervene in a System</title><secondary-title>The Academy for Systems Change</secondary-title><short-title>Leverage Points</short-title></titles><periodical><full-title>The Academy for Systems Change</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>1997</year><pub-dates><date>1997</date></pub-dates></dates><abstract>By Donella Meadows~ Folks who do systems analysis have a great belief in “leverage points.” These are places within a complex system (a corporation, an economy, a living body, a city, an ecosystem) where a small shift in one thing can produce big changes in everything. This idea is not unique to systems analysis — …</abstract><language>en-US</language><urls><web-urls><url>http://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\596NXTUG\leverage-points-places-to-intervene-in-a-system.html</url></text-urls></urls><access-date>2018-09-23 20:32:17</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Beer, Stafford</author></authors></contributors><titles><title>Brain of the Firm 2e</title></titles><pages>432</pages><edition>2 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>1995</year><pub-dates><date>16 May 1995</date></pub-dates></dates><pub-location>Chichester</pub-location><publisher>John Wiley &amp; Sons</publisher><isbn>978-0-471-94839-1</isbn><abstract>"Stafford Beer is undoubtedly among the world′s most provocative, creative, and profound thinkers on the subject of management, and he records his thinking with a flair that is unmatched. His writing is as much art as it is science. He is the most viable system I know." Dr Russell L Ackoff, The Institute for Interactive Management, Pennsylvania, USA. "If . anyone can make it [Operations Research] understandably readable and positively interesting it is Stafford Beer . everyone in management . should be grateful to him for using clear and at times elegant English and . even elegant diagrams." The Economist This is the second edition of a book which has already become a management ′standard′ both in universities and on the bookshelves of managers and their advisers. Brain of the Firm develops an account of the firm based upon insights derived from the study of the human nervous system, and is a basic text from the author′s theory of viable systems. Despite the neurophysiology, the book is written for managers to understand. The companion volume to this book is The Heart of Enterprise, which is intended to support and complement this text. "Stafford Beer′s works represent required reading for everyone who believes that a capacity for rigorous thinking is an essential attribute of today′s successful managers and administrators. Brain of the Firm shows a first–rate intellect at work and provides concepts, models and inspiration for both practitioners and teachers." Sir Douglas Hague, CBE</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://smile.amazon.co.uk/Brain-Firm-2e-Classic-Beer/dp/047194839X/ref=smi_www_rco2_go_smi_g9905632998?_encoding=UTF8&amp;%2AVersion%2A=1&amp;%2Aentries%2A=0&amp;ie=UTF8</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Drucker, Peter</author></authors></contributors><titles><title>The Daily Drucker</title></titles><pages>494</pages><keywords><keyword>Performing Arts / Dance / General</keyword><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-03-09</date></pub-dates></dates><publisher>Routledge</publisher><isbn>978-1-136-01929-6</isbn><abstract>A powerful new learning tool for the ambitious, self-directed manager, entrepreneur, or business person today, The Daily Drucker distils the essence of management guru Peter F. Drucker's teachings in an easy-to-access, daily calendar format. It presents in organized form: a key statement of Drucker’s, followed by a few lines of comment and explanation, with topics ranging across a great many fields of his work: management, business and the world economy; a changing society; innovation and entrepreneurship; decision-making; the changing workforce and the non-profit and their management. However, the most important part of this book are the blank halves of its pages. They are what the readers will contribute, their actions, decisions and the results of these decisions.There are 366 readings, each addressing a major topic, one for every day of the year. Each reading starts with a topic and a “Drucker Proverb” such as “Know Thy Time”, capturing the essence of the topic. Then there is a teaching taken directly from the works of Peter Drucker. Next comes the action step, where you are asked to “Think on” the teaching and apply it to yourself and your organization.</abstract><remote-database-name>Google Books</remote-database-name><language>en</language><urls><text-urls><url>https://books.google.co.uk/books?id=TnhQDwAAQBAJ</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Pflaeging, Niels</author></authors></contributors><titles><title>Organize for Complexity: How to Get Life Back Into Work to Build the High-Performance Organization</title><short-title>Organize for Complexity</short-title></titles><pages>144</pages><edition>Revised, ed. edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>19 Mar. 2014</date></pub-dates></dates><publisher>BetaCodex Publishing</publisher><isbn>978-0-9915376-0-0</isbn><abstract>A book about complexity and work - and about how to deal productively with both. A condensed introduction to the theory and practice of organizational high performance. A manifesto for contemporary leadership and profound transformation in organizations of all kinds. 3rd eidition."Boldly, Pflaeging dissects classic management theory and in a well-humored manner, offers coherent alternatives." Harvard Business Review"Niels Pflaeging is the father of the end of management." Winfried Felser, competence-site"When Pflaeging shakes the dogmas of management, they crumble in his hands." Financial Times Germany"Niels Pflaeging is always right up front, where the new in business is getting measured and mapped." Peter Felixberger, changeX</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Organize-Complexity-High-Performance-Organization-Publishing/dp/0991537602</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Pflaeging, Niels</author></authors></contributors><titles><title>Org Physics: The 3 faces of every company</title><secondary-title>Niels Pflaeging</secondary-title><short-title>Org Physics</short-title></titles><periodical><full-title>Niels Pflaeging</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>2017-03-06T13:17:06.613Z</date></pub-dates></dates><abstract>How a triad of structures allows companies to absorb complexity</abstract><urls><web-urls><url>https://medium.com/@NielsPflaeging/org-physics-the-3-faces-of-every-company-df16025f65f8</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\SPPEKE25\org-physics-the-3-faces-of-every-company-df16025f65f8.html</url></text-urls></urls><access-date>2018-09-25 17:32:29</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Fisher-Ogden, Philip</author><author>Burrell, Greg</author><author>Marsh, Dianne</author></authors></contributors><titles><title>Full Cycle Developers at Netflix</title><secondary-title>Netflix TechBlog</secondary-title></titles><periodical><full-title>Netflix TechBlog</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-05-17T15:01:01.876Z</date></pub-dates></dates><abstract>Operating what you build, empowered with amazing developer tools</abstract><urls><web-urls><url>https://medium.com/netflix-techblog/full-cycle-developers-at-netflix-a08c31f83249</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\UZHI5BNE\full-cycle-developers-at-netflix-a08c31f83249.html</url></text-urls></urls><access-date>2018-09-25 14:58:25</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Bottcher, Evan</author></authors></contributors><titles><title>What I Talk About When I Talk About Platforms</title><secondary-title>martinfowler.com</secondary-title></titles><periodical><full-title>martinfowler.com</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>05 March 2018</date></pub-dates></dates><abstract>These days everyone is building a 'platform' to speed up delivery of digital products. But what makes an effective digital platform?</abstract><urls><web-urls><url>https://martinfowler.com/articles/talk-about-platforms.html</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\HAKUI52D\talk-about-platforms.html</url></text-urls></urls><access-date>2018-09-25 11:55:44</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Schotkamp, Tom</author><author>Danoesastro, Martin</author></authors></contributors><titles><title>HR’s Pioneering Role in Agile at ING</title><secondary-title>https://www.bcg.com</secondary-title></titles><periodical><full-title>https://www.bcg.com</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>1 June 2018</date></pub-dates></dates><abstract>First, HR carried out an agile makeover of the bank’s Dutch unit—then, it transformed itself. HR and functional-area leaders everywhere, take note.</abstract><language>en</language><urls><web-urls><url>https://www.bcg.com/en-gb/publications/2018/human-resources-pioneering-role-agile-ing.aspx</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\W7XX9L75\HRs Pioneering Role_ex01_tcm-193159.png</url><url>C:\Users\matth\Zotero\storage\GU2RHRJ9\human-resources-pioneering-role-agile-ing.html</url></text-urls></urls><access-date>2018-09-25 07:40:45</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Laloux, Frederic</author></authors></contributors><titles><title>Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness</title><short-title>Reinventing Organizations</short-title></titles><pages>382</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>10 Feb. 2014</date></pub-dates></dates><pub-location>Brussels</pub-location><publisher>Nelson Parker</publisher><isbn>978-2-9601335-0-9</isbn><abstract>The way we manage organizations seems increasingly out of date. Survey after survey shows that a majority of employees feel disengaged from their companies. The epidemic of organizational disillusionment goes way beyond Corporate America-teachers, doctors, and nurses are leaving their professions in record numbers because the way we run schools and hospitals kills their vocation. Government agencies and nonprofits have a noble purpose, but working for these entities often feels soulless and lifeless just the same. All these organizations suffer from power games played at the top and powerlessness at lower levels, from infighting and bureaucracy, from endless meetings and a seemingly never-ending succession of change and cost-cutting programs.  Deep inside, we long for soulful workplaces, for authenticity, community, passion, and purpose. The solution, according to many progressive scholars, lies with more enlightened management. But reality shows that this is not enough. In most cases, the system beats the individual-when managers or leaders go through an inner transformation, they end up leaving their organizations because they no longer feel like putting up with a place that is inhospitable to the deeper longings of their soul.  We need more enlightened leaders, but we need something more: enlightened organizational structures and practices. But is there even such a thing? Can we conceive of enlightened organizations?  In this groundbreaking book, the author shows that every time humanity has shifted to a new stage of consciousness in the past, it has invented a whole new way to structure and run organizations, each time bringing extraordinary breakthroughs in collaboration. A new shift in consciousness is currently underway. Could it help us invent a radically more soulful and purposeful way to run our businesses and nonprofits, schools and hospitals?  The pioneering organizations researched for this book have already "cracked the code." Their founders have fundamentally questioned every aspect of management and have come up with entirely new organizational methods. Even though they operate in very different industries and geographies and did not know of each other's experiments, the structures and practices they have developed are remarkably similar. It's hard not to get excited about this finding: a new organizational model seems to be emerging, and it promises a soulful revolution in the workplace.  "Reinventing Organizations" describes in practical detail how organizations large and small can operate in this new paradigm. Leaders, founders, coaches, and consultants will find this work a joyful handbook, full of insights, examples, and inspiring stories.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Reinventing-Organizations-Creating-Inspired-Consciousness/dp/2960133501</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Feathers, Michael</author></authors></contributors><titles><title>Working Effectively with Legacy Code</title></titles><pages>456</pages><edition>01 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2004</year><pub-dates><date>22 Sept. 2004</date></pub-dates></dates><pub-location>Upper Saddle River, NJ</pub-location><publisher>Prentice Hall</publisher><isbn>978-0-13-117705-5</isbn><abstract>This book provides programmers with the ability to cost effectively handlecommon legacy code problems without having to go through the hugelyexpensive task of rewriting all existing code. It describes a series of practicalstrategies that developers can employ to bring their existing softwareapplications under control. The author provides useful guidance about how touse these strategies when refactoring or making functional changes to codebases. One of the book's key points is that it teaches developers to write teststhat can be used to make sure they are not unintentionally changing theapplication as they optimize it. Examples are provided in Java, C++, and Csharp,and the book assumes that the reader has some knowledge of UMLnotation. Strategies using UML and code in C++ and Java primarily whilelanguage independent advice will be delivered in side bars and appendices forlanguage specific users.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Magazine Article">19</ref-type><contributors><authors><author>Cutler, John</author></authors></contributors><titles><title>12 Signs You’re Working in a Feature Factory</title><secondary-title>Hacker Noon</secondary-title></titles><periodical><full-title>Hacker Noon</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016-11-17T04:52:04.072Z</date></pub-dates></dates><abstract>I’ve used the term Feature Factory at a couple conference talks over the past two years. I started using the term when a software developer…</abstract><urls><web-urls><url>https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\N9I5HRAI\12-signs-youre-working-in-a-feature-factory-44a5b938d6a2.html</url></text-urls></urls><access-date>2018-09-24 06:51:38</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Lencioni, Patrick M.</author></authors></contributors><titles><title>The Five Dysfunctions of a Team: A Leadership Fable</title><short-title>The Five Dysfunctions of a Team</short-title></titles><pages>240</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2002</year><pub-dates><date>18 April 2002</date></pub-dates></dates><pub-location>San Francisco</pub-location><publisher>John Wiley &amp; Sons</publisher><isbn>978-0-7879-6075-9</isbn><abstract>In The Five Dysfunctions of a Team Patrick Lencioni once again offers a leadership fable that is as enthralling and instructive as his first two best–selling books, The Five Temptations of a CEO and The Four Obsessions of an Extraordinary Executive. This time, he turns his keen intellect and storytelling power to the fascinating, complex world of teams.   Kathryn Petersen, Decision Tech′s CEO, faces the ultimate leadership crisis: Uniting a team in such disarray that it threatens to bring down the entire company. Will she succeed? Will she be fired? Will the company fail? Lencioni′s utterly gripping tale serves as a timeless reminder that leadership requires as much courage as it does insight.   Throughout the story, Lencioni reveals the five dysfunctions which go to the very heart of why teams even the best ones–often struggle. He outlines a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team. Just as with his other books, Lencioni has written a compelling fable with a powerful yet deceptively simple message for all those who strive to be exceptional team leaders.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Five-Dysfunctions-Team-Leadership-Lencioni/dp/0787960756</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Forrester, Russ</author><author>Drexler, Allan B.</author></authors></contributors><titles><title>A model for team-based organization performance</title><secondary-title>Academy of Management Perspectives</secondary-title></titles><periodical><full-title>Academy of Management Perspectives</full-title><abbr-1>AMP</abbr-1></periodical><pages>36-49</pages><volume>13</volume><number>3</number><issue>3</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>1999</year><pub-dates><date>August 1, 1999</date></pub-dates></dates><isbn>1558-9080</isbn><electronic-resource-num>10.5465/ame.1999.2210313</electronic-resource-num><abstract>The team-based organization performance model is a map for the landscape of organizations that use a lot of teams. The critical issues that team-based organizations must resolve to perform effectively are: formation, getting the right pieces in place and fitting them together: dependability, making reliable connections between the parts; focus, targeting the direction and goals of the organization and its accountability processes: buy-in, the ownership of and involvement in the organization's work and the issues of power and control; coordination, achieving smoothness and consistency in an organization's operations: impact, the impression the organization makes on itself and its clients; and vitality, the energy that starts and sustains the organization over time, and the capacity it has to learn and adapt. This article visits each of these landmarks, illustrating them with company examples, examining the keys to mastering them, and describing detours that some organizations have taken and how they got back on track. The article also provides an aerial view of the elements and their relationships.</abstract><remote-database-name>journals.aom.org (Atypon)</remote-database-name><urls><web-urls><url>https://journals.aom.org/doi/abs/10.5465/ame.1999.2210313</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\DHRKPC2R\ame.1999.html</url></text-urls></urls><access-date>2018-09-23 14:34:33</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>DeSanctis, Gerardine</author><author>Poole, Marshall Scott</author></authors></contributors><titles><title>Capturing the Complexity in Advanced Technology Use: Adaptive Structuration Theory</title><secondary-title>Organization Science</secondary-title><short-title>Capturing the Complexity in Advanced Technology Use</short-title></titles><periodical><full-title>Organization Science</full-title></periodical><pages>121-147</pages><volume>5</volume><number>2</number><issue>2</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>1994</year><pub-dates><date>1994</date></pub-dates></dates><isbn>1047-7039</isbn><abstract>The past decade has brought advanced information technologies, which include electronic messaging systems, executive information systems, collaborative systems, group decision support systems, and other technologies that use sophisticated information management to enable multiparty participation in organization activities. Developers and users of these systems hold high hopes for their potential to change organizations for the better, but actual changes often do not occur, or occur inconsistently. We propose adaptive structuration theory (AST) as a viable approach for studying the role of advanced information technologies in organization change. AST examines the change process from two vantage points: (1) the types of structures that are provided by advanced technologies, and (2) the structures that actually emerge in human action as people interact with these technologies. To illustrate the principles of AST, we consider the small group meeting and the use of a group decision support system (GDSS). A GDSS is an interesting technology for study because it can be structured in a myriad of ways, and social interaction unfolds as the GDSS is used. Both the structure of the technology and the emergent structure of social action can be studied. We begin by positioning AST among competing theoretical perspectives of technology and change. Next, we describe the theoretical roots and scope of the theory as it is applied to GDSS use and state the essential assumptions, concepts, and propositions of AST. We outline an analytic strategy for applying AST principles and provide an illustration of how our analytic approach can shed light on the impacts of advanced technologies on organizations. A major strength of AST is that it expounds the nature of social structures within advanced information technologies and the key interaction processes that figure in their use. By capturing these processes and tracing their impacts, we can reveal the complexity of technology-organization relationships. We can attain a better understanding of how to implement technologies, and we may also be able to develop improved designs or educational programs that promote productive adaptations.</abstract><remote-database-name>JSTOR</remote-database-name><urls><web-urls><url>https://www.jstor.org/stable/2635011</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\4RC9CGSI\DeSanctis and Poole - 1994 - Capturing the Complexity in Advanced Technology Us.pdf</url></pdf-urls></urls><access-date>2018-09-23 14:08:13</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Knight, Pamela</author></authors></contributors><titles><title>Acquisition Community Team Dynamics: The Tuckman Model vs. the DAU Model</title><secondary-title>4th Annual Acquisition Research Symposium of the Naval Postgraduate School</secondary-title></titles><periodical><full-title>4th Annual Acquisition Research Symposium of the Naval Postgraduate School</full-title></periodical><pages>55</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2007</year><pub-dates><date>30 April 2007</date></pub-dates></dates><abstract>The Tuckman (1965) four-stage sequential model of team development (Forming, Storming, Norming, and Performing, or FSNP) represents today's most widely used model.&#xD;However, the Tuckman model is a conceptual statement that was suggested by the data and has not been empirically validated (Tuckman, 1965). Hadyn, Teare, Scheuing and Armistead (1997, p. 118) state that, "despite increasing interest in teamwork, much of the literature on the subject is inconclusive and often derived from anecdote rather than primary research."&#xD;The goal of this research was to develop empirical evidence to determine whether or not the Tuckman model or some variant thereof provides an appropriate model to explain the development of small, short-duration technical teams within the Acquisition Community.&#xD;The results showed, to a 95% confidence level, that only about 2% of 321 teams studies followed the Tuckman model (FSNP). However a modified model, called the DAU Model (FNP—Tuckman model sans Storming), was experienced by 229 of the 321 teams (77%). This discrete three-stage model, along with a redefined Storming function that takes place throughout the teams' duration, constitutes a strong model of team dynamics for the studied Acquisition population.&#xD;This research demonstrates that not only do technical teams generally follow the DAU model, but also that there is a strong correlation between teams producing above average products and teams following this model. The results of this research strongly suggest the possibility that the productivity of a technical team may be significantly improved by guiding its development through a well-defined process.</abstract><remote-database-name>Zotero</remote-database-name><language>en</language><urls><web-urls><url>http://www.dtic.mil/dtic/tr/fulltext/u2/a493549.pdf</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\36LLN877\Acquisition Community Team Dynamics The Tuckman M.pdf</url></pdf-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Magazine Article">19</ref-type><contributors><authors><author>Larman, Criag</author><author>Vodde, Bas</author></authors></contributors><titles><title>Choose Feature Teams over Component Teams for Agility</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2008</year><pub-dates><date>15 July 2008</date></pub-dates></dates><abstract>Feature teams, common enough in small groups, are all too rare in large product development - but they can be a key to scaling with agility. This article analyses how feature teams resolve weaknesses of component teams, and points out key issues to address when transitioning. It is an excerpt from "Scaling Lean and Agile Development," by Craig Larman and Bas Vodde, to be published later this year.</abstract><urls><web-urls><url>https://www.infoq.com/articles/scaling-lean-agile-feature-teams</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\NA7FUCZR\scaling-lean-agile-feature-teams.html</url></text-urls></urls><access-date>2018-09-17 17:10:49</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Conway, Mel</author></authors></contributors><titles><title>Toward Simplifying Application Development, in a Dozen Lessons</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>03 January 2017</date></pub-dates></dates><urls><web-urls><url>http://melconway.com/Home/pdf/simplify.pdf</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\PEN4SH8V\simplify.pdf</url></pdf-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Conway, Melvin E</author></authors></contributors><titles><title>HOW DO COMMITTEES INVENT?</title><secondary-title>Datamation</secondary-title></titles><periodical><full-title>Datamation</full-title></periodical><pages>4</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>1968</year><pub-dates><date>1968</date></pub-dates></dates><remote-database-name>Zotero</remote-database-name><language>en</language><urls><web-urls><url>http://www.melconway.com/Home/pdf/committees.pdf</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\JGUIFA8Q\Conway - 1968 - HOW DO COMMITTEES INVENT.pdf</url></pdf-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Ackoff, Russell L.</author><author>Addison, Herbert J.</author><author>Bibb, Sally</author></authors></contributors><titles><title>Management F-laws: How Organizations Really Work</title><short-title>Management F-laws</short-title></titles><pages>180</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2007</year><pub-dates><date>24 Jan. 2007</date></pub-dates></dates><publisher>Triarchy Press</publisher><isbn>978-0-9550081-2-2</isbn><abstract>A full collection of more than 80 of Russell Ackoff's management f-laws: the uncomfortable truths about how organizations really work, what's wrong with the way we design and manage businesses, what makes managers tick... and how we can make things work better. Russell Ackoff is one of the world's top business brains. Herbert Addison has worked for years in business book publishing. Sally Bibb is a pioneer of organizational change. Who better to zero in on organizations, take them apart and then suggest ways of putting them back together - but better?</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://smile.amazon.co.uk/gp/product/0955008123/ref=od_aui_detailpages00?ie=UTF8&amp;psc=1</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Ackoff, Russell L.</author></authors></contributors><titles><title>Re-Creating the Corporation: A Design of Organizations for the 21st Century</title><short-title>Re-Creating the Corporation</short-title></titles><pages>348</pages><edition>First Edition edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>1999</year><pub-dates><date>7 Oct. 1999</date></pub-dates></dates><pub-location>New York</pub-location><publisher>OUP USA</publisher><isbn>978-0-19-512387-6</isbn><abstract>Over the last three decades the average life expectancy of a corporation in North America has dipped well below 20 years. In fact, by 1983 a full third of the 1970 Fortune 500 companies had been acquired, merged, or broken apart. In this landmark book, one of the business world's foremost pioneers, Russell L. Ackoff, delivers this indispensable guide for those hoping to beat these odds―and to better navigate the corporate challenges of the next millennium.  While most business and management schools continue to teach the functions of a corporation separately―production, marketing, finance, personnel―the reality is that for a corporation to endure each division must work with the others to create an effective system. Re-Creating the Corporation is Ackoff's masterful blueprint for understanding and creating these model corporate systems. In four comprehensive sections―Background, Process, Designs, and Change―Ackoff lays out in clear concise prose the five organizational goals of successful corporate systems: plan effectively, learn and adapt rapidly, democratize, introduce internal market economies, and employ a flexible structure that will minimize the need for future restructuring. And through a deft mix of practical and theoretical examples drawn from a wide range of applications in a wide range of firms, this book ultimately guides executives to the system best suited to meet their organizational goals. Re-Creating the Corporation, which is the culmination of a lifetime of innovative and insightful business thought from one of the business world's premier thinkers, is essential reading for those attempting to navigate the rapidly changing economic environment of the next millennium.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/gp/product/0195123875/ref=od_aui_detailpages00?ie=UTF8&amp;psc=1</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Larman, Craig</author><author>Vodde, Bas</author></authors></contributors><titles><title>Large-Scale Scrum: More with LeSS</title><short-title>Large-Scale Scrum</short-title></titles><pages>356</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>30 Sept. 2016</date></pub-dates></dates><publisher>Addison-Wesley Professional</publisher><isbn>978-0-321-98571-2</isbn><abstract>The Go-To Resource for Large-Scale Organizations to Be Agile    Rather than asking, “How can we do agile at scale in our big complex organization?” a different and deeper question is, “How can we have the same simple structure that Scrum offers for the organization, and be agile at scale rather than do agile?” This profound insight is at the heart of LeSS (Large-Scale Scrum).   In  Large-Scale Scrum: More with LeSS,  Craig Larman and Bas Vodde have distilled over a decade of experience in large-scale LeSS adoptions towards a simpler organization that delivers more flexibility with less complexity, more value with less waste, and more purpose with less prescription.   Targeted to anyone involved in large-scale development,  Large-Scale Scrum: More with LeSS,  offers straight-to-the-point guides for how to be agile at scale, with LeSS. It will clearly guide you to  Adopt LeSS Structure a large development organization for customer value Clarify the role of management and Scrum Master Define what your product is, and why Be a great Product Owner Work with multiple whole-product focused feature teams in one Sprint that produces a shippable product Coordinate and integrate between teams Work with multi-site teams</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><pdf-urls><url>C:\Users\matth\Zotero\storage\WKRJ8U9K\LeSS-poster.pdf</url><url>C:\Users\matth\Zotero\storage\EF6CQMZT\Larman and Vodde - 2016 - Large-Scale Scrum More with LeSS.pdf</url></pdf-urls><text-urls><url>https://www.amazon.co.uk/Large-Scale-Scrum-More-Addison-Wesley-Signature-ebook/dp/B01JP91OR4</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Tune, Nick</author><author>Millett, Scott</author></authors></contributors><titles><title>Designing Autonomous Teams and Services</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>2017</date></pub-dates></dates><publisher>O'Reilly Media</publisher><isbn>978-1-4919-9431-3</isbn><abstract>In high-performing organizations such as Salesforce and Spotify, autonomous product development teams own problems end-to-end—from interacting with customers to delivering engaging digital products. These teams find new ways to solve customer problems by constantly running...</abstract><language>en</language><urls><web-urls><url>https://www.oreilly.com/programming/free/designing-autonomous-teams-and-services.csp</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\LBBDGNVN\Tune and Millett - 2017 - Designing Autonomous Teams and Services.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\9PFLNK3I\designing-autonomous-teams-and-services.html</url></text-urls></urls><access-date>2018-09-10 19:49:36</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Report">27</ref-type><contributors><authors><author>Levina, Natalia</author><author>Vaast, Emmanuelle</author></authors></contributors><titles><title>The Emergence of Boundary Spanning Competence in Practice: Implications for Information Systems' Implementation and Use</title><short-title>The Emergence of Boundary Spanning Competence in Practice</short-title></titles><keywords><keyword>boundaries</keyword><keyword>boundary objects</keyword><keyword>boundary spanners</keyword><keyword>Boundary spanning</keyword><keyword>Bourdieu</keyword><keyword>client-consultant relationship</keyword><keyword>intranet</keyword><keyword>IS implementation</keyword><keyword>IS use</keyword><keyword>Knowledge Management</keyword><keyword>organizational learning</keyword><keyword>practice theory</keyword><keyword>roles</keyword><keyword>TT refs</keyword></keywords><dates><year>2005</year><pub-dates><date>2005/03/16</date></pub-dates></dates><pub-location>Rochester, NY</pub-location><publisher>Social Science Research Network</publisher><isbn>ID 1276022</isbn><abstract>This paper investigates how an organizational competence in boundary spanning emerges in practice by drawing on the concepts of boundary spanner and boundary object. Using data from two qualitative field studies, we argue that in order for boundary spanning to emerge a new joint field of practice must be produced. Our data illustrate that agents partially transform their practices in local settings so as to accommodate the interests of their counterparts. While negotiating the new joint field, agents become what we call "boundary spanners-in-practice" who produce and use objects which then become locally useful and which acquire a common identity - hence, "boundary objects-in-use." Moreover, we show how boundary spanners-in-practice use various organizational and professional resources including the influence that comes with being nominated to boundary spanners' roles to create the new joint field. The conditions necessary for boundary spanners-in-practice to emerge are outlined and discussed; as are important implications for IS implementation and use.</abstract><work-type>SSRN Scholarly Paper</work-type><remote-database-name>papers.ssrn.com</remote-database-name><language>en</language><urls><web-urls><url>https://papers.ssrn.com/abstract=1276022</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\LPP84NCL\Levina and Vaast - 2005 - The Emergence of Boundary Spanning Competence in P.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\AM6DNVDX\papers.html</url></text-urls></urls><access-date>2018-09-10 13:30:40</access-date><misc2>SSRN Scholarly Paper</misc2></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Kelly, Allan</author></authors></contributors><titles><title>Project Myopia: Why projects damage software #NoProjects eBook: Allan Kelly: Amazon.co.uk: Kindle Store</title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>28 July 2018</date></pub-dates></dates><publisher>Software Strategy Ltd</publisher><isbn>978-1-912832-03-3</isbn><urls><web-urls><url>https://www.amazon.co.uk/Project-Myopia-projects-software-NoProjects-ebook/dp/B07F1XJ2B5/ref=sr_1_1?ie=UTF8&amp;qid=1536576139&amp;sr=8-1&amp;keywords=project+myopia</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\ZEPN6Y76\ref=sr_1_1.html</url></text-urls></urls><access-date>2018-09-10 10:46:54</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Scholtes, Ingo</author><author>Mavrodiev, Pavlin</author><author>Schweitzer, Frank</author></authors></contributors><titles><title>From Aristotle to Ringelmann: A Large-scale Analysis of Team Productivity and Coordination in Open Source Software Projects</title><secondary-title>Empirical Softw. Engg.</secondary-title><short-title>From Aristotle to Ringelmann</short-title></titles><periodical><full-title>Empirical Softw. Engg.</full-title></periodical><pages>642–683</pages><volume>21</volume><number>2</number><issue>2</issue><keywords><keyword>Coordination</keyword><keyword>Open source software</keyword><keyword>Productivity factors</keyword><keyword>Repository mining</keyword><keyword>Social aspects of software engineering</keyword><keyword>Software engineering</keyword><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>April 2016</date></pub-dates></dates><isbn>1382-3256</isbn><electronic-resource-num>10.1007/s10664-015-9406-4</electronic-resource-num><abstract>Complex software development projects rely on the contribution of teams of developers, who are required to collaborate and coordinate their efforts. The productivity of such development teams, i.e., how their size is related to the produced output, is an important consideration for project and schedule management as well as for cost estimation. The majority of studies in empirical software engineering suggest that - due to coordination overhead - teams of collaborating developers become less productive as they grow in size. This phenomenon is commonly paraphrased as Brooks' law of software project management, which states that "adding manpower to a software project makes it later". Outside software engineering, the non-additive scaling of productivity in teams is often referred to as the Ringelmann effect, which is studied extensively in social psychology and organizational theory. Conversely, a recent study suggested that in Open Source Software (OSS) projects, the productivity of developers increases as the team grows in size. Attributing it to collective synergetic effects, this surprising finding was linked to the Aristotelian quote that "the whole is more than the sum of its parts". Using a data set of 58 OSS projects with more than 580,000 commits contributed by more than 30,000 developers, in this article we provide a large-scale analysis of the relation between size and productivity of software development teams. Our findings confirm the negative relation between team size and productivity previously suggested by empirical software engineering research, thus providing quantitative evidence for the presence of a strong Ringelmann effect. Using fine-grained data on the association between developers and source code files, we investigate possible explanations for the observed relations between team size and productivity. In particular, we take a network perspective on developer-code associations in software development teams and show that the magnitude of the decrease in productivity is likely to be related to the growth dynamics of co-editing networks which can be interpreted as a first-order approximation of coordination requirements.</abstract><remote-database-name>ACM Digital Library</remote-database-name><urls><web-urls><url>http://dx.doi.org/10.1007/s10664-015-9406-4</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\326EHGNB\Scholtes et al. - 2016 - From Aristotle to Ringelmann A Large-scale Analys.pdf</url></pdf-urls></urls><access-date>2018-09-10 07:33:26</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Kelly, Allan</author></authors></contributors><titles><title>No Projects - Beyond Projects</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2014</year><pub-dates><date>05 Dec 2014</date></pub-dates></dates><abstract>Applying the project lifecycle model to software development complicates both and makes developing good software harder.  Allan Kelly presents ideas on how to move beyond projects and into what he calls a Continuous Work, or Steady State Work Model.</abstract><urls><web-urls><url>https://www.infoq.com/articles/kelly-beyond-projects</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\FBZFUC7E\kelly-beyond-projects.html</url></text-urls></urls><access-date>2018-09-09 14:39:13</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Kotter, John P.</author></authors></contributors><titles><title>Accelerate!</title><secondary-title>Harvard Business Review</secondary-title></titles><periodical><full-title>Harvard Business Review</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>2012-11-01T04:00:00Z</date></pub-dates></dates><abstract>How the most innovative companies capitalize on today’s rapid-fire strategic challenges—and still make their numbers.</abstract><urls><web-urls><url>https://hbr.org/2012/11/accelerate</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\E5VLD288\accelerate.html</url></text-urls></urls><access-date>2018-09-07 15:57:44</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Kelly, Allan</author></authors></contributors><titles><title>Business Patterns for Software Developers</title></titles><pages>406</pages><edition>1 edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>3 Feb. 2012</date></pub-dates></dates><pub-location>Chichester</pub-location><publisher>John Wiley &amp; Sons</publisher><isbn>978-1-119-99924-9</isbn><abstract>A must–have recipe book for building software Perhaps you can relate to this all–too common scenario: you know all about your software product?but could do with some help in understanding the strategic side of things. If so, this book is the one–stop resource you′ll need in order to become a successful software entrepreneur. Patterns expert Allan Kelly provides you with the step–by–step route that needs to be followed in order to understand business strategy and operations. Each chapter starts out with a solid introduction and theoretical overview, which is then further illustrated with patterns and case studies, all aimed at helping you move into the management of software.  Teaches you the ropes of business strategy and operations for software Places special emphasis on the patterns for those who make software for sale Addresses patterns philosophy, patterns strategies, business strategy patterns, and software company lifecycle Shares practical tools, tips, and examples of best practices so you can see how each specific pattern fits in and needs to be implemented.  Business Patterns for Software Development divulges strategies, operations, and structures for building successful software.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Business-Patterns-Software-Developers-Allan/dp/1119999243</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Bernstein, Ethan S.</author><author>Turban, Stephen</author></authors></contributors><titles><title>The impact of the ‘open’ workspace on human collaboration</title><secondary-title>Phil. Trans. R. Soc. B</secondary-title></titles><periodical><full-title>Phil. Trans. R. Soc. B</full-title><abbr-1>Phil. Trans. R. Soc. B</abbr-1></periodical><pages>20170239</pages><volume>373</volume><number>1753</number><issue>1753</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018/08/19</date></pub-dates></dates><isbn>0962-8436, 1471-2970</isbn><electronic-resource-num>10.1098/rstb.2017.0239</electronic-resource-num><abstract>Organizations’ pursuit of increased workplace collaboration has led managers to transform traditional office spaces into ‘open’, transparency-enhancing architectures with fewer walls, doors and other spatial boundaries, yet there is scant direct empirical research on how human interaction patterns change as a result of these architectural changes. In two intervention-based field studies of corporate headquarters transitioning to more open office spaces, we empirically examined—using digital data from advanced wearable devices and from electronic communication servers—the effect of open office architectures on employees' face-to-face, email and instant messaging (IM) interaction patterns. Contrary to common belief, the volume of face-to-face interaction decreased significantly (approx. 70%) in both cases, with an associated increase in electronic interaction. In short, rather than prompting increasingly vibrant face-to-face collaboration, open architecture appeared to trigger a natural human response to socially withdraw from officemates and interact instead over email and IM. This is the first study to empirically measure both face-to-face and electronic interaction before and after the adoption of open office architecture. The results inform our understanding of the impact on human behaviour of workspaces that trend towards fewer spatial boundaries.&#xD;This article is part of the theme issue ‘Interdisciplinary approaches for uncovering the impacts of architecture on collective behaviour’.</abstract><remote-database-name>rstb.royalsocietypublishing.org</remote-database-name><language>en</language><urls><web-urls><url>http://rstb.royalsocietypublishing.org/content/373/1753/20170239</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\F9XLI9ZT\Bernstein and Turban - 2018 - The impact of the ‘open’ workspace on human collab.pdf</url></pdf-urls><text-urls><url>http://www.ncbi.nlm.nih.gov/pubmed/29967303</url><url>C:\Users\matth\Zotero\storage\3QZ96ZQN\20170239.html</url></text-urls></urls><access-date>2018-09-03 21:22:23</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Strode, Diane E.</author><author>Huff, Sid L.</author><author>Hope, Beverley</author><author>Link, Sebastian</author></authors></contributors><titles><title>Coordination in co-located agile software development projects</title><secondary-title>Journal of Systems and Software</secondary-title></titles><periodical><full-title>Journal of Systems and Software</full-title><abbr-1>Journal of Systems and Software</abbr-1></periodical><pages>1222-1238</pages><volume>85</volume><number>6</number><issue>6</issue><keywords><keyword>Agile methods</keyword><keyword>Agile software development project</keyword><keyword>Coordination effectiveness</keyword><keyword>Coordination strategy</keyword><keyword>Coordination Theory</keyword><keyword>Extreme Programming</keyword><keyword>Scrum</keyword><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>June 1, 2012</date></pub-dates></dates><isbn>0164-1212</isbn><electronic-resource-num>10.1016/j.jss.2012.02.017</electronic-resource-num><abstract>Agile software development provides a way to organise the complex task of multi-participant software development while accommodating constant project change. Agile software development is well accepted in the practitioner community but there is little understanding of how such projects achieve effective coordination, which is known to be critical in successful software projects. A theoretical model of coordination in the agile software development context is presented based on empirical data from three cases of co-located agile software development. Many practices in these projects act as coordination mechanisms, which together form a coordination strategy. Coordination strategy in this context has three components: synchronisation, structure, and boundary spanning. Coordination effectiveness has two components: implicit and explicit. The theoretical model of coordination in agile software development projects proposes that an agile coordination strategy increases coordination effectiveness. This model has application for practitioners who want to select appropriate practices from agile methods to ensure they achieve coordination coverage in their project. For the field of information systems development, this theory contributes to knowledge of coordination and coordination effectiveness in the context of agile software development.</abstract><remote-database-name>ScienceDirect</remote-database-name><urls><web-urls><url>http://www.sciencedirect.com/science/article/pii/S0164121212000465</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\LKI2XFMC\Strode et al. - 2012 - Coordination in co-located agile software developm.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\QVSLLQNC\S0164121212000465.html</url></text-urls></urls><access-date>2018-09-03 21:10:59</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>HBS Communications</author></authors></contributors><titles><title>Collaborate on complex problems, but only intermittently</title><secondary-title>Harvard Gazette</secondary-title></titles><periodical><full-title>Harvard Gazette</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-08-15T18:17:12-0400</date></pub-dates></dates><abstract>When solving problems, both groups in which members never interacted and groups whose members constantly interacted provided expected results. The surprising outcome came from groups whose members collaborated intermittently.</abstract><language>en-US</language><urls><web-urls><url>https://news.harvard.edu/gazette/story/2018/08/collaborate-on-complex-problems-but-only-intermittently/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\S5ILWPWN\collaborate-on-complex-problems-but-only-intermittently.html</url></text-urls></urls><access-date>2018-09-03 20:51:28</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Bernstein, Ethan</author><author>Shore, Jesse</author><author>Lazer, David</author></authors></contributors><titles><title>How intermittent breaks in interaction improve collective intelligence</title><secondary-title>Proceedings of the National Academy of Sciences</secondary-title></titles><periodical><full-title>Proceedings of the National Academy of Sciences</full-title><abbr-1>PNAS</abbr-1></periodical><pages>201802407</pages><keywords><keyword>collective intelligence</keyword><keyword>social influence</keyword><keyword>social networks</keyword><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018/08/10</date></pub-dates></dates><isbn>0027-8424, 1091-6490</isbn><electronic-resource-num>10.1073/pnas.1802407115</electronic-resource-num><abstract>People influence each other when they interact to solve problems. Such social influence introduces both benefits (higher average solution quality due to exploitation of existing answers through social learning) and costs (lower maximum solution quality due to a reduction in individual exploration for novel answers) relative to independent problem solving. In contrast to prior work, which has focused on how the presence and network structure of social influence affect performance, here we investigate the effects of time. We show that when social influence is intermittent it provides the benefits of constant social influence without the costs. Human subjects solved the canonical traveling salesperson problem in groups of three, randomized into treatments with constant social influence, intermittent social influence, or no social influence. Groups in the intermittent social-influence treatment found the optimum solution frequently (like groups without influence) but had a high mean performance (like groups with constant influence); they learned from each other, while maintaining a high level of exploration. Solutions improved most on rounds with social influence after a period of separation. We also show that storing subjects’ best solutions so that they could be reloaded and possibly modified in subsequent rounds—a ubiquitous feature of personal productivity software—is similar to constant social influence: It increases mean performance but decreases exploration.</abstract><remote-database-name>www.pnas.org</remote-database-name><language>en</language><urls><web-urls><url>http://www.pnas.org/content/early/2018/08/09/1802407115</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\ZLHDYIN6\Bernstein et al. - 2018 - How intermittent breaks in interaction improve col.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\XQ78SS7D\1802407115.html</url><url>http://www.ncbi.nlm.nih.gov/pubmed/30104371</url></text-urls></urls><access-date>2018-09-03 20:58:53</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Jang, Sujin</author></authors></contributors><titles><title>Cultural Brokerage and Creative Performance in Multicultural Teams</title><secondary-title>Organization Science</secondary-title></titles><periodical><full-title>Organization Science</full-title><abbr-1>Organization Science</abbr-1></periodical><pages>993-1009</pages><volume>28</volume><number>6</number><issue>6</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>December 1, 2017</date></pub-dates></dates><isbn>1047-7039</isbn><electronic-resource-num>10.1287/orsc.2017.1162</electronic-resource-num><abstract>This paper presents a novel theoretical framework of how members of multicultural teams leverage their diverse knowledge to produce creative outcomes. I develop and test a model of cultural brokerage, which I define as the act of facilitating interactions between actors across cultural boundaries. I find that team members with multicultural backgrounds engage in cultural brokerage on behalf of monocultural team members. Among multiculturals, “cultural insiders” (those whose cultural background overlaps with other team members’) brokered by integrating knowledge from different cultures, whereas “cultural outsiders” (those whose cultural background has no overlap with any other team members’) brokered by eliciting knowledge from different cultures. Both integrating and eliciting significantly enhanced creative performance at the team level. These findings advance our understanding of the process of creativity in culturally diverse teams.</abstract><remote-database-name>pubsonline.informs.org (Atypon)</remote-database-name><urls><web-urls><url>https://pubsonline.informs.org/doi/full/10.1287/orsc.2017.1162</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\IMLJHLK8\Jang - 2017 - Cultural Brokerage and Creative Performance in Mul.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\RNYY9GT6\orsc.2017.html</url></text-urls></urls><access-date>2018-09-03 20:37:21</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Bernstein, Ethan</author><author>Bunch, John</author><author>Canner, Niko</author><author>Lee, Michael</author></authors></contributors><titles><title>Beyond the Holacracy Hype</title><secondary-title>Harvard Business Review</secondary-title></titles><periodical><full-title>Harvard Business Review</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016-07-01T04:00:00Z</date></pub-dates></dates><abstract>The overwrought claims—and actual promise—of the next generation of self-managed teams</abstract><urls><web-urls><url>https://hbr.org/2016/07/beyond-the-holacracy-hype</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\JIFHDPV5\beyond-the-holacracy-hype.html</url></text-urls></urls><access-date>2018-09-03 20:32:52</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>MacCormack, Alan</author><author>Baldwin, Carliss Y.</author><author>Rusnak, John</author></authors></contributors><titles><title>Exploring the Duality Between Product and Organizational Architectures: A Test of the 'Mirroring' Hypothesis</title><secondary-title>Research Policy</secondary-title><short-title>Exploring the Duality Between Product and Organizational Architectures</short-title></titles><periodical><full-title>Research Policy</full-title></periodical><pages>1309-1324</pages><volume>41</volume><number>8</number><issue>8</issue><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>2012/10/1</date></pub-dates></dates><abstract>A variety of academic studies argue that a relationship exists between the structure of an organization and the design of the products that the organization produces. Specifically, products tend to "mirror" the architectures of the organizations in which they are developed. This dynamic occurs because the organization's governance structures, problem solving routines, and communication patterns constrain the space in which it searches for new solutions. Such a relationship is important, given that product architecture has been shown to be an important predictor of product performance, product variety, process flexibility, and even the path of industry evolution. We explore this relationship in the software industry. Our research takes advantage of a natural experiment, in that we observe products that fulfill the same function being developed by very different organizational forms. At one extreme are commercial software firms, in which the organizational participants are tightly coupled, with respect to their goals, structure, and behavior. At the other, are open-source software communities, in which the participants are much more loosely coupled by comparison. The mirroring hypothesis predicts that these different organizational forms will produce products with distinctly different architectures. Specifically, loosely coupled organizations will develop more modular designs than tightly coupled organizations. We test this hypothesis, using a sample of matched-pair products. We find strong evidence to support the mirroring hypothesis. In all of the pairs we examine, the product developed by the loosely coupled organization is significantly more modular than the product from the tightly coupled organization. We measure modularity by capturing the level of coupling between a product's components. The magnitude of the differences is substantial—up to a factor of six, in terms of the potential for a design change in one component to propagate to others. Our results have significant managerial implications, highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.</abstract><remote-database-name>www.hbs.edu</remote-database-name><urls><web-urls><url>http://www.hbs.edu/faculty/Pages/item.aspx?num=43260</url></web-urls><pdf-urls><url>C:\Users\matth\Zotero\storage\V3337ABV\08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\ZAZN5ZZG\item.html</url></text-urls></urls><access-date>2016-12-03 12:22:22</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Leveson, Nancy G.</author></authors></contributors><titles><title>Engineering a Safer World: Systems Thinking Applied to Safety</title><short-title>Engineering a Safer World</short-title></titles><pages>560</pages><edition>Reprint edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>14 Feb. 2017</date></pub-dates></dates><pub-location>Cambridge, Massachusetts London, Englang</pub-location><publisher>MIT Press</publisher><isbn>978-0-262-53369-0</isbn><abstract>A new approach to safety, based on systems thinking, that is more effective, less costly, and easier to use than current techniques. Engineering has experienced a technological revolution, but the basic engineering techniques applied in safety and reliability engineering, created in a simpler, analog world, have changed very little over the years. In this groundbreaking book, Nancy Leveson proposes a new approach to safety-more suited to today's complex, sociotechnical, software-intensive world-based on modern systems thinking and systems theory. Revisiting and updating ideas pioneered by 1950s aerospace engineers in their System Safety concept, and testing her new model extensively on real-world examples, Leveson has created a new approach to safety that is more effective, less expensive, and easier to use than current techniques. Arguing that traditional models of causality are inadequate, Leveson presents a new, extended model of causation (Systems-Theoretic Accident Model and Processes, or STAMP), then shows how the new model can be used to create techniques for system safety engineering, including accident analysis, hazard analysis, system design, safety in operations, and management of safety-critical systems. She applies the new techniques to real-world events including the friendly-fire loss of a U.S. Blackhawk helicopter in the first Gulf War; the Vioxx recall; the U.S. Navy SUBSAFE program; and the bacterial contamination of a public water supply in a Canadian town. Leveson's approach is relevant even beyond safety engineering, offering techniques for "reengineering" any large sociotechnical system to improve safety and manage risk.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><pdf-urls><url>C:\Users\matth\Zotero\storage\VH5HU73M\Leveson - 2017 - Engineering a Safer World Systems Thinking Applie.pdf</url></pdf-urls><text-urls><url>https://www.amazon.co.uk/Engineering-Safer-World-Systems-Thinking/dp/0262533693</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Skelton, Matthew</author></authors></contributors><titles><title>How to find the right DevOps tools for your team</title><secondary-title>TechBeacon</secondary-title></titles><periodical><full-title>TechBeacon</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2018</year><pub-dates><date>2018-03-16T11:00:00-04:00</date></pub-dates></dates><abstract>Building a DevOps tool suite? Here are 9 field-tested tips for making all the right choices—and avoiding disaster.</abstract><language>en</language><urls><web-urls><url>https://techbeacon.com/devops/how-find-right-devops-tools-your-team</url></web-urls></urls><access-date>2020-10-12 18:32:55</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Brooks, Frederick</author></authors></contributors><titles><title>Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition</title><short-title>Mythical Man-Month, The</short-title></titles><pages>336</pages><edition>2nd edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>1995</year><pub-dates><date>8 Aug. 1995</date></pub-dates></dates><pub-location>Reading, Mass</pub-location><publisher>Addison-Wesley</publisher><isbn>978-0-201-83595-3</isbn><abstract>Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.   The added chapters contain (1) a crisp condensation of all the propositions asserted in the original book, including Brooks' central argument in The Mythical Man-Month: that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is therefore critical; and that it is difficult but possible to achieve this unity; (2) Brooks' view of these propositions a generation later; (3) a reprint of his classic 1986 paper "No Silver Bullet"; and (4) today's thoughts on the 1986 assertion, "There will be no silver bullet within ten years."</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Edwards, Damon</author></authors></contributors><titles><title>What is DevOps?</title><secondary-title>dev2ops</secondary-title></titles><periodical><full-title>dev2ops</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2010</year><pub-dates><date>2010-02-23</date></pub-dates></dates><language>en-US</language><urls><web-urls><url>http://dev2ops.org/2010/02/what-is-devops/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\HWVRRFGJ\what-is-devops.html</url></text-urls></urls><access-date>2021-02-23 16:41:58</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Hansson, David Heinemeier</author><author>Fried, Jason</author></authors></contributors><titles><title>Remote: Office Not Required</title><short-title>Remote</short-title></titles><pages>256</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2013</year><pub-dates><date>31 Oct. 2013</date></pub-dates></dates><pub-location>London</pub-location><publisher>Vermilion</publisher><isbn>978-0-09-195467-3</isbn><abstract>For too long our lives have been dominated by the ‘under one roof’ Industrial Revolution model of work. That era is now over. There is no longer a reason for the daily roll call, of the need to be seen with your butt on your seat in the office. The technology to work remotely and to avoid the daily grind of commuting and meetings has finally come of age, and bestselling authors Jason Fried and David Heinemeier Hansson are the masters of making it work at tech company 37signals. Remote working is the future – and it is rushing towards us. Remote: Office Not Required combines eye-opening ideas with entertaining narrative. It will convince you that working remotely increases productivity and innovation, and it will also teach you how to get it right – whether you are a manager, working solo or one of a team. Chapters include: ‘Talent isn’t bound by the hubs’, ‘It’s the technology, stupid’, ‘When to type, when to talk’, ‘Stop managing the chairs’ and ‘The virtual water cooler’. Brilliantly simple and refreshingly illuminating this is a call to action to end the tyranny of being shackled to the office.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Remote-Required-David-Heinemeier-Hansson/dp/0091954673</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Helfand, Heidi</author></authors></contributors><titles><title>Dynamic Reteaming: The Art and Wisdom of Changing Teams</title><short-title>Dynamic Reteaming</short-title></titles><pages>293</pages><keywords><keyword>TT refs</keyword></keywords><dates><year>2019</year><pub-dates><date>31 July 2019</date></pub-dates></dates><publisher>Reteam, LLC</publisher><isbn>978-1-73356-721-3</isbn><abstract>Dynamic Reteaming shares real stories of how successful software companies have thrived through changing their teams as opposed to keeping them the same. Team change will happen whether we like it or not. People will come and go from our teams. Our companies might double in size or even get acquired. We can catalyze team change to reduce the risk of attrition, learning and career stagnation and the development of knowledge silos. Dynamic Reteaming describes practices for effective reteaming as well as antipatterns. In this book you'll learn how to integrate new people into an existing team, how to deal with the loss of team members, when to split a team, how to isolate teams for focused innovation, how to rotate team members for knowledge sharing, how to break through organizational stagnation and much more. Learn to apply the five team change patterns: Isolation, One by One, Grow and Split, Merging and Switching. Get practical tips and tricks for managing team change.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Dynamic-Reteaming-Wisdom-Changing-Teams/dp/1733567216/ref=sr_1_2?dchild=1&amp;keywords=heidi+helfand&amp;qid=1614098958&amp;s=books&amp;sr=1-2</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Kersten, Mik</author></authors></contributors><titles><title>Project to Product: How Value Stream Networks Will Transform IT and Business: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework</title><short-title>Project to Product</short-title></titles><pages>272</pages><edition>Illustrated edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2019</year><pub-dates><date>28 Feb. 2019</date></pub-dates></dates><pub-location>Portland, OR</pub-location><publisher>IT Revolution</publisher><isbn>978-1-942788-39-3</isbn><abstract>In the Age of Software, will your business dominate and maintain relevance--or will it become a digital relic?As tech giants and startups disrupt every market, those who master large-scale software delivery will define the economic landscape of the 21st century, just as the masters of mass production defined the landscape in the 20th. Unfortunately, business and technology leaders are woefully ill-equipped to solve the problems posed by digital transformation. At the current rate of disruption, half of S&amp;P 500 companies will be replaced in the next ten years. A new approach is needed. In Project to Product, Value Stream Network pioneer and technology business leader Dr. Mik Kersten introduces the Flow Framework--a new way of seeing, measuring, and managing software delivery. The Flow Framework will enable your company's evolution from project-oriented dinosaur to product-centric innovator that thrives in the Age of Software. If you're driving your organization's transformation at any level, this is the book for you.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Project-Product-Networks-Transform-Business/dp/1942788398/ref=sr_1_1?dchild=1&amp;keywords=mik+kersten&amp;qid=1614099392&amp;s=books&amp;sr=1-1</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Kim, Gene</author><author>Debois, Patrick</author><author>Willis, John</author></authors></contributors><titles><title>The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations</title><short-title>The Devops Handbook</short-title></titles><pages>250</pages><edition>Illustrated edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>1 Dec. 2016</date></pub-dates></dates><pub-location>Portland, OR</pub-location><publisher>Trade Select</publisher><isbn>978-1-942788-00-3</isbn><abstract>For decades, technology leaders have struggled to balance agility, reliability, and security, and the consequences of failure have never been greater. The effective management of technology is critical for business competitiveness. High-performing organizations are 2.5 times more likely to exceed profitability, market share, and productivity goals. The DevOps Handbook shows leaders how to create the cultural norms and the technical practices necessary to maximize organizational learning, increase employee satisfaction, and win in the marketplace.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Devops-Handbook-World-Class-Reliability-Organizations/dp/1942788002/ref=sr_1_1?dchild=1&amp;keywords=devops+handbook&amp;qid=1614099424&amp;s=books&amp;sr=1-1</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Blog">56</ref-type><contributors><authors><author>Lane, Kin</author></authors></contributors><titles><title>The Secret to Amazons Success Internal APIs</title><secondary-title>API Evangelist</secondary-title></titles><periodical><full-title>API Evangelist</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2012</year><pub-dates><date>2012-01-12</date></pub-dates></dates><abstract>A network of research sites dedicated to the technology, business, and politics of APIs.</abstract><language>en-us</language><urls><web-urls><url>https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\3EQLEVXB\the-secret-to-amazons-success-internal-apis.html</url></text-urls></urls><access-date>2021-02-23 21:08:00</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Miller, George A.</author></authors></contributors><titles><title>The magical number seven, plus or minus two: some limits on our capacity for processing information</title><secondary-title>Psychological Review</secondary-title><short-title>The magical number seven, plus or minus two</short-title></titles><periodical><full-title>Psychological Review</full-title></periodical><pages>81-97</pages><volume>63</volume><number>2</number><issue>2</issue><keywords><keyword>Cognitive Processes</keyword><keyword>Information Theory</keyword><keyword>TT refs</keyword></keywords><dates><year>1956</year><pub-dates><date>1956</date></pub-dates></dates><isbn>1939-1471(Electronic),0033-295X(Print)</isbn><electronic-resource-num>10.1037/h0043158</electronic-resource-num><abstract>A variety of researches are examined from the standpoint of information theory. It is shown that the unaided observer is severely limited in terms of the amount of information he can receive, process, and remember. However, it is shown that by the use of various techniques, e.g., use of several stimulus dimensions, recoding, and various mnemonic devices, this informational bottleneck can be broken. 20 references. (PsycINFO Database Record (c) 2016 APA, all rights reserved)</abstract><remote-database-name>APA PsycNET</remote-database-name><urls><pdf-urls><url>C:\Users\matth\Zotero\storage\VVD3ADRD\Miller - 1956 - The magical number seven, plus or minus two some .pdf</url><url>C:\Users\matth\Zotero\storage\KKN26DXR\Miller GA Magical Seven Psych Review 1955.pdf</url></pdf-urls><text-urls><url>C:\Users\matth\Zotero\storage\3AD5XBW7\1957-02914-001.html</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Niall Murphy</author></authors></contributors><titles><title>What is Site Reliability Engineering?</title></titles><keywords><keyword>TT refs</keyword></keywords><dates/><urls><web-urls><url>https://sre.google/in-conversation/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\G6WAJFG9\in-conversation.html</url></text-urls></urls><access-date>2021-02-23 21:38:43</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Pais, Manuel</author><author>Skelton, Matthew</author></authors></contributors><titles><title>The Divisive Effect of Separate Issue Tracking Tools</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2017</year><pub-dates><date>2017-03-22</date></pub-dates></dates><abstract>Separate issue tracking systems for Development and IT Operations are a source of conflict and ineffectiveness for many organizations. For effective Database Lifecycle Management (DLM), we typically need shared issue tracking systems where DBA teams can see upcoming work from Development and Development teams can see details of live service issues logged from Production.</abstract><language>en</language><urls><web-urls><url>https://www.infoq.com/articles/issue-tracking-tools/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\ARPVP7KP\issue-tracking-tools.html</url></text-urls></urls><access-date>2021-02-23 21:49:37</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Web Page">12</ref-type><contributors><authors><author>Pais, Manuel</author><author>Skelton, Matthew</author></authors></contributors><titles><title>Why and How to Test Logging</title><secondary-title>InfoQ</secondary-title></titles><periodical><full-title>InfoQ</full-title></periodical><keywords><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016-10-26</date></pub-dates></dates><abstract>Logging and aggregation are crucial tools for today's complex, distributed systems. They provide rich insights which keep time to recover short. We must therefore make sure we test logging adequately.</abstract><language>en</language><urls><web-urls><url>https://www.infoq.com/articles/why-test-logging/</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\EQHKNCQF\why-test-logging.html</url></text-urls></urls><access-date>2021-02-23 21:50:56</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Raymond, Eric S.</author></authors></contributors><titles><title>The New Hacker's Dictionary</title></titles><pages>570</pages><edition>third edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>1996</year><pub-dates><date>11 Oct. 1996</date></pub-dates></dates><pub-location>Cambridge, Mass</pub-location><publisher>MIT Press</publisher><isbn>978-0-262-68092-9</isbn><abstract>This new edition of the hacker's own phenomenally successful lexicon includes more than 100 new entries and updates or revises 200 more.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/New-Hackers-Dictionary-MIT-Press/dp/0262680920</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Robertson, Brian J.</author></authors></contributors><titles><title>Holacracy: The New Management System for a Rapidly Changing World</title><short-title>Holacracy</short-title></titles><keywords><keyword>TT refs</keyword></keywords><dates><year>2015</year><pub-dates><date>2 Jun. 2015</date></pub-dates></dates><publisher>Henry Holt and Co.</publisher><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Holacracy-Management-System-Rapidly-Changing/dp/B01L985542/ref=tmm_hrd_swatch_0?_encoding=UTF8&amp;qid=1614117307&amp;sr=1-1</url></text-urls></urls></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Magazine Article">19</ref-type><contributors><authors><author>Rock, David</author><author>Grant, Heidi</author></authors></contributors><titles><title>Why Diverse Teams Are Smarter</title><secondary-title>Harvard Business Review</secondary-title></titles><periodical><full-title>Harvard Business Review</full-title></periodical><keywords><keyword>Decision making</keyword><keyword>Diversity</keyword><keyword>Leading teams</keyword><keyword>TT refs</keyword></keywords><dates><year>2016</year><pub-dates><date>2016-11-04T13:00:24Z</date></pub-dates></dates><isbn>0017-8012</isbn><abstract>Research shows they’re more successful in three important ways.</abstract><remote-database-name>hbr.org</remote-database-name><urls><web-urls><url>https://hbr.org/2016/11/why-diverse-teams-are-smarter</url></web-urls><text-urls><url>C:\Users\matth\Zotero\storage\USHN2I6G\why-diverse-teams-are-smarter.html</url></text-urls></urls><access-date>2021-02-23 21:56:57</access-date></record><record><database name="MyLibrary">MyLibrary</database><source-app name="Zotero">Zotero</source-app><ref-type name="Book">6</ref-type><contributors><authors><author>Rummler, Geary A.</author><author>Brache, Alan P.</author></authors></contributors><titles><title>Improving Performance: How to Manage the White Space on the Organization Chart</title><short-title>Improving Performance</short-title></titles><pages>288</pages><edition>3rd edition</edition><keywords><keyword>TT refs</keyword></keywords><dates><year>2013</year><pub-dates><date>4 Jan. 2013</date></pub-dates></dates><pub-location>San Francisco</pub-location><publisher>Jossey-Bass</publisher><isbn>978-1-118-14370-4</isbn><abstract>Improving Performance is recognized as the book that launched the Process Improvement revolution. It was the first such approach to bridge the gap between organization strategy and the individual. Now, in this revised and expanded new edition, Gary Rummler reflects on the key needs of organizations faced with today's challenge of managing change in today's complex world. The book shows how to apply the three levels of performance and link performance to strategy, move from annual programs to sustained performance improvement, redesign processes, overcome the seven deadly sins of performance improvement and much more.</abstract><remote-database-name>Amazon</remote-database-name><language>English</language><urls><text-urls><url>https://www.amazon.co.uk/Improving-Performance-Manage-White-Organization-dp-1118143701/dp/1118143701/ref=dp_ob_title_bk</url></text-urls></urls></record></records></xml>