Blogs

I’ve moved my blog over to http://ambiguiti.es from now on. Over there I’ll be talking about web and mobile development, and maintain a more general blog relating to events, conferences, job postings, and other such news in the industry.

Scott Sehlhorst, as always, has some interesting insights into the software development process. He argues this week that Agile is sometimes used by developers to hide or absolve themselves of responsibility, but that the opposite is true. Agile actually increases accountability by preventing a ‘throw it over the wall to QA’ culture and by promoting developer ‘ownership’ over features and quality.

Read the full post here.

I’ll admit that I’m not an Agile expert and I don’t understand a lot of it yet, but in a recent project I saw this responsibility-dodging behavior on an Agile team, and I think the culture of supremacy of developers over project coordinators preventing anyone from calling them out. The scrum-model is a short rapid-fire way of tracking team progress, but the flip-side is you get the perception of transparency but in fact only get a surface-level view of what the developer is actually doing. When things are not going right in a project, developers are able to cut features and push timelines, unfairly shifting the burden onto project coordinators who then have to deal with the client. The failure of the project coordinator in this case was that they didn’t notice or seem to mind that the developers had the same goals day after day and didn’t make progress. What’s funny is these people would rephrase their goals each day but say exactly the same thing. That’s a fault of the coordinator, not the model, but even if they did notice, what could they really do about it. In a room full of many people who is going to step forward and say ‘hey! you’re full of crap!’

I managed to deploy the latest version of Jiibe today, which included (among other things) the new Jiibe Badge. You can now embed your personal or company jiibe on your blog or corporate website. See mine below:

The great thing about it is it’s real-time, so it always reflects your latest jiibe, even if you go back and change some of your answers.

There is a company in Toronto that makes some pretty sweet microscopes and they have a sizable software development and manufacturing team. A few months ago I was visiting the company (I used to work there) and I noticed their new Team Rules poster next to the developers’ cubicles. I guess this is an attempt to foster a particular sort of team culture. What culture would this represent to you?

VisualSonics Team Rules

1. We have open honest communication; no held punches.
2. Discussions are about issues and ideas, not about personalities.
3. We challenge each others ideas, we never take it personally.
4. If a challenge becomes personal, we apologize, we accept the apology, and we move on.
5. We challenge ideas openly, debate passionately, then we get the best decisions.
6. We value the exposure of problems, it allows us to find solutions.
7. We always support the group decision unanimously; one decision out of the room.
8. 100% buy in = no unresolved issues = no politics.
9. This is not a democracy.
10. Issues, their action plans, time lines, and persons accountable must be documented.

I thought it was interesting that a lot of these rules are about consensus-building and decision making, but hidden away near the bottom (item 9) is a clear indicator that in fact they are not really that interested in consensus at all. Are these the seeds of a poisonous work environment, or the building blocks for a cohesive team? You decide. Are there team rules at your company? If so, what are they?