Agile was always something you could be before it was a particular process you could do. And it was always possible for a team to line up in a tight formation and move together in mutual support toward a goal. Teams performed scrum behaviors long before there was the proper name, Scrum, and long before there were any specified Scrum roles and terminology or any particular Scrum-prescribed deeds to be done.

Just ask the Romans.

So before there was Agile, there was agility, and before there was Scrum, there were teams living and breathing scrumish essence. It is good to remember this. Beginning in 1992, I was part of just such an agile, scrumish team, the original Visual C++ team at Microsoft, a truly great software team that pioneered many of the ways a software team could show actual agility. The number and extent of this team’s accomplishments are staggering, and have been pretty thoroughly documented elsewhere by me and others. No real history of software development processes and/or teamwork can safely ignore a team that was surely among the most agile of all commercial software teams.

In a period of about four years, this team, using specific agility-demanding-and-exploiting techniques, coalesced almost like magic and went on – in a sequence of increasingly impressive product releases – to reduce its previously victorious competition to a memory, and to set business, technical, and process standards that define key aspects of the programming and general software development environment in which we live and create today. Take this team’s standard behaviors, add pair programming, a pinch of nomenclature, and voila! You have the fundament of today’s most desired project practices as defined by Agile, which first appeared in the next decade.

It is natural and fitting therefore that such winning practices eventually become a type of orthodoxy, that their characteristics become normative, and that technology evolve to embody tools supporting these best practices. That such technology can be found in Visual Studio is doubly fitting (and personally satisfying), given its heritage. That Visual Studio should proffer such technology also provides a certain nice self-referential quality and a pleasing reminder of the larger fractal reality in which software development always takes place.
The present volume promises to elucidate for the reader the ways and means of conducting the prevailing best practices using the prevailing technology. It is time, and past time for such a book, describing such a reality. Its publication marks a particular moment in the evolution of things: when technique and technology have aligned in time.
The current moment is one wherein a technology is synergistically both created by and creates a technique. In this case, Scrum and Agile (techniques) create and henceforward co-evolve with TFS and Visual Studio (technologies).

So it shall likely be; as it is ever so.

It is commonplace to observe that things go faster and faster. Thirty five years ago, there was essentially nothing to program except a few ungainly huge and hugely limited machines. And twenty years ago, there was no way to program all the things there were with any sort of predictable result. Today, I think it can be safely stated, that if you carefully follow the advice in this book, and if you connect with the rational energy or the results-oriented spirit of the technical culture that gave rise to – and lies behind – Agile, Scrum, and TFS, you will be able to deliver software of a desired degree of stability at a desired time and at the anticipated expense.

But please notice that – historically speaking – it is only just now that we can reliably develop software. That we can now do so will have profound impact on our world. We can expect even greater technical change than heretofore, and soon, and ever sooner still as time progresses. While our burgeoning technical culture is more a nascence than a Renaissance, there is no reason to expect that it will be of any less import. There is every reason to expect that it will be global, deeply unifying, and promotional of the freedom of information and people.

Since software is basically the codification and distribution of intelligence, and we can now do more and more of it, faster and better, what happens next? Now that we can generate software at will, and, using practices like Scrum and technology like TFS, we can deliver it more or less as desired. What, then, shall we do with this brand new, unlimited and unimaginably great power? What civilization shall we build? What intelligence shall we distribute?

These are the questions to ask an agile team, and to ask only an agile team, because only such a team can reasonably even consider the questions. When they gather up, when they scrum, when they charge down field together toward a goal in a mutually supportive way, a goal they will therefore surely reach, just what goal is worth hitting? What world do they choose to build?

What is your vision?

Master the lessons in and around this book, and then answer that question in what you create.

Jim McCarthy
Woodinville, WA
2011

