Lack of Team Authorization

Team authorization is at the heart of Scrum. Scrum provides TWO places where teams have substantial authority: The Sprint Planning meeting, and the Daily Scrum. Teams must believe they have authority over team life before they can self-organize. Without authority over team life, Scrum teams can never inflect to 2X, 3X, or 4X levels of productivity.

This post analyzes the levels of formal team authorization that Scrum defines for the Sprint Planning and Daily Scrum meetings. This post calls attention to how most problems in implementing Scrum are rooted in very low levels of team authorization.

Original date of note: 06/30/2010 by Dan Mezick

Background

I wrote the highly incendiary post on ‘Zombie Teams‘ some time ago. It caused a lot of people to say “Absolutely” and “hell ya!” This Zombie Teams post generated other feedback as well, some not quite so positive.

For the record, Jeff Sutherland is linking to that post, displaying it on his Scrum log. See it here.

This newer article and others like it are planned, to provide a bit more background on the dynamics of “team de-authorization”. The Zombie teams post may seem a bit “over the top” but serves to call attention to an essential aspect of good Scrum– which is, very strong support for team authorization.

Team authorization is at the heart of authentic and genuine Scrum. Please note that these insights are coming directly from my experience coaching Scrum teams in all kinds of organizations and situations.

The coaching work is providing experience to gain these insights and I am sharing them with you directly, here. Some of these insights seem obvious when you read them, but the reality is that the actual authority dynamics are often very subtle.

Read on.

Team Authorization 101

The typical problems in new Scrum implementations are derived from an ambiguous or otherwise troublesome lack of clarity about team authority. The main problem is a lack of sensitivity to Team Authorization.

Team must believe they have substantial authority to self-determine most aspects of team life. Scrum provides high levels of formal team authorization in two Scrum ceremonies: the Sprint planning meeting and the Daily Scrum.

Sprint Planning

In Sprint Planning, ONLY the team is authorized to fill the Sprint backlog. Note that while teams are authorized, behavior is constrained per the Scrum rules: the team must pull from the TOP of the Product Backlog. That fact is less important than the fact that only the TEAM is authorized to do this.

Here are some ways to undermine team authorization in the Sprint Planning meeting:

1. “ZONED PRIORITIZATION” GAMES BY PRODUCT OWNER. ‘Zoned’ prioritization of the Product Backlog by the Product Owner. Instead of unique priority numbers for each backlog item, have ‘groups’ that are listed as priority 1, priority 2, etc. For example, have 12 items labeled as “priority 1”, then another set of items labeled “Priority 2”. This is the same as telling the team what goes into the next two Sprints. This de-authorizes the team and leads to very weak Scrum.

Guidance: Counsel the Product Owner to stop telling the team what to do indirectly via Backlog Item priority zones. Explain that the team must pull from the top of the Product Backlog and that each item in it must have a unique priority number. Postpone the Sprint Planning meeting until and unless the PO complies with this request.

2. PRODUCT OWNER CAN FIRE TEAM MEMBERS and/or SCRUM MASTER. In addition to zoned prioritization, make sure the Product Owner cannot fire or otherwise influence the employment of team members or the Scrum Master.This de-authorizes the team and leads to weak Scrum.

Guidance: Be mindful that the team is not going to stick their necks out and tell the truth about how they feel if doing so might get them fired.

3. WEAK SCRUM MASTER PATTERNS. The Scrum Master is supposed to mediate and protect the team…from what? From the Product Owner, that’s what. If the Scrum Master does not understand this, other otherwise takes up the Scrum Master role in a weak way that does not protect the team, the team experiences “de-authorization” during Sprint Planning and learns to be quiet and do what they are told. Organizations that do not want to do authentic Scrum often exhibit a pattern of having temporary or not-too-knowledgeable Scrum Masters, or Scrum Masters who often can be fired by (“under the authority of”) the Product Owner.

Another scenario is a Product Owner showing up at the Sprint Planning meeting with a Product Backlog that is not in good shape. Now the weak Scrum Master sits idle as the PO attempts to push epics on the team, and succeeds. This is usually because the team and/or the Scrum Master can be fired by the Product Owner.

Guidance: Notice the weak-SM pattern and question and inspect the pattern. Ask: how is your organization actually exhibiting it? For example, is it expressed as a series of team members who occupy the Scrum Master role for 1 or 2 iterations each? Or is there some pre-existing authority relationship between the PO and SM, such as the PO being able to fire the SM? Examine the situation closely.

Daily Scrum

In the Daily Scrum, ONLY the team is authorized to speak. This is not strictly true since the Scrum Master is authorized to play referee, and can speak when the team is not following the rules of Scrum in the Daily Scrum meeting.

There are many ways to screw up the Daily Scrum. Let’s look at a few of these opportunities to derail Scrum team authorization during the Daily Scrum:

1. SCRUM MASTER ACTING AS PROJECT MANAGER. The Scrum Master is authorized to speak during the Daily Scrum when the team gets off-task. If the Scrum Master oversteps by speaking more frequently, the result is team de-authorization and a weakened Scrum implementation. The Daily Scrum is the team’s meeting. If the ScrumMaster oversteps, the result is weak team authorization and a weak Scrum implementation.

Guidance: Emphasize to the team that it owns this meeting and provide counsel to the Scrum Master to stay out of the way.

2. SCRUM MASTER IS ALSO A TEAM MEMBER. This causes all kinds of problems– in particular during the Daily Scrum. The dual-role over-authorizes this “team member” during the Daily Scrum and leads to all kinds of problems. When the person in dual-role (SM and team-member) speaks during this meeting, which role is actually speaking? This confuses the team about Scrum and weakens their sense of team authorization during the Daily Scrum. Note that the highest levels of team authorization provided by Scrum occur during the Daily Scrum. Period. Screwing with this teaches the team that they have low levels of effective team authorization.

Guidance: Avoid dual-role for the Scrum Master. If you must do this, carefully manage it by adding constraints to Scrum Master behavior IN ADDITION TO the constraints defined by Scrum.

3. WEAK BOUNDARY MANAGEMENT BY SCRUM MASTER, ESPECIALLY DURING THE DAILY SCRUM. The Daily Scrum is the team’s meeting. In reality, per the rules of Scrum, the Daily Scrum has three roles: team-member, Scrum Master and Observer. As a practical matter, if the CEO of the organization attends the Daily Scrum, they attend in Observer role. Observers may not speak during the Daily Scrum. This means the CEO is in fact de-authorized in that space and that time in his or her own organization!!

It is essential that everyone involved understands this.

If people with high levels of organizational authority are allowed to speak, that is in fact a corruption and diminution of the extremely high level of authorization Scrum defines for the team in this meeting. This meeting is the team’s, and is facilitated by the Scrum Master. If the boundary management from the Scrum Master is weak or non-existent during the Daily Scrum, the result is extremely low levels of team authorization and a “check out” on the part of team members. They become a Zombie team.

Guidance: Make sure all Scrum rules are adhered to during the Daily Scrum. Observers need to arrive on time, adhere to the rules, and exit upon the conclusion if the meeting. Is short, Observers need to honor the team.

