Management by Baseball

Agile and Lean management requires the manager to be flexible in adapting methods, systems and techniques not only for "local" conditions (meaning the specifics of your own shop and the specifics of the project) but also for evolution in those conditions. But as I explained in an earlier entry in this series, to be effective, you have to individualize management tactics for each individual talent in your team.

Former baseball manager Tony La Russa gave extra thought when he was inventing Agile management to specific tactics that were powerful, that cost a little effort and delivered high return on that effort. I call that tactic, "Speaking in the Talent's Language"

That language, at its simplest means using each person's slang or closely-held words. We all to this to some degree; when you work in a shop where people commonly use creepy connectors such as "from the get-go" or "at the end of the day" or by starting sentences with "So," it becomes very difficult for normally socialised people to avoid using that language. But, in general, most people on the team will understand you if you use this local vocabulary. And then individuals each have their own, specific words that at work are local to them. And if you can incorporate that vocabulary into your personl communications with team members, you'll tend to get better return on communication effort.

As the North America becomes more multi-lingual, speaking in the talent's language sometimes requires communicating, literally, in a "foreign" language. And if that what it takes to optimize the talent's potential, then to master the Agile management panoply, you better go that way. Here's a concrete example from La Russa himself, from his book, One Last Strike: Fifty Years in Baseball, Ten and a Half Games Back, and One Final Championship Season (pages 335 - 337). That last season La Russa managed the St. Louis Cardinals, and won the World Series, they early on rode the success of a very young pitcher, Jaime Garcia, who had carried them in the beginning of the season, but as he racked up innings and his young arm healed more slowly, and as the opposition learned to identify his skills and patterns better had had lesser and less-consistent results in the second half.

Garcia is a bilingual man who grew up in the U.S. but for whom Spanish was his first language. La Russa is going to him in a post-season game, but has been protecting him with lower and more specific appearances of late. If La Russa uses traditional, no-Agile techniques, he'll just manage to optimize the team but not "waste" ergs checking in with the team member.

In the lead-up to the game, I'd sought him out a couple of times, just to check in with him to see how he was doing. Jaime's from Reynoso, Mexico, but grew up in Texas. As we talked, we slipped into and out of Spanish and English. I'm not completely calculating when I do this, it just comes naturally to someone who's bilingual. Having these shared languages helps with personalizing -- it establishes another point of commonality with some of the players, just as anyone would look for in getting to know another person

Using, or learning, a foreign language is a maxxxximum connection-builder. If you can do this to advance your abilities in your own management environment, that's a better investment than yet another analytical model or financial system. But you don't have to go that far to succeed with speaking in the talent's language.

Just be attentive to each team member's forms and styles of communication and the vocabulary they use and mis-use and customize your communications to deliver better outomes.

No one expects you to be as good as La Russa, but he and his mentors invented Agile; you just have to strive relentlessly to be that good.

Agile management requires paying attention to what you know and acting on that knowledge. Agile management requires relentless innovation to adapt to evolving circumstances by fixing it even if it's not broken. Both at the same time.

That requires, among other things, a great deal of courage, which is what it takes to respect opposites and, as I mentioned in the last entry, have the courage to give both poles consideration.

Baseball has mastered this synthesis of opposites for about a century. Good managers in all fields keep themselves from melting down from decision compelxity by what I call "aliasing". That's autonomically recognizing patterns you can face repeatedly the same way instead of ignoring historical we-did-this-and-that-happened track record. When managers do that energy conservation move it saves ergs for facing the less-known or less-predictable.

At the same time, if you're too attached to MBE, while you are investing decision time in ever-fewer conundra (which is comfortable), you need to break your comfort to make sure context hasn't changed or that you're not ignoring a second-order improvement you could experiment with and install. Agile has a useful bias against re-inventing what already works, but that's a leaning and not a binary absolute. In the end, you have to escape past flops to concentrate on what's in front of you. In the end, you have to be accustomed to innovating so you don't end up digging ruts that are hard to get out of when the situation has evolved enough that changing your tactics is required.

