Gummball’s BodyBlog

I finished this book weeks ago, and I’ve been struggling to get started on the book report.  Sure, I can crank out a few pages regurgitating paraphrased snippets of what I’ve read, examples of tribal leadership I’ve seen in my life, or whatever, but that’s so boring to me (and I’d imagine it would be to you too).  You read the book already; you know what it says.  I think book reports should be just as useful for the person reading them as the person writing them, so droning on about specific examples of what I’ve seen in my past when I worked in restaurants, attended college, etc. (which I’ll probably never see again, and I know most who read this will never see at all) wasn’t sitting well with me.  Then, this past Friday, I was hit with a useful, relevant, real-world application of tribal leadership, thanks to an e-mail from Kelly.  The intersection of Agile development with Tribal Leadership:  A Wolf in Sheep’s Clothing, or a Pig Dressed Up in Chicken Drag – however you’d like to look at it.

As we implement Agile development in our organization, we are naturally experiencing some growing pains, as would be expected any time a major process overhaul is being adopted.  These are confounded with the effects of a solid but still relatively new staff, lingering communication issues within and between functional teams (namely Developers and Product Owners), and the ever-present naysayers who arguably think, through actions (not admissions), that Agile won’t work.  In the history of organizations using Agile approaches to develop products, software, or anything else, one constant seems to shine true:  Agile only works if it is followed to the letter.  In light of that, the team of Scrum Masters, whose primary goal is ensuring the process of Agile itself is impeccable, recently proposed us, the Product Owners, with a proposition.  In the traditional Agile model, the Product Owners act as a resource to the team rather than an integral member of the team, meaning specifically that Product Owners are present in the Daily Scrums only to listen to the team and to clarify any issues they have, but Product Owners are “chickens” in that we aren’t committed to daily tasks and, therefore, shouldn’t be proactively speaking in our Daily Scrums (brief, 15-minute status meetings for the team).

As I was reading through the original e-mail, I immediately began thinking of the implications to the organization as a whole.  That’s when the idea for this report hit me.  We are an organization which believes strongly in empowering employees to do the best job possible, and much of that empowerment comes from the sharing of information.  The leaders which “naturally emerge,” as coined in Tribal Leadership, seem to be those who do just that – share information freely for the greater good of the team, often forsaking personal acclamation in the process (at least on the surface).  These leaders, which the book obviously refers to as Stage IV (or V) leaders, are those under which true progress and innovation will be experienced:  “We are great, and they are not.”  They are markedly different from those at Stage III, who tend to be the information-hoarders, communication blockers, and “I” mode operators, often seeking personal victories:  “I am great, and you are not.”

The other key difference in Stage III and Stage IV / V individuals is the manner in which relationships are formed.  I won’t go into tremendous detail, since the book explains it far better than I could, but suffice it to say that Stage III leaders concentrate on creating one-to-one, or dyadic, relationships, whereas Stage IV leaders concentrate on more group relationships (defined as having 3 or more members).  The key difference is that the Stage III individual manages relationships that way so that s/he can be the “expert,” the one with the contacts, and the hub for all communication which will need to take place between team members (so as to always be in the know, in the power, so to speak).  The Stage IV leader, on the other hand, matches people together so they can help one another.  S/he is, by definition, more effective, as decisions can be made without the Stage IV leader’s OK (since empowerment was given).