4.SCRUM MASTER CAN FIRE TEAM MEMBERS. This is a cardinal sin in Scrum. The Scrummaster has formal authority to fire team members while also responsible for “protecting the team.”. This is a fundamental conflict and every team member knows it. If the SM can fire you, you are not saying anything difficult to say, that might get you fired.

In the real world, managers and project managers that have hire/fire authority become Scrum Masters…..this leads to profoundly weak Scrum.

Guidance: (direct from Jeff Sutherland by the way) … if there has to be a firing, the Scrum Master needs to ‘delegate it up’ to his or her boss. The SM should never fire a team member.

For hiring, make sure the team is consulted. Consider scheduling a team interview and/or including the team in the hiring or team-member-selection process in some otehr way. make sure the team BELIEVES they have some influence over the selection of new team members.

Summary Guidance:

High levels of team authorization are at the heart of genuine and authentic Scrum. Take care to notice that Scrum literally authorizes teams, formally, via rules for the Sprint Planning meeting and the Daily Scrum.

Scrum literally mandates formal authorization of the team via the Sprint Planning and Daily Scrum rules, Pay attention to this– and take care to avoid undermining authentic and genuine Scrum team authorization in any way.

***

About the Author

Dan Mezick: An expert on teams and a trusted adviser to CxO-level executives worldwide, Dan consults on enterprise-wide culture change, implementing Scrum, and the often difficult adoption of authentic Lean principles. Learn more about Dan Mezick here.

He creates and teaches specific, useful tools and techniques for facilitating successful enterprise-wide adoption of agile and Scrum. Dan’s articles on teams and organizational dynamics appear on InfoQ.com, ScrumAlliance.org, and AgileJournal.com. Learn more about Dan Mezick’s agile writing here.

He’s the organizer of the Agile Boston user group and a 3-time presenter at Agile2007, 2008 and 2009, an invited speaker to the Scrum Gathering (Orlando) in 2010 and a news reporter for InfoQ.com

Reach Dan at:

dan.mezick [at] newtechusa [dotcom]

You can learn much more detail about Dan via his Agile Coaching page here.

June 23, 2010 Meeting 630PM: Damon Poole on Kanban and Scrum.

MEETING VENUE: MICROSOFT offices in WALTHAM. REGISTER NOW for this meeting

DIRECTIONS TO MICROSOFT WALTHAM.

WEDNESDAY June 23 2010, 630PM

DAMON POOLE on: KANBAN and SCRUM

Damon Poole is Founder and CTO of AccuRev. Mr. Poole has eighteen years of software development methodology and process improvement experience spanning the gamut from small collocated teams to organizations with 10,000 globally distributed developers. In addition to Agile development, Mr. Poole specializes in software configuration management (SCM), lifecycle management and release management. He has spoken at numerous software development and Agile-related conferences, including SD Best Practices, Software Test & Performance, SCQAA, Q-Con, EclipseCon, Deep Lean, Agile Bazaar, and Agile 2008. He earned his BS in Computer Science at the University of Vermont in 1987.

Presentation: DAMON POOLE on KANBAN and SCRUM,”like chocolate and peanut butter”

KANBAN and SCRUM, Like Chocolate and Peanut Butter

You may have heard that Scrum and Kanban are mutually exclusive or that Kanban isn’t good for large software projects. In fact, much as Scrum and XP play well together, so do Scrum and Kanban.

This session will introduce Kanban from a Scrum perspective, show how the Lean practice of “One Piece Flow” is the key to both, and look at how to mix and match Scrum and Kanban to fine tune a process that fits your circumstances. This will include: decoupling once-per iteration activities from the iteration, work-in-progress limits, and the concept of “pull.”

005-26-2010 MEETING AGENDA:

6:30 PM: DAN MEZICK on “much more than SCRUM”

7:00 PM: Food & socializing & networking time

7:25 PM: DAMON POOLE on KANBAN and SCRUM

8:25 PM: SUMMARY AND CONCLUSION OF MEETING

REGISTER:

MEETING VENUE: MICROSOFT offices in WALTHAM. REGISTER NOW for this meeting

DIRECTIONS TO MICROSOFT WALTHAM.

NOTE: Please don’t register casually for this meeting, as you do us a big disservice to us by distorting the actual count for the seating and food. Registration is an explicit commitment to attend.

DIRECTIONS TO MICROSOFT WALTHAM.

The Chris Matts Interview (Part 02)

InfoQ interviews: Chris Matt

Chris Matts

Chris Matts is a very interesting member of the Agile community, and is based in the UK.

First, Chris is a proponent of ‘real options’ analysis, which is a quantitative method of decision making under uncertainty. His ideas on using real options in Agile practice appear on InfoQ. The first InfoQ article is “Real Options Underlie Agile Practice” and the second article is “Lean + Real Options = [Reduced Complexity]

Second, Chris seems to know and connect everyone in the Agile community.

Lastly and of some import: he is a truly prolific writer of provocative, in-depth commentary on many InfoQ articles.

Chris’ ideas on real options, the Agile Manifesto and more can be found at his blog: www.decision-coach.com.

Note: Chris collaborates actively with Olav Maassen to create the total content found at www.decision-coach.com.

Olav Maassen

NOTE: Part 01 is here
Chris, you talk quite a bit about “do not commit early unless you know why”…..can you explain this phrase?

Real Options are really about focusing on the timing of commitments. To achieve a goal, there are many ways to achieve the goal, each of these different ways is an option, a “real option”. And each option has an ‘expiration date and time’, a time after which it is no longer available as an option. In the real world, each option also has an ‘expiry condition’.

How about a very quick real-world example of this?

Imagine you are a building contractor with four builders. You are holding a party and are you want to build a swimming pool. It takes one person four weeks to build it, two people take two weeks and four people will take a week. The option to build it with one person expires four weeks before the party. The option to build it with two people expires two weeks before the party and four can build it in one week.

By deferring the commitment until a week before, you can decide not to build the pool if the party is cancelled up until a week before. However there is now the risk that one of the builders will be ill and you are not ready in time for the party. You have three options for building the pool, each expires at a different point with a different risk profile.

“Do not commit early unless you know why” means you do not chose in advance which of the three options to chose….. unless you have a reason which could be anything. For example, your four builders have nothing better to do this week. By starting now, they complete a task that you know you want doing and it means they will be free in the future when they may be needed.

This means the default behavior should not be to start now or as soon as possible. Instead, know when you should start. Too often we see people make emotional commitments and stick to their decisions even though we know there are now better options.

If you have the information you need to remove the uncertainty from the decision process, then you can commit early. For example, you decide to build a pool regardless of the party and you know your builders are free for the next two weeks and are going to be busy after that, then build the pool early.
You talk alot about ‘real options’ … to exercise an option, it is imperative that you know you have a choice. Is your message about real options (“choice”) resonating in the Agile community? If so, why so? If not, why not?

There are a growing number of individuals who use real options thinking. Its still a very small part of the Agile Community though. I can always tell when someone “gets it” when they apply it outside of IT. One friend used real options to organise their wedding. Another used real options to chose a school for their son. I love it to hear these kind of stories.