In Baseball, they call this "Don't Look Back" or "Short Memory". To succeed in a zero-sum, hyper-competitive venture, you have to have short memory to keep your cerebrum in the moment.

As Tony La Russa mentioned on the very first page of his book, One Last Strike, writing about the final game of the season, the one that would determine whether his team would make the playoffs as a wild card or not:

Normally, I don't look back. I keep my focus on the game ahead. Yet on this morning, as I prepared to head over to the stadium, the emotional surge of this was all too much, and I broke one of my golden rules

You take that pause to think back or look too far forward and suddenly you've lost focus. Save that for after the game, and look back to learn from your past wins and losses.

That goes not only for the manager herself, but for the team one leads to keep them focused on the next sprint and nailing it.

I'd always stress this with our players, telling them that the second they started being content with what they've done, they weren't focusing on what they were going to do. You can't (afford to) trulysavor what you're doing while you're doing it. {snip} The real fame and fortune would be by-products of winning. The real fun was how we competed.

Agile has adsorbed this technique from Baseball. Celebration of success and tweaking what went wrong are important, but the actual work of the next sprint is much more important. Yes, it's hard to find that balance between the necessary efficiency of "aliasing" decisions by cloning past successes and the equally-necessary relentless drive to innovate even what apparently works.

The only dangerous thing about Agile Project management is that most people who try it don't understand it well enough to avoid failure. The Agile MANifesto has a pillar that is the most misunderstood:

¿How misunderstood? Well, most misinterpreters think this either means "don't bother to plan at all" or "respond to change in the moment without pre-meditiation". The latter stance fits many young managers who cut their teeth on the kinds of video games labeled "first person shooters" where the path to victory is making instant twitch decisions in response to stimuli and having quick reaction time. Some Agile managers execute this way, and while the results are not always tragic (because in Agile, just-so-so-but-quick is most often a virtue), an investment in planning that the manager knows intimately but holds loosely usually pays off much better in quality without hindering time-to-decision.

In the last entry I explained a little about the necessity in a competitive environment of adapting to rapidly-evolving conditions and Agile project management, a constellation of methods that originated in Baseball and of which Chicago White Sox, Oakland Athletics and St. Louis Cardinals manager Tony La Russa was a master practitioner.

Mastery comes from the combination of three things: rigorous pre-examination and creation of what I'll call assemblies (sets of decisions that go together well) to simplify decisions one needs to make quickly and the willingness to deploy occasional seemingly-radical experiments in real time, even during a vital project.

I'll use an example from La Russa's recent book, One Last Strike (p. 132-133).

Here's the situation. 2011 season, at the end of August (5/6ths of the season now gone) his Cardinals are 8-1/2 games out of first place, behind the Milwaukee Brewers. They are facing the Brewers in a series at home, and they've take two of three games already and there's one game left in the 3-game series. If they can sweep the series, it will be a powerful competitive statement, but if they lose the last game, it will mean that with 25 games to go, they "lost" two games in a turnaround.

Every single game is massive now, and this is one of the small handful left with the very team they need to close on.

Most planners would take the surest right-now advantage, playing as though this 136th game was the last game ever to be played, discounting the future entirely. Not La Russa; he's willing to try an innovation right here, right now. Bold and cold.

Then came a game I consider to be tied for first for the scariest I've ever managed

I made the decision to hold off on starting Carp (by far his best pitcher, and who was fully rested) in the final game of the series, even though it was his turn. His last outing had been a struggle, and after his five months of pitching, it make sense to tak advantage advantage fo the off day; also, he was usually oustanding against the Reds, who we were playing next.

