Rubber Match

This week is the rubber match between the Space Men and the Flex Men at work.

We've covered a lot of ground in this phase of the project. A lot of it was fighting learning curves and getting infrastructure stood up. We spent a lot of time using Lean set based decision making on what technology we wanted to use. This was good in that we are more confident in our decision, but bad in that it cost time. The good news is we wouldn't have picked the technology we ended up with if we had used a traditional "place your bets early" approach. So it worked. Yay.

It is inevitable yet annoying that the first rev. of any piece of software has to pay the first rev. tax of standing up infrastructure, figuring out methodology, forming/storming/norming/hopefully-performing, and learning rapidly in general.

The team makes its choices (as Sarge would say) and lives with the repercussions. We made a lot of good choices luckily, but we certainly made some bad ones. The bitch of it is you never really know which choices were good and which choices were bad unless they were very right or very wrong. You are always left wondering what if we did this - what if we did that?

And so it goes - here comes the rubber match between the Space Men and the Flex Men. I am using this phrase incorrectly, but I felt like using it anyhoo, so so what!?. It really is the integration week. When we take a lot of reasonably well tested Jini/JavaSpaces code (unit, integration, and FIT) and try to integrate it with Flex code.

For better or worse, we split our small team into two - one focusing on the backend JavaSpaces side and one focusing on the Flex UI side. This was mostly due to fighting learning curves, but was also due to working styles and geography. We wanted to try a lot of things and splitting the team at the time seemed to be a way to cover the most ground with technology and methodology. We'll never know if this was a good decision. But we made our choices.

A team where everyone is skilled in all areas of the system is obviously best. But you can't just wave a wand and make this happen. You have to get there iteration by iteration choice by choice.

Wish us luck this week - the rubber match is going to hurt! :)

Pair Programming

So I have been a long time doubter of pair programming.

I just spent 2 - 1/2 days pairing with this man.

I have to say - I really enjoyed it. Part of it is that I just love slinging code and I became a technical manager of sorts (in addition to remaining a technologist dude) 7 months ago. Pairing is a great way for me to get my code fix. Even after 7 months of not slinging heaps of code, certain corners of my brain started turning off. It was great to dig back in and light those corners back up. I even came up with a good idea to simplify something and received my "space man merit badge".

Our small team has been experimenting with pair programming for those that want to. It has been very successful.

I think that some of it is the fact that we are dealing with so much new (at least to us) technology. Pairing is (obviously to me now) a great way to spread knowledge, learn, etc.

I certainly don't think that 8 hours of pair programming every day is appropriate - at least for me or probably most people. But it is clearly a great thing to do *at least* a couple times per week or some such. I guess it depends on your role etc.

Anyways, I love it when a long standing belief / opinion of mine changes. It helps me know that I am pushing myself outside of my comfort zone and pushing myself. One thing is obvious (or should be) about the world we all live in now. Those that stop learning are toast. If you aren't learning new things (e.g., about your domain, techniques (e.g., agile, lean, xp, etc.), technology, negotiating/people skills, hospitals/manufacturing) you are going to hit a wall. It is amazing how comfortable you get with this concept once you sign up with life-time learning. I am constantly amazed at how many people don't view the world this way.

iGel

More panic than usual at the panic factory.

We have had some methodology panic. Not so much disagreements, but more:

em, we have to release this in a little bit and we have to collaborate more so we better agree on how we are going to work together now so we can deliver and not look lame/dumb/hand-waver-ish

type of stuff. We are transitioning from doing a lot of throw away semi-functional POCs where collaboration was optional to building 1 skeleton system where we must collaborate heavily or we will slip.

These types of transitions are tough. But if they don't kill you, they only make you stronger.

You can be on the best team in the world (I actually think I am on one of them - no joke) and until you have been through the ringer and shipped something with that team, it doesn't matter much what you have done before with other teams. You have to make it work with this team. It can be hard to get the rhythm building - especially when so much has to be bootstrapped to get that first story tested and working.

I have been using Scrum for quite a while - at least 5 years on and off (mostly on). I like it because it is easy. The teams I have been on that have used it were always successful enough - mainly because all Scrum really says is you have a backlog, a sprint/iteration planning meeting, a daily scrum meeting, a sprint retrospective meeting and you have short iterations where you can course correct.

Within Scrum I have been a part of various analysis approaches. I have been a programmer / analyst and have been on teams that have had dedicated analysts who do insanely large Use Cases. Now I am on a team with 1 analyst who just churns out epics /stories like they are going out of style. She "gets it". I like people that "get it". I have been helping here prioritize / size the backlog lately.

On this project we are amping it up a bit and embracing things like Epics, stories, heavy TDD (Test Driven Development), and gasp ... a little pair programming (strictly voluntary for us). It really helps when you have an iGel Ninja around. You don't even have to listen to him talk - you just watch his hands and you understand (mostly). Come to think of it, we have 2 - we also have an Irish one. He isn't so much with the hands, but when he is the smoothest swearer I have ever met. It doesn't offend anyone when he does it even if it is a f-bomb. Dropping an occasional f-bomb is crucial to iGel success IMHO.

I have tried and failed too many times to count at TDD. But this time I am on a team that has the will and desire to succeed. I know many of the things that make it fail or rot on the vine. It basically comes down to discipline and no broken windows.

Our wiki is quite helpful in all of this as usual. I would jump out the window if someone took the wiki away.