I think there are a number of reasons why real options have not really caught on.

1.People are put off by the name and think it is about clever financial mathematics. There is no maths in it at all.

2. A lot of people are disappointed when they come to a real options session. I think they expect fancy maths and stuff and when its not there. As a result, they dismiss.

3.Real Options is quite subtle. There are a few practices but mainly its a set of principles that you apply according to your situation. I tend to avoid speaking about the practices as I want people to think about the general principles rather than focus on the practices.

4.Real options are as much about psychology as anything. The way we make decisions is probably one of the core aspects of our personalities. It has a big impact on our behaviour. Asking people to change how they make decisions after an hour long presentation or after reading an article is a big ask.

5.People like certainty. They really dislike uncertainty. Real options asks them to embrace something they dislike.

6.Most importantly I am appallingly bad at explaining real options. I was working with them for a couple of years before I really discussed them much with anyone else. As such, the way I think about them is hard to explain. In other words, it is my fault they are not better understood.

What is the link between real options and group-level decision making? Isn’t choice in software development decision-making simply a capital allocation problem, where the capital is ‘developer attention and effort’ ??

Real Options are an information hungry decision process. A group of people have more information than an individual. As such, groups should be better at making decisions than an individuals as long as their goal is to make the best decision for the group rather than making the best decision for their personal benefit.

I use real options for the business investment decision process. However there are lots of decisions to be made on an it project. Architecture, choice of development tools, choice of developers. The trick is to get everyone on the team to bring the right information into the group in a timely manner. When we start talking about the timing of releasing information, or of withholding information, we are in the realms of game theory.

If everyone human being on the planet above age 18 has perfect understanding of real options as a tool for decision making, what does that world look like? Is it better or worse– and why?

Diversity is another way of saying options. Prejudice goes against the principle of making commitments early. We value options, so we would value people who are different. In effect, we would see an end to prejudice and war. I think the world would end up looking a bit like the world of “Diamond Age” by Neal Stephenson.

I think society is moving in that direction already.
What do you get out of your prolific InfoQ commenting habit? You are committing to an option early (you can comment on anything on InfoQ any time), so you must know why. Tell us why.

I get two things out of commenting on articles. One is a discussion about the subject which may reveal further information. The other is to signal to the readers that sometimes the article is discussing a subject that is not as cut and dried as people think. Occasionally you read an article and the tone indicates that the material is “best practice” or generally agreed. In reality the article is an opinion piece and a comment is a good way of indicating their are other opinions.

I think that most people read Infoq articles in the day or two after they are published. Although the articles stay around forever, most of the attention occurs in the first few days. Therefore if you want the best chance for a good discussion of the article you need to get in early otherwise people will not see your comment.

Lots of people know you and you seem to introduce people constantly at these conferences. Sometimes you challenge people in print and in conversation. One thing that is interesting is how you are interested in influencing the leaders by challenging their thinking respectfully from time to time with well-formed arguments. Why do you exercise this option?

The leaders of the Agile community are a constraint to learning. By removing them as constraints, learning will flow more easily. People will find the real leaders of Agile, the people doing it every day for a living who are struggling to solve their problems. Also, the close followers of leaders are voracious learners with the right risk attitude to try new ideas.

I’m not really interested in the queen, but rather in stealing her army of ants.

About the Author

Dan Mezick is an Agile coach and trainer focused on Scrum. He’s a 3-time presenter at Agile2007, 2008 and 2009 and an invited speaker to the Scrum Gathering (Orlando) in 2010. Dan’s company provides Scrum training and Agile coaching, counsel and guidance to executives, managers and teams. Learn more about Dan here.

The Chris Matts Interview (Part 01)

InfoQ interviews: Chris Matts

Chris Matts

Chris Matts is a very interesting member of the Agile community, and is based in the UK.

First, Chris is a proponent of ‘real options’ analysis, which is a quantitative method of decision making under uncertainty. His ideas on using real options in Agile practice appear on InfoQ. The first InfoQ article is “Real Options Underlie Agile Practice” and the second article is “Lean + Real Options = [Reduced Complexity]

Second, Chris seems to know and connect everyone in the Agile community.

Lastly and of some import: he is a truly prolific writer of provocative, in-depth commentary on many InfoQ articles.

Chris’ ideas on real options, the Agile Manifesto and more can be found at his blog: www.decision-coach.com.

Note: Chris collaborates actively with Olav Maassen to create the total content found at www.decision-coach.com.

Olav Maassen

OK Chris…what is the one thing you want the Agile community to know? Be specific and detailed.

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.

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.

So the worldwide Agile community started out as a “learning machine”?

Yes. I was lucky enough to attend the first two Agile Development Conferences in Salt Lake City. They were amazing learning experiences; I learned so much. In fact the first discussion on Real Options took place in an open space with a small group that included Steve Freeman, Eric Evans and Rebecca Wirfs-Brock. It was great to discuss my half-formed thoughts with a band of great minds who gave me a great deal to think about.

It was like a bunch of kids exchanging baseball cards, except instead of cards, they were exchanging ideas. The crowd was so confident in their abilities that they were able to take on the ideas and try them out, feeding the experience back through blogs and written experience reports.

Did you go to Denver in 2005?

I skipped Denver but to Agile 2006 in Minneapolis. What I saw dismayed me greatly. Bil Kleb ran an open space on “Cognition, Learning and the Scientific Method”. I presented my two favorite models, Kolb’s Model of Learning and the Conscious-Competence model to the group. I then mapped them to the Agile Community. Helen Sharp said something like “Oh my Goodness, Agile is a Learning Machine”. Unfortunately some of the behaviors I saw in Minneapolis worried me.

Which behaviors?

The world had changed since 2004 in Salt Lake City. The APLN had created the declaration of incoherence (which Tom Lister famously lampooned at the APLN summit). A leadership manifesto that famously omits the word “listen”. Agile was starting to become commercially successful…

..And?

…and, a lot of the great conversations that happened in Salt Lake City were no longer happening.

The commercial aspects meant that the “elders” of the community were sensibly focusing on generating business. People were just too busy to talk. We had discussions in the bar but open space was dying. People were starting to claim “thought leadership” in areas and unfortunately there wasn’t much listening. After all, how can you be a leader if you are listening to others?

What was the impact?

The impact of this is that experienced practitioners started to stay away from the conference. They now flit in and out but unless they need to be at the conference for commercial reasons, the people who go to learn, attend once or twice and then stop turning up. So the experienced practitioners are starting to stay away. I know a number of people who cannot be bothered to attend anymore because “there is nothing interesting happening in the Agile space”. The people who are confident enough to try new ideas are staying away.

In summary, the learning is slowing down and will stop…. or rather, find a new home. I realized that the reason I come to the Agile 200x conference is to meet up with friends… a holiday rather than training. Realizing that, I’ve decided to spend the week in which I would have been at Agile2010 with my family and friends on a beach somewhere.

Are you saying the Agile Alliance conference is less important, not just to you …but to everyone?

