Friday, January 28, 2011

It's a common thread in agile transitions that people are not sure what pairing, teamwork, and self-organization will do to their status on the team. Will the team be so leveled that nobody will stand out? Will the weak be exposed and humiliated? I am going to write this as if there were two states, strong and weak. Before reading anything that follows, remember that everyone is good in some areas and weaker in others. I have seen javascript gurus who weren't very database-smart, and people who were great with requirements and product knowledge but had no sense of scalability or performance. Any human characteristics are spectra, not point measurements. With that in always in mind, read on:

There is good news, more good news, and some hard and potentially sad news in all of this. The first bit of good news is that nobody who works in an agile team ever asks these questions. In reality, it's not a problem. Let's get down to cases.

Rockstars

If you are the rock star of the team now, you will find that pairing will give you mentoring and teaching opportunities and respect that you've never had before. Invariably, a great programmer on any team (whether outgoing or quiet) becomes revered by the team. If you have the skills alone, you have the skills paired too. I've not seen any great programmers fall through the cracks. Sometimes a pair mismatch may be uncomfortable for a while, but you can elevate the skills of your teammate. Imagine what it is like when all the members of the team will listen and will up their game. You will find it is much cooler to be a revered member of a competent team than to be the high-and-mighty member of a mediocre team. You have nothing to lose and everything to win.

Bob Anderson named a strategy "Attack The Weak" (tongue-in-cheek), in which the strong member of a team intentionally selects a less-established or less-experienced partner on purpose, as a teaching and sharing opportunity. This is a good strategy, provided the strong member is nurturing and not dictating. The point is to raise the partner's skill level, not to expose them as weak. Not every pairing has to be of this form, but several a week is a good idea.

Growing Developers

If you are the weakest player on the team, you will find that pairing gives you an opportunity to learn from your teammates. In addition, as the partner shares the keyboard and ensures that you're doing test-first work, you will find that it's harder to make a mistake that gets through to integration (let alone release). You have a safer working/learning environment.

In a strategy I call "eat the rich", you choose a partner who knows something you want to understand better. That partner may be a tester, a UI expert, a performance expert, the local ruby guru, or someone who really deeply groks the platform. By pairing with them a few times a week, you add their skills to your own.

The Borg Collective

A common fear is that everyone will be assimilated, and the entire team becomes an amorphous mass of fungible "resources", that the strong and the weak will be indistinguishable, and that morale will collapse. Some fear that incompetent developers will be able to hide in the team and drag down efforts, or that brilliant developers will be unrecognized.

The fact is that people are different, and are drawn to different aspects of the work. We can all get better at everything, but some things will speak to us more deeply than others. As a result, we will have special strengths and weaknesses.

When you work entirely in pairs, everyone who works with you will get to know you. While it makes no sense to recognize and reward individual efforts in a team (thereby creating competition and sabotaging the team effort), there is no question in anyone's mind who the strong and weak players are. This information is best kept within the team, but there is no question. In a 360-degree review, the strong team players will be recognized. Think how great it would be if your coworkers were the ones who promoted you, because you have helped them improve and they respect the skills.

This is where the potentially sad part comes in. Some people cannot program well, but do it anyway. If an initially weak player shows potential and improvement, everybody is happy to see them grow and change. Sadly, some people don't get any better. If they don't take advantage of the team-learning and remain weak and unskilled, they will demoralize the team. Nobody wants to be hand-holding and nose-wiping and babysitting all the time. If someone is a continual drag on the team, and doesn't improve, and doesn't show any signs of potential, everybody on the team knows that too. In order to protect the team's morale and productivity, teammates may "vote him off the island" by asking their scrum master or project manager to consider counseling that person into a position more suited to their skills, even if that means another company. This is sad to the one who has to leave, but can actually improve the morale of the team. It is doubly sad if the one asked to leave has an inflated self-image and thinks himself a rock star. On an agile team, though, it should never be a surprise to be asked to leave.

School for Deserters

The other concern is that people will improve their marketability as developers. After all, they've had months of self-improvement and now can put the big A word on their resume ("agile", not what you are thinking) so now they could command a higher salary if they leave.

Okay, fair cop. You will suddenly have a team of developers that are the envy of the other companies in your area. Competitors and neighbors will start to take notice, and may extend some recruitment feelers into your team.

Think about the mixed blessing here: You have the team that everyone wishes they had. If you want to look at this as a problem, go ahead. Might you have to hand out some bonuses or raises based on the performance of the team? You might, but don't you want to have a team that is deserving of recognition and reward? Isn't that better than the alternatives?

