Posted on

Agile BS: The Productization of Agile

There is a preponderance of BS in and around the Agile community right now. Scrum has become productized, and ‘agile enablement’ firms touting that ‘agile is all we do’ are selling one or another variety of snake oil. Boston is a place where this is especially acute.

David Anderson, a guy who wrote a book called Kanban, is calling this out, and he is not alone. He spells it out here:

There is an initial assessment or appraisal…then some proposed future state envisaged…the new future state process is designed and it becomes the target outcome for the transition that is introduced and managed through the change management process.

This is a traditional 20th Century approach to change. It offers the reassurance of a defined outcome, and the outcome is envisaged either using a prescription from a text book, or by utilizing a model and designing a solution. The issue with this is that it assumes the problem exists in the complicated domain…

…It is ironic that the approach to Agile transitions has been a very non- Agile, big design up-front, make and follow a plan, approach. The fact that many Agile transitions are challenged and underperforming (and I’ve been saying this for at least 5 years now) may be that the approach being used is inappropriate to the domain of the problem. What we need is an Agile approach to change – an approach that incorporates feedback loops and evolves as new information emerges.

(See the full blog post here)

Andy Singleton, a friend of mine in Boston who makes great tools for distributed teams, is also on to something also, when he writes:

Pair programming:  Great for vendors, bad for customers.  Pair programming is like those girls that go to the restaurant bathroom together.  What are they doing?  If you are a vendor selling “pairs”, you have an awesome situation where you can charge twice as much, and you can easily churn guys on and off the pairs, one at a time, to steal talent for turnover or new projects.  If you are customer, you pay twice as much and you get churn.

(See the full blog post here.)

These writing from these two gentlemen are pointing to the productization of Agile. It’s a sad state of affairs that appears to be encouraged by the Scrum Alliance and the Agile Alliance.

Organizations need to think for themselves and be responsible for their own learning. Each firm must create a custom solution from practices that are based on solid principles. David Anderson and Andy Singleton are on to something. One size does not fit all.

The productization of Agile is happening now. The message is: one size fits all.

And it’s all BS.

 

 

Posted on

Culture: In The Garden of Your Mind

Culture exists in the garden of your mind.

Here is a fun and short video about that.

This is an awesome video from an awesome person who made a huge change in the world.

This man was quite a culture hacker. Enjoy it !

Elapsed Time: 3 minutes 11 seconds.

 

Posted on

The Intentional Learning Organization

There is absolutely nothing automatic where group learning is concerned.

As a group, we either intend it, or we don’t. Look no further than the current (low) learning levels of typical groups: teams and organizations; and local, state and federal government. Look no further than how nations act and behave with respect to learning.

If learning in groups was automatic, we would already:

  • Be colonizing Mars;
  • Be creating Genius Organizations at will;
  • Be curing cancer;
  • Be electing leaders that actually help us evolve as a species;
  • Be routinely processing conflict without war;
  • Be routinely managing population growth.

AND SO ON. See? Very little of these achievements are actually within reach. Getting all of this kind of stuff done requires people who agree. People who are aligned. No one person can pull any of this off alone.

No, group learning or what I call Tribal Learning, is a highly intentional and uncomfortable act. If it was easy, we’d be colonizing Mars by now. Cancer would be cured. See? You have to intend it.

In a business setting, Tribal Learning requires that we do at least some of the following:

  • Be Purposeful
  • Facilitate Our Meetings
  • Examine Our Norms
  • Be Punctual
  • Structure Our Interactions
  • Announce Our Intent
  • Game Our Meetings
  • Conduct Frequent Experiments
  • Manage Visually
  • Inspect Frequently
  • Get Coached
  • Manage Your Boundaries
  • Socialize Books
  • Pay Explicit Attention
  • Open The Space
  • Be Playful

These are the exact patterns and topics that The CultureGame book addresses. Most of these group-level behaviors are very uncomfortable.

