1. Architects should write code. Period.
2. I would put a Senior Developer in the Architect role (additional hat) – with the responsibility for a good architecture, the responsibility to find a consens with the other developers, and the final word if no consens can be achieved
3. For larger companies, or companies with scaling demands, I’d add (at least) one Architect who writes code, moving from team to team and feature to feature, but who has 80% of his time a strategic architecture role

My thoughts over the years out of my head :-)

I’m really happy, that I got the tip for your blog.

Maybe you can help me. ;) Who would be the architect in your team? In bigger companies you often have a person called “… Architect”. Sometimes they are developers too, sometimes not.

An idea? :)

What would you suggest from your experience? I’m highly interested in this (and in the PM / dev ratio :-)

One thing I’m curious though is the 5-7 developers and the (I think?) only 1 QA person. Is that the ratio you meant? Can you explain a little more on your reasoning behind this? Thanks!

Cheers,
Phatthana

Stephan, the 2-Pizza Teams at Amazon’s link doesn’t work. It has a single line break on it!

See you!

“Your a jackass. Probably a consultant who loves to bill clients for work that a team of 1-3 developers can do with one being a client relationship person.”

Or you could read:

http://codemonkeyism.com/about/

Cheers
Stephan

My last 5 man team assignment where I was billed at $125/hr as part of a 5 man team I did 8 hours of real work but had to bill for 40 hr a week for 4 weeks. In total each individual did about 8 hours of work as it passed trough the timeline. The client still got billed about (125*5*40*4) $100,000.

Don’t give me that “maybe it your project shit”. I have 20 years of experience and have seen it all. There are too many specialist and managers on software development these days.

I have been on those team you describe. It is overcapacity. But I have seen worst with 4 project managers who I cannot describe/define what they are for/do because when it came time for sub task to be completed (i.e. the initial data load, etc.), it was late because nobody was responsible for handling that sub-task. In the end they got a developer to do it at the last minute at a 4 week delay until completion. I still don’t know what those 4 project managers did.

I think that while the ideas of Brooks are in principle correct, their expression in the book is somewhat arcane. Some of the skills that were highly important at the 70s (e.g.: documentation) are much less needed in a modern team, and vice-versa.

Thus, your post is fulfilling the very important role of “translating” Brooks to our times.

Thanks.

For me the role of the SM is to enable the team to be the greatest team ever, irrespective of the project/tasks they’re working on while the role of the team is to deliver the greatest product ever. Different roles, different focus; one is team focused, the other delivery focused. Sort of like pair programming in XP, one pair of eyes on the big picture, one pair on the finer details.

Plus, also remember that in essence your SM should be busy 150% of the time dealing with impediments and, well, anything that could make the team (and the company for that matter) perform better. If they’re busy on tasks for the deliverable, they’re bound to lose focus and inevitably become an impediment themselves!

nice post. There is one role I am missing from your description. What about the Scrummaster? There is literature that suggests he should be part of a cross functional team. I tend to concur. In my experience a Scrummaster can only “feel” the problems of a team if he is at least colocated if not even working on some tasks of the team.

What do you think?

Joerg

I’ve read Brooks several times (some years ago) and hold it in high regard, so it’s very probable that my ideas mix with thos of mythical Man-Month.

Like you, I think that the magic number is around 8-9. I think one of the factors in getting to this limit is the ability to effectively break a story (or whatever the team’s unit of work is) to developer-oriented tasks. Too many developers – the PO, Designer & Tester will be overworked. Too few developers – these guys will feel underemployed. A really delicate balance.

The exact number is influenced by a combination of many factors so getting it requires some trail-and-error.

Also, it all resonates with some of the ideas of Brooks (Mythical Man-Month). He used the “surgical team” metaphor to explain his view on cross-functional teams. He also had nice insights about team size, communication boundaries, etc. (“adding people to a late project makes it later!”)

Unfortunately most projects I have been involved lately are very far away from those insights …

The worst thing I have seen recently are development teams that do at least 50% of their time 3rd level support / maintenance of the system in production.
In this case I think it is impossible become productive. And it is impossible to do something like Scrum with short iterations, because any dev can just be absorbed with a “production-ticket” at any time …

Have you also come across situations like that? How can you address this problem, so that teams can become productive again?

In a small team environment every developer is a person, rather than just another engineering unit, and has a good take on the entire project.

The tradeoff is it becomes more difficult to replace that person, but the benefit is in your project actually having a chance of working out the way it should.

It’s almost never true that throwing more developers on a given project produces better results. Given the proper environment, and people, a small team size of 5-7 developers can do better than a team of 100.

Also, there’s little point having a dream development team unless you have a dream marketing / sales team (or is that a given.. :)

Lastly one other important aspect is the support of the finished product with customers. IMO, they also need to be alongside the development team, they need to have intimate understanding of how the product works, be excellent at writing documentation and so on.

I like your team, but would make the scope wider to ensure there was a dream team for everything…

“If you have someone in your team who can take on all the tasks that inevitably surface around test environments you’ll save a lot of time for the rest of the team.”

You’re right, I’d like to have on too. From my experiences, sprints with direct involvement from operations went smoother.

“Good post by the way.”

Thanks.

If you have someone in your team who can take on all the tasks that inevitably surface around test environments you’ll save a lot of time for the rest of the team. Let the developers worry about developing features and killing bugs, and have operations support them.

Good post by the way.