Conclusion

Yes, when you become a true agile team, the teamwork does eliminate individual rankings in a traditional way. You can't say who completed a piece of work because the team did it (perhaps every single member had a hand in it), so old individual rewards are hard to give. Worse, individual rewards can break down a team if they create competition between the members, since competition can stymie free and open sharing of skills. On the other hand, peer respect is more to be coveted and can be measured.

Even if there were no way to reward people for being great team members and mentors, imagine how much more pleasant it would be to work with a team of capable, motivated partners instead of a mixed bag of people who don't really have the on-the-job opportunity to up their game in a meaningful way. It's an exciting thought.

All members of a team can grow and teach and develop in an agile pairing environment, and this makes the company stronger as well. It will fly in the face of some classic motivational schemes, but Agile is a little counter-intuitive that way.

This week I made some social networking advancements and started to build a few other new skills.

The first is Tweet Feed which is likely responsible for you seeing this short article. I am not going to have to hand-tweet the AgileInAFlash or AgileOtter articles because they're auto-tweeted for me.

The second is that blogger's admin screens let me turn on the social button bar after each article, so readers may more easily promote anything they find interesting or outrageous. It's a small thing, but already I've seen a new tweet from the page. It's a very small thing, but sometimes small things matter.

I'm on ohloh now. My friend Sam Hart has prodded me a bit, and I finally realized he's right (it takes me a while sometimes) and I should take some credit for the work I've done in the public space, like the PDK. I never realized that I was the check-in leader there. Sam wants me to pick it up and make it a living project again, and I'm thinking he may be right. Mind you, I am a little more interested in the DITS concept, but I have opportunities.

A big social breakthrough is that I realized that taking the train downtown isn't as bad as I made it out to be. Now that I'm moved a bit south and am near a station on a different line, it's just $12.00 for the round trip and it's a bit over an hour each way. This is important because all my peers in the agile community are downtown and I could benefit much from being connected with the local community. It will help with the Talent Agency idea as well as Agile In A Flash, and we all know how iron sharpens iron.

I have entered the world of video production. I really am NOT great at it, but I made some progress in the video realm. I am now a fan of dead-simple transcoding front ends. Arista has been handy for me. While Open Shot is still my editor, I don't always get new content into the right format and size for media sites. I used Arista and encoded for iPod, and it turns out to be totally viewable by mac and windows users (the poor saps) in addition to more enlightened Ubuntu users (1/2 grin).

I ended up putting opening and closing title images on the "Deal" video, and put a drum track at the beginning and end. I still don't know anything about making interesting videos or screencasts, but I suppose that's the future. It's a way to connect, and connecting is good.

I also started with Django all over again. I've read a bit more of the book (on the train) and re-did the "Django for the impatient" and am getting to a point where I can more easily dig into the unit testing problems. I just needed some backgrounding. I've been invited to play in a nice open source project in Django, so I have a wealth of options.

I also am looking at a few good opportunities for my next gig. There is so much to learn, and so many good people to work for, it is an embarrassing wealth of options. Will I be Agile Otter or Django Otter next month?

Monday, January 24, 2011

I have our first video finished. Notice how my face never appeared. I'm going to have to get used to hearing my voice on these, maybe I'll do the full-frontal face thing in one of the future videos. Either way, we now have a commercial that explains what this whole Agile In A Flash thing is about.

Thursday, January 20, 2011

I have played with Django, but never really did any work in it. Even my toy app died before I got to a "good working model" state with it, because I did not maintain focus and wandered off too much. Since then I've developed a keen interest in learning more web technology, and so this time is Django Charge 2.0.