In place of Carp, I sent out rookie Brandon Dickson (who, if you haven't heard of him, don't worry because no one else has either) This was one of the decisions that Jim Leyland and I call "Going Deep". Over a season, there are decisions that require serious deliberations on seveal levels. This one could have ben the mold. Why Disckson and not (Jaime) Garcia or Carp? Garcia would have had seven days' rest which was good, but then he would have missed the Reds and the Braves (two tough teams La Russa needed to beat, missed because by using him in this game, it would delay his day to be ready subsequently, which, when used, would delay the next start after, too). Dickson features a good hard sinker with a developing curve and a change-up. I was hoping unfamiliarity would get him through the Brewers' very good lineup a few times

In the end, I figured the last Brewers game was important, but not as important as setting up Carp for the rest of the schedule. I knew it was serving up a juicy topic for anyone interested. I only concerned myself with one group's opinion: our players. {snip} If we had lost the first two (games) then I might have gone with Carp because we would have been facing elimination with another loss. I'd agonized and agonized over that rotation, and pulling the trigger on this decision was so hard -- but flying in the face of conventional wisdom I strapped on the worry beads and and we all went at it.

The key points here are (1) he attempted a contrarian innovation even at a crucial juncture with the season on the line and (2) even though he had thought through the planning for his rotation for the entire season and all the contingencies, he was willing to adapt to the situation in front of him by breaking the protocol and take a chance on getting even better outcomes. And (3) he agonized over the decision. Agile doesn't mean low-stress; in many ways, it's higher stress, because your walking the hire wire without a net below (the every detail nailed down plan).

NOTE: In that final game of the series against the Brewers, Dickson wasn't very good but not awful, and the Cardinal offense outscored the opponent for a victory and a vindication of La Russa's decision. And, of course, the Cards went on to get into the playoffs and win the World Series. Agony paid off.

The final point about making any really hairy decisions: agony is what it feels like, unless you don't care. If you are aware of the possible consequences, then it's agony. If it works, then it's a good decision. If it fails, then it's a bad decision. You survive by working the process as best you can, which includes remembering that they pay you for using your best judgment, so use it.

To have mastery of Agile or Lean processes, you have to hold fear at arm's length, be bold, be willing to plan rigorously AND to innovate off the plan on the fly.

In Baseball they do it all the time. Can you?

The Intro to this series of posts exposes the generally-unknown fact that Major League manager One of the challenges of Agile product design & development is project management. The foundation of Agile is the drive to diminish overhead, and planning IS overhead. As I pointed out in the Introductory post to this series, the Agile MANifesto says

Responding to change over following a plan

But Agile and Lean mean moving quickly. And moving quickly without management is instrinsically risky...unless you do it it as they do in Baseball.

Tony La Russa and his mentors invented a form of project management that Agile Development has cloned almost exactly for its own purposes. As La Russa describes in his recent book, One Last Strike, the way to project manage in an Agile way is far more intensive and demanding and requires more skill than traditional plan-every-detail project management does.