Meeting new people is always a huge pleasure at the Agile200x conference. The Agile Alliance has a simple task ahead. To create a conference that satisfies the commercial aspects of the Agile Community but also supports an on-going software learning machine. There is no “O” in “Agile”, but there is an “A”. The conference should be about “AND” rather than “OR”. Applying agile principles might help.


Why are you so passionate about this “learning machine” topic?

Software development is one of the most important industries of the 21st century. To date, it has been plagued by theory and opinion of academic thinkers who have taken us down dead end after dead end.

The Agile Learning Machine started out as an alternative that promoted practices that ACTUALLY WORK! Unfortunately since then we have seen quite a bit of theory and untested ideas make it into the mainstream as “thought leaders” come up with new innovations to show they are still at the cutting edge.

I earn my living in software development. I use Agile tools to make my life easier. They have made my life a lot easier. I would like to see the continuation of more ideas. Agile is not a destination, it a journey. As someone at Agile2008 said “Agile is a personal commitment to change as well as a corporate commitment to change”. ( I wish I could attribute the statement ).

What’s up with this comic book you put together on real options?

The “Real Options at Agile 2009” is not about project management or business analysis. It is manual for how to set up a group learning machine or a “distributed cognition system” as I refer to it. 😉

The Real Options at Agile2009 comic book.
If there is one thing in the world you can make happen, what is it and why?

I would like the world to understand that we stand on the eve of a glorious age. An age where everyone on the planet has access to food and information. A world where the restraint is not capital, but rather where the limit is our imagination.

A world where everyone has options, real options. 😉

Watch for Part 2 of the Chris Matts interview. It covers “early commitments”, choice, group-level decision-making, why Chris comments on InfoQ articles so frequently, and more.

Part 02 is here.

About the Author

Dan Mezick is an Agile coach and trainer focused on Scrum. He’s a 3-time presenter at Agile2007, 2008 and 2009 and an invited speaker to the Scrum Gathering (Orlando) in 2010. Dan’s company provides Scrum training and Agile coaching, counsel and guidance to executives, managers and teams. Learn more about Dan here.

Agile 2.0: What’s Next

There is clear evidence that Agile as we know it is completing a phase of growth, and beginning a new phase.

Some supporting data points in this observation include Alistair Cockburn’s Agile2009 keynote, “I Come to Bury Agile, Not to Praise It”, where he states:

<quote>

Agile software development was defined from small, colocated projects in the 1990s. It has since spread to large, distributed, commercial projects around the world, affecting the IEEE, the PMI, the SEI and the Department of Defense. Agile development now sits in a larger landscape and needs to be viewed accordingly.

</quote>

Forrester research printed a report recently, declaring Agile mainstream:

<quote>

Perhaps the clearest sign of the mainstreaming of Agile is the abandonment of orthodoxy: Teams are puzzling out the mix of methodologies and combining them to fit within their organizational realities, blending Agile and non-Agile techniques and practices to create a hybrid methodology that fits larger organizations. Other changes, such as new team dynamics and the redefinition of roles such as the business analyst, show the genuine force behind Agile adoption. It’s time for software development professionals to stop sitting on the fence where Agile is concerned. According to those who have successfully adopted Agile, the benefits are well worth the effort, and with the recent dramatic increase in Agile adoption, the probability of working in or with an Agile team has increased for everyone.

</quote>

InfoQ itself is reporting on this wider perception of mainstream Agile and what it means for organizations, sponsors, managers and teams.

So, if the consolidation and integration of elementary Agile practice is ending, that means something new is starting.

Does a new phase of innovation lie just ahead? If so, who are the new thought leaders? Where is the edge of the new Agile frontier?

One man to watch is Michael de la Maza, an agile coach and trainer from Boston with more than a PhD from MIT. Michael is researching controversial topics like intimacy in teams, and organizations. Blog posts like “Make Love, Not Money” describe how creating an extraordinary place for humans to work can generate just as much (if not more) profit than a traditional enterprise.

<quote>

Some folks in business are pursuing a strategy that is not taught in business school: The best way to maximize profit is to stop thinking about maximizing profit and, instead, to focus on treating people right. That is to say, the best way to make money is to focus on loving people.

</quote>

According to the thesis, the upside is that profit and human psychological health and wellness can co-exist and in fact must co-exist in the new, hyper-productive world that Agile innovators are actively working to create.

Agile Coach Michael de la Maza

At issue is how to organize work, such that the “extraordinary workplace” can be experienced and encourage teams to the sustainable-pace, hyper-productive “flow” state.

According to de la Maza, companies like Zappos get it right:

<quote>

Tony Hsieh of Zappos puts it this way: “Culture is our number one priority…Our whole belief is that if we get the culture right then a whole bunch of other stuff like building a brand…will happen naturally on its own.

</quote>

Another example, according to de la Maza, is Fog Creek Software. The company posts a philosophy of workplace design on the company web site.

<quote>

…Fog Creek Software is an egalitarian company. Most of our technical people have the title Member of Technical Staff and work independently or on self-managing teams. There is no middle management.

…Fog Creek serves lunch, free, to the entire staff every day

…the average Fog Creek developer has 694 square inches of screen real-estate, 2 desktop computers, and an Aeron chair. Most have private offices with windows and doors.

…Project Aardvark Blog In 2005, a team of four summer interns built the first version of Fog Creek Copilot from start to finish. By the end of the summer it had paying customers. A documentary about the process, Aardvark’d: Twelve Weeks with Geeks, is available in DVD format.

…Our Software Management Training Program (SMTP) offers mid-career professionals the opportunity to earn a Master’s in the Management of Technology while learning about the management of software companies from the inside.

</quote>

Another controversial blog post by de la Maza entitled ‘Touch‘ generated some interesting comments on the Scrum Alliance Google group site. In this post, he asserts:

<quote>

Humans love to touch and to be touched. Parents hold their children to comfort them. We hug people who are in pain.

In prison, one of the greatest punishment that can be meted out is to place a prisoner in solitary confinement. Solitary confinement does not involve any direct physical deprivation. The prisoner receives the same amount of food, sleep, and exercise. But he does not have human contact for almost the entire day. Studies show that this loss of touch has debilitating psychological effects which, in approximately one third of all cases, persist well after solitary confinement has ended and the prisoner has rejoined the general population.

</quote>

The de la Maza post on human touch sums up as follows:

<quote>

As agilists, one of our goals is to create environments in which trust, respect, communication, care, and love are in abundance. Touch is one of the most powerful ways to create such environments.

</quote>

This de la Maza post on touch has a summary video of about 4 minutes that clearly explains the ‘touch thesis’ and depicts a variety of touch exercises held during an Agile-related user-group meeting in Boston.

Many in the Agile community are skeptical at best. Consider this response on the Scrum Alliance Google group site:

<quote>

I’ve been thinking about this idea since you first floated it a few weeks back on the Scrum Collective list. It makes me uncomfortable,and I wasn’t sure why. But I think it is simply this. It is phony. I am a very physical person, and will spontaneously hug people I feel close with, or have an affinity with, yes, even in a work situation. But that comes from the heart, not from some exercise that tells me” hugging is good”.

