Development Dream Teams

I would go as far as to say that the “Operations guy” role is mandatory rather than optional. In my current project we started out without one and has been suffering since.

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.

@Hans-Eric: I guess it depends on the stories you develop. If you change the configruation, add services, add new servers, add load etc. it is mandatory to haven an operations guy in the team.

“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.

I would want the Product Manager / PO to be very clued up both on the business side and the technical side.

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…

I’d like to iterate that it’s a very good idea of keeping the developer team size small (5-7 people max).

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.

All very true!

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?

Stephan, I really appreciate your ability to take a complicated matter and explain it in a down-to-earth manner.

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!”)

@Itay: Thanks.

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.

Hi Stephan,

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

@Joerg: I wouldn’t consider the ScrumMaster as part of the team, more like a referee. But I do agree, the ScrumMaster should be colocated, as I always was. Even when offered my own office, I did stay with the team because “can only “feel” the problems of a team if he is at least colocated”

I have to agree with Stephan on this, I’ve tried the role of SM and coding at the same time and it got a bit difficult to handle, not impossible though but not ideal at all.

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!

Stephan,

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.

you need someone extremely creative, not just technical. creativity will solve the impossible problems in ways never imagined. You also need an insanely great tester. one awesome tester is worth 20 average ones easily.

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.

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.

@Joe: Hu?

“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

Two pizza, eh? That’ll cut down on late teens and their black-hole-for-a-stomach hungers, unless they are very, very good. :-)

Nice one.

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

See you!

@Isaac: Thanks. Fixed.

Nice article Stephan. Eric Evans told me once that teams should have the size of an eight-oared – if not it gets out of
sync. But these kinda teams: more desire than reality. Of course everyone wants to
work in a team with experienced developers with generalizing specialists, insanely good testers, domain experts, scrummasters who know their job and good product-managers who are capable managing the backlog.
From my experiences many teams are not real teams but rather project groups with micromanaging and no real collaboration.
Building real D/B/T-Teams (http://www.agile2009.com/files/session_pdfs/Scaling%20Software%20Agility%20Overview%20Agile%202009.pdf)
is hard shit and requires a lot of organizational/environmental changes. Most of the companies i’ve worked for didn’t have
such an environment and/or people. That’s the sad truth.

Cheers,
Phatthana

Thanks for posting this, helps me solidify some of my own ideas on team composition.

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!

[...] this matter on and off for a while, but what brought it to my full attention was this article on Dream Development Teams. In it the author talks about an ‘Operations Guy’. An operations guy would be [...]