Team room

A while back when I expressed by concerns about a particular team room I got some negative reactions including from one of the persons who working that particular room. My assertion was that I wouldn't be able to concentrate in such a crammed room.

Now I've come across a few more pictures and I'd like to share the location of pictures of a team space that I really like: it's on Brad Wilson's blog.

Now that our Savila team has grown to 3 fulltime members plus myself I think I should post a few pictures myself as well. So watch out for them ;-)

I almost forgot. Have a look at entry #11 (Cadenza). I guess the plants not only give the room a special atmosphere but also help to dampen noise.

Tags :

Does Sustainable Pace mean a 40 hour week?

It is travel day and I have some extra time to catch up on my RSS feeds. On InfoQ I came across this:

InfoQ Personalized Feed for Stephan Schwab in Does Sustainable Pace mean a 40 hour week?:
Sustainable Pace is a well known XP practice however, different people relate to it in different ways. Could an Agile team increase its sustainable pace by working longer? An interesting discussion on the Scrum Development group tries to debate the correlation between the number of work hours per week and sustainable pace.

Interesting thought but probably completely futile and towards the wrong direction. Software Developers are not anywhere similar to machines because they are humans - not resources, as many misguided project managers, and probably many managers in general, perceive these talented people. You cannot increase the input and get more output.

On any team you need to leave room for learning. Without learning there is no improvement in productivity or quality or anything else. Skipping the learning means stagnation. In a profession such as software development stopping to learn is dangerous and will get the company and the individual developer into trouble in the near future.

So... Maybe the right question would be to ask how much time out of the regular work week should be devoted to learning, which is not related to the problem being solved in the current project. What the software development profession at large is in bitter need of is a much more elevated level of skills and knowledge and that includes developers and those who manage them.

Tags :

Interesting idea from the US: instead gas tax breaks use the same money for highspeed networks

The context of this is the upcoming election of the next US president and although I'm not a US citizen and have anything to say about this particular topic it does refer to a thought I carry with me since the early days of running an Internet Access Provider in Germany back in 1994.

Dave Winer in Scripting News for 5/2/2008:
And the money we’d give up for Federal gasoline tax could be better spent on putting high capacity network lines under our streets to increase communication. Some of the car trips must be to exchange information that coud be replaced by moving packets around at gigabit speeds. It wouldn’t cost much to retrofit a few cities with really high speed lines, then we could get to work on developing the services that would make life more interesting, fun and efficient.
Tags :

Sleep deprivation is not a badge of honor

Signal vs. Noise in Sleep deprivation is not a badge of honor:
Forgoing sleep is like borrowing from a loan shark. Sure you get that extra hours right now to cover for your overly-optimistic estimation, but at what price? The shark will be back and if you can’t pay, he’ll break your creativity, morale, and good-mannered nature as virtue twigs.

This is just so right I can fully underwrite it. If you think otherwise, think twice ;-)

Some businesses should stay away from Agile

I'm pretty sure you know that very well ... I've spent today wandering around thinking about the topic of corporate IT and Agile. One of my thoughts were related to education and the type of person one wants to have on a team. I even started to write a blog post about it but stopped because its a broad topic and certainly needs more thinking to make sense.

But one thing seems to be clear. While the corporation views IT in a supportive function Agile might not work at all. They will always set a fixed deadline, a fixed budget and expect a full feature set. The fun part will always be that "full feature set" will never be clearly defined, because they just want "something that helps the business". And obviously there is no time to figure out what that is, because they have a business to run. ;-)

So unless "the business" understands that software development is always new product development with all the risks that come with it, those projects will always be in trouble. They would be better off to buy off the shelf software instead of attempting to develop their own.

When you develop a new product you usually don't make it a fixed-time, fixed-budget and fixed-scope project. You target a point in time (a trade show maybe) to release a first version or you have a budget and go as long as it lasts. Or you define the scope and accept that time and money needed to accomplish the task are unknown.

If you are a business and just want support from IT, then you should stay clear from any form of development. It certainly is far better to choose off the shelf software that can be customized. You then pay people to do specific work and that's basically what ERP systems like SAP R/3 offer. The good thing about this is that you can get people who are really qualified to do the job, because the way how such a system gets customized doesn't change so drastically as for example Java web frameworks or technology in general. It may be expensive, but it certainly is far more predictable than custom software development. It's kind of calling a carpenter or plumber - just a bit more advanced.

Tags :

Psychological evaluation for Agile?

Based on a number of recent experiences I've come to think that there might be a relationship between work ethics, personal motivation and whether one will succeed with Agile projects. This post will definetely not give the answer. It is merely a thought I wish to publish and maybe some kind readers will provide their own opinion or share their own experience.

To me it seems that there are two types of people in software development. Those who are passionate about creating some work of art and enjoy building software. And those who simply work to make ends meet.

By no means I am condemming those who wish to make ends meet. That's only natural and in a world where one has to buy food, shelter and other supplies it is simply a matter of survival, if looked at closely. People do so many things to that end and I can only speculate why some of that type chose software development and not something else.

Let me make clear that the last sentences do not only refer to those who actually write code. I am talking about all the others who are involved in any software project as well. That includes persons who represent the business side and write specifications - user stories or in other form -, those who manage teams and individuals, those who work in QA, system administration and everything else.

It is astonishing to see what small teams comprised of passionate and highly motivated indiduals can accomplish when they are not restrained by any form of governance. I believe a team comprised of good "corporate citizens" would probably work for a year and still be disussing which toolset to use.

The question is why is that?

Maybe it is because there are so many choices that only someone who devotes his life to the art of software development is able to keep track and accumulate enough knowledge for making an informed decision. Can that be? The regular corporate office worker spends 8 hours at work. A good chunk of that time is used up by meetings, responding to emails, preparing reports and other administrative duties. When this person arrives at home she is tired and wants to be with her family. And the weekend is certainly not spent researching technology topics. I remember one 40ish gentlemen who was working in the IT department of a mid-sized company on SAP R/3 stuff by the time I met him. He was pretty interested in learning about network security and TCP/IP networking in general. So I referered him to a number of books and his response was something like "I have maybe 10 minutes per day to read when I come home".

The Agile Manifesto says:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

That is very noble and makes a lot of sense. Unfortunately it does not mention anything about the type of individuals.

Can Agile work with people who are only interested in their paycheck, having fun in life and be home one time? Can it work with those who like it easy? Those who prefer to hold up anything with endless discussions about nuisances unconsciously knowing that it will allow to water down anything and get away with it?

Or is Agile merely something for the doers, self-motivated people who are interested in getting it done and then improve it further? Does it refer to entrepreneurs?

How hard is it to transform a worker type person into someone who is passionate about his work? Do we need a psychological evaluation of team members to determine whether they are suitable for Agile?

Update: After posting I did a Google search on psychological evaluation Agile. I would not have expected the result. Interesting...

Tags :