That is because learning is uncomfortable.

That is because learning is change, and change is uncomfortable.

To learn as a group, everyone has to want to do it. Or, they have to at least tolerate the new patterns of behavior (see above) that encourage group learning.

Is it really this simple? Yes, it is really this simple.

Tribal Learning: If nobody wants to, it ain’t gonna happen.

Leaders have a role to play in helping people to ‘want to’. I plan to explain that one soon.

 

Posted on

Keith Ray: Thought Pioneer

The following is printed with permission from Keith Ray. It originally appeared here. The post is preserved here in unadulterated form. In this post he makes certain assertions that start to link Agile practices with the ability to manifest a Learning Organization. This is a great read.

 

 

Quotes:

Continuous Learning. I’ve always said that XP requires a Learning Organization, and this practice make it explicit.

and this one…

“….If everybody isn’t learning, then learning becomes a subversive activity.”

What is striking about this post is the obvious development of many of what are called Tribal Learning Patterns in the Culture Game book….blogpost follows…..

============================================

2003.Apr.24 Thu

What is Industrial Extreme Programming?

At the BayXP meeting last night, Joshua Kerievsky, Russ Rufer, Somik Raha, and Tracy Bialik of Industrial Logic gave a presentation on their version of XP that they have developed over the last several years. They named it “Industrial Extreme Programming” (IXP). What follows here are taken from my notes. Any errors are my own.

IXP is what Industrial Logic has been doing the past few years as they work with their clients in training and coaching XP projects. Joshua said he was concerned with recent “blendings” of XP and other methods (DSDM, FDD, Scrum, Crystal) because some of those blendings were throwing away XP’s planning practices (one of the most valuable aspects of XP). Many of these blendings were for the most part untried and unproven, as well, though the unblended methods have records of success.

IXP doesn’t remove any of the core practices of XP (except Metaphor, and few teams have really felt like they successfully used XP’s Metaphor practice). IXP builds on XP, adapting it for survival in larger companies, highly political companies, and large teams.

Kent Beck defined four values of Extreme Programming, values he felt were essential… other values were good, but he wanted to emphasis four in particular. XP’s values are Communication, Courage, Feedback, and Simplicity. Agile Modeling adopted those four and added Humility.

Joshua and his team have chosen five values, which they not only want to emphasize, but insist that the absence of these values in the project or company will cause failure and unhappiness. The IXP values are: Communication, Simplicity, Learning, Quality, and Enjoyment.

The value of Enjoyment is sometimes deemed controversial. Joshua considered Fun, and probably felt Enjoyment sounded better. People who enjoy their work are more likely to want to learn I’ve always said that XP requires a Learning Organization). People who enjoy their work and enjoy working together are more likely to have the teamwork that XP requires.

Quality is “we know it when we see it.” Quality products, quality code, a quality process, quality people.

These are the original XP practices that IXP includes (more or less), sometimes with modified names and meanings: [names in brackets are the original XP names, or the names I prefer over Kent’s names.]

 

  • Sustainable Pace
  • Planning Game [Release Planning, Iteration Planning]
  • Frequent Releases [Small Releases]
  • Refactoring [Merciless Refactoring]
  • Story Test-Driven Development [Programmer Tests, Acceptance Tests, TDD]
  • Continuous Integration
  • Pairing [Pair Programming]
  • Collective [Code] Ownership
  • Coding Standard
  • Domain-Driven Design [replaces Metaphor]
  • Evolutionary Design [replaces Simple Design?]

The name changes are for clarity and to expand things beyond just coding — people can pair on other things besides code, collective ownership can extend beyond code.

The new practices are:

 

  • Readiness Assessment
  • Viability Assessment
  • Project Community
  • Project Chartering
  • Test-Driven Management
  • Storytelling
  • Storytesting
  • Small Teams
  • Sitting Together
  • Continuous Learning
  • Iterative Usability
  • Retrospectives

