Wringing Necks

Re: Title. Sorry, its Friday the 13th, couldn't resist!

Anyhoo...I was checking out this InfoQ post which asks the question of whether you need a single person as your "Product Owner" or it can be many. I have my opinions about the answer to that particular question, but I'll save that for another post. It's the undercurrent of that question I want to discuss now.

"One neck to wring". "One throat to choke." I've heard this and similar statements for years in reference to Product Owners (in Scrum terms that is; in XP, we may say Customer). In other words, there are people who make the statement that part of the Product Owner's role is to be the "one throat to choke", the "one neck to wring".

My take on this is similar to my feeling on the "Chickens & Pigs" thing: me don't like it, and here's a quick run-through of why.

This euphemism, at its heart, is a statement of accountability. It basically implies that the Product Owner is accountable for the outcome of your agile project, for its successes and/or for its failures. Beh, hogwash.

Let's backtrack a tad (just can't help myself ;-). I'm a believer that there exists at least these two primary degrees of agile teams:

• Agile Team v1.0: practices have been installed and people are following their agile methods generally as the book tells them. They are following the mechanics, that is, but that's all. What's missing? Well, a real team. Agile Team 1.0 may not be a bad thing, it's likely to be a much better thing than to have no agile at all, but it's not the hyper-productive thing your executives were clamoring for.
• Agile Team v2.0: as with v1.0, the team is following the practices, but this team is a real team. In other words, the team is truly "self-organizing" and empowered. This team understands and manages the interpersonal aspects of good teamwork. This team truly understands that at root of success are people, and the interactions between them. This is the team that execs bought into [noun] "Agile" for; this team kicks ass.
  

Said another way, in Lencioni terms, the members of Agile Team 2.0 trust one another, engage in unfiltered conflict around ideas, commit to decisions and plans of actions, hold one another accountable for acting on those decisions, and focus on the achievement of collective results. Agile Team 1.0, on the other hand, does not do all of this.

Highlight: "...hold one another accountable...". There ya have it, Agile Team 2.0 is a team that shares its 'Accountability'. Each member is accountable; the developers, the testers, the CM folks, etc..., and finally, yes, the Product Owner (Customer) too. No "one neck", no "one throat", everyone.

Bottom line, if any one person holds the accountability for success/failure on your agile project, particularly if that one person is your Product Owner, you've got more to learn about how to be [adjective] agile, about how to be a team.

The good news is that you're not the best you can be, you've got room for some big improvement, how lucky!

Mi Code-ah, Su Code-ah

In one sentence, what does 'Collective Code Ownership' (CoCO) mean?

In the words of Kent Beck, it means "Anyone can change anything anytime".



Said another way:  There ain't no such thing as 'My code, your code'.  Them there is bad words, mi amigo.

And then, in many more sentences...

How many times have you been routed a defect that came out of your team but you had no idea how to address it because you "didn't code that part"? How many times have you been unable to take on a story because "Jerry's the only one who knows the business logic"? How many times have you been unable to proceed until you got approval from the person who "knows that code"? How many times have you had to leave a story on the shelf because the person who "owns that code" got wolfed for a few days (or "hit by a bus")? I could ask these questions forever but I'll stop there, I expect you get the point.

Thus, as one of the main practices that stems from the value of Collaboration, Collective Code Ownership aims to break those recurring enemies of productivity. It says that, certainly within at least a team, everyone owns all the code. Furthermore, everyone is free to...scratch that, everyone is responsible to be equipped to effectively make updates to absolutely whatever code their story takes them to -- without feeling like an intruder and without having to get "permission" or any non-casual advice from your so-called "expert" or "owner". From a more measurable POV, CoCO states that everyone on the team (developer-wise) must be able to describe the design of anything the team is working on in no more than 5 minutes.

So, why possibly might this not always happen? Well, I see at least a few reasons.

• First, it requires a very high level of collaboration and trust within a team, something that, unfortunately, isn't necessarily present "We've gone Agile! Day 1".
  
• Second, it might not absolutely require it, but a test-covered, well-factored, and expressive code base goes a very, very, very, very, very long way to making this work. Ok, I lied, it is required. And again, this is something that for many new teams is simply not the situation.
  
• Third, in many cases, particularly on bigger enterprise-y projects, it simply takes a good amount of work and an investment in time (which, of course, is money) to make this happen. Alas, to much dismay, its an investment that often ends up taking a back seat to "hittin' that next deadline".

And lastly, it takes courage. It takes being comfortable with stepping out of your "comfort zones" (pun intended) every now and again. It requires shifting your self-image from "I'm good at working on this code" to "I'm good at working on code".

Heck, isn't that why you became a programmer in the first place? You didn't start your days banging on the keyboard dreaming of being "the dude who knows the billing system inside & out", or "the keeper of the logging framework", or "the Hibernate guy" did ya? You loved code, programming, creating things, bringing new stuff to life, a real Doc Frankencoder. Tap back into that, set the inner geek free, you'll be happier for it.

