…if you don’t keep your smartest people fully-informed, you’re going to wind up telling them what to do. And telling knowledge workers what to do is one of the biggest causes of mistakes, waste, and general low morale that I’ve ever seen.

I really like this quote from an article about letting employees take control of their time. The two points I got from the article were, one, that in order to make this work, you need to give your employees ownership of the success of the company and, two, that leadership needs to be completely open about everything and tell employees not only the what but the why.

These two points, plus the quote above, translate directly to development teams. One of the practices of an Agile project is group ownership of the code. So if one development pair sees a problem in the code, it is their responsibility to fix it and not ignore it because it is someone elses problem. If there are bugs in the code or a project fails, then responsibility for that is shared by the entire team, not just the developers that implemented it.

Transparency in business decisions can be seen in the use of story cards. I worked on one project were the “so that” part of story cards was missing. We were implementing bits of functionality and not adding business value. This lead to a lot of debates with business as to why we were implementing certain things.

As for telling people what to do, this one drives me crazy. One project I was on, story cards were placed on a wall and given out by the tech lead. Dev pairs were not able to sign up for stories. You could request a story, but it amounted to asking for permission to work on a particular story. You could not just pick up the next story without asking if it was okay to play it first.

People need to feel that they are trusted and once you give them that trust, they will surprise you. Trust them, give them ownership of the project they are working on and allow them to understand both the what and the why and you will amazed at what people create, because now they are not creating something for you they are creating something for themselves.

Why comments are evil?

This one I think I might understand to a degree. I agree with the idea that comments can very quickly get outdated and far removed from the code that they are suppose to comment. I also understand that if you write clean code then “what” comments are unnecessary. The thing I don’t understand is why this means that we should actively go through a code base and delete all comments? Or why we as developers should deride code that contains comments?

I personally think there is a place for “why” comments in a code base. I come across an odd bit of code, an odd business rule implementation, should I have to go and find the user story to find out why that particular odd decision was made? Or should I have a unit test explaining it: shouldDoThisBecauseIn1973BusinessMadeAOneOffDealWith...(). Where is the right place for this information to be captured? I would think that a story card would travel farther away from the code even faster then a comment.

Why design is evil?

This is probably my biggest pet peeve about Agile and the thing I really don’t understand. Why is design evil? We seem to have this idea that doing up front design before starting a story is not allowed. You cannot be doing XP if you do design, “design is waterfallish, we have organically grown code here.”

Personally, I think that in order to have well designed, clean, layered code, you need to do some design up front and you need some kind of architectural model to which your organically grown code adheres to. Otherwise, instead of lasagne, you get ravioli.

Why must you pair all the time?

I have already stated that I don’t really know how to pair and this is an outcome of that. I have heard of shops were if you are not pairing you are not coding. Heaven forbid that either you or your pair are ever sick. Are there no kinds of coding jobs that can be done by one person? Is there no benefit or place for a single programming sitting quietly in a room with the door closed focusing on a problem? What about all those studies that have been done about flow and the fact that open offices promote sickness and disease? What about a little privacy during the working day?

Why Agile principles become Agile rules?

This is the thing I don’t understand the most. Why is it that for many people and many shops, Agile principles become rules and the only way to do things? I have met people and worked in shops were they have Agile all figured out and any deviation is heresy. If you are doing Agile this one way, then you are unprofessional and a very bad programming. I always though that principles were just that principles, guidelines, starting points, rules of thumb. Things to be discussed, to be examined, and possibly bent or even broken when the situation calls for.

Isn’t one of the prime tenants of Agile the idea that we should analyze what we are currently doing and make it better. Doesn’t this mean things need to change? Or does it mean we are not disciplined enough in our adherence to one true path of Agile?

I only want you to tell the team what you think is valuable to them; what did you do or find yesterday that is of value sharing with the team; what do you know, that we need to know.

Ever since I was on a project where we were told to not talk about anything technical, I have always wondered about what is of value to the team. I am a developer, valuable things to me are usually technical and of no value, or interest, to the business people. Does this mean I should say nothing at my stand up?

At my current project, our stand ups have gotten very dry and boring. They have basically devolved into status meetings about we did yesterday. We then have a dev huddle around the story wall and actually discuss things of possible value. In reality, this is also just a status meeting where we give our current status to the tech lead. He goes through the stories and we say where we are and when we will be finished.

This has always bugged me. First because I don’t really like giving my status twice and second because it seems a tad redundant. Shouldn’t I be saying in my stand up what I would say in the dev huddle? Also, because the dev huddle has no real rules assigned to it, it can get quite long and boring.

Okay, back on track and enough with the complaining. I merely offer up the above as an example of my question about what the point of a stand up is and how does one decide what is appropriate to say and has value?

