Oliver Thylmann’s Thoughts

As Ibo just posted about Sevenload’s Secret Garden strategy, I thought I’d wage in with my own thoughts on structuring your development environment. We see ourselves as a technology company at Ormigo, mainly because we do not believe the local market problem, getting it online, will be solved with a sales force.

Ibo’s article is in german so I will try to translate a few of his views and comment and elaborate. He is only giving a few insights, but they are relevant none the less. The basic idea is to build an environment that helps to build great products.

What Ibo has developed, with Tom and Axel, is to put the developers in a “hermetically sealed” environment, meaning they are behind closed doors. The general idea is good in that you need to get into a flow and disrupting developers in their work is bad. Fully closing the door and letting nobody in is an interesting concept and I am looking forward to hearing more of how it works. From my personal experience I would argue that you then need core teams and an operations team and that operations team needs to be in another room, because there are operating things that need to be discussed shortly.

The other big problem with this closed door is that you loose communication, and the most important thing in software development is communication. That is the entire idea behind scrum, which he hints on later. Of course the communication needs to be structured, but based on his idea, there would be no problem having teams dispersed over different countries, especially because he says that most communication goes over an internal IM client.

He does say that developers need the right gear and among others two monitors. We have been doing that from the start and it is proving very valuable, but it is not limited to developers. Especially if you say that developers need a laptop, buying a second 20+” monitor is needed and the price point is not so much different from a desktop system in many cases. One thing I like is his idea of having large flatscreens on the wall that give the status of the servers and features in development or just launched.

There are no walls between people in the same group, which I agree too, but only glass walls between different teams within development. We actually have smaller rooms here, with 2-3 people in development in one room because some people need to close the door from time to time. That is really his secret garden idea but tailored to the developers that want it like that and those that don’t.

His basic ideas of a secret garden actually fit to scrum again and also are often common sense, like not fighting but discussing. But that is a culture thing and the culture at Ormigo can sometimes seem rough. This is an extension of having people with experience and clear views in the company though, and we can all disagree vehemently, discuss things and then come to the conclusion for a plan to follow, because each view has been heard and we can then agree to disagree but agree on a plan. That is very important, and needs a good managed of a meeting culture, which is independent of the secret garden system though in my mind.

He also says that they have only structured discussion among small teams, also with different departments, which is fully reasonable. It fits with our meeting system for bi-weekly deploys. In the middle of the current sprint we have a short meeting with everybody for an update of the current sprint and discussing the next sprints high level goals. There we also discuss who is responsible, which will be one person from bizdev and one developer as a minimum. That allows for rotating responsibilities through the entire team. This small team then makes sure to get a better idea about what the next sprint will be about showing that in a short meeting over lunch at the end of the week. Next monday we normally deploy our current sprint, and then go down into tasks for the following sprint, splitting up different tasks for different people in kind of sub-responsibilities. Then the system starts over. So yes, you need small meetings, clear responsibilities, but you need very semipermeable walls between each department in the company, while being clear that you don’t just walk up to somebody and ask a short question (which is hard sometimes).

Congratulations for using JIRA as a task management system, even though I am not sure if it does not create too much task management overhead. Doing development for corporations that might be needed though. We are using Trac internally and are feeling very happy with it because it allows us to easily handle small sprints and mix around tasks. Yes, there are no task dependencies in the system and no required process flow, but that is not needed with the right structure behind it and small sprints. These interdependencies are only needed if you do a 3 month sprint for example, where you start to need a real project management. Interdependencies are for us between sprints on a higher level.

He also says that often you loose yourself in technical details, which is something I can only agree with. This is why the development team needs to know the business side and the numbers and the real goals. Goals are not “build feature x” but “get more SEM traffic” or “allow more ratings” which can be measured afterwards. The technical detail bit is actually what makes the difference between a great developer and a good one. A great developer will know what is needed and what is overkill. You should not die in beauty. But there again the bi-weekly deploy system works very well in that it requires you to focus.

Looking forward to hearing more from Ibo about their structure and how it is working out. Scrum is great but real Scrum is REALLY hard.

The two topics do not really relate but they come up in one article that Valerie from alarm:clock euro linked to. GigaOm also has a few comments on the article, also stating that the Sulake Labs, the finish start-up behind Habbo Hotel, is making something like $77 million a year at the moment. Not bad for a 2.5d virtual world. The article is a good read though on learning more how they stumbled upon their success.

Our company has, indeed, stumbled onto some of its new products. But never forget that you can only stumble if you’re moving. - Richard P. Carlton, Former CEO, 3M Corporation

It’s a really interesting model their playing with, and fun to hear a bit about what “games” people play within the game. I also found it interesting that the founder talks about having moved all development to an agile/scrum methodology and now releasing every 30 days. They seem to be very happy with it and the switch must have been very hard, especially if you pull it through 100%. The uncertainty that comes into the system is sometimes challenging. The speed, happiness and creativity is the reward.

I just finished reading Agile Software Development by Cockburn in the last few days and it’s a very good book to get an introduction to the subject. Lots of the ideas in there ring back memories from the MBA and knowledge management actually.

For one the sender, receiver problem and frame of reference. The thing is that communication involves a sender, a receiver and a channel. The big problem is that while the channel has noise, both sender and receiver have a frame of reference that puts what they say or hear into the right context for them. This means that you can very easily not understand each other correctly. One solution here would be to often do something like this: “So what you are saying is, just so I understand it correctly, … .” This will also help if you try to win over people and notice a flaw in their reasoning.

The frame of reference will only get a sound base after the norming, storming, performing phases of building a team have been gone through. This is also one of the reasons why outsourcing is a problem. You will not go through that phase and a performing team is a lot better than a norming or storming team. You will have to have so good documentation that frames of reference or noise in the channel are not important.

Cockburn actually says that software development is like rock climbing. It’s cooperative and goal seeking, yet load bearing between different people of a team that are still individuals with different talents. It’s very skill sensitive and requires training as well as the right tools. The resources are limited and you have a plan around which you improvise. It’s fun, challenging and dangerous. Great analogy.

What this also means is that you need to find the right amount of documentation and keep it so rough that you don’t need to continuously update it. This is really where it gets hard for new entries into the team, depending on how much shared vocabulary you already have.

Understanding how people work, behave, interact is key. They make mistake and this is why Agile wants short iterations, to catch them fast and keep them from growing fangs. People prefer to fail conservatively than to succeed differently.

Through University we are taught to be unique (just thinking of how unique your final thesis in germany has to be), and this makes it a none team effort and something that does not make people reuse code as such. Therefore you need to make sure that your culture, attitude and people’s education makes them want to reuse.

Another important item is “flow”. Developers, or anyone actually, get into a flow after 20 minutes of quite time. Turning of the phones for 2 hours is important to really get there at least for a few hours a day.

Motivation is another key part, which can come from three different areas: pride-in-work, pride-in-accomplishment, pride-in-contribution. That is oversimplifying it a little bit as everyone is different, but it seems about right. Another might be fear, but then again that might not be motivation then But if you want to use the above, split projects into small phases.

Osmotic communication means sitting people together, at best from different parts of the organization because they will pick stuff up if they want it or not. Information radiators are good here too, which is something that VISA used very well actually. Written use cases can be used for information stickyness.

So where is the sweetspot. 2-8 people in a room, 2-4 week increments, fully automated regression tests, experienced developers, reflection after each increment, usage experts in each team.

Great stuff all in all. Looking forward to pushing more into this with the new team.

Technorati Tags: Agile, Scrum, Software Development, Teams