I visited some very nice, very smart people this week to took me into their offices and showed me some of their Django code. We started to talk about testing, and I made a small abortive attempt to do some plain-old-unit-testing in their python code base. It was not all that I hoped it would be (Dean, please revert that code if you haven't already). I ran out of time to play, but hopefully will be back to enjoy some pair programming goodness in the near future.

The cool and interesting bit about Django testing is that testing through manage.py will have you standing up an instance of the app complete with database. The setup is fairly onerous, but the tests run quite quickly. I think a lot of good integration testing can be done this way, but I wanted to do proper unit testing, where "proper" means that I do not stand up an application instance, don't use the database, and all of my unit tests (even when there are 20K of them) will run in less than 45 seconds. This becomes hard because Django's object mapper is in the DNA of django model objects. I guess I'll end up designing around that limitation, hopefully without my head exploding.

The other complication is the virtualenv. We definitely want to run the tests in the virtual environment, but don't want to launch a shell instance to do it. I'd like to autonose this, or better yet hook it into pyCharm and/or eclipse pyDev. It shouldn't be much of a problem... worse case should be launching the tool inside the virtualenv.

I'm not interested in doctest. I have a long-standing phobia against the use of magic comments. They offend my sense of how things should work. I'll be doing unittest (unless I succumb to pressure to write my own framework).

Today I begin my new hobby. I'll follow up here with links to interesting Django unit test links, and probably little discoveries. I'm not going to rush to solution, but try in code-camp style to work perfectly instead. It will be fun.

Today the deck is released for purchase. I'm getting tweets and messages from people who have either purchased the eBook or placed an order for decks. Thanks to everyone for their support in our crazy little project. So far many retailers are selling.

Wednesday, January 19, 2011

The one thing I haven't said about my time as a remote pair programmer is that remote pair programming is a brilliant idea and it matters. The reason I didn't mention it there was because that was work. This is personal development.

We improve our skills and our exposure in the world by pairing with more people. I've been a shy guy, not always jumping into the pairing sessions at conferences, and I'm the poorer for it. I could have been soaking up mojo from the greats instead of hiding out.

But remote pairing? You are not in front of a whole bunch of strangers who are potentially judging you. You're in a one-on-one situation with someone you couldn't have visited personally due to any number of travel constraints. It's just the two of you and your headphones. You can work on your code, or the other guy's code, and it doesn't matter. It can be 6am or 2am or noon on a saturday, any time your schedules just happen to coincide.

This is something I think we need to foster. We need a good system for hooking up eager remote pair partners with their peers, betters, and rising stars all over the world. Imagine how much good we could do if it were possible to pop onto some web site (a software talent agency?) and hook up with Ward Cunningham or Andy Hunt or Corey Haines for a couple of hours after dinner. It's not just name-brand acts either -- there are thousands of programmers who could teach me or learn from me in a session (maybe both). We could form up community that spans the globs, one or two time zones at a time.

The problem is that remote pairing tools all suck really bad or cost money.

Because remote pairing really matters, we need to all jump in the pool. We need to be filing reports for the likes of Yuuguu and WebEx and GoToMeeting or any other company with competence. We need a few open source projects to do screen-sharing or edit-session-sharing. Eclipse needs better sharing, though they've got an interesting start.

This is all solvable stuff. The technical side could be made to work. We just have to put ourselves into it. If we can solve the pairing technical problems, the remote partner exchange idea is just a simple python or ruby script away.

Wouldn't you enjoy jumping into someone else's code on the weekend or in the evenings. Wouldn't it be fun to put the next patch into some great OS project if you had a guide and peer to join you? Wouldn't you love to have good working relationships with hundreds of people who could recommend you for interesting jobs and projects around the country (or the world)?

Remote pairing matters, and it may be the way we all move the trade forward. It's a brilliant idea, and we need to support those who are out front, solving the big problems.

Saturday, January 15, 2011

Being a telecommuter or remote team member is considered a pretty sweet deal and is recognized as a more "green" way of working. Remotes don't share illnesses with their teammates, and yet work when ill. Remotes don't participate in office gossip or struggle with personalities the way locals can. The perceived problem with remotes is that they are unmanaged (in fact, they are impossible to micro-manage effectively). The actual problem with remotes is that they can be disconnected.

The solution to the perceived and real problem seems to be in the sweet spot of remote pairing. I was lucky enough to work for a few years as a remote pair-partner. As a remote, I worked common hours just as my peers did. I joined them in the morning, took lunch when they did, and worked until they went home in the evening. We spend most of the day on-camera together (or at least in voice via headsets), sharing the screen and development tools, writing tests and code, exploring technical problems, and building solutions.

It is not the "remote developer concept" that many have in mind. I worked from my home, but did not make my own hours. I did not go to an office by day, but also did not work for myself. I could not take arbitrary days off as self-employed or many work-from-home people often do. It worked well for me and for my employer.

We found a pretty sweet combination by using Skype for voice and video, git for version control, and Webex to do screen sharing. The latency for webex is surprisingly low, and suited our needs very nicely. I set up a netbook with a built-in camera for skype so the company laptop's CPUs could be fully devoted to programing and screen-sharing (so necessary when using cpu-hungry development tools). An Asus EEEPC netbook is under US$300 most places, and mine really does a great job. I have had a few headsets. They're inexpensive, but they also tend to get uncomfortable after a few hours, so I would definitely try several. I used a few logitech models and was more-or-less satisfied.

The other useful tools for a remote pair partner? I second monitor (a large one) and synergy. Synergy allows one keyboard and mouse to be used by multiple computers. It is easy to setup and use, and allowed me to switch between netbook and work notebook very easily. I found myself mousing among three screens attached to two computers, and never thinking twice about it. It all just became transparent.

If your organization is interested in using remote teammates, I cannot over-recommend the combination of WebEx, Skype, Netbook, Work Computer, Synergy. For very little cost, you have a powerful pairing system.

There are shortcomings to being a remote pair-programmer, though. You are not visible to your bosses, and can be forgotten sometimes. You do not participate in the conversations at the next cubicle, in the hallway, or at lunch. You don't see the same visual cues as to the team's progress. You can't feel the emotional charge in the room to know when people are afraid, tired, angry, or excited.

A remote does not have the physical presence necessary to be an agile coach or effective scrum master. Email and text will not truly fill the gap of rich, human communication. Your view of the team is the webcam. That leaves you out of mentoring opportunities, so you learn and teach less than you could have on-site.

Remote meeting participation is awful. The room is full of people, and there are one (or a few) mics. Inevitably the people doing the most speaking will be furthest from the microphones, and the most fidgety people will be close to them. There will be long stretches when you can't make out what is being said behind the rustling papers, pen clicks, rhythmic tapping, layers of whispering, etc. The worst interruptions in sound are caused by the the other remote who is on speaker phone but didn't mute their mic. Every time a sound activates their mic, all other sound on the line is cut off. It is almost as if someone were toggling the mic in the meeting room. One can lose interest in trying to keep up and return to coding, missing the reason they were invited to the meeting in the first place.

Finally, a remote is harder to promote and easier to release than a body you see every day in the office. That might be seen as an advantage to an employer, but will probably seem a little off-putting to the remote employee. My intention was to try remote development for a quarter or two, yet we stuck it out together for over two years. That's a pretty nice experiment, and I thank GeoLearning for the great and mutually-beneficial opportunity.

Would I be remote again? I think I would. I would remote with the same team in a heartbeat, because they're good people and we learned how to do this together. I still learned, connected, and enjoyed software development with good people. But I think I would like to go onsite again for a while. However convenient it is to be distant, programming is still a social act and still best done shoulder-to-shoulder.

People, software, and organizations often grow in this way: they accumulate without assimilating, and aggregate without integrating. As a result, they tend to be disconnected and fragmented and without a real focus or direction. In all three cases, it's amazing how functional they can be considering the shape they are in.

Perhaps this is the different between innovative young companies and the well-worn thinking paths of large ones, between young turks and hold functionaries, between greenfield software and legacy.

If so, then can we renew our creativity, youth, vigor, and clarity by ordering and integrating ourselves?

I would like to believe it is so. The idea, alas, is too grand for me. It's out here now, and maybe it will spark something more easily grasped and leveraged.

Thursday, January 13, 2011

I had some thoughts cross my mind today, and wanted to write them down before they fade.

I'm of some reputation in the agile community, a sometimes-recognized author, a consultant (ex-of Object Mentor, ex-of CSC Consulting) and an agile coach. I've taught thousands of developers to program in C or C++ or Python, how to do TDD in many more languages, and the intricacies of object-oriented design. I've refactored horrible code and tested and built tools and transformed teams.

I am also a 48-year-old man who needs to establish his personal brand. Many of us are introverts by nature, and those of us with rural, midwestern upbringing tend to self-deprecation. I've always found self-promotion abhorrent. Writing a promotional bio actually makes me a little sick at my stomach. The shame of it is that I could have learned to be comfortable with it a long time ago.

If I had begun the push earlier and had some coaching I would have made some different technology and career choices, but who knew? I jumped the track a few times, missed a few predictions, and didn't do some things that might have made me wealthier and more secure in my life and community.

Now imagine that you are well-known in your community, and you heard of some upcoming new Corey Haines or Ben Rady or other talented kid. You would have the contacts to introduce them around. You could help them to establish their web presence and write up promos. You could promote them among their peers. You could connect them with editors who could shepherd them into writing gigs with magazines. You could hook them up with local communities, find them speaking opportunities and help them polish their presentations. You could help them to write the kinds of things that get picked up on reddit, hackernews, and the like. You could find them side gigs, maybe help them negotiate rights to quote code and publish details on the work they do. You would have to learn about buzz and how it works, the way a publicist does.

It would be a talent agency for programmers.

With just one or two good success stories, you would raise the value of your organization and all of the people being coached there. Companies would be interested in using your people, and people would find value in joining.

It would be rough at first. You'd collect money much as a headhunter would. You would get a clip from placement, maybe a finders fee or the like. Maybe a clip from writing gigs you developed, deals you sign. There would be much to learn, but relationships would have a long tail. In time you could collect money on both sides.

I know that people already get involved in the community and connect and conferences, but not all people know how to do that or how to build momentum that way. It's a knack that some charismatic people have and others do not. Not all talented people can keep a room spellbound like Bob Martin or connect with people so easily as Corey Haines.

I wonder if the software world is big enough that we could have a talent development agency for software developers. It's a really intriguing thought, since self-promotion is not always what good techies do best.

I'm still the midwestern introvert, but I wonder if some of my extroverted peers see some value in the proposition.

Friday, January 7, 2011

I wrote earlier about code being under test, and how advantageous to have a test "under" several layers of testing. As I was looking through my old google docs, I found this drawing I'd made to explain layers of testing in a web app.

Terminology is catered to the audience of the time, and will probably confuse some. For instance "controller" here is really more like the "model" layer with its duty of acting as facade and moderator for underlying objects. Its purpose is primarily ensuring business rules and performing a single broad function that includes potentially many objects at the lower level.

The "API" objects here are the business objects. Again, tailored to the local terminology. Apologies. Maybe the Agile Otter should redraw the whole thing sometime soon. Anyway...

The idea is pretty simple, but sometimes people don't quite understand why the code-behind needs to be thin and why they shouldn't re-implement functionality in the fitnesse tests. If we use good cohesion and manage coupling well, then the unit testing becomes fairly simple, as do the unit tests on the controller.

We can test the code-behind through the web but even automated browser-tests are slow, often running for hours. It is handy to have browser tests, but nobody wants to sit and wait for them to finish. Most shops will push them off to the build farm so they don't suck up developer time. If code it only tested by-hand through the user interface, testing is pushed off to a dedicated testing team who will script and re-run the sames tests month after month for hours. It quickly becomes too expensive to keep scaling that team, and they start selectively running ui tests, in which case errors will slip out to production and customer care will have extra work, and bug fix reports will pull programmers out of new feature engineering. Often a company will have to split off a separate full-time team to do production bug fixes and data repair. It gets expensive quickly. Automating the tests means that we might be able to run all the tests every day, so that fewer defects can get out to the customers. It's cost-effective, but again very slow. The less the code-behind does, the better we can deal with it being potentially untested.

Our integration and acceptance tests (shown here with FitNesse) are going to run many minutes, maybe an hour or more. If the tests take only a few minutes then programmers will run them several times a day, probably before committing or pushing code to the shared repository, almost certainly at the completion of a programming task. Ideally these tests will bypass the code-behind entirely, but not re-implement any of its functionality. In order to make these tests effective, we need to empty the code-behind so that it is little more than plumbing between the controller and the UI. The business function controller is pretty testable, but the tests are like integration tests with many objects involved and possibly significant effects. It can still be tricky to test at this level unless most of the interesting bigs are pushed down into the business objects. The less it does, the easier the testing is.

Finally we're getting into the individual business objects. These tend to be pretty easy to test, as they mostly act only upon themselves. Good news for us. We can write extensive tests to drive behaviors into the objects. They become robust and predictable and understandable to the degree we stick to what we know about coupling and cohesion. Because they are underneath layers of testing (UI, FitNesse, controller, and individual unit tests) we can have more confidence in the changes we make here.

Maybe the picture isn't perfect, and the terminology is a little twisted, but the idea here is very simple. It works out that we can save ourselves time and money and even save face if we learn to keep the upper layers of the application thin, and save the meaty implementation for the areas where it is under layers of testing.

Of course, all blessings are mixed and even dark clouds can have a silver lining, so simple ideas can have costs and side-effects all their own. But this simple idea seems to work and seems to reduce problems for development teams and companies which employ them.

Wednesday, January 5, 2011

This is a limited time offer. If you would like to have The Agile Otter working for you, this might be your chance.

If you are looking to expand your technical team or need an experienced Agile coach, feel free to drop me a line (tottinge@gmail.com) and we can talk through particulars. I can work as a remote pair-programming partner (tech team) or on-site in NW Chicago burbs (coaching).