Readiness Assessment answers the question “Are they able to transition to IXP?” See http://www.industriallogic.com/xp/assessment.html.

Viability Assessment answers the question “Is the project idea viable? Profitable? Feasible? Does the project have the necessary resources?”

Project Community expands on Kent Beck’s “Whole Team” concept. “People who are affected by the project and who effect it.” (Hope I got that quote right.) This includes QA staff, middle and upper level managers, tech support staff, programmers, DBAs, customers, end-users, and probably marketing and sales. (Reference to David Schmaltz / True North Consulting’s Project Community Forum.)

Project Chartering provides the Vision and Mission, as well as the definition of who is in the Project Community. A light-weight exercise that seems to be necessary for clarifying the project’s goals.

Test-Driven Management requires objective measures be defined for the success of the project. External results like “support 100 users by December 2003.” The Whole Team cooperates to achieve this goal. Also defines return on investment.

Sustainable Pace. They considered renaming this to “Slack” (see the book by Tom DeMarco). An example of the value of slack is that it can provide the time for someone to write the tool needed to increase development speed — too much focus on getting stories implemented quickly can be sub-optimal.

Storytelling. I think Joshua separated this out from Planning Game in order to emphasize that story-telling is a natural way to get requirements (sometimes after a bit of coaxing). IXP stories are not necessarily “user-centered” stories, since they may address concerns of administrators, maintainers, etc. “A story is an excuse to have a conversation.” Conversation is required to understand some stories — a story that can’t be understood can’t be implemented. Five words for a story title was also mentioned.

Storytesting. One word, to parallel Storytelling. This is defining the acceptance tests, but not writing them. IXP coaches help their clients in both Storytelling and Storytesting. Ideally, you do want “executable documentation” and they talked up Fit by Ward Cunningham – a framework that allows anyone using any editor capable of creating HTML tables to be able to specify acceptance tests. (Programmer help is still required to plug an application into Fit’s acceptance test framework.)

Planning Game. Joshua says that it is very weird that some of the hybrid methods are throwing away the planning game. This practice is so useful that many of Industrial Logic’s clients, who did not adopt all of XP, did adopt the Planning Game. Still, the concept of “velocity” (work done per iteration) seems to elude some clients

Frequent Releases – frequent end-user releases — same as XP’s practice. Enables rapid return on investment. Releasing to end-users provides opportunity for feedback, to find issues in deployment, issues raised by real live users. “Without learning, feedback does no good”.

Small Teams — for large projects, set up networks of small teams, with their own code-bases and coding rooms. A 30-person project might consist of teams as large as ten people and as small as three. Sometimes there might be a testing team and/or refactoring team that join the each of other teams at various times and then move on. Industrial Logic practices Pair Coaching, which does not require that both coaches be together at all times. Pair Coaching does enable coaching larger projects than a single coach could cope with.

Sitting Together — Joshua says that the term “Open Workspace” turns some people off, but it is the same concept. He has seen a 40-person XP team in one very large room, but that’s unusual. He has also seen one or more people give up the office they worked hard to get, because pairing in the same room as other people let them focus better and learn more. Sitting together / pair-programming can be done via internet collaboration, so it isn’t limited to open workspaces. The gave an example of a team split in two time-zones, who decided to synchronize their hours to allow more “virtual pairing”.

Continuous Learning. I’ve always said that XP requires a Learning Organization, and this practice make it explicit. Examples… Study groups who are not just allowed, but encouraged to get together for three hours a week, during office hours, because they know this helps them advance in their careers. XP Coaches who assign practice drills to the programmers or QA testers. “Lunch Break” learning groups show that management doesn’t care enough about their employees learning. An XP coach in Italy spends an hour a day teaching his junior programmers — whose skills are rapidly advancing. I think an member of the audience said “If everybody isn’t learning, then learning becomes a subversive activity.” Joshua also said that “resume-driven-design” tends to happen because programmers are starving to learn, but not given opportunities to do so.

