Exceptional Workplaces and Great Engineers

I believe in exceptional workplaces. I believe in building great atmosphere, helping people to fulfill their potential and making work more fun.

There was time when I believed that exceptional workplace results in exceptional workers.

I don’t anymore.

Actually I’m confused when it comes to the subject. When I read Joel Spolsky writing about Fog Creek I’m all “Hey, the guy is a guru, he just can’t be wrong.” And then I hear the story about Googlers complaining about lack of variety of coffee brands and I’m all “What the hell? Can’t they just appreciate how much their employer is doing for them every single day?” I see how much genuine fun can be initiated by integration events. And then I see people who aren’t able to understand all of these features aren’t a duty of their employer – it’s either good will or an investment which doesn’t have to bring any ROI by the way.

Google attracts great engineers, but not with free snacks or gorgeous offices. In the first place it’s because they run extremely interesting projects and then it can be about exceptional workplace too, but in a second or a third place. I guess Google also attracts loads of people who aren’t anywhere close to be great engineers.

The same was with Microsoft back in 90s. Now Microsoft is the source of all evil but then it was a destination for many great engineers. And I don’t really remember anyone mentioning free soda as the main reason of choosing Microsoft.

At the same time I’m happy I can offer people in my team bonuses which aren’t offered by our competitors on local labor market. These guys haven’t joined the team because of these add-ons but they make working here a bit nicer.

Someone can say there used to be more “features” in our company some time ago but my answer is “so what?” Maybe some people will stop treating all these bonuses as granted and actually start appreciating when they get one. Because if you’re one of those who spend all day complaining about lack of variety of coffee brands you may want to reconsider what’s really important for you at work.

After all, exceptional workplace is only one of many pieces of attracting great engineers. Definitely not the most important one.

A Couple of MS Project Myths

I’m no fan of MS Project. If I had to choose I rather hate it than love it. However there are popular myths on MS Project repeated over and over again which are just that – myths.

1. Microsoft Project is only for bigger organizations because it’s incredibly expensive.
How about MAPS subscription which gives you, among tons of other licenses, a license for MS Project Server and 10 sits of MS Project? This actually scales up to 10 people preparing MS Project Schedules and unlimited number of people who just update tasks (via Web Access). And that all for stunning price of $300. When you outgrow the initial setup you have to buy additional licenses for a standard price but it will take some time.

2. Microsoft Project has no real collaboration features.
MS Project as a desktop application has no collaboration features - that’s true. But if you take some time to setup MS Project Server you instantly get all the basic collaboration features (and I guess many advanced ones too). Of course it isn’t deployed in the cloud which is quite a disadvantage these days but still the argument doesn’t seem valid for me.

By the way this is one of areas where Microsoft completely screwed. In the early 00s they had everything to bring so called Project Management 2.0 to the table but missed the chance.

The Kanban Story: What We Do and What We Don’t Do

Last two posts of the series (on Kanban Board and on setting up whole thing) were Kanban implementation-in-a-pill kind of story. As you may guess that’s not all since Kanban doesn’t prescribe many things which you can use and, most of the time, you do.

To show the big picture there are two lists: practices we use and these we don’t.

Things we do

• Cross-functional team.
As I mentioned at the very beginning (the_beginning) we have cross functional team which is a great thing. Virtually every action connected with our product in any way is performed within the team.

• Co-location.
We sit together in one small room. That’s so damn great. I wouldn’t change it for private office even if you paid me.

• Roles.
We have old-school roles within the team. Developers who, guess what, develop. We have our commando guy who mixes roles of QA, system administration and maintenance. He could work as our bodyguard too. My role is project and product management which in our case could be called Product Owner as well. We also have a guy responsible for business development. Nothing fancy here. Everyone just knows what they’re supposed to do.

• Measuring lead time.
When I initially wrote a draft for this post this was on the “things we don’t do” list. For some time it wasn’t needed much since with no production environment it wasn’t crucial to know whether specific feature will be ready in 2 weeks or rather 16 days. Now, as we need more precise estimates, measuring lead time emerged as useful tool so we started doing that.

• Continuous improvement.
Implementing Kanban was an improvement to the old methodology. Starting to measure lead times was another. We look for tools or frameworks which improves the way we develop our products in terms of speed, quality, code readability etc. Nothing fancy here – we just try to make our lives a bit easier whenever we can.

• Unit testing.
We write and maintain unit tests. We don’t have 100% coverage though. I trust our developers would write unit tests wisely. Most of the time they add unit test covering a bug scenario as they fix bugs too.

• Continuous integration.
Oh, is there someone who doesn’t do that?

• Static code analysis.
There are coding standards we follow. They’re checked during every build. After a couple of weeks coding standards became native and basically invisible so it’s hard even to say that it’s a real practice.

Things we don’t do

• Iterations.
At least formal iterations. We don’t have sprints whatsoever. To bring some order we group some features and call them "iteration,” but that’s nothing like scrumish iterations. I’ll write a bit more about our pseudo-iterations soon since that isn’t something very standard done by-the-book.

