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.

Very good post over at Software by Rob. It’s about the important things that developers need to work happily at your company.

He places everything in two parts. Hygiene and Motivation. This is actually very similar to Maslow’s hierarchy of needs something that is always again turning out to be true. Maslow put motivation into a hierarchy.

* Physical Needs: working conditions, wage, housing, catering,…
* Safety: health insurance, pension provision, safety, security in job
* Social: sports, clubs, parties, outings, open communications, …
* Esteem: Regular positive feedback, prestigious job titles, promotions
* Self-actualisation: challenging, encouraging, can structure own work

The idea is that you need the first parts like with a pyramid. If the base is not there, it is futile to add the others. In bad working conditions, no amount of challenge will lead to motivation.
The same thing is true for hygiene. You need it to start with. Or at least a good amount of it. Maslow is actually a bit clearer that you need the base as a must have.
So let’s put this more into perspective for developers.

1. Being Set Up to Succeed
The idea is that you really want to build something, something that doesn’t put unnecessary road blocks in your way, that is maintainable. It needs to be a quality product. It’s craftsmanship. You don’t tell a craftsman to build a crappy table. I am happy to be able to put a check here.

2. Having Excellent Management
You need to take bullets for your team, no micro-managing, give them free the freedom to think themselves. This is really too early to tell. This really takes time to build up. The verdict is still out.
3. Learning New Things
It seems that if your job gets more variety, and you get to acquire new skills, you will forgo a 20% raise. A really good developer needs to learn. Of course they have to want to, which is kind of a circle. Good developers do. This is a kind of test. I am making damn sure they have the option.

4. Exercising Creativity and Solving the Right Kind of Problems
I think I have to try one suggestion he has: drop a Sudoku in the middle of the developers to see them attack it. Might be a good trick when hiring somebody new. I agree that developers love challenge in general, so a big job is to make sure that the problem at hand is a difficult one. And remember, easy problems can be difficult if put in the right light and made into a challenge.

5. Having a Voice
When a developer speaks, somebody has to listen. Simple. That’s actually true for all people I’d say.

6. Being Recognized for Hard Work
Peer pressure. Something Google uses as a management style. Hard to make right and not backfire.

7. Building Something that Matters
Building something that somehow has more reason than making money. I think we score big there at Ormigo, because we give local merchants an option to compete in the global advertising market.

8. Building Software without an Act of Congress
Let them build it. Don’t talk about building it, but build it.

9. Having Few Legacy Constraints
This is really a cry for refactoring and putting that into your development model, making time for it. The thing is that you don’t want anything in your app to hold you back. But as you are learning along the way, the stuff holding you back will appear again and again.

I actually have to say that we are doing pretty well at Ormigo. A lot of this can be read out of simple management practices from an MBA if you look at it from the right angle.

I recently found two interesting articles relating to Google’s management style. It starts with Steve Yegge talking about Good Agile, Bad Agile. Working along the agile development approach with some changes, this obviously interested me. In a sense he is right. On it’s own, without adaptation, without thinking, it is another fad that consultants will exploit. It is also true to many other things I have learnt about people management, so the general ideas underpinning agile software development are right.

After having worked at Google for some time he thinks he has understood the development process and I will take his word for it as the insights he give ring true.

They are not really using managers as such but mostly tech leads as they code themselves. In the end, I believe developers choose their tech leads themselves as different people have different skills and the “lead” part should be taken up by those with the most developed necessary skills of the moment. Management’s task is to facilitate that and get out of the way.

Another point is that you as a developer can switch projects and teams at any time. This of course requires a big company, as you need some amount of projects, and you need some system to make sure every project is filled. But more to that later. That you can spend 20% of your time on other projects is known and a good idea if you have the right people that will work on related projects any way as that inspires them.

They also have very few meetings, which again comes with clearly defined projects. “Make the search results appear faster” doesn’t require a lot of meetings other than with your collegues over a brainstorm.
The interesting thing is that there are no Gantt charts of date-task-owner spreadsheets. Nothing resembling project management as such. We are moving a similar way though. The thing is a Gantt chart doesn’t make you faster. Identification with the vision does.

You also don’t work insane hours (”unless you want to” with the “want to” being pushed a bit ;)) which again relates well to Joel’s point that 8 hours of creative work are all you get out of people. With 12 hours they are bound to do other stuff and you start getting higher turnover. If you do it all the time.

One important part that I didn’t know up till now is that a large part of Google relies on incentives. Your reward is in relation to how important management sees a project. The incentives are financial and in other forms. The “other” part comes from Google’s peer review culture, which I posted about recently. If you have good people and a peer review system, with financial rewards tied to peer reviews to a large extent, then the review of those peers, people you respect because you know they are good, will have a large incentive component. Check this:

“I might have been mistaken, actually. Having your name and picture up on that big screen at End of Quarter may not be the biggest incentive. The thing that drives the right behavior at Google, more than anything else, more than all the other things combined, is gratitude. You can’t help but want to do your absolute best for Google; you feel like you owe it to them for taking such incredibly good care of you.”

All this does though is to get people to work on the right projects. The best explanation is his first sentence on this:
“At Google, projects launch because it’s the least-energy state for the system.”

Ok, there are project managers, and product managers and all that. But they really only nudge. Teams sit together, lots of meeting rooms are there. Meetings happen in the middle of the day, and people come in early or late to keep the rest of the day to working.

But again the small pionts matter. Google takes “things like unit testing, design documents and code reviews more seriously than any other company”. That results in them having one code base, and switching teams and sharing code becomes easy.

The other thing is that Google is not date driven. Their drive is their desire to build something. Google wants things done as fast as possible. You need to create that urge.

Something I agree with is that index cards are not the optimal solution. We are actually using FogBugz here and it provides us with a good work cue, per project, per release. If you add time estimates it gets even more powerful but they tend to be a pain in a smaller organization. Don’t mistake this for trying to control people. It is just to have an idea of how much work is in front of you.

I also agree with him in that you can’t do too many sprints or too short sprints. You still need a bit of freedom. We are currently using two week sprints, but something have a break of a week in between or just cleaning sprints. What the sprints do help with is having a bit more structure above and beyond projects. Of course you can work on the next sprint tasks if you want, but everybody knows that there is a clear goal with the current sprint and that goal is something we all want to reach because we know why it is there. The date at the end is just to give us a clearer goal.

Then there is the part I fully agree with. You can do things, that are not really part of the sprint, but that will improve your productivity immensely in the remaining ones. I could make a sprint saying that this one does not have unit tests in it, or that the idea to move our javascript interaction to it’s own framework will cost us time … but that is short sighted, and this short bit might be super short.

Then Greg Linden talks a bit about all this incentive stuff. Gives it just this other bit of certainty.