So, I would like some help. Hi, my name is Chris and I can’t pair.

There, I’ve said it. I have taken the first step and realized that I have a problem. Now if I could only figure out what the other 11 steps are to becoming a great pairer.

Here’s the thing, I keep hearing these stories about pairs who sit in front of a computer all day long, so much in the zone that they are able to right code telepathically. They never talk. They never argue. They never discuss and beautiful, simple code drips from the finger tips into the computer. Every line is surrounded by tests and their api’s will be studied from now to the end of time.

And then there’s me and my pair. I go to touch the keyboard and my pairs fingers are twitching above their keyboard like their life depends on entering one more line of code. I haven’t even written anything and they are correcting me.

So, I ask a simple question, “how do you pair”? How is it possible to work with someone so closely all day without stepping on each other’s toes and fighting about what it is that you are implementing?

I think my problem is that I am not an experienced developer (I’ve only been doing this for a few years compared to most of my pairs who have upwards of ten years under their belts) and I want to contribute something. I don’t really want to sit their and watch someone else type. However, the people I am pairing with don’t know how to pair either. They are used to sitting in front of a computer alone and banging out code.

And due to my inexperience and lack of pairing know how, I have no idea what to do?

This really rubbed me the wrong way. Agile is not about what works today, it is about making things better tomorrow. It is about identifying that little, or big, thing today that we can do just a little better tomorrow and implementing the change. If it works, we then find the next thing to improve and if it doesn’t work, then we try and figure out why and implemented the idea differently.

When it comes to the processes and practices we use everyday, “but it works fine now”, is simply unacceptable. It means that we have stopped moving forwards and have stagnated as a team. Regardless of how good things may seem, we always need to be asking how we can make thing better tomorrow.

I should have nothing to complain about, and yet, I do. However, I would like some feedback on my complaints. I think the team could be doing things better and would like some other opinions on a gripe that I have.

We have a practice of kicking off stories before a pair can begin work. This involves getting the BA, the producer (the business representative), the tech lead, the tester, and the rest of the team together to discuss a single story that a pair is about to work on. The reason that I have been given for this is that stories change too quickly and frequently and, therefore, cannot be reviewed any earlier then just before the pair begins work.

People are busy though, especially the business representative, and thge pair ends up sitting around waiting until everyone is available. A few of us have put forth the idea of doing a kickoff of all the stories committed to for an iteration during the iteration planning meeting. Then simply letting the pair work on the story when they get to it. If there are changes, it is the devs responsibility to read the story and discuss those changes with the BA and business. The conversation shouldn’t end just because everyone has done a kickoff.

Management, however, squashed this suggestion pretty quickly for the reason stated above. My take is that they don’t trust the devs to properly read and implemented the story. Which brings us to walk through.

Walk throughs happen after a story is dev complete and once again involves the BA, the producer, the tech lead, the tester, and the pair. Everyone goes through the story, dissecting it to ensure that it has been implemented correct. The pair cannot work on anything else until the walk through has been done. In the end, this means that the devs have to wait for everyone to be available.

The interesting thing is that even with all this scrutiny, I am not convinced that it results in any less bugs or better code. As far as I can tell, it simply wastes everyone’s time. The amazing thing is that the team continually votes to keep kickoffs and walk throughs as part of the process and adds things to make then either longer or harder to perform.

I can see value in each of these practices. Once you have completed a story, it is nice to have another pair of eyes take a look and double check that you haven’t missed anything. And before you start, it is important to have that conversation with the BA and business in order to clarify exactly what it is that they want. Both of these are vital parts of software development.

I think the part that bugs me is the lack of trust that is implied by the way the two practices are carried out. I feel that as a dev I am assumed guilty until proven otherwise. Until I can repeat back to the BA and producer what is written in the story, I am deemed not worthy to begin work on it. Likewise, until the business, BA, and tech lead have all signed off on a story, it is deemed incomplete simply because it was implemented by a developer. Or I could be reading to much into things.

Other devs have also commented on the lack of trust they feel due to these two practices, so I don’t think it is just me. But how do you go about changing this kind of culture? And is it even worth changing? It gets frustrating when these issues come up in retro and either management simply says no or the rest of the team votes to make them even more complicated and time consuming. I am not sure how to change an entire teams mind, especially when it seems to most people that it is working fine.

Initially, Mutt was not going to be a part of the album and the result was that Def Leppard were constantly faltering and second guessing themselves. They produced some great bits of music, but they were unable to pull everything together into either a song or an album. In the end, Mutt came back and they produced an album that debuted at number 1 on the charts and eventually sold 16 times Platinum (according to wikipedia).

So what is the point of all this? Well, I have been wondering about the need or role of a “producer” in a software development team. One thing that set Mutt Lange apart was that not only did he understand, capture, and carry the vision of the kind of album Def Leppard wanted to produce, he also pushed the band members to be the best they could and then go a little further.