• Stand-ups.
We have permanent sit-downs instead. Whenever something needs to be discussed we just start the discussion not waiting for morning stand-up whatsoever. No-meeting culture works surprisingly well so far.

• Formal retrospectives.
Same as in previous point. We just launch “I don’t like it, let’s change it” kind of chats whenever someone has some valuable input. You could call them informal retrospectives on call.

• Burndown charts.
We have no fixed scope within iteration to burn since we don’t have real iterations. I occasionally draw burndowns for a specific feature (a single sticky note). I do it mainly to check how my well works schedule simulation (estimates plus statistical analysis).

• Code review.
I’m a big fan of code review. I tried to implement it twice in my teams and failed twice. As long as developers won’t want to do code review I’m not going to force them. That just doesn’t work this way.

• Pair programming.
This one I don’t believe in. So do our developers.

• Test driven development.
We write unit tests. We do this after not before. This is another practice I’m not a big fan of and another which takes people who strongly believe in it to make it work.

If I forgot to mention something on either list just let me know what I omitted and I shall provide update.

I encourage you to read the whole Kanban Story.

Project Management 2.0 in 2001

Project management 2.0 is one of these buzz words I don’t trust much. To make the thing more vague people label different thing with PM 2.0 name. Anyway in general I won’t be far from truth coming with a simple timeline: Web 2.0 brought Web 2.0 applications supporting project management, applications took “2.0” name as a differentiator and voila their users magically started doing project management 2.0. Some mixed that with agile growing into strength to make the meal spicier.

Similar position seems to be occupied by Andrew Filev, CEO of Wrike, which I reviewed some time ago. In his guest article on Agile Software Development Made Easy blog Andrew stresses importance of tools in modern project management. Tools are there to help with on-line task actualization, easy collaboration and information sharing. In a role of Uncle Pure Evil we have good old MS Project. Andrew writes:

Traditional project management software applications, like MS Project, were created to support the waterfall project management style and are file-based. All the data on different projects are stored in various disconnected files and are usually accessible to the team members in the read-only mode. The existing combination of processes and tools does not encourage the team to contribute to project plans directly on a daily basis. With these solutions, someone has to connect all the pieces and bits of information into a bigger picture, and this person is the project manager. Traditional project management applications also are rarely suitable for distributed teams that work in a heterogeneous environment of multiple operating systems. This software is focused on the project manager and places him or her in the center of the project communications. It often means that the project manager must collect all the data and manually put the information into the project plan.

Well, sounds like using MS Project is crap. I’m no fan of the tool so you guys don’t need to discourage me to use it, but it still doesn’t sound appealing at all.

The problem is I used MS Project back then in 2001 and actually it solved every of problem mentioned above. We had mpp file deployed on a Project Server and the team was using MS Project Web Access (in their browsers) to update their tasks on a daily basis. Updates were instantly seen by team manager (we didn’t have anyone with “Project Manager” printed on their business card).

Sharing documents? Share Point Server dealt with this. Areas created for each version of software, design documents published, stored and edited there. Email alerts incoming every time something has been changed. And yes, it worked in a browser. I know SPS is a crap now. Imagine how crappy it was 8 years ago. But it did the job.

By no means would I advise you to use this combo (MS Project + SPS) now to aid your project management. The point I’m trying to make is that we basically done project management 2.0 back then in 2001 when no one even thought of that name. Why? Because good project management hasn’t changed that much over time. I fully agree here with Glen Alleman who points that project management principles remain the same.

OK we’re still trying to find better ways to reach our goals: better tools, more suitable methodologies, better adjusted practices etc but is that all so different than it used to be? Nah.

Above example shows how artificial are efforts to create new market just with new cool slogans. Yet it would be hard to say they’re completely unsuccessful too. Anyway don’t tell me PM 2.0 is great because it’s, well, 2.0, brand new, it’s all about collaboration and nice tools which come in package. Don’t tell me because we did it in 2001 already.

The Team of Trust

One of my recent posts triggered Glen to start a discussion which touched, among others, processes and lack of them in some situations. We went through a few of situations discussing how our teams deal with them.

As I was describing how we currently work one thing struck me: how much we trust each other when it comes to our areas of competency. When we choose development tools or frameworks I trust our devs they won’t come with something unreasonable employing “let’s try this because it’s cool” approach. When it comes to hardware and infrastructure we basically takes whatever our tech support guy advices us to. I haven’t heard much of questioning my area of product management either.

It’s like we all instantly know who’s an expert on a specific field and we just go to the guy ask what to do. On the other hand almost never decisions are made without consulting with the rest of the team. I’d say it’s easier to implement any decision when everyone is convinced to it, but I can say only for myself. I don’t know why others do the same, but they just feel an urge to do so, which is good so I don’t complain.

That is why we don’t need a formalized process which helps us to make decisions. Personally I’m not fan of processes. I’d keep things as they are as far as they go well. Unfortunately usually they don’t until you enforce some level of organization/processes/formalisms/you-name-it. Yet in small, competent team of trust you can go a long way without formalizing things around.

This is why this kind of team is such a precious thing. At least mine is. How about yours?