michele

 No, the title isn’t a typo. It is worth considering the difference between assigned leadership and true leadership and how the two interact in a variety of environments.

 Since the Core Protocols, as used in BootCamp, provide for dynamic leadership behaviour from any team member, the issue of the boss/manager/leader role can be a sticky one.

 Particularly before one attends a BootCamp session and learns the Commitments and Protocols in the Core.

 Particularly for the boss!

 To look at this issue, I find it helpful to be more precise and explicit about the use of the term “leader.” We often use the word to mean a role in a hierarchy and also to mean a behaviour with particular outcomes.

 For example, in BootCamp, the bosses in the simulation play the role of a leader in a hierarchy, in that they assemble the team, hire consultants to help, provide the team the assignment, and monitor the progress and quality of the product. At the same time, anyone on the team can behave as a leader by, for instance, proposing a course of action in a Decider (the protocol used by Booted Teams to make unanimous team decisions), which the team decides to follow or not.

 So the first is a leader position in an organizational chart sense; the second is dynamic, changing, emergent behaviour.

 Some bosses may see true leadership in employees and fear that this means their “organizational” leadership role is threatened. And not surprisingly, there is often resistance to this idea in the form of organizational position protection: “I declare myself the team leader,” or “I have been appointed the team leader,” (and am going to protect my position and resist being declared unnecessary). This resistance is usually supported by those who report to the organizational leader, since in most organizations, teams want and wait for the boss to tell them what to do. Or at least are expected to – by the bosses!

 When an intact team attends BootCamp together, it is ideal to have the organizational leader present. This allows organizationally assigned leaders to realize that they can simultaneously lead and get help in leadership from those who work for them. The benefits become immediately apparent: the bosses can now spend more energy working upward and outward because they are getting lots of help from their team in areas such as developing and improving the vision, ideas, product quality, etc. It’s like getting the same paycheque and becoming much more effective without having to do as much work.

 The hard part can sometimes be convincing the boss to accept the benefits of increased leadership behaviours from employees. To adjust, bosses usually have to practice learning to listen well, getting out of the way of emerging leadership behaviour, and holding employees accountable to the responsibilities and accountabilities of the Core Commitments.

 Maximizing the leadership behaviours on a team is ideal: Consider the possibilities of the untapped leadership potential on your team if the assigned leaders and all the team members were meeting their leadership potential together right now as a team.

Paul Reeves: With his partner in all things, Vickie Gray, Paul enjoys his four children, four grandchildren, flying his Challenger ultralight, his motorcycle, sailing, singing, dancing, and all of the galaxy’s blessings. Simultaneously Paul operates Business Improvement Results to provide consulting and training in the use of best practices for Teamwork (the Core Protocols), and for Information Technology Service Management (the ITIL Framework). He is particularly fascinated by the emergent leadership behaviours and creative activities seen in the ongoing laboratory for the best practices in teamwork behaviours known as BootCamp.

michele

The Core Dimension

When folks talk about whether Agile, or XP, or any other working method is as good as or better than the Core, they’ve lost the plot.  One isn’t “good” or not, compared to another. The Core is in a different class entirely.

 Most methods are tools of control. They try to externally control one or more of features, time and cost, on the assumption that “great” and “on time” are mutually exclusive. Instead, the Core Protocols starts with the assumption that you must, and can, have both “on time” and “great” and that external control is not only not necessary, but wasteful, distracting to team members, and only successful coincidentally.

 The Core asks the team to get real about the common root cause of the disappointments we have all had with our method or framework of choice: the basic human behaviours of the team using the method. In most work environments we fight, procrastinate, lie to ourselves and others, and the only solution we have found to this mess of delinquency in the past 200 years is control.

 Most team-based methods start with the assumption that left to themselves, humans in groups will descend into chaos before lunch.  Therefore, the method itself and roles like project manager or process owner must control, guide, measure and direct this unpredictable human collection called the team to save both themselves and the investment before it’s too late.

 Instead, the Core gives the team universally useful tools (protocols) that help navigate most of the usual team landmines. It then assumes that once the team is functional with the protocols, individuals will be intelligent enough to use those tools effectively and adaptively as required without external control.

 So, if it is effective for an individual to work alone, or in a group, or with one other person, to seek innovation, or follow another’s lead, that team member is assumed to be capable of accurately assessing the situation and making the right choice.

 Further, the Core trumps external control with the much more rigorous and immediate mutual accountability and commitment of team members to each other. Team leads and project managers, a source of waste and distraction on a self-organized team, may be replaced by adaptive shared leadership and holding each other accountable.

 When you have a team in a state of shared vision, with high bandwidth communication and adaptive to the complexity of their environment using the most effective exchanges then any tool, whether software, methods, frameworks or equipment, becomes a potentially useful tool.

 That’s because a great team will get the most out of anything you give them. What you will get is great not because of the tool but because of the team. A great team could make a great product out of shoelaces and a pop can.

 Take away the manager, team lead or facilitator holding the remote control. The team will adapt to the lack of external control and rapidly shift to what is interesting, useful, innovative and fun. They will naturally dampen the patterns of drama, dependence, fighting, lack of accountability, and poor communication and instead amplify the patterns of productivity, passion, innovation and effectiveness.

 Doing so simply makes more sense and brings meaning to their…our…work.  So to get the most out of any method, framework, tools, infrastructure, skills, and resources, a team using the Core is your best first investment.

