Structuring your Development Environment
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.