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!

{"X} + {"Y"} = {"X", "Y"}

Adding 2 Java arrays in 4 lines.

First, and foremost, do your damndest to avoid the use of primitives. If you're in the 21st century anyway, we have higher level languages and those languages have objects and, hot damn, let you make objects - so use them!!!

Be assured you'll hear more from me on that front for a long time to come. Anyhoo though...

This quick post is about when you, for one legit reason or another, do have to work with primitive Java arrays. As in "String[]" array, not "ArrayList<String>".

Today, Gil and I had to and were quite miffed to find there was no easy built in way to combine to existing arrays. Once the disgust was gone enough to type again, we coded a little utility to do it.

So, here's what we ended up with:

public static String[] arrayAdd(String[] one, String[] two) {
 String[] newArray = new String[one.length + two.length];
 System.arraycopy(one, 0, newArray, 0, one.length);
 System.arraycopy(two, 0, newArray, one.length, two.length);
 return newArray;
}

Do note please that this creates a third array which is thus returned (as opposed to actually changing the state of either one of the input arrays).

If you've got better suggestions (libraries, whatever), shout em out. Otherwise, enjoy.

And, yes, of course, we do have a test for that!

ps// can't help it.  To reassert my initial point, "resist your primitive obsession", using a List (object), of course, you get:

public static List<String> listAdd(List<String> one, List<String> two) {
 List<String> newList = new ArrayList<String>();
 newList.addAll(one);
 newList.addAll(two);
 return newList;
}

..and then of course if you don't want a new collection instance:

 one.addAll(two);

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".