Self As Team

I am sure I have my annoying ways of working but there is one thing that drives me nuts about some of the teams I’ve worked with.

Showing up to a meeting late.

The thing I like about scrum is even though we meet daily, we end up with fewer planned meetings (lots of ad-hoc white board sessions but they are very focused and productive). The thing I don’t like about scrum is having to wait for 5 or 10 minutes for the team to assemble. Sure there are things you can try and do to stop this behavior. I hate the idea of a ‘late jar’ where you contribute $1/minute you are late (donated to charity or food for the sprint review, etc) because if you agreed to attend a meeting at a certain time, then get there on time. On high performing teams, this isn’t as much of an issue. In some of the dysfunctional teams I’ve worked on, this is chronic.

I suggest that if you have 10AM meeting, then at 9:58, head over to the meeting rather than wait until 10:05 to go. Sure, you’ll wait around for 30 seconds or so but at least your team won’t be waiting on you.

Should be low-hanging fruit but is never seems to get picked.

I really don’t like most of the titles I have seen. Architect is probably the most overused and most overloaded one there is. I agree with in the recent post from Dietrich Kappe But Where are All the Architect Positions? in when companies say they want an architect, they really want a senior developer. This has been my experience too. I think of myself as a very senior developer who does lots of application architecture (overload for ‘application design’) and who is aware of enterprise architecture options/approaches. I’m really a developer who understands a larger number of perspectives than a less senior developer. This is because I’ve lived on many many more software projects and have worn many different hats. I also remember what worked well and what didn’t so am always on the lookout for new frameworks or techniques that improve my future existance.

In my view, an architect is more than just a person who understands frameworks or the various supportability or security implications of this decision or that… An architect is really a ‘lead developer’ who doesn’t just bring conceptual elements to a project, they lead the development – showing by doing, coaching, reviewing, spiking, advising.

So, when I think of software architect, I really don’t think of the academic sitting in the ivory tower, I think of the gal or guy on a project that always seems to be a step ahead of problems. They are busy as hell but always have time to explain or discuss. They foster proactive and transparent communication in their teams. They don’t own the design or framework choices, they encourage evaluation and trade offs. Most of all, they contribute instincts to the team. Instincts to help shore up the team to tackle some of the non-intuitive aspects of the development life cycle like TDD.

Working on a a self organizing scrum team means low ceremony and trying to work as a collective whole so titles mean little. I hope hiring managers and contract outfits will begin to dig into the needs of the project more than relying on titles. This is especially true when they talk to ‘architects’ that graduated in 2005.

Just say, my title is chief bottle washer.

I’ve been a long time consumer of internet information. I work on internet based projects and do lots with my client’s intranet spaces.

I have offered advice and asked the occasional question from time to time on specific technology boards such as Springframework but largely, I’ve taken information rather than offer it.

My net contribution to cyberspace is mostly negative.

This blog will attempt to rectify this situation little by little.

My hope is any contribution I make doesn’t further tip the contribution scale in the wrong direction.