Iterative Usability. The UI must be usable and tested regularly. Management-Tests should be tied into Iterative Usability. Redesign the UI as soon as feedback shows its flaws. Paper-based GUI design was also mentioned.

Time was running out, so the remaining practices were discussed quickly…

Evolutionary Design. Drives all design. Their tutorial has ten practices for this. (http://www.sdmagazine.com/documents/s=7928/sdmsdw3d/sdmsdw3d.html.)

Coding Standard. Have one.

Pairing. As per XP, but not just programmers.

Collective Ownership. As per XP, supported by tests, pairing, etc.

Retrospectives are a critical practice. Some clients are reluctant to get 40 people together for 2 or 3 days for a full project retrospect, but they should do it for the unexpected learnings that come from it. Also do mini-retrospectives each iteration.

Refactoring. Early and often as per XP. Don’t let “refactoring debt” accumulate.

Domain Driven Design. Even though never officially a part of XP, it has been done by every good XP programmer that Joshua knows. The Model objects are kept separate from the rest of the code (GUI, etc.) The acceptance tests normally operate on the model objects, skipping the GUI. See the book on this subject at http://domainlanguage.com/. See also Erik Evan’s “Ubiquitous Language”.

Story-Test-Driven-Development. First write a failing acceptance tests. Then use the TDD cycle (failing programmer test, code to make programmer test pass, refactor) until the acceptance test passes. This is “top-down” TDD, and it best avoids writing unnecessary code.

Continuous Integration. As per XP.

See http://www.industrialxp.org/ for more information. Check out these papers, too: http://industriallogic.com/papers/index.html
Posted on

Pioneers in Thought Leadership

I am actively looking for people who have been linking Agile to the Learning Organization concept before 2012. Specifically, I am looking for folks who have written anything in books, papers and blog posts predating 2012, that explain how Agile practices are actually the A-B-C steps to building a small Learning Organization that we currently call a Team.

Here are some of the links I have received so far. These links show how pioneering thinkers have been VERY CLOSE to the idea that Agile practices actually are the A-B-Cs that get a group to start engaging in patterns of behavior (the Tribal Learning Patterns) that literally manifest the Learning Organization in small groups.

These are the pioneering thought leaders, the true trailblazers:

Chris Matts: 2003, web page:

http://abc.truemesh.com/archives/000107.html

“…Agile is Learning…All Agile principles and practices are based upon feedback and learning. ”

Chris Matts: InfoQ interview: 2010

http://www.infoq.com/news/2010/05/learning-machine

“…I want the the Agile community to know that the community is in fact a learning machine….. and it is broken. If something is not done to fix it, it will only last another couple of years before it fragments and something else will rise to replace it.” (NOTE: Please examine www.TheCultureGame.com and www.CultureConference.org)

“…I recently wrote a blog post where I state the Agile Manifesto is actually a call to arms to create a software learning community. This is not a recent view of Agile although it is a recent reflection on the manifesto.”

 

Keith Ray, circa 2003, via his blog:

http://homepage.mac.com/keithray/blog/2003/04/24/

“…Continuous Learning. I’ve always said that XP requires a Learning Organization, and this practice make it explicit.”

NOTE: If the above link is broken, USE THIS ONE: http://newtechusa.net/agile/keith-ray-thought-pioneer/

Keith Ray: A link from Keith Ray circa 2003…

….that covers QUITE A FEW of the Tribal Learning patterns that Agile practices encourage…..no direct mention linking Agile practices to the manifestation of the Learning Org…

http://tech.groups.yahoo.com/group/extremeprogramming/message/82917

There’s a company that provides facilitators and arranges events for
other companies to help them think about their problems. They get a lot of people together in one room (they have places in various cities for
this purpose), and do various exercises not unlike some described in
Norm Kerth’s book on Retrospectives, and among other things do a log of
writing on sheets of paper on the walls.

 

 

 

 

 

Posted on

Agile: Gateway Drug to the Learning Organization

This post is how Agile is really just a gateway drug than can lead to a hard-core habit of Organizational Learning. However, that progression from merely ‘playing Agile’  to becoming a full-blown Learning Organization is by no means guaranteed.

 

In 1990-1991, Peter Senge wrote a book called THE FIFTH DISCIPLINE. In that book he describes the 5 characteristics of a ‘Learning Organization’. In my view, describing a Learning Organization is far easier than building one. Finding a learning organization as described by Senge is also quite difficult. In fact, it is about as difficult as finding an organization that has implemented and achieved real Agility, what I call Free-Standing Agility.

Agile is a culture hack, and the intent of the hack is to produce a small learning organization- we call it a Team.

What is Agile then?

Agile is a gateway drug to real organizational learning. All of the Agile techniques are in a sense very small A-B-C prescriptions  for learning how to be a Learning Organization.

Scrum.

Kanban.

Task Boards.

Information radiation.

Retrospectives.

XP.

Pair programming.

Iteration.

Burndown charts.

Work-in-process limits.

Test-driven development.

Etc.

ALL of these practices are nothing more than gateway drugs to the ultimate enterprise high: organizational learning.

Working at an organization that rapidly learns is the ultimate high. You are respected as you respect others. The space is safe for the best idea, asking for help, and calling bullshit when we start sidetracking. You love working with the people there, even as you strongly disagree with them.  Mistakes are learning events. Differences are raw material for innovation. You use specific techniques and behaviors to rapidly learn as a group. The people there value what you value. You feel in sync and are in fact highly engaged.

Participating inside a true Learning Organization is the ultimate career high.

We are in the late-majority stage with respect to Agile. Most organizations are “playing Agile”, in effect “smoking the dope” of Agile practices to get a quick buzz. These organizations are not focused on organizational learning as the end game. They are out in left field, missing the boat, asleep at the switch. The buzz you can get from Agile is nothing compared to the transcendent bliss of experiencing social membership in a genuine Learning Organization.

Team learning is by no means automatic. We must intend it as a group. Everyone and every organization gets what it wants. To know what an entity wants, examine long-run results. Intentions == Results.

The next chapter with Agile is business agility. A business that is truly Agile is in fact a Learning Organization. The primary tool for getting there is a focus on creating and maintaining a culture that is 100% conducive to extremely high levels of Tribal (group) Learning.

Culture hacking is one way to get there. Culture hacking is the intentional modification of culture, with or without permission…with intent to change the game. Agile is a great example. Agile is a total culture hack.

I explain ALL of this in great detail in my book, The Culture Game. It is a culture hacking tutorial and reference guide– the handbook for game-changers and innovators who live and work in the corporate “reality-distortion” field.

The Culture Game book explains the 16 learning patterns that, if implemented, can almost automatically generate much higher levels of business agility.

Summary

Is organizational learning addictive? It might be.

Scrum, Kanban and the rest….they are mere gateway drugs to the real deal: the enterprise-wide mainlining of the habits that lead to the ultimate organizational buzz: The Learning Organization.

Agile is a gateway drug to organizational learning and the blissful state and status that any rational organization must aspire to: the learning organization.

The Learning Organization: Argyris and Schon defined it. Senge popularized it. The Agile movement made it real.

But not at scale.

Agile is a convenient gateway drug to the ultimate buzz: participating in always-on, enterprise-wide organizational learning.

Who wrote this? Learn more here.

Posted on

Agile: It’s a Culture Hack

On September 12 in Philadelphia and September 14 in Boston, Agile Philly and Agile Boston are bringing the Agile Culture Conference to the world. Philadelphia and Boston associate with freedom and revolution. And life, liberty and …the pursuit of happiness.

It’s time!

Thomas Paine said it well when he said:

“…self-organizing teams perform for themselves almost everything that is ascribed to managers.”

Well, he did not exactly say THAT, but he is close. Click the link above to see what he REALLY says.

It’s time to call Agile what it is: it’s a culture hack. The values, the principles, the practices,  and processes are all a bundle of culture hacking tools. The harsh reality of software development has spawned a bottom-up revolution in how we think about working. In teams.

Agile is a culture hack. With Agile, we can create a Learning Organization.

And what exactly is a Learning Organization? According to Wikipedia,

A learning organization is the term given to a company that facilitates the learning of its members and continuously transforms itself. Learning organizations develop as a result of the pressures facing modern organizations and enables them to remain competitive in the business environment. A learning organization has five main features; systems thinking, personal mastery, mental models, shared vision and team learning.”

Organizations do not organically develop into learning organizations; there are factors prompting their change. As organizations grow, they lose their capacity to learn as company structures and individual thinking becomes rigid.”

We can create a genius from a group of people- if they are willing. We call this genius “a team”. The reason “Agile does not scale” is precisely because becoming a Learning Organization is at best a challenging task. It is also a deeply rewarding one. We all need to wake up: Agile people are culture hackers. We are in the business of creating Learning Organizations. WE. KNOW. HOW. TO. DO. IT.

The broader implications of this are profound. The implications are:

1. Cultural design, culture engineering and culture hacking are in fact better descriptions for what we do than any other description. We Agile folks are in the business of culture. We are culture engineers. We do culture engineering. Culture hacking is one kind of culture engineering.

2. Culture technology exists and can be exploited to create Learning Organizations. My book, THE CULTURE GAME is a culture technology tutorial and reference guide. It is a handbook for culture engineers.

3. In organizations, our work is about reclaiming a cultural garden that is full of cultural weeds. The root word for culture in Latin has many meanings, one of them is ‘to grow’. We are in the business of cultivating certain kinds of growth, and eradicating undesirable growth.

4. Agile methods are culture hacking methods. Agile frameworks are culture hacking frameworks. In the hands of a competent coach and in an organization of willing people, we can and do facilitate genuine cultural movement.

Enter THE AGILE CULTURE CONFERENCE

We have an amazing event planned for the Fall. The event is historic and represents a potential turning point in the Agile story. This is the moment when we port Agile up and out of IT, from teams to tribes…and entire organizations.

We have amazing keynotes. Harrison Owen, the father of Open Space,  is the keynote in Philadelphia. Dave Logan, the author of TRIBAL LEADERSHIP, is the keynote in Boston. Both events have amazing speakers like Traci Fenton, CEO of WorldBlu, the worldwide champion of Freedom At Work. We have Ayden Adler, the Exec Director of Orpheus Orchestra, the renowned, self-managed orchestra that has NO CONDUCTOR. We have many noted authorities in the Agile space speaking in breakout sessions.

You can attend in Philly AND Boston, and connect by train. The Agile Train. You can self-manage and self-organize your colleagues and friends to be part of this event with you. We the organizers are chartering a party BUS for speakers, sponsors and organizers, shuttling the whole group from Philly to Boston.

Agile has been struggling to understand itself these past several years. The cat is now out the bag: cultural architecture and design, leading to higher levels of engagement and productivity, is the new normal.

We are culture hackers!

Agile is a culture hack. We are culture hackers. We are culture designers.

We are culture engineers.

LEARN MORE AND REGISTER:

Get your ticket for Agile Culture Conference PHILADELPHIA here!

Get your ticket for Agile Culture Conference BOSTON here!

Posted on

Winning the Productivity Game

Dave Logan is the author of TRIBAL LEADERSHIP. In this book Dave describes the triad, a structure that is essential for scaling Agile from teams to tribes.

In my book THE CULTURE GAME, I describe how to use triads to get viral spread of the sixteen team-learning practices described in that book.

Please join Dave Logan and myself (Dan Mezick) on the 1-hour FREE call entitled Winning The Productivity Game.

During this public learning event, you will learn:

  • How to raise your productivity at work, both individually… and in teams;
  • Why your meetings (and often work in general) can be soul-sucking death march from hell, and what to do about it;
  • What specific techniques you can use as a manager and/or someone who convenes meetings…to raise the level of engagement and productivity at work;
  • Where you can find specific resources and tools to help you install small changes (“culture hacks“) with big, positive effects for your teams and the wider organization.

Register now for this call to learn the specific steps you can take tomorrow to raise the level of productivity in your organization.

 

During this 1-hour call, you can help make work and meeting more engaging, productive and fun. I plan to disclose specific techniques to do this that are found in THE CULTURE GAME book.

You can click this link to learn more about the event, and sign up to be on the call! I hope to see you there ! Here is part of the description of the event found on the CultureSync registration page:

Play the game and love your work. Author and coach, Dan Mezick, will join Dave Logan for a rousing 60 minute romp through the games you can play every day to make work more productive, satisfying, and fun.

Dan says: 
Productivity at work is a game. If the core requirements for productivity at work are not present, you disengage and check out. If the core requirements are there, you automatically experience fun, satisfaction and potentially, a deeply engaged sense of well-being.

We’re sure he’ll share the 8 specific things he’s learned you must do if you are to win the game of engagement, happiness and productivity at work. You’ll walk away from the call with actionable techniques you can start using today to win the productivity game.

NOTE: This is a free online event from CultureSync, Dave Logan’s company providing education, tools and resources for leaders, managers and teams who are seeking an upgrade of their company culture.

REGISTER HERE:  Winning The Productivity Game

Posted on

Culture Hacking

Culture hacking is almost the same as software hacking. Culture hacking modifies culture, instead of modifying software. Software hackers in the 1970’s created code for personal use and for others to also use and enjoy. In the modern day, culture hackers actively modify culture for personal betterment and the betterment of others.

 

Hacking Culture- like it is software

What is significant here is the software view of culture. I have already written about how culture is a system, like software, and can be hacked like software. In my view culture is composed of stories, and stories are composed of language. If you modify language you are in fact culture hacking.

I credit Jim McCarthy and Michele McCarthy for emphasizing this link between culture and software,  in their book SOFTWARE FOR YOUR HEAD. The book describes structured interactions for humans. Likewise I credit the McCarthy’s with moving decisively to popularize the phrase culture hacking. My book  THE CULTURE GAME is literally a culture hacking manual.

Here is what Jim McCarthy says about culture hacking:

A culture is the set of shared attitudes, values, goals, and practices that both describes and shapes a group. Our era is increasingly characterized by an emergent “software culture.” Not only is software itself creating much of our global wealth, but the unique challenges of creating our software have demanded wholly new types of engineered corporate culture from us. In response to the demands of software, various high tech development disciplines have been articulated and “packaged up.” We have created several seminal management “movements” (such as Agile, Scrum, XP, etc.). These movements represent the birth of culture engineering and are primitive compared to what will soon follow.

Culture hacking is itself a distinct kind of culture engineering, and is faithful to the particular hacker ethos that originated in the world of software hacking. Good culture hacking will tend to protect personal freedom, extend openness, embody rationality and promote culture design elegance. Culture hacking takes into account the limits and uses of authority, is skeptical of incoherent institutional power, and is subversive of it. As our many cultures become increasingly (and fruitfully) hacked, we will likely grow in effectiveness, and ambition. This will bring more and more of the world’s problems into manageable scope. This will likely trigger an unprecedented Golden Era.

 

Agile in reality is a great big culture hack: a collection of processes and methods and specific actions that, when used together, influence culture at various levels: team, department, division, enterprise.

Agile is a culture hack. And over time, we may start to understand it as a relatively and historically primitive one at that.

Think of it like this:

culture hacking = agile++