More Noise?

January 30, 2007

Last week Mike Vizdos wrote an article at Implementing that had me scratching my head a little. In this article Mike was arguing that Silence is a symptom of poor communication, and that when team members have conversations over messenger, those that would gain collateral information from the conversation would be shut out from such juicy bits.

One of my colleagues once walked into a room with a new team. When he told me about it, he said something along the lines of, “It was so quiet you could hear the waterfall.”

Think about that last statement for a moment. I’ll stick around.

Welcome back. Good thought break? Hope so.

When *I* hear this statement, I realize a team is probably not working to its full potential.

While not the Uber scrum master Mike is, I don’t think he understands the psychologies of programmers to realize that ambient conversations are going to murder their performance and concentration. When I initiate a conversation with a person over IM that is in the same office, it gives them the ability to multi-task and not be thrown off their process completely.

I’d basicly equate this to trying to program with the TV on. Some of us can do it, some of us can’t, but nobody is as productive with it on, as with it off.

A lot of the rules of Scrum are really important, transparency between client and team, team and scrum master, team and team are super important, but were not the Borg. And there are only so many hits performance can take in the name of transparency before Scrum starts to become a hindrance.

Long live IM!


Our outsourcing is killing us

December 28, 2006

and our company is asking for more.

We’ve been contracting developers and testers overseas, known for the length of this article as Initech. (Wha?) So like I said, we’ve been using Initech for the majority of our support issues, and then using them to make up large portions of our development teams. The former, while a developers dream (never have to fix a bug in released code, holy cow) is eventually going to lead to shoddy quality and less attentiveness on the behalf of the in-house development team.

As a result, Test driven development and even more importantly any real refactoring attempts are ignored by management, and not voluntarily adopted by the majority of the development team. Test driven development will catch the majority of your issues at dev time, and ensuring quality in following builds through the magic of continuous integration. Since we aren’t writing our tests first our coverage is quite low based on our weak testing discipline, but a much bigger result is that we are not performing the third step of TDD, which is Refactor Ruthlessly.

What we’ve got now is a bunch of weakly tested, ugly, smelly code that we just need to mangle enough to produce the functionality we want, without having to worry to much about the long term quality issues.

I know what your thinking, excuses, excuses. Good developers should refactor, they don’t need a reason, they have the motivation to have quality code developed and part of that is refactoring. There are other factors, and since this is an outsourcing rant and not a refactoring rant, I can’t go into those fully yet.

The Initech guys really are talented, I’m impressed by what they can do, especially under the conditions we impose upon them. Yet they have serious lapse in their completeness. Such as jobs being reported as done just being skipped, functionality being skipped, holes in the design going unnoticed all killing us overall.

Our in house development staff is spending a large portion of their time reviewing, fixing, and completing Initech code. Add these extra duties, to the new demands of scrum, we are finding the amount of time we get to actually code is being severely decreased which leads back to in house developers not having the ambition to self impose TDD and Refactoring into their day to day efforts.

Less apparent is the effect this is having on employee moral. You can argue developers ambitions for their work but whatever they are, this process is ruining it. Our code isn’t something to be proud of, our day to day operations are contain less coding and we’re producing less of those glorious features everyone praises us for. Would it surprise you to find out we’ve had some key people leave in the last few days?

I may make outsourcing seem like the root of all evil, I don’t think we need to do away with them, but with our current process, structure, and personnel, we cannot handle the work load given to Initech. They are great tools for supporting our current in house development team, but history has shown that we can’t trust them on a consistent basis. I hope the message can be relayed to the top, otherwise life as an Initech babysitter will continue to suck.


Lets get a conversation going: Scrum style

December 2, 2006

Implementing Scrum has setup a new forum at! I know its kinda empty right now, but I think it’s a really good idea to get this thing going strong, so lets all band together and post our brilliant thoughts. (Or mundane if your not quite as brilliant as I am.)

False Start

December 2, 2006

So at our company we are utilizing the Scrum development process. As currently only my friends are reading this blog, and none of them have any clue what Scrum is, I feel I must include the obligatory short description of what Scrum is.

Scrum is a management system that says a team works for 30 days on the most important tasks for the product. At the end of those thirty days, you should have a finished product that your ready to ship, which is harder then it sounds. Anyway, back to what this has to do about me.

Today, at our daily stand up meeting, before I even knew what was happening, our sprint was canceled. We are a little stretched thin personnel wise and bodies from our team (namely me) were needed elsewhere to help keep the company on track. There are two ways to take this, one, being that this is a knee jerk reaction by the company to throw resources at their problem. The other is to think of this as addressing a problem in its infancy so that there is not a major screw-up down the road.

Currently I’m on the latter, but others on the team were of the opinion it was the former. This change seems like something an Agile company should be able to accomplish, but in my view, software development is just not able to be truly agile. Going from one task to another, requires huge amounts of knowledge transfer, gathering a mental image of the structures and environment this task. With this built in margin of time between switches, is it possible for a programmer to be all that agile? Is he not more lumbering?

So if we thought of developers instead of agile lithe dancers, but lumbering mainframes, would we be more cognisant of the productivity and limits of a developers output?