Vickie Gray is an organizational tree-shaker, complexity-hunter, idea-generation-machine, teamwork lab rat, coach, and Human Systems Dynamics Professional. She is a veteran of 15 years of frameworks, methodologies, management science and similar faith healing. She can be reached at www.adaptivecoach.com

This post is about that cliché. It bothers me. It always has. So, I spent some time thinking about why it bothers me.

1. First, I think a CEO of a major corporation should expect people to do things that he himself will not do. That’s what he pays them for.
2. If Schultz decides to do something unreasonable like never take vacations or work 60 hour weeks or not ask for help, does this implicit agreement with his employees mean they are expected to conform to his irrational behavior? In other words, if he does something dumb, does he get to expect that the people who work for him do the dumb thing too?
3. It bothers me that such an experienced CEO defaults to such overused clichés in company meetings. Does he think about what he says when addressing the thousands of people who work for him? Or does he just go through the motions? And ditto for any other “leader” who has used this cliché.
4. It bothers me that what people are really saying when they use this phrase is “I’m going to ask you to do things that are hard, but since I do them or would be willing to do them, I expect you to do them too.” I would prefer to hear that  (although I think it is not a great idea) instead of the indirect version.

I can imagine myself at some point asking or expecting that employees do as I do. But the cases I can think of would be very specific.

1. I would ask particular people who follow me (those who I know want what I want and are of high potential) to reach their potential. So, I would ask that while I work to reach my potential, I would ask the same of some followers.
2. There are many people who I can imagine leading who I wouldn’t ask to do what I do. They don’t do what I do. They have a different value system, perform a wholly different type of work, or have limited involvement in what I want.

I guess what I am saying is that there are some people who I “would ask from them what I ask of myself.” However, this would be only a certain type of person in a certain relationship to me and my expectations would be at a very high level. Furthermore, if I did ask these people to do as I do, I would just ask directly. I wouldn’t make a blanket statement to everyone with ambiguous meaning.

H. Schultz: “I won’t ask….”

M. McCarthy: “Ok, don’t”

A second New York story can be found at http://www.cbsnews.com/stories/2011/03/10/60minutes/main20041733.shtml

A New York charter school is focusing on GREAT teachers. The hypothesis is that if you get the most talented teachers, you will get the best results in the classroom. One of the many conventions this school breaks is tenure. Tenure is rejected as a reasonable method for employing teachers. Hallelujah. Tenure seems outdated to me in the worst way (To me, tenure smells of aristocracy. However I am not familiar with the history of tenure, so I don’t know if the two are linked.), and it is refreshing to see “experts” saying this on network television. Another convention the principal of the charter school breaks is firing. He readily fires those teachers who are not delivering great results. I think all corporations could learn a lesson from the story of this school and the principal’s determination to get the greatest players on his team through recruiting, firing, and appropriate salaries. For those who use the Core Protocols, you will notice the awareness of the ideas of “greatness” and “mediocrity” and how he uses these terms consistently to create messages about what he is working to accomplish.

michele

Soon, the humanity of the humans involved intruded on my naivete. The time came to re-form our team for this year and I got a mail from the captain saying that nobody would play on our team except a few of us, not enough to make a team. At first I wanted to fight. I wanted to fix whatever was wrong. I found out that many of the women who had been on my team were a clique at the tennis club, and that I was not aware of their cliqueishness (par for the course for me). In their mean girls spirit, they decided that the captain was “bad” and they would start their own team (this is another interesting topic, authority issues, and a second interesting topic, the power of norms in groups). I really like the captain. She has always been a good friend to me and fair as a captain.

Anyway, I wanted to fix the mess, and instead I decided to accept it. I accepted that the other women on the team were acting irrationally, and that that was ok. Instead of fixing it, I simply sent the captain a letter that said “I will do whatever you do. I’m with you.” If she found a new team for us, fine. If she got enough people to make a team, fine. If she combined with another broken team, fine. If she went to another club, fine. If we didn’t get to play this year, fine.

And a beautiful thing happened. We were both offered spots on the other club team right away. We were also offered spots on a team at another club that had the following rules:

1. Food, fun, compete, in that order
2. No crazy people on our team (I had always wanted a rule like this and thought it was impossible to find such a team)
3. If you have an issue with someone on the team you talk to them directly, (no cliques, no gossip)

So, I’ve been practicing on the new team with the GREAT vision and it is really nice. And I believe that it is a gift to me for being accepting instead of resisting.

michele