</quote>

Where’s the confirmation from others that de la Maza might be correct?

The confirmation may be coming from no less an authority on teams than Sports Illustrated. The leading sports magazine is the world is now publishing articles on the deeper meaning and effects of the ‘high five’ and other forms of human touch in pro sports.

One in-depth Sports Illustrated article on this, literally entitled The Winning Touch, is especially telling. It supports de la Maza’s assertion that healthy human touch directly and immediately encourages team productivity:

<quote>

In a recent study with the daunting title, Tactile Communication, Cooperation and Performance: An Ethological Study of the NBA, to be published in the journal Emotion later this year, a team of researchers at Cal examined the effect of “touch” in the NBA. During the first two months of the 2008–09 season they observed 294 players, a sampling from all 30 teams, and tabulated how often and for how long each player touched teammates—touch being defined as any of 12 interactions, including high fives (by far the most common), head slaps and leaping shoulder bumps. The result? An impressive, if not surprising, correlation between smacking one’s teammate on the head and winning lots of games.

</quote>

According to established Agile thought leaders like Alistair Cockburn, the earlier phases of Agile adoption are probably now behind us.

In the new phase, previously unknown and all-new thought leaders address the edge of the Agile frontier, and bring a rich set of new ideas into the Agile thought space.

About the Author

Dan Mezick is an Agile coach and trainer focused on Scrum. He’s a 3-time presenter at Agile2007, 2008 and 2009 and an invited speaker to the Scrum Gathering (Orlando) in 2010. Dan’s company provides Scrum training and Agile coaching, counsel and guidance to executives, managers and teams. Learn more about Dan here.

Scrum Certification: The Dynamics of Authorization

Scrum certification is now very much in focus. The Scrum Alliance has authorized new certifications, and a new role called Creative Director.The new role is currently held by the outspoken Tobias Mayer. The new Scrum Alliance certifications include Certified Scrum Developer (CSD) and Certified Scrum Coach (CSC). The Scrum Alliance’s relatively new tagline, “Transforming the World or Work” symbolizes the very real changes taking place inside this credentialing organization.

These new credentials and new roles at the Scrum Alliance come on the heels of founder Ken Schwaber formally leaving the Scrum Alliance to create an all-new credentialing authority called Scrum.org. Ken Schwaber is a signatory of the Agile Manifesto and a noted authority on agile and Scrum.

The mission of Scrum.org as listed on the Scrum.Org web site is as follows:

<quote>

Scrum.org’s purpose is to improve the profession of software development so that we love our work and our customers love working with us and trust our integrity. To do so:

1. We maintain the consistency and integrity of the Scrum process.

2. We work with select partners to develop courseware and knowledge on how to use Scrum in various domains or work, such as risk management.

3. We work with trainers to learn and use the Program Development Partner courseware to help others learn how to build products using Scrum.

4. We work with Scrum users to help them incrementally improve their ability to use Scrum, including the application of self-assessments.

</quote>

Scrum certification is a hot topic, and getting even hotter with the development of new credentials by both the Scrum Alliance and the all-new Scrum.Org led by Ken Schwaber. (InfoQ articles on the emergent and ever-evolving nature of Scrum certification are listed below.)

Noted authorities in the agile/Scrum community are now engaging in active and often very heated discussions about the current and emerging dynamics of Scrum certifications.

Ron Jeffries, a signatory of the Agile Manifesto, is asserting with authority that Scrum certifications divide the community rather than unify it.

In a recent high-impact blog post entitled Scrum Alliance: Drop Certified ??, he asserts:

<quote>

It’s time for the Scrum Alliance to stop using the C word, “Certified”. It is holding us all back by dividing and diluting our impact on the world of work.

</quote>

Ron goes on to say:

<quote>

I’m writing this as a challenge to the Scrum Alliance (and scrum.org as well).

I’m challenging you people to drop the word “certified” from your offering. Figure out a revenue model based on delivering real value to people, not on extracting $50 for a PDF certificate, not on extracting many more dollars for a REP licence, not on extracting way more than that to be a “Certified” trainer. Base the value of the Scrum Alliance — and you, too, Ken — on making real people more successful and happier.

Yes, I know your hearts are good and the damage is low among the world at large. The damage from the C word is high, however, in the community that matters, the community of people who do this work.

It’s time to do the right thing. Stop using the C word.

</quote>

Mike Sutton, a UK-based Scrum coach and trainer, is the first comment, with a re-focus on community:

<quote>

Ron,

We should drop it if we think it is so tainted. But – I don’t. I think the agile community is railing against the level of rigour that is behind the C word, the ease of getting ‘Certified’ (effectively if you pay your money, you get certified) and the fact that there is no emphasis on continuous improvement – either by the need to recertify or the threat of decertification.

In many ways the Certification is not the issue. It masks the issue. We *all* want professionals (folk who are paid to do something) that are technically competent (in whatever they are paid to do), seek to continuously improve, know and constantly finding ways to collaborate, are passionate about doing great work and are mature enough to reflecton how they can achieve that. Some of that needs knowledge of process (agile) , but most of all it requires ongoing almost pastoral support of the individual by the community they are a part of.

Now that is the C word that we should be focusing on – Community.

</quote>

So far, so good. But it only takes a little while for a post like this to get the attention of Tobias Mayer. Tobias, a Scrum Alliance staffer, is compelled to weigh in on the debate. He responds with a delicate suggestion for Ron Jeffries..that he stop offering certified Scrum training:

<quote>

Ron, clearly you are opposed to Scrum certification, yet you say you ride the bandwagon to reap some of the benefits thereof. Perhaps that is what really needs to be addressed here. True change begins within oneself, not in other people, so “be the change you want to see in the world”.

You are an asset to the Scrum Trainer community, and I think almost without exception other trainers respect you, and value your contributions, but being a CST does NOT mean you must deliver CSM (and now CSD) training. The latter is a privilege of the former, but they are not bound. So practice what you preach in this post, and stop offering certificates with your training. Given your strong feelings on the matter it would seem the honorable thing to do.

And perhaps your example will encourage others to follow a similar path.

</quote>

A little later on, an outspoken blogger named John Sonmez weighs in. He makes the following comments and provides a link to heated and scathing rebuke of both Scrum.org and the Scrum Alliance:

<quote>

Ron,

Keep beating that drum. Right on. I agree whole-heartedly.
I just posted about the subject here: http://simpleprogrammer.com/2010/03/31/scrum-for-the-money/

I also agree about XP.

</quote>

This high-impact and authoritative blog post from Ron Jeffries entitled Scrum Alliance: Drop Certified ?? is now closed to comments. Many others posted comments to this hot blog post before comments closed, and the post certainly keeps the Scrum certification debate alive.

With the very real changes at Scrum Alliance and the advent of Ken Schwaber’s Scrum.org, the Scrum certification story is far from over … and in fact seems to be entering an entirely new phase of development.

Related InfoQ articles:

Is Scrum Certification Having Another Makeover?

http://www.infoq.com/news/2010/02/scrum-certification-makeover

Scrum Certification Test