I personally think every software development team needs someone like this. A team needs a leader who understands the technical aspects of things and is able to look at a snippet of code and see the possibilities and then push, guide, and direct the team to meet those possibilities. A team needs someone who looks at code after every check in and pushes the team to produce the best code possible. A team also needs someone who carries the vision for the software and only allows ideas through that conform to that vision. This ensures that code falling outside of the vision is removed.

Traditionally, I guess this role would be the architect, however, lately, most architects don’t code; they simply produce nice little pictures that don’t mean much. So perhaps this role should fall to the technical lead. My last project, the tech lead definitely fulfilled this role (thanks, Tim). It was a great learning experience. It was not possible to cut corners or leave out a refactoring because I knew my tech lead would spot it and say something. This pushed me to take more time and ensure my code was the best it could be.

I am currently on a project where no one really fulfills this role and I can definitely see a difference. I think the team suffers and the code suffers. The tech leads spend most of their time either in meetings or taking care of fringe problems instead of taking care of their teams and the code they produce.

With all that being said, there is one caveat to this discussion. Def Leppard went through two different producers before Mutt Lange returned. I don’t think just anyone can do the job of “producer” on a technical team. The team needs someone who cares about code quality, who understands and investigates new technologies and ideas, who has real experience to back up what he is thinking, and who has the ability to really bring the best out of people. and maybe that is the problem, there are simply not enough Mutt Langes in the world of software development.

The last client I worked with had a factory style, compartmentalized view of software. They spent months working on the design and when they thought they had it right, they sliced it up into small components and farmed them out to the lowest bidder. When it came time to integrate those pieces back together, they were stunned when they didn’t fit and the application refused to run. Six teams then spent months fixing everything up to release a very fragile, but working, product.

Part of the problem was that they tried to implement and solve too much too quickly (well, in combination with the whole lowest bidder thing). The final application basically implemented the same thing four times. Instead of solving the problem for one product line and implementing a working, stable solution then moving on to the next product line, they did all four at once.

Moving this idea forward to two-pizza teams, I have a fear that companies could do the same thing. One trick to making small teams work is how you divide the problem. Each team, and thus each problem, needs to be completely atomic. Therefore, no two teams are implementing the same ideas.

If you have an application that does basically the same thing across multiple product lines, have a single team do the initial vertical implementation (i.e., end to end across all integration points). Once the initial implementation is completed and working, other teams can then build upon it sequentially, implementing the remaining product lines upon a proven solution. This will also provide business value back to the company earlier rather then later and give the user’s something to test.

I think the best way of dealing with this is to be constantly breaking up teams and not letting any team work on more then one problem together. As soon as a team has solved their problem, that team is disbanded and the team members move on to new groups. This way, you maximize knowledge sharing and allow everyone to learn about what that team did.

I use Google’s Gmail client. I have not opened a desktop email app in about a year. I originally made the switch because I was using several different computers and traveling a lot. Using Gmail allowed me to send and received email wherever I was on whatever computer I was using. The downside to this convenience is that I do not have a local backup of all my emails. A problem that is easily fixed for email, but not so easily done for things like calendars and news readers.

In addition to Gmail, I use — 37signals’ Backpack and Highrise, Google reader, and Google Calendar. The data in the apps is not as easily replicated without entering it twice.

The last area I have been thinking about is online backups. I have looked at two companies; Mozy.com (I am trying their free account now) and ElephantDrive.com. Both have very attractive plans at reasonable rates. The upside is that they provide offsite backup which is good to have. The downside is that if I ever loose my data locally, I may have to download 50 Gigs of data one file at a time. It almost makes more sense to buy a terabyte drive, fill it up, and store it in a bank vault.

The question I would like to pose is what do people think, do you use online applications or do you put all your data on your computer? In this age of online computing, does it makes sense to have all your data online, or is there still a place for desktop email clients and news readers?

1. Blog a minimum of once a week.
2. Resurrect my TeamDocs open source project and bring it to a 1.0 release
3. Create and release my first Ruby on Rails project

I am also going to manage these three goals as one would manage projects. I am not sure if I am going to use Basecamp or some other software. For TeamDocs, I will probably use the space on Google Code. This means I will be updating the website and checking in new code in the very near future.

As for the third project, more information on that will come. I am not sure if I am going to make it open source or try to release a hosted web application.

I took a look back at 2007 and realized that I had not really accomplished anything. In a nutshell, 2007 was mostly a brain-dead year for me. I made the mistake of relying on all my learning coming from work. Although I have learned lots of things little of it was technical. Instead, most of it was people or soft-skills. This was a mistake on my part; no one should ever rely on their work as their sole source for learning.