Instead of front-loading all the individual details, the La Russa methods involve front-loading basic rules of action and working out every contingency and its tendencies in advance. That way, when you are in the moment of decision-making, you don't have to think through possibilities from scratch. It's very much like modular architecture (think Alexander's A Pattern Language: Towns, Buildings, Construction) or modular software development. Each game (project) has patterns you know in advance, probabilities that evolve rapidly during the execution. Each pattern consists of coherent clusters of interrelated pieces, like a set of 16 Lego blocks you would use to make a doorway-and-arch or a building corner. Each decision you make will be based not on perfection but on optimal utility in that moment, and that might involve riffing off one of the components that make up that pattern, to increase its "performance" probability in the specific instance of its application.

Figuring out which components, what might need to vary for contexts, and contingencies is a lot of hard work, fun for some of us, but challenging nevertheless. You are simplifying the work (by using patterns/clusters) in order to save energy to invest in the contingency efforts.

La Russa describes (page 206-7) a classic example of a super-critical project management planning/contingency-design cycle he went through in 2011, his St. Louis Cardinals' last World Series championship year. and his last season. The set-up is this: The Cards had to win the last game of the season to earn a spot in the playoffs. Weeks in advance of that game #162, he had arranged his pitching staff so that if that was a win-or-go-home moment, which it turned out to be, the team would have Chris Carpenter, easily the teams best pitcher, starting that game. That way, if the game was irrelevant to the playoffs, he would rest "Carp" & use him in the playoff opener; if the Cards were out of contention, he could start Carp or not.

He used Carpenter in the last game and that closed a few (Carp could not start the first playoff game as they would have had him do, ideally) and simultaneously opened a ton of possibilities/patterns he could use. They won their game, but two other games going on after theirs could affect the outcome by changing the standings. Look at his relentless (Agile) project management thinking.

My thinking about the rotation for the Phillies series began in the 45 minutes following our victory over Houston in game 162. While the guys were agonizing over those final innings bteween Atlanta and Philly, I was in the officegoing over stats and messing around with some ideas about how to get the most Carp for our buck. I knew one thing without a doubt: we had to have Carp pitch in two of those five games. Had to.

I came to that conclusion immediately, even when I was still in Houston before the champagne was uncorked. While we hadn't fully committed to having him start on three days' rest (note: less rest than normal, undermining of peak performance) I know that I first considered it back then. After we were sure we were in and headed back home on the plane, I looked at the rotation again. What we had found over the years about the best-of-five Division Series was that pitching your two best pitchers twice gives you the edge. Ideally, you'd like your number one go in games 1 and 4 and your number two in games 2 and 5. (note: ideal because then the number one gets an extra day of rest between series if you win, so can start earlier against the next opponent). We couldn't do that. Carp obviously wouldn't start the first game on Saturday because he had just pitched on Wednesday. That meant the soonest he could go was the second game on Sunday {snip} the fifth and deciding game. (note: not ideal, but a good fallback to have your best pitcher in a deciding game).

La Russa accepts this as his base decision. But he's not done. As with all Agile projects, there are people involved, and team members need both to buy in and deliver.

...we were on our way back to St. Louis. I was still sitting there with a pad and pencil taking notes about the possible rotation for the upcoming series. I got up and walked back to where Carp was. I held out the paper and tapped the space on the page where I'd penciled in his name.

Carp smiled and nodded. "I'm good to go."

"Not yet. We'll wait and see how you feel Friday (note: the second day after a start and the day of testing soreness/recovery)"

I walked back to my seat. Of course he'd want the ball. I already knew that. I just wanted to let him know that we were going to wait to see how he felt before fully committing.

That was a base plan for games 2 and 5, but what about the rest? It's somewhat simpler because La Russa is now building around a draft decision-made that makes for some givens.

His decision algebra is detailed in the book, but again, he's starting with known clusters, delivering small certainties, and then building draft plans for each decision.

Each of the decisions for this high-impact, multi-million dollar Agile project is something he crafts carefull but holds loosely. On game day while filling out the lineup card, he's not going to be krazy-glued to his initial draft; if he needs to riff to match evolving contexts, he will, using other patterns or, in La Russa's or other top-notch managers' cases, inventing soemthing on the fly.

La Russa is a pretty extraordinary practitioner of Agile project management, evevn for someone from Baseball. But as I've said before, the 25th-percentile Baseball manager can manage and lead rings around 85% of billion-dollar company CEOs.

Perhaps nowhere does is this secret so exposed as it is in the Agile and Lean practice of "information radiators" or Kanban, simple forms of data exposed to the team simply but inescapably, with as little and as simple technology/techniques as one can make it.

There are two reasons for this: the better-known and the lesser-known reasons.

The better known reason for these information radiators is shared accountability for results. Think those organizational United Way "thermometer" mimicking cut-outs that stand in reception areas to show everyone how much money is pledged and how much more there is to go to get to the target. The measures or specifics must be understandable across both the team and management.

The lesser known reason is when you give up sophisticated automation on the collection side and do it instead with low-tech tools, you are less intermediated from the source. That is, the act of writing on graph paper with a pencil or pen reifies the information in your memory, clarifies possible points of connections or patterns.

On the surface, it's an odd thing that Agile Software Development, which is all about producing high-technology artifacts leans strongly towards lowest-functional-technology to support its processes. But delegating the "thinking" to technology exposes you to the Peavy Principle, that is, that every technology added enables new abilities while disabling existing ones. So as a manager or a team leader, it's important to collect meaningful information yourself using measures that have meaning to you, and then share them with the team.

As Tony La Russa explained in his recent book, One Last Strike: Fifty Years in Baseball, Ten and a Half Games Back, and One Final Championship Season, he's started doing this even when he worked for the first baseball team to use computers in the dugout, Roland Hemond's Chicago White Sox. He had learned from one of his own skippers, Dick Williams when he was a young player for Williams' 1968 Oakland Athletics.

In La Russa's own words (p.118):

I was yo-yoing between AAA and the big club. {snip} During the brief times I was up, I was able to pick up several very important points and strategies relating to leadership and managing from the A's manager. {snip}

It was Dick's advice that led me to the practice of filling my lineup cards with game notes. The very important after-game review revealed many winning nuggets because they were all part of thos cards. You took actual game info, added insight, and came away with "stuff" about your team, your opponents, and what had decided the game just played.

Dick Williams was someone I knew as a baseball writer and later as an acquaintance and someone I talked baseball with a couple of dozen times, twice for over an hour. In the times we spoke face-to-face, he was managing the Seattle Mariners, and he'd sometimes rifle through his lineup cards to find or shape a point. These information radiators aren't just for private use, they are for information sharing.

Agile and Lean owe a lot of what makes them tick to Baseball in general, and La Russa and one of his mentors, Dick Williams, than it's inclined to share.

ASIDE: La Russa has the reputation as an anti-data guy, which he is not, because being anti-computer and anti-data are not synonymous. Sure, there are plenty of BITGODs who hate both data and computers, and plenty of contemporary Sabermetricians who love both data and computers...but those two dualities are not locked immutably together like Woody Allen and the Windsor Light Condensed typeface. La Russa always used data as part of his problem-solving, critical-thinking algebra. He just used Williams' note taking model as his radiator instead of an Apple ][ or other electronic tool.

If there's one word that embodies this "personalization," as La Russa calls it, that word is 'supportive'.

But the support in supportive must not be infinite. You try to support every aspect of a team member's aspirations and personality and goals, but not to the point that it degrades the team as a whole or another member's ability to contribute.

As I've explained many times before, one of the endemic weaknesses of North American institutions, especially corporations, especially those where Finance dominates strategy or organizational tactics, is " binary thinking". Binary thinking is where the decisionmaker views things as having two opposite possibilities, and no others. Nuance tends to be winnowed out for the binary thinker. What channel shall I distribute through...direct or indirect? Is the Syrian Opposition "good" or "evil"? Should I plant soybeans or sorghum? Should I expand our markets or look for a buyer? Shall I limit myself to 950 calories a day or not bother to diet at all?

Binary thinkers are mentally (and usually physically) uncomfortable in the grey areas (and almost all the best possible methods work when executed in grey areas). Even when binary thinkers try to be nuanced, their tone-deafness to nuance tends to create craptastic outcomes (like the illogic and un-coherent nature of Henry Paulson/Timmy Geithner Big Bank Bailout, a classic lesson inthe tragedy of letting binary thinkers make important decisions).

Agile and Lean management methods count on nuance in most areas, and most extremely in the areas of personnel management (Second Base in the MBB Model), a field Tony La Russa and his management team have managed well and simply. In La Russa's own words (p.10):

Personalizing with players never meant that everything they did was okay. We didn't sign any blank checks. You're kidding yourself if you think you'll win players' trust that way. You win them over with your honesty. In fact, one of the ways we'd show this throughout the season was in how we reacted when they made mistakes. Whatever the problem was, we'd tell them what they'd done{snip} and we'd deal with it as a fact and not a judgment. We created an environment that recognized that mistakes would happen and would be corrected.

Supportive leadership increases the quality of team outcomes...until it doesn't, and then it degrades team outcomes. Finding a balance, overcoming binary alternatvies between all or none, is one of the most challenging states a manager can find.

BALANCING EXERCISE
There is no single technique that works for all managers, but you can use a Dick Williams technique.

If you've made a point of being a supportive team leader, make a hand-written (yes, not typed or just thought out...the act of writing it down will make your archival thinking clearer) list of all the instances where you were too supportive, wrote, as La Russa calls it, a blank check that didn't work out.

Think through if it should have worked out that way every time...that is, make sure there were no external factors that trashed the outcome and that it was the blank check itself that caused the failure. If it was the blank check, think throughwhat you could have done instead.

The simplest approach is the honesty La Russa and his management team apply, what management star Keith Ferrazzi and his outfit call "candor". As you probably already know, most big corporate or military or government or academic organizations are not healthy enough to allow for daily honesty/candor. If you work in one of those organizations, your fallback is to keep going back to your list, remind yourself of where you went overboard with supportive leadership and test yourself again and again to make sure you're not repeating the blank-check error.

It's not as good as what Tony La Russa would achieve, but it can reduce Agile and Lean managers' frequency and consequences of falling into the errors of writing blank checks.

Agile and Lean methods have borrowed heavily from this Baseball standard, realizing that when The Talent is the Product (as it is in Baseball or virtually any non-commodity endeavour such as product design or -development, medicine, logistics, et.al.), you can only succeed when you squeeze every bit of utility out of every contributor.

Utility is not the "More With Less" Cult foolishness of pressuring the talent to work unpaid overtime or trying to replace them with commodity offshore shops that will work for a quarter of minimum wage. Utility is not finding an excellent approach that is optimal on average and applying it to everyone -- that hallmark of the Quality movement works pretty well in many cases when the object being managed in INanimate, but is going to be sub-optimal in over 90% of instances.

In the recent and very useful Tony La Russa book, the skilled manager talks about how he and his management team make this everyone-the-same-while-everyone-differently method.

He calls it "Personalization". As he describes it in his book (pp 8-11)

For years, what we'd always done as a coaching staff -- equipment men to video guys, the strength and fitness coach, public relations people, the director of travel, everybody -- was to personalize our relationships with the players. Whoever you were, my coaching staff and I wanted to estblish a relationship with you. Not every player is the same and not every position they play is the same. Our goal was to create an environment where the ballplayer looked forward to coming to work and knew that a bunch of people were trying to put him and his teammates in the best position to succeed.

Further, he explains a few paragraphs later, how changes to baseball (aligned perfectly to the vicissitudes of contemporary corporate and government work environments) early in his management career made the returns on effort of personalization much higher. In the parasitic mutant of real capitalism that dominates the North American & Eastern European economies, talent loyalty is discounted in planning, and the norm for staffing is what I call "the disposable employee".

Again to quote La Russa's book:

My awareness and emphasis on personalizing coincided with a shift in the players and in sports culture. During the 1980s, professional baseball was changing dramatically compared to my introduction to the major leagues in the '60s and '70s. The distractions of fame and fortune were a constant adversary to the manager focusing on team matters. {snip} It was hard and it was time-consuming, but it worked. {snip}

Every team and every season has its own set of problems. By personalizing, I was creating a pattern of feedback that would address thosed problems -- both big and small -- that we faced as a team and as individuals. {snip} In the process of personalizing those messages, we'd develop a number of "edges" that would help us compete individually and collectively. These edges ranged from the macro -- team chemisty, handling adversity, making players' families feel welcome -- to more individual issues like physical and mental toughness, feeling comfortable in pressure situations, {snip} and dealing with distractions. {snip}

The edges gave us a competitive advantage but we could only produce these edges by providing individual feedback.

It is a fallacy of contemporary corporate management that if executives can treat the Talent as interchangeable meatware/widgets/work units, that it's mondo easier and less time-consuming (true) and just about as effective (GONG...FALSE). That fallacy is a classic, what I call Management by Wishful Thinking (MBWT) and in spite of the consistent negative feedback, the relative temporary comfort of minimizing managerial effort keeps the majority of North American executives going back to that black hole for productivity and effectiveness.

The product developers who packaged La Russa's ideas along with De Marco & Lister's into a "new" model they branded Agile know well -- as well as Baseball management -- that The Talent is the Product, and the only way to succeed outside the world of commodity mediocrity is Adaptive Planning and Adaptive Leadership -- that is, designing and executing work with the current and goal/end contexts in mind (just the way Baseball managers make staffing and tactical decisions based on the inning, the score and the individual aptitudes of each involved contributor) and treating each individual as an individual instead of a cog in a machine.

Agile owes this great, if unpublicized, debt to La Russa. There are 16 more to come.

He wasn't, however given the tribute he was due in general because he could be obstreperous and sometimes not effusive or reticent with the press, and the press, after all, determines a retiring manager's press coverage.

Specifically, though, no-one mentioned LaRussa's management techniques were one of the two bases of the Agile Development movement. It was ignored because the baseball press is pretty ignorant of contemporary software development models and the software development trade press is pretty ignorant of baseball managers (well, I think they're sometimes ignorant of the actualities of software development, too). Further, software development gurus tend to pretend the other, totally software-dev based source for Agile, the work of Tom DeMarco & Timothy Lister as summarised in their classic 1987 book Peopleware — Productive Projects and Teams wasn't a primary radix of Agile management.