http://www.infoq.com/news/2008/11/scrum-certification-test

About the Author

Dan Mezick is an Agile coach and trainer focused on Scrum. He’s a 3-time presenter at Agile2007, 2008 and 2009 and an invited speaker to the Scrum Gathering (Orlando) in 2010. Dan’s company provides Scrum training and Agile coaching, counsel and guidance to executives, managers and teams. Learn more about Dan here.

The Emerging Dynamics of Certification

Scrum and agile certification is now very much in focus. The ‘certification story’ is unfolding to become a major subject of debate in 2010. The story has several facets, with action from the Scrum Alliance, Scrum.org and the community-at-large, including notable bloggers and the Agile Skills Project.

At issue is the basic value of certification.

Skills Mind Map Fragment. from the AGILE SKILLS PROJECT

The story has several facets. The first facet is the recent blog post from Ron Jeffries asserting that certification divides the agile community. In that post, entitled Scrum Alliance: Drop Certified ??, he asserts:

<quote>

It’s time for the Scrum Alliance to stop using the C word, “Certified”. It is holding us all back by dividing and diluting our impact on the world of work.

</quote>

The full detail from InfoQ on the Ron Jeffries blog post can be viewed here.

The second facet of the certification story is the Scrum Alliance. The Scrum Alliance has authorized new certifications. The new Scrum Alliance certifications include Certified Scrum Developer (CSD) and Certified Scrum Coach (CSC). The Scrum Alliance’s relatively new tagline, “Transforming the World or Work” symbolizes the very real changes taking place inside this credentialing organization.

These new credentials at the Scrum Alliance come on the heels of founder Ken Schwaber formally leaving the Scrum Alliance to create an all-new credentialing authority called Scrum.org. Ken Schwaber is a signatory of the Agile Manifesto and a noted authority on agile and Scrum.

Thus the third facet of the certification story is the development of Scrum.org. The mission of Scrum.org as listed on the Scrum.Org web site is as follows:

<quote>

Scrum.org’s purpose is to improve the profession of software development so that we love our work and our customers love working with us and trust our integrity. To do so:

1. We maintain the consistency and integrity of the Scrum process.

2. We work with select partners to develop courseware and knowledge on how to use Scrum in various domains or work, such as risk management.

3. We work with trainers to learn and use the Program Development Partner courseware to help others learn how to build products using Scrum.

4. We work with Scrum users to help them incrementally improve their ability to use Scrum, including the application of self-assessments.

</quote>

Scrum certification is a hot topic, and getting even hotter with the development of new credentials by both the Scrum Alliance and the all-new Scrum.Org led by Ken Schwaber. Of particular interest is the fact that both organizations offer a Certified Scrum Developer (CSD) credential. The detail on the Scrum Alliance CSD can be found here while the Scrum.org CSD info can be found here.

A fourth facet, and perhaps the most interesting, is the emergence of the AgileSkillsProject at AgileSkillsProject.org. The organization describes itself as follows:

<quote>

The Agile Skills Project is a non-commercial resource that will establish a common baseline of the skills an Agile developer needs to have, including a shared vocabulary and understanding of fundamental practices. The Project intends to:

* Establish an evolving picture of the skills needed on Agile teams
* Encourage life-long continuous learning
* Establish a network of trust to help members find like-minded folk, and to identify new mentors in the community

</quote>

The Agile Skills Project (ASP) has direct connections to Ron Jeffries and several others who are notable in the agile community; see the full picture here on Ron Jeffries’ blog. InfoQ is carefully following and reporting on this story; see related InfoQ articles on the Agile Skills Project here and here.

What does the Agile Skills Project think about certification? One person involved in leadership of ASP is D.Andre Dhondt. In a recent email to InfoQ, Andre writes:

<quote>

“Following the recent flurry of blogs/tweets/etc. onCertifications (Robert Martin, Ron Jeffries, Chet Hendrickson,Tobias Mayer, Cory Foy, George Dinwiddie, Mike Sutton), I think it could be newsworthy to write an article about how certification really is just a red herring, as Sutton
suggests. The Agile Skills Project (ASP) doesn’t have an axe to grind here–it’s got no money, and doesn’t make a profit forrating/ranking/qualifying classes/certs/etc.

“The real, underlying problem is how do we get people hooked on lifetimeskills improvement? I think the answer is apoint-accumulating model in which people can show what they’redoing, be it paid courses or self-trained study. Dan Pink says motivation comes from autonomy-mastery-purpose. We givepeople autonomy in choosing whether they go for certs or not,read books, or go to conferences–but count it all as something that demonstrates progress, their way to mastery.We give purpose to the whole thing by making it community-owned…”

</quote>

One item of note regarding the Agile Skills Project is the ability of users of the ASP web site to post a personal “skills inventory”. This amounts to a chronological summary of professional development activities over time. See the sample skills inventory of D.Andre Dhondt here.

The ASP project is seeking community feedback on everything they are doing. The project is now an element of an new and emerging certification landscape for agile practitioners.

Related InfoQ articles:

Is Scrum Certification Having Another Makeover?

http://www.infoq.com/news/2010/02/scrum-certification-makeover

Scrum Certification Test

http://www.infoq.com/news/2008/11/scrum-certification-test

About the Author

Dan Mezick is an Agile coach and trainer focused on Scrum. He’s a 3-time presenter at Agile2007, 2008 and 2009 and an invited speaker to the Scrum Gathering (Orlando) in 2010. Dan’s company provides Scrum training and Agile coaching, counsel and guidance to executives, managers and teams. Learn more about Dan here.

Agile in the Mainstream

Mainstream agile is an idea whose time has some. Larger consulting services firms are now touting ” agility”. Firms like IBM Global Business Services and Cap Gemini are now pitching Agile-related service offerings. Offshore firms like Cognizant and ITC Infotech are active in the Agile software and services space.

Mainstream Trends

A quick scan of the online job sites shows a remarkable increase in the use of the term ‘agile’ in job descriptions. Here is a sample of the data changes in roughly one year, from the job sites Dice.com and Monster.com:

Term found in Job Listings Dice, July 2009 Dice, April 2010 Growth
Agile 2084 4088 96%
Scrum 755 1222 61%
Term found in Job Listing Monster, July 2009 Monster, April 2010 Growth
Agile 1756 3031 72%
Scrum 379 755 99%

Given this kind of sudden mainstream popularity, what does it mean for Agile in general?

What does ‘mainstream’ Agile look like? What’s in “mainstream” Agile?

Scrum is the most popular Agile framework. As such, it is a good focal point for discussing “mainstream Agile”.

So, what does ‘mainstream Scrum’ look like?

According to Martin Fowler of ThoughtWorks, “flaccid Scrum” is the new pandemic. The pattern has three steps and looks like this:

<quote>

* They want to use an agile process, and pick Scrum

* They adopt the Scrum practices, and maybe even the principles

* After a while progress is slow because the code base is a mess

</quote>

According to Fowler,

<quote>

…projects get into trouble for poor internal quality all the time, the fact that a lot crop up under Scrum’s flag may be more due to the fact that Scrum is so popular at the moment then anything particular to Scrum.

