Key takeaways
|
Many software development teams attribute their success to their use of disciplined software technical practices. We have noticed an interaction between software technical practices and the strength of the team bond. They appear to result not only in higher levels of team productivity and product quality, but they also improve team happiness. The team is the stuff of which software is made. By becoming more aware of how human consciousness is heightened and how it can be brought into the service of the team, we also become more aware of how the sociotechnical practice of software development can build a better world.
The 10th State of Agile™ survey, conducted by Version One over the last ten years, indicates this lack of focus on technical practices. The higher level foci in the executive summary are on measuring success at the project level through tracking velocity and iteration and release burndown metrics. Project success indicators included “on-time delivery, product quality, and customer/user satisfaction metrics.” According to the 2015 survey, the benefits of Agile include:
- Ability to manage changing priorities (87% of respondents)
- Team productivity (84% of respondents)
- Project visibility (82% of respondents)
Technical practices do not appear as a consideration in Agile adoptions until page 8 of the 16-page report and then only in the context of other techniques such as retrospectives, prioritized backlogs, and open work areas. However, the section summarizing “Actual Improvements from Implementing Agile” highlights increased team productivity, increased team morale/motivation, enhanced software quality, and improved engineering discipline as 4 of the 12 improvements measured. This focus doesn’t address the consciousness raising effects that appear to underlie these improvement areas. Our contention is that the team is a dynamically changing system through which the product is delivered, and technical practices improve the consciousness of the team. This higher consciousness contributes to desired business outputs beyond the obvious engineering improvements and should be given consideration in an evaluation of organizational agility.
What We Mean by Consciousness
When we use the term “consciousness” in this article we are talking about awareness, noticing, and understanding of self and Other.
Agile coach and Scrum trainer Jeff McKenna describes the benefits of highly conscious individuals on Agile teams in his book Conscious Software Development. Allan Combs, a consciousness researcher and neuropsychologist, provides an excellent description of the progressive elaboration in sophistication, or “heightening,” of group and societal consciousness in Consciousness Explained Better. While McKenna talks about individual consciousness on teams, we are discussing team level consciousness. And, we are applying Combs description of societal consciousness evolution to teams because they exist within the societal context.
Our overall approach, explained in more detail in the rest of this section, is as follows. Since we know we are mutually co-arising, the more evolved each team member’s level of consciousness is the higher the consciousness of the team is overall. We have observed that structured dialogue, such as pairing, TDD, and refactoring, accelerates the process of changing mental models about ourselves, others, and the work we do together. These communication processes test and establish our alignment and congruence as necessary to establish and strengthen the field of the team. The value to the business is the collaborative capacity and decision making skill that results, enabling greater work throughput at higher levels of quality, which translates to lower cost.
In Consciousness Explained Better, Combs describes how consciousness evolved over human history. He shows that integral consciousness emerged at the beginning of the 20th century. This level of consciousness continued to expand in the culture through the last century in parallel with the emergence of complexity in software development.
To distinguish integral consciousness from its predecessor, Combs writes:
A mental perspectival understanding of the snow would specify when it fell according to clock time. "It snowed between three and five o'clock this morning." But an integral experience of the snow might emphasize that it is, "The night's snow; the gift of the night," or some other poetic representation emphasizing the quality of the experience of the night and the snow, rather than abstracting an event outside of experience that presumably occurred during a particular episode of clock time. (Combs, pg. 75)
The emergence of integral consciousness is a result of rapidly increased access to many different perspectives and many people of different backgrounds coming together in postmodern society. As a result individuals then can begin to realize the vast range of choice in who they are and the burden of self-authorship. In other words, they realize that both their mental models of who they are and how the world is are not necessarily as immutable as they appear.
The principle of “mutual causality” as described by Buddhist scholar and environmental activist Joanna Macy means the doer and the deed are co-arising and create each other. We are created by our actions. We co-arise through our work and our interactions with others. When teams form and perform well, they likely have taken advantage of mutual causality. Their awareness of their effect on each other (the extent to which they co-arise) causes them to become an aligned group. The field formed by such alignment serves to elevate the team’s awareness of each other and their purpose. By field we mean the collective consciousness or sub-perceptive interaction processes between people.
Recognizing the principle of mutual causality heightens our interest in dialogue and technical practices because we recognize we are each other’s whetstone.
Structured Dialogue as the Social Technology of Software Development
Software development is a sociotechnical endeavor. Socio-technology is the study of processes at the intersection of society and technology. Software development is as much about human interaction as it is about hardware configuration and coding languages. The technical practices are the tools and methods of a developer’s social system, and are examples of structured dialogues, both inter- and intrapersonal. Structured dialogue, as a sociotechnical practice, moves us along an evolutionary path toward greater consciousness.
The human/machine interface is seductive. It can exert the power to dominate the consciousness of those who spend a large quantity of time interacting with it. But, the machine cannot participate in the human field or help to heighten consciousness as another (even unskilled) human can. To quote McKenna (bold ours):
A lot of people who advocate agile methods sell the individual short, implying that we don’t want individual contributors to stand out. That’s not true at all— what is true is that we want people who are very conscious in their work.How does this kind of consciousness manifest itself? In my experience, it mostly shows up in the communication that goes on within a team, because great teams are all about communication. . . . (McKenna, pp. 27-28)
Communication: Alignment, Congruence and the Field of the Team
Communication is required for alignment, which establishes and supports the field of the team. The quality of the field is a reflection of the team’s consciousness level.
All communication, even in a group, occurs between two people, each of whom has to hold up his or her end. When both people do, you achieve something I like to call congruence...When I say that I agree even when I don’t, that’s incongruent— that’s me not being true to what’s going on within myself. That’s not high-performance communication. (McKenna, pg. 28)
Congruence is the internal, or intrapersonal, consistency and candid expression of what one knows to be true and how one feels. Congruence is analogous to alignment which occurs interpersonally. Interpersonal alignment is key to integral connection and shared mental models. Attempting to align with an incongruent person results in alignment with a fictional person rather than the actual person. Alignment across a team requires the ability to process multiple perspectives--certainly more than one’s own--all at once and is a key intrapersonal skill requirement for collaboration.
Processing multiple perspectives is essential to skilled collaboration. The technical practices examined in this article are structured dialogues that build awareness and collaborative capacity. Through them we learn: “I am a self; there are other selves. I have a choice in what I think/am. Other choices and perspectives are also valid.” Technical practices strive to move us toward integral consciousness to realize collaborative capacity.
Mental Models
“Double-loop learning”, best described by business theorist Christopher Argyris, is a process wherein the learner’s mental model is changed such that future unanticipated errors are prevented. This is different than the learning of mere facts and is a deeply engaging psychological process.
McKenna notes:
When I see two people really going at it in a discussion, the first thing I think is, wait a minute, do we have a shared understanding of the context? What happens in those situations is we forget that the mind is not the tool that we should be using. This is the part that’s so hard to grasp, especially for those of us who got into computers because interacting with other humans was very scary. (McKenna, pg. 32)
Commenting on the psychological demand inherent in double-loop learning, organizational theorist Haridimos Tsoukas noted that team members have “to be open to criticism, to be willing to test their claims publicly against evidence, to accept that they too are partly responsible for the problems they are confronted with.” (Argyris, 1991, pg. 15)
Being more psychologically present at work is a critical and necessary part of the work itself. It causes us to be more fully exposed as persons to our co-workers, to understand our own and others’ levels of consciousness, and to be aware of the context into which our work will enter.
Being psychologically present enables us to examine and alter our mental models. As a result of being open to our colleagues, we are more able to change our mental models together and to become more aligned.
Relationship Between Coding and Consciousness
Programming is a creative act that exists largely inside the human mind. Unlike physical engineering problems, software development exists in a virtual space, with fewer constraints than other disciplines. The act of writing code is an immensely personal process, and there are many sources from which developers gain their skills. No two coders build code in exactly the same way. When two programmers have similar styles or development processes it is sometimes due to common influences but is just as likely a result of convergent evolution.
Watching software being built is observing the motions of a human mind. Correspondingly, changing the process that a developer uses to create their code is a transformation of the way that programmer thinks.
Agile frameworks “hack” organizational culture--and consciousness--by overlaying existing corporate cultural patterns with alternate values and principles of engaging the work. These patterns could take numerous product generations to evolve on their own. Similarly, technical practices hack consciousness by enhancing individual and team learning and awareness processes with structured sociotechnical protocols. These protocols rapidly raise skills around noticing, awareness, and understanding. The three we’ll focus on are pairing, refactoring, and Test Driven Development (TDD).
Pair Programming and Consciousness
Pairing is a good example of such a sociotechnical practice. Pair programming is two programmers creating code collectively using a single computer. Collectively, the developers have responsibility for organizing the structure of the program they are building.
Consciousness raising occurs through the mutual learning processes of the developers. These learning processes are facilitated through dialogue. They involve sharing ideas, identifying and verifying assumptions, and mediating power allocation and use between the developers.
Pair partners may consult external parties or references for help with general problem solving about the code, the task being worked on, or the relationship between the partners pairing.
Often this leads to one being more focused on the syntax and coding conventions (as they type the code) and the other planning the next incremental step for the pair to build towards completing their task. Pair programming does not require test-driven development (TDD), but there are benefits from using both techniques simultaneously. Pairing drives alignment of mental models and a heightened consciousness of the Other.
What Happens When Programmers Pair
The process of building a design requires something other than raw code-writing skills. It requires an understanding of the reasons it’s being created, the analysis of the structure being created, and the feedback that comes from comprehension of the design and implementation. Tests can provide functional feedback that the code behaves as requested. However, the software abstractions (e.g. responsibilities, collaborations, names) should be intelligible to another human. Pairing moves this activity from a reflective action to one that precedes the creation of the code. The act of co-creation requires an alignment of consciousness between individuals.
Matt: When I begin to create a piece of software, I have an early idea of the behavior that I wish it to perform. That mental model exists solely in my consciousness. If I am working with one or more partners, they will also have a mental model of what we are going to create. Because we are separate minds, those models, by definition, cannot be the same. In fact, they are likely to differ by an extraordinary degree. It is through our written, verbal, and physical interactions that we gain understanding of the other’s construct. Our mental models shift through dialogue and become more similar over time. Eventually our thinking converges such that we have almost the same model of what we are creating.
Pair programming creates code that is mindful of the programming literacy of the developers, a property not guaranteed in solo development. The act of pairing requires that the code must be understood by a human being as well as the computer. This is a beneficial side effect which is usually taken for granted when it occurs but is rarely delivered in fact: Coders have to be aware of the behavior of the code they were creating, not just the underlying mechanics of their solution. By doing so, they are less likely to “code by coincidence.” Their consciousness expands to include the ‘other’ who would use or maintain their code.
Refactoring and Consciousness
Refactoring is one of the strongest practices we see as particularly helpful in heightening consciousness within individuals and on teams. Mechanically, refactoring is defined as changing the structure of the code while preserving its behavior. The motivations behind refactoring reveal its impact on consciousness. Refactoring is motivated by a desire to understand and be understood by another who might not be present.
What Happens During Refactoring
Matt: As I create code, there are times when the code does not hold a shape that makes change easy. Sometimes this is because I do not understand the interactions in the program well enough. Sometimes it is because the structure of the code resists writing an easy test to extend its behavior. Whenever this happens, I suspend writing new tests and focus on reshaping the design. I look at the structure of the code and I manipulate it to expose the aspect of the design that I wish to interact with. I keep the tests passing to confirm that I haven’t broken the design.
As I reorder the code, I’m discovering patterns and larger abstractions in the structure. I refine the domain language of the program. In this way it is similar to a discussion where I have understood my partner’s line of thinking, and we arrive at a mutually desirable and surprising insight together. This revelation of the design’s capability provides a new way for me to make my code more comprehensible to those that will need to read it, and to make the design easier to interact with for future extension.
If I’m refactoring code with a partner, we can compare our impressions of the design, and select changes that incorporate our common understanding, making this practice even more effective.
Refactoring builds the developer’s awareness of the context where they are creating code, which reveals their intent to future readers of their work. This is a compassionate practice that strives to bring another into the current coder’s immediate experience just as the poet strives to bring their reader into the immediacy of the experience of the poem. The communication of more expressive concepts than just the mechanism of the code leads to a common understanding across the team.
Test Driven Development and Consciousness
One of the biggest challenges that engineers face is that they focus intently on the implementation but very little on the requirements that their creation is being built to satisfy. Programmers who do not use incremental design techniques like Test Driven Development often must hold large portions of the code in their mind at once. This approach leads a programmer to spend their focus on disjoint details, rather than the whole picture. Have you ever heard a programmer refer to their code’s behavior as if it were their own: “I process the transaction”, rather than “It processes the transaction”? In a way, by holding the design in their mind as they create it, programmers must become the program. They solve the problem and write code that mimics their thought process. The high cognitive load that occurs from doing this makes solutions very error prone: It’s too easy to miss a set of data or a path that the program won’t solve correctly. Incremental development, and TDD in particular, enable the programmer to build code that satisfies requirements without forcing them to perform extraordinary mental feats for simple details.
What Happens When Test Driving Code
Matt: When I create test-driven code, I am starting a dialogue. I run the existing tests to solidify my starting point and give me a stable base from which I can confidently proceed to modify the code. If I am starting fresh with no existing code, I have a formless void of potential from which I may extrude content.
The test I write is my interpretation of the new behavior that the program must perform. I am doing this on behalf of the person using my code, so I need to be aware of how they will be using it. I expect that the test will reveal the need to add more code to the design. By writing code test-first, I am building the design incrementally. I receive constant feedback from my tests to assure me that the code I’ve created is functional. I make the test as simple as possible, because its failure will require me to create code to make it pass. If I make the test too large a request and spend too much time on the code to make it pass, I can get lost in the machinery of the program and lose sight of the reason that I’m building the code in the first place. With short cycles, my mind can focus solely on the aspect that I wish to extend; there is no need to hold the whole design in my head. My cognitive load is lower, and I can focus on the “why” rather than the “what/how”. This makes the next test easier to write, and helps me to stay in a short alternating pattern of testing and coding.
The continuing refinements in the shape of the code start to hint about the next test to write. With short cycles of incremental development, continuous refactoring, and the tests keeping the code healthy, programming becomes a flow activity where I can immerse myself in the joy of problem solving without interruption, yet steadily increase the value of the software I’m writing. Now I’m no longer just writing code test-first, I’ve shifted my capability to Test Driven Development.
When I am pairing to do TDD, building the next piece of code starts with an abstract feature request for my partner and I to understand and implement. If the abstraction is too vague, too large, or too complicated, our pace of development slows as our pair seeks alignment. As we begin to understand each other’s mental model, an effective, sustainable pace develops. More importantly, each piece of co-created code has been tested for correctness and comprehension by two minds.
Test Driven Development helps developers retain their humanity while coding because it helps them not “become the program” in order to maintain the awareness necessary to solve the coding problem. It builds mental “muscle memory” around lower-order coding tasks so that developers can use their minds to focus on the higher-order problems. They can pay more attention to the context where their product is used and to the people who will use it.
What You Can Do
No matter what your role is in relation to a software development team, you can speak up for and support the conscious use of technical practices. This might take the form of you, as a team member, starting to do TDD on the code you write. If you are an engineering or project manager, you can start making space in budgets and timelines for focused practice such as Coderetreats and Code Dojos as well as encouraging teams to educate themselves about technical practices and using them. You can speak up for technical practices as part of continuous improvement at the review or retrospective meetings or support writing stories into the backlog to carve out time for technical practices with specific goals in mind, such as refactoring an area of the code base so that it is easier to maintain.
Practice Development Mindfully
Software technical practices can be used to develop effective, literate code. However, achieving proficiency from these practices doesn’t automatically arise from knowing the rules of the process: Developers who desire to use the practices cannot expect to be instant experts at them any more than someone can expect to be a successful poker player just by reading a book. Most developers realize that they must be intimately familiar with both language syntax and programming idioms to be productive. Technical practices likewise must be parts of a developer’s intrinsic behaviors such that awareness of the process fades into the background. When the flow of code development is uninterrupted by uncertainty of lower-level actions, the mind can focus on the higher-level domain of the software problem at hand. This is where productive development occurs.
Unfortunately, many developers learn to code in a solitary, non-collaborative environment (likely a competitive one, such a classroom). By learning to code in a “test-later” or “test-never” manner they can bring significant cognitive complexity into their design. Their code is significantly more difficult to test, decompose, and reorder. Since they are reluctant to show others their code, they receive no feedback from an outside observer on whether they are competent.
These habits are already ingrained in most coders by the time they are introduced to more disciplined practices. They need time to unlearn old behaviors in an environment where they focus on how the code is being built, rather than what is being built. Most corporate software projects have challenging constraints on effort and deadlines that repeatedly deter this type of learning on the job. Mindful practice should be a regular part of the team’s development. It creates a culture of learning that continuously builds the team’s capabilities, reinforces good practices, weeds out poor ones, and seamlessly integrates new members into the common team developer culture and aligned consciousness.
Educate Decision Makers
What teams actually do to deliver products is often obscured to people who are even two levels removed from the daily work. Stakeholders to the team may see bug counts, unproductive conflict, or poor morale—key indicators of poor productivity. The most common reflex is to apply more project and product management controls. Instead, the team should be focusing on learning. The mechanism is sociotechnical practices because, properly adopted, they raise team consciousness and build collaborative capacity. These outcomes unknit the human systems gaps in awareness, noticing, and understanding of self and Other that drive common team problems such as poor morale, escalating defect counts, and unproductive and time-wasting conflict.
Make Outcomes Visible
Opportunities will come your way to intentionally practice pairing, TDD, and refactoring. Be alert to those opportunities, and take them. Make the results you achieve visible as a means of building credibility for doing more intentional practice.
Jean: Recently I was working with a client on a complex big data, cloud-based social networking product development project. I noticed that the team dynamics were strong: the team both got along well under remarkably adverse circumstances and responded well to conflict when it arose. Further, they were motivated to learn and had been grappling with challenging technical content for a period of months with measurable success. However, I also noticed that it appeared that they would benefit from improved technical practices and that this learning would serve them not only in terms of better throughput and lower defects but also in terms of revitalizing them after a long period of intense work. They had just then reached the midpoint of the first phase of the development of the product.
Seeking a technical practices coach, I enlisted Matt to facilitate a Coderetreat for the team. While some education was required of management stakeholders, the value derived from a single day of code play resulted in:
- a significant harvest of team building,
- raised consciousness in terms of how new and junior team members were included in the daily work processes,
- drastically increased hope and confidence in the team’s ability to decrease defects written into the code, and
- improved decision making in succeeding sprints which rapidly improved throughput.
These rapid improvements were made immediately obvious to executive staff through the following few planning and review cycles as well as through the team’s ability to problem-solve when unexpected issues came up.
Intentional practice of technical practices creates a safe container in which learning about the self and other--as technical practitioners and team mates--can occur. The discipline of sitting together in structured dialogue balances power and surfaces gaps in engineering skill or conflict negotiation, and puts team members in touch with their own humanity as thinking, feeling beings involved in complex collaborative problem solving. They come to understand and develop compassion and skill through both personal experience and observation.
Running an Experiment Can Help
Every engineering group likes to think it’s different, and they’re right. However, there are more commonalities among software engineering groups than differences, which is how we can adopt lessons learned elsewhere to local advantage. The claims made in this article may seem surprising, so testing them at some level yourself is only wise--not to mention exciting.
In 2015 Cotten Blackwell, an Engineering Manager at Huron Consulting, a management consulting firm in Portland, Oregon, ran a pilot test of implementing pairing and TDD with one of their two engineering teams for three five-week sprints. Cotten later presented a case study and results of the experiment at an AgilePDX Downtown Pub Lunch meeting, a monthly self-organizing discussion group in Portland. Many of the tactics and challenges he related were to be expected. Agile had been a presence in the organization for seven years by the time he began working with management and team members to explore the value of running a TDD and pairing pilot. There were concerns about the cost of running a pilot. Not all team members were initially supportive and the effects of a piecemeal approach to implementing practices were understood, even experienced.
Cotten had attended one of the Matt’s public Coderetreats and saw value in using that format as a means for a one-day test before launching a formal pilot. The organization leveraged their subscription to “Gartner Technical Professionals” and talked with Gartner analysts who cover Agile best practices to get research-based data to influence their leadership to run the pilot.
The QA manager used that data in an internal brown bag discussion to spread the word. Management was advised of the cost of not connecting the team through high quality technical practices including avoidable rework, longer bug life cycles, expensive technical debt, lack of sustainable pace, and unhappy workers. A survey of the team confirmed that TDD and pairing were the two biggest practice gaps. An architect did an audit that determined nearly half of the rework each sprint could have been avoided with TDD and pairing.
After running a three-sprint experiment Cotten reported that even previously skeptical team members found value in continuing. They learned that when pairing, the skill of both pair members quickly rises to the level of the more skilled / experienced member. There was less siloing – more sharing of special expertise, tips, and tricks. Less work was blocked by the workload of a single team member, and their “bus count” risk was reduced. The team found that TDD, pairing, and refactoring supports keeping Huron “a great place to grow your career” and increased their “happiness index.” By the time of Cotten’s report, the overwhelming majority of developers enjoyed pairing and preferred it to solo work.
Huron didn’t measure whether implementing these technical practices increased the overall consciousness level of the team. Though the ideas in this article were still developing at that time, we see hallmarks in Cotten’s report of a higher level of connectedness, and therefore likely consciousness, in his report as it stands.
Conclusion
This article has introduced you to a link we have seen between the quality of technical practices and the level of consciousness on software development teams. We each noticed this independently in our coaching practices and when we had a chance to work together, we saw it even more starkly. Additionally, we have each experienced the benefits of structured dialogue to heighten the awareness of ourselves, those we work with, and to support the kind of learning required to raise consciousness. Our work is a means, not only to meet our material needs, but to understand the world and ourselves, as is true for many others in our craft. Software developers have tremendous power to leave the world a better place than they found it. The mindful use of technical practices is key in attaining the consciousness that can achieve this.
Previous writings in software development, taken together with writings on consciousness showed to us we are onto something. McKenna shows us that consciousness and software development are necessarily related. Combs shows that consciousness evolves; that we must progress from one level to another in sequence; that integral consciousness emerged around the turn of the 20th century and expanded through the culture in parallel with the emergence of software development as an increasingly complex area of knowledge. Macy shows that humans are subject to mutual causality such that we evolve in relation to each other. Argyris double-loop learning model is the means through which personal and group transformation, or consciousness evolution, occurs. The technical practices which cause us to encounter ourselves, each other, and the work bring us productively into the context for transformation--if we practice them intentionally and take advantage of the full learning potential in them.
Marc Andreeson’s famous Wall Street Journal article, “Why Software is Eating the World” described how software has become a pervasive part of every business on the planet. Software has become a backdoor through which a knowledgeable developer can influence an ever-increasing portion of the world.
It appears that we actually code our thinking, our understanding of the world, and, arguably, our consciousness into the products we work on. The humane, ethical stance seems to be to use the technical practices to help ourselves and each other raise our consciousness to the greatest degree that we can.
Success in consciousness raising would show up in our ability to work together smoothly, to produce products with fewer or even no defects, and to be very mindful of what we’re building and why. Such teams may, indeed, work on the next evolution of social media but not because it is cool but actually because they have considered their values, the context the product enters into, who will use it under what circumstances, and are convinced that the product will make the world a better place.
The problems before us today, both in software development and the world at large, require higher consciousness solutions. The mind that created the problem can’t solve it. Many technical practices are structured dialogues that engage learning and reflexivity which increases internal complexity over time. Internal complexity is the evidence of raised consciousness. The resulting suppleness of mind and creative/adaptive thinking capacity in relation to people and problems results in evolved, higher consciousness interactions and solutions and evolved, higher consciousness people in society. Meanwhile, products benefit as do teams and workplaces. The value in conscious practice of technical practices is in raised consciousness and the unforeseen solutions that come about as a result. This is innovation and the ground of innovation. Makers make themselves into and through the thing made, in and through the process of making.
Acknowledgements
We would like to thank the following people for their comments, reflections, interest, and support during the development of this article: Ray Arell, Cathy Bennet, Cotten Blackwell, Ward Cunningham, Sarah Huntington, Mike Lonergan, Jeff McKenna, and Adam Simantel.
Sources Referenced and Consulted
Argyris, C. (1994). Good communication that blocks learning. (cover story). Harvard Business Review, 72(4), 77. Retrieved from EBSCOhost.
Argyris, C. (1991). Teaching smart people how to learn. Harvard Business Review 4(5): 4-15
Beck, K. and Andres, C. (2004). Extreme Programming Explained, 2nd edition. Boston: Addison-Wesley.
Combs, A. (2009). Consciousness Explained Better: Towards an Integral Understanding of the Multifaceted Nature of Consciousness. St Paul: Paragon House.
Macy, J. (1991). Mutual causality in Buddhism and general systems theory: The dharma of natural systems. Albany, NY: State University of New York Press.
McKenna, J. (2014). Conscious Software Development. CreateSpace Independent Publishing Platform.
McTaggert, L. (2008). The Field: The Quest for the Secret Force of the Universe. New York: Harper.
Richardson, J. (2014). Double Loop Learning: A Powerful Force for Organizational Excellence. Pacific Northwest Software Quality Conference Proceedings 2014.
Wheatley, M. J. (1999). Leadership and the New Science: Discovering Order in a Chaotic World. San Francisco, CA: Berrett-Koehler Publishers, Inc.
About the Authors
Jean Richardson is a coach and software product delivery professional whose experience and career path have spanned both traditional and Agile methods, frameworks, and cultural perspectives. The leadership model she espouses, Pervasive Leadership (InfoQ, Prezi, blog), is designed to help leaders set a collaborative context while still meeting their own stewardship responsibilities to the organization. She blogs here and can be found on Twitter at @JeanAtAzureGate
Matthew Plavcan is a technical practices coach who assists teams in adopting Agile practices and building their technical capabilities. His career includes verification of desktop microprocessors and teaching software development at the University of Illinois. Matt is an advocate and instructor of the Code Dojo and Coderetreat patterns, which use dedicated practice to hone professional programming skills. He facilitates events for the Portland, Oregon community and is a coordinator for the 2016 Global Day of Coderetreat. He posts his coaching and development musings on Twitter at @mplavcan