The “traditional” Agile development model, which has been proven time and time again to dramatically increase production efficiency, tries to break down communication between the Product Owner and the team of Developers, indicating the proper communication channel should the Product Owner need to communicate something to the team (on a daily basis) is to communicate those needs to the Scrum Master, who will then disseminate the information.  In Agile terms, the Product Owner is a “chicken,” since s/he is not “committed” (to use another Agile term) to the process itself, and the Scrum Master and Developers are the “pigs.”  Under that model, the Product Owner and Scrum Master have a Stage III relationship, with the PO having the opportunity to release or withhold information as s/he sees fit and the Scrum Master having the same opportunity (not saying that would ever happen in our organization, but it is possible).  The Product Owner also has little or no relationship or rapport with the Developers themselves.  After continuing this dyadic relationship daily for long enough, it is very likely that a Stage IV Scrum Master or Product Owner will regress into a Stage III mindset, where “I have all of the information,”  “I have the sole and absolute power to control this group,”  and “If they want anything done, they have to come to me” (obviously mixing some Scrum Master and Product Owner mentalities together there).

The alternative approach to Agile, which is presently up for debate at Bodybuilding.com, is to integrate the Product Owner into the team WITH the Scrum Master and Developers, allowing open communication and free sharing of information.  This allows the Product Owner to interact directly and proactively with the Developers, both in the Daily Scrums and at any point throughout the day, without the filter of a Scrum Master (though the Product Owner is still not responsible for the daily direction of the team).  In Agile terms, the Product Owner now becomes “committed,” or is a “pig” on the team, which makes sense since it’s the Product Owner’s neck if the team doesn’t accomplish that to which they’ve committed.  The liberal sharing of information and the manner in which relationships are constructed (teams vs. dyads) indicate this is a more Stage-IV-friendly approach to Agile.

So what is the problem?  Put the keyboard down, quit-yer-bitchin, and just do the latter?  Not so fast.  Recall the earlier statement – “Agile only works if it is followed to the letter.”  To deviate from Agile, even in a simple way, runs the risk of the entire Agile system’s failure.  Another consideration (from Tribal Leadership) is the progression of individuals through the stages.  Recall Stage II – “My life sucks because . . .”  These individuals are bound by grief, do the minimum to get by, and are always seeking out excuses.  An individual can’t leapfrog Stage III.  In order for a Stage II individual to get to Stage IV, s/he must first go through the third stage, believing s/he is great and everyone else is not.  How can you think “we” are great, when “we” includes “you,” if you don’t think “you” are great?  You can’t, reinforcing the natural progression through the stages.  I have not yet worked with the teams enough to identify where I think each team member is in terms of tribal stages, but I would imagine there is a possibility of a few lingering Stage II’s.  If that’s the case, maybe the first approach, though potentially dangerous, is the more reasonable one.

In the end, all we can do is evaluate everyone on our teams.  Off the cuff, I really don’t believe we have any Scrum Masters or Product Owners who are at Stage II.  If we identify some Stage II Developers, we have one of two choices.  We can go with Option #1 (PO=Chicken), but we MUST ensure both the Product Owner and Scrum Master are strong enough as Stage IV leaders to not regress back to Stage III.  Otherwise, the entire business will suffer.  The alternative is to go with Option #2 (PO=Pig).  The probability of this approach failing rises with the level of “comfort” and depth of the individuals being at Stage II, reiterating the need for us to carefully evaluate all team members to determine where each is in his/her tribal progression.

An alternative which hasn’t been discussed is a hybrid of the two, namely that the PO remains involved as a Stage IV leader (or a “Pig”), but that those individuals on the team identified as being Stage II are given personal attention, probably by the Scrum Master, and slowly elevated to the Stage III status.  This is, of course, assuming we have Stage II people on the Sprint teams, which is still unknown (yet doubtful).  All possibilities must be considered, though.

In closing, nobody wants failure.  Bodybuilding.com doesn’t discourage individual greatness, but it does encourage group greatness even more.  One thing is for certain.  No process, regardless of how much it improves efficiency, throughput, or any other workbook metric I could throw out there, is worth changing our core values and working as a Stage IV organization aspiring continually to be at Stage V.  I feel safe saying, without asking my comrades,  that we as Bodybuilding.com leaders would all agree with that.  I can say that with such certainty because we DO have such open, transparent communication, and everyone knows the values of everyone else.  We are truly a Stage IV organization.