</quote>

Now here is where it gets interesting. He says:

<quote>

I always like to point out that it isn’t methodologies that succeed or fail, it’s teams that succeed or fail. Taking on a process can help a team raise it’s game, but in the end it’s the team that matters and carries the responsibility to do what works for them. I’m sure that the many Flaccid Scrum projects being run will harm Scrum’s reputation, and probably the broader agile reputation as well.

</quote>

Mainstream Meaning

What does this mean regarding the ‘mainstreaming’ of Agile? It means that Scrum as a term may become meaningless over time, as organizations who claim to be doing ‘Scrum’ are in fact doing something else, and callng it Scrum. Jeff Sutherland and Ken Schwaber have a name for it: they call it “Scrum-but”.

Fowler has a term for the “watering down” of a previously well-formed definition….he calls is Semantic Diffusion:

<quote>

Semantic diffusion occurs when you have a word that is coined a person or group, often with a pretty good definition, but then gets spread through the wider community in a way that weakens that definition. This weakening risks losing the definition entirely – and with it any usefulness to the term.

</quote>

In response to the trend, Ken Schwaber and Jeff Sutherland, co-creators of Scrum, have created a definitive and authoritative definition of Scrum, called the Scrum Guide. This freely downloadable resource describes Scrum. The document is intended to strengthen and sustain the Scrum definition. According to Ken Schwaber,

<quote>

Scrum has been used to develop complex products since the early 1990s. This paper describes how to use Scrum to build products.

</quote>

A excellent discussion of the Scrum definition appears on Dominique Stender’s blog post on Ken Schwaber’s “Confusion about Scrum”. In that post he echos Martin Fowler’s stand on ‘semantic diffusion:”

<quote>

I also agree with Ken that it is required to have one (!) formal description of what Scrum is. As [Ken] points out, in application Scrum is mixed up with other agile approaches such as Kanban, XP and others. This makes it important to have one (!) “master copy” of what is Scrum and what is not Scrum. A benchmark is required.

</quote>

Mainstream Agile: Of Products and Product Owners

The “mainstreaming” of Agile may mean that Scrum as defined by Ken Schwaber and Jeff Sutherland is even more polarizing than ever. Even as Agile goes mainstream, the co-creators of Scrum are in fact hardening the definition of Scrum. What is going on here?

Case in point: the current Scrum Guide states that the Product Owner is “always a single person, never a committee. ” Others in the blogosphere are talking tough now about Product Owner problems in Scrum implementations. For example Roman Pichler of InformIT writes in an article on Product Owner problems:

<quote>

A product owner committee is a group of product owners without anyone in charge of the overall product. There is no one person guiding the group, helping to create a common goal, and facilitating decision-making. A product owner committee is in danger of getting caught in endless meetings with conflicting interests and politics—something also referred to as “death by committee.” No real progress is achieved; people stop collaborating and start fighting each other.

Always ensure that there is one person in charge of the product, an overall or chief product owner who guides the other product owners and facilitates decision-making, including product backlog prioritization and release planning.

</quote>

The “mainstreaming of Agile” seems to be setting up a need for a very clear definition of terms.

The term ‘Scrum’ is being actively defined and sustained by Scrum’s founders, via the definitive Scrum Guide.

Conclusions? What the term ‘agile’ actually means is becoming more and more important, as Agile goes mainstream…..and subject to what Martin Fowler calls “Semantic Diffusion“.

About the Author

Dan Mezick is an Agile coach and trainer focused on Scrum. He’s a 3-time presenter at Agile2007, 2008 and 2009 and an invited speaker to the Scrum Gathering (Orlando) in 2010. Dan’s company provides Scrum training and Agile coaching, counsel and guidance to executives, managers and teams. Learn more about Dan here.

Scrum Gathering: Community of Practice

The agile community is developing concensus around three important areas of practice: requirements gathering, agile coaching, and open space formats for group learning. At the recent Scrum Gathering, these topics were prominent topics of discussion on Day 1, Day 2, and Day 3 of the event.

<image> guy on floor with postits, small image </image>