But the time has come to explain his rôle in this business innovation, as he and co-author Rick Hummel explain in their recent book, One Last Strike: Fifty Years in Baseball, Ten and a Half Games Back, and One Final Championship Season. They don't address Agile Software Development directly, but if you read the (very cool) book, and then read the Agile Manifesto (it's not a Personifesto...all 17 signers were male), you'll see a direct path from the La Russa methods to the foundational management approaches of the Agile school. To remind you, the Agile Manifesto reads thusly:

• Individuals and interactions over processes and tools
  
  
• Working software over comprehensive documentation
  
  
• Customer collaboration over contract negotiation
  
  
• Responding to change over following a plan

The MANifesto also presented 12 Agile principles. They lifted two-thirds of those twelve directly from Baseball s.o.p.

Specifically, the eight are:

• Welcome changing requirements, even late in
  development. Agile processes harness change for
  the customer's competitive advantage.
  
• Business people and developers must work
  together daily throughout the project.
  
• Build projects around motivated individuals.
  Give them the environment and support they need,
  and trust them to get the job done.
  
• The most efficient and effective method of
  conveying information to and within a development
  team is face-to-face conversation.
  
• Agile processes promote sustainable development.
  The sponsors, developers, and users should be able
  to maintain a constant pace indefinitely.
  
• Continuous attention to technical excellence
  and good design enhances agility.
  
• The best architectures, requirements, and designs
  emerge from self-organizing teams.
  
• At regular intervals, the team reflects on how
  to become more effective, then tunes and adjusts
  its behavior accordingly.

The most advanced management techniques in industry are about three decades behind Baseball management. Smart management practitioners know they can blow away their competitors if they draw from Baseball, and the Agile MANifesto crew were clever enough to do this. I'm going to give you 17 examples in the coming weeks drawn from the La Russa book that will show you clearly how the Agile Manifesto dudes cloned La Russa's successes to sculpt their constellation of software development methods.