And, you're in luck, the benefits do not stop there.

At a team level, having a collective code ownership implies more freedom to have people pick up the most important stories or tasks, independent of what part of the app they may affect. It allows you to focus more people on the next story, to have the team bum-rush it, get it started then completed quickly before moving onto the next most important story, which in the end is a better way to run your iteration than to "multi-thread" many concurrent stories.

Does this mean that your team will religiously have everyone working on everything, everyday?  Course not, even if that did make sense, it ain't physically possible (in this dimension).  But it does mean that you should switch up pairs periodically (preferably at least daily), and share a story's tasks amongst your pairs. Have pairs face each other and be in earshot, rather than nestled off in their own cubbies and corners.  Have team design pow-wows around the whiteboard and code reviews around the projector every couple days. Use your wall-space to document decisions and debate working designs.  Collectively own the problems, collectively own the decisions, collectively own the code.

And at an organizational level, Collective Code Ownership allows your teams to grow in a way that keeps up with the way your product matures.  Many applications will start their life having intense development needs in each of its various components, and logically teams will form around these components.  This may work initially (or it may not), but it comes with a natural tendency for silos of knowledge to form around the components, which will become problematic and counter-productive as the product matures and the user's needs shift away from "component-based enhancements" and more towards "application workflows" that span multiple components.

So, yes that's right, I'm saying that Collective Code Ownership in fact goes beyond "your team"; it applies as well to "your organization".   Do the same rules apply as within the team?  "Everyone codes everything everyday", "pair with everyone", "describe the design in 5 minutes", etc?  No, it doesn't necessarily mean that.  But it does mean that you should initiate mechanisms for people to periodically get a glimpse into what other teams are working on, both functionally and technically.  It does mean that you might need to let your teams re-assemble now and again to spread knowledge and prevent yicky silos.

And finally, most importantly and most simply, whether "your team" or not, Collective Code Ownership, more than anything, is a state-of-mind:  if you need to change some code, then damn it,  its yours to change - and that's all good!

* Check out also what we IXP'ers say officially about "Collective Ownership".

Where'd Jeff Probst go? (aka, Kicking someone off the island)

Yesterday I spent the better part of my morning reading through the 130 or so messages in the Scrum Dev Yahoo group's "Rotten Apple In Scrum Team" discussion, then I posted this "newsy" summary of the discussion on InfoQ.

In a nutshell, Marko told the group of a guy on his team he sees as a drastic "under-performer", or as he put it originally a "rotten apple", and asked for advice as to what to do with him. Read the InfoQ post to get a deeper sense for how people responded, but the gist of most of the advice was for Marko to take an open-minded and objective stab at finding out (and/or helping the team find out) what's really driving this person's performance, or, rather, lack thereof. And then to help him out.

"Try 'Beginners Mind'"..."take queue from Linda Rising"..."pair up with the guy"..."be nice, be helpful, be supportive"...and so on and so on. Hear this clearly (before I get to my real point of this post): I generally agree wholeheartedly with all the advice presented.

Now though, all that Dr. Jeckyll buildup for the Mr. Hyde thought: 130+ replies and not one mention of "kicking someone off the island"?

[...and the crowd gasps in horror...]

I've seen, and I'm sure you have too, a team who had an individual who truly did bring the team down. Typically not because they couldn't program quite as fast, or weren't quite as smart, or weren't quite as good in front of customers, or anything skill/experience/productivity-related like that. Rather, simply because they had a negative attitude, because they didn't play nicely or just plain didn't care.

[*Note: For what's worth, I do not think this applies to Marko's guy, but the discussion got me thinking anyway.]

One seriously under appreciated technique that I stress should be considered for these true "rotten apples" is to get them off your team, kick 'em off the damn island. No one says you have to fire them, just get them out of the way somehow.

Forget tools, intelligence, certifications, experience for a moment. The degree with which having a good team (in the "synergy" sense that is) contributes to good results (and, hell, a good time) is amazing; having a great team, well that's just indescribably astounding, magical even. Conversely, the degree with which having a bad team atmosphere can lead to serious bed-shatting, well, that's also quite amazing as well.

So if you've got someone who after the Prime Directive and the Beginner's Mind and the Pairing has still got that sour-puss face and, more importantly, is still killing your team's ju-ju, then by all means call the spade a spade, cut your losses, and remove them. Be as graceful as you like, but please, as Bo used to say, just do it.

Again I stress, I'm about as "glass half full" as they come - I'm not trying to encourage a general exclusive, head-chopping, "only the best" attitude. 95 times out of 100 your man intends the best and just needs a little love, and by all means you outta be doing your damnedest to facilitate that happening. My point is that for those other 5, stop being so P.C. and get the bad apple out of your basket. Your team's ju-ju will thank you for it.

** Update: Thanks to Esther Derby for shouting out about her related and more concretely useful post from some time ago echoing the same sentiment.