The first item of note is the very interesting talk given by Jeff Patton (http://agileproductdesign.com/) on ‘User Story Mapping’ at the Scrum Gathering recently in Orlando. This is a sense-making technique, where a facilitator guides a group into a sense-making exercise. The exercise requires a large wall (or floor space) and an ample supply of sticky notes.

The notes contain the bare minimum notes to recall a function or feature. Upon prompting by the facilitator, participants call out features, and function, and connections. The faciliator writes the note, and sticks it on the wall. A rows-and-columns arrangement emerges. Sometimes a row goes all the way around a wall. You can see examples and learn more here (http://www.agileproductdesign.com/presentations/user_story_mapping/index.html)

Once you have identified the notes, the facilitator sticks them on the wall in a rows-and-columns arrangement that naturally emerges. Once the notes are posted, participants come up and move them around as they make sense of the emerging application “in the large”. Participants stand back and ponder the developing organization of the notes, connected via proximity to each other.

<image> postits on wall, small image </image>

The emergence or organization and sense-making that develops via the User Story Mapping technique is striking. The facilitator does well to stop “well short” of supplying any advice or definitions of what is evolving, as the participants move the notes into self-styled rows and columns of organization.

The important thing to note here is that the resulting ‘User Story Map’ is a boundary object. A boundary object is a shared physical object that has unique and distinct meaning for each constituency that views or manipulates it. Thus a boundary object provides a kind of intersection where different points of view converge. As such, boundary objects facilitate sense-making across groups, teams, tribes, divisions, and organizations.

Another topic which is gathering some attention lately is that of Agile Coaching. Attention is now drawn to the importance of an Agile Coach, and some even consider coaching to be a cornerstone of an effective Agile practice and not merely something to bootstrap new Agile teams. Additionally, an Agile Coach can be of great benefit for those who have some experience, but are struggling with issues in their Agile implementations.

At the Scrum Gathering Open Space event in Orlando, Lyssa Adkins, author of the forthcoming Coaching Agile Teams from Addison Wesley, led out with a session on Agile Coaching Circles. Here the experienced and highly facilitative ‘master’ coach creates a space where a group of coaches share insights and experience.

Those who have experience with delivering coaching often mention the large amount of emotional energy that is discharged during coaching sessions. Especially during coach-faciliated retrospectives, the requirement that the coach relate to the group’s emotional state can require substantial emotional investment.

And the truth is that few if any people can relate to that experience. Having access to other coaches in a facilitated circle is at once remarkable and refreshing. Now coaches have a place where they can leverage the experience of others, recharge emotionally, and accelerate learning.

The concept of coaching circles is an interesting one, and Lyssa Adkins (at www.CoachingAgileTeams.com) is helping to drive adoption of this concept as one of the originators of the idea.

The last noteworthy item from Scrum Gathering concerns Open Space Technology. The Scrum Gathering in Orlando provided a unique experience in Open Space when it hosted an Open Space event facilitated by Harrison Owen, arguably the “Father of Open Space Technology”. Open Space is mainstream, and those who know how to leverage it (via facilitation skills) are in a great spot to influence culture and transformation inside the organizations that employ them.

Businesses are increasingly valuing facilitated meetings to keep them on-task and productive. As Agile goes mainstream,. with it comes a strong preference for facilitated meetings and facilitated group-level decision making. Proven facilitation skills are now in demand.

These are interesting times for organizations. We in the collective Agile space are in a spot to greatly influence culture inside teams as well as modern “tribes” and corporations. The Scrum Gathering recently held in Orlando provided a great opportunity to gain the skills necessary to become truly influential.

Dan Mezick is an Agile coach focused on Scrum. He’s a 3-time presenter at Agile2007, 2008 and 2009 and an invited speaker to the Scrum Gathering (Orlando) in 2010. Dan’s company provides Scrum training and Agile coaching, counsel and guidance to executives, managers and teams. Learn more about Dan here.

The “Command and Control” Military Gets Agile

Agility is a term that is gaining traction in some very unusual places. The military is suddenly taking Agility (big “A”) very seriously. The military defines Agility as “the ability to successfully respond to change”. The term “command and control” is used so commonly in the military that is abbreviated to “C2” in common usage. There is also a C2 Journal, a journal all about Command and Control. The C2 Journal has many articles on Agility recently.

Earlier this year, in March, a “Precis” was published by the Department of Defense Command and Control Research Center entitled The Agility Imperative. This document describes Agility as related to security and war. What is striking is the clarity of the language relative to software agility. Consider the following:

“Agile people conceive and approach the world and their assigned tasks differently from those who are less agile. In general, agile people have a propensity to seek improvements, are more willing to consider information that is at odds with preconceived notions, and are more willing to be different and take risks. These basic characteristics can be enhanced or suppressed by education, training, and culture. Unfortunately, many organizations, both large and small, suppress agility-enabling characteristics.”

The document from the C2 Research Center has much to say about people. For example:

“Often it is productive to focus on simply removing the obstacles to Agility. Just as an open and inquisitive mindset is an enabler of Agility, a closed and complacent mindset is an impediment.”

Those seeking clarity on the “command and control” vs. “Agile” debate are likely to enjoy examining the content at the Department of Defense Command and Control Research Center . For example, at this site, you can download a slide deck devoted to defining Agility in military terms. What is striking here is the near 100% overlap with descriptions of software development agility. Apparently, software development and war have much complexity in common: according to the Precis entitled “The Agile Emperative”, Agility applies anywhere there is a “Complex Endeavor” to deal with.

Does this sound familiar?

Information, Interactions, & Decisions in C2

Requisite Agility

Some definitions and concepts that apply to the military use of Agility might be useful in the software development world, especially as applied to large IT shops that are organized around the waterfall approach. One such concept is Requisite Agility. The paper The Agility Imperative defines “Requisite Agility” as a balanced level of Agility, a capital-allocation concept not generally discussed in the agile literature when addressing the mixing agile and traditional approaches.

“Agility is not an end unto itself. Therefore, Agility is not a capability that should be maximized. The capability to be agile (Agility Potential) and actual reactions to changes (Manifest Agility) both involve costs. These costs can be justified only by the nature of the challenge. The appropriate amount of Agility to seek, Requisite Agility, is a level that balances the costs of attaining it with the consequences of not having it, given the situation. Thus, Requisite Agility, not
unlimited Agility, should be the goal.”

Another interesting paper found inside the C2 Journal on the C2 Research Center site, Agility, Focus, and Convergence: The Future of Command and Control makes some points that can be applied directly to software development Agility:

“The word “control” is inappropriate…because it sends the wrong message. It implies that complex situations can be controlled…push the right levers; take this action or that; solve this problem. But this is a dangerous oversimplification. The best that one can do is to create a set of conditions that improves the probability that a desirable (rather than an undesirable) outcome will occur and to change the conditions when what is expected is not occurring. Control is in fact an emergent property, not an option to be selected.”

This C2 article goes on to say that ‘command and control’ is such a loaded term in the military that it limits perceptions and learning. Influential writers inside the military are working to change that language. The new suggested language uses Scrum values (Focus) and terminology from complexity science:

“Focus & Convergence is the term … to replace Command and Control…it captures the essential aspects of command
and control and can easily be understood by individuals without a prior knowledge of or experience with command and control. Furthermore, these words do not carry any preconceived notions of how to achieve these objectives. Focus as a replacement for command speaks directly to what command is meant to accomplish while being agnostic with respect to the existence of someone in charge or particular lines of authority. Similarly, convergence speaks directly to what control (the verb) is meant to achieve without asserting that control as a verb is possible or desirable. The combined term, Focus & Convergence, speaks to the existence of a set of dynamic interactions between the two functions.”

Another article on Agility in the C2 Journal, Agile Networking in Command and Control, focuses on how to incorporate “Agile C2” into modern military operations.

“Agile C2 … refers to the capability of a force to adjust to and manage changing operational conditions. Agility is seen as including robustness, resilience, responsiveness, flexibility, innovation, and adaptation in order to be effective…In order to achieve agility, it is required to have almost instant information sharing using robust networks, “self organizing” social structures for high responsiveness and fast feedback, and understanding of cause-and-effect relationships.”

In project management, we debate the relative merits of traditional Project Managers and Agile approaches. Here the military is doing something similiar, referring to “Agile Command and Control” while we refer to “Agile Project Managers”. It is interesting to note the parallels, especially in light of heated discussions on the PMI-Agile Yahoo Group about the validity of “Agile Project Manager” hybrids which incorporate aspects of waterfall and agile approaches.

The military is directly studying this dynamic of mixing traditional C2 with Agility. Consider this quote from The Agility Imperative:

“…understanding the consequences of the mixture of agile and non-agile people, in a variety of circumstances, is important. This is a topic being currently explored by DoD’s CCRP and its DoD and international partners.”

Those interested in articles and papers that address military Agility can search the C2 Research Center and quickly find resources such as papers, slide decks and web pages that cover Agility relative to traditional C2. The C2 Research Center is the place on the web where the best military minds are studying Agility relative to “Command and Control”. As such, it may be a great resource for those seeking to bridge Agility and traditional approaches.

Guys. Seriously.

The most amazing paper (perhaps ever) on Agility is referenced in this thread, have you seen it?

It lives at the Dept of Defense Command and Control Research Center.

http://www.dodccrp.org/files/Alberts_Agility_Imperative_Precis.pdf

Slide Deck defining Agility

http://www.google.com/custom?q=Agility&sa=Google+Search&domains=www.dodccrp.org&sitesearch=www.dodccrp.org

http://www.dodccrp.org/files/IC2J_v1n1_01_Alberts.pdf

The Future of Command and Control (C2 Journal)

The future of command and control is not Command and Control. In
fact, the term Command and Control has become a significant impediment
to progress.

“…our organizational structures and processes and, indeed, our approaches
to management, governance, and command and control, need to be re-examined
in the light of their ability to deal with an appropriate level of unpredictability.
Changes in our structures and approaches will be necessary to make them better
able to deal with the unfamiliar and unexpected.”

“Agility is the ability to successfully cope with change.”