Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Agile and Other Processes and the fly likes Organizational changes for a growing team Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Organizational changes for a growing team" Watch "Organizational changes for a growing team" New topic
Author

Organizational changes for a growing team

Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally I intended to post this last week during the giveaway, but as I just noticed that the authors seem to be still listening, I though I'd give it a try. Any other comments are welcome, too, of course!

After the team I'm working with struggled last year due to the bad economy, things are getting better now - actually so much better that for the last months we had *too much* to do. And the coming months look similar. The problem is, it looks like just adding man power won't cut it.

We are currently a team of four core developers, with two more developers assisting from time to time. We do develop for a whole bunch of different customers (a product which gets enhanced and customized for specific needs). For the last years, we always had two project managers.

In the past, we always developed very much "on demand", that is, we often wouldn't know what we work on the week after next week. Most often we would meet shortly at the start of the week and get "user stories" for the week from the project managers. The project managers where also available during the week, so that they could answer questions that arose during development.

Now that we get more and more project proposals, the PMs have more and more to do to speak to potential customers etc. Often one of them is away for a whole week, often both are away for consecutive days. Additionally they feel that they can't afford any longer to do a planing meeting with us every week.

So the current proposal suggests to give us developers more responsibility. We will only do a bigger planning meeting with the PMs once a month, and do the weekly planning without them. They also want every developer to be responsible for specific components of the system, so that they know a single contact person if they need to discuss something component-specific. (With "component" I mean functional modules like "report generation", "diagram plotting", "web ui" etc. pp.)

I embrace the increased responsibility (we actually sometimes felt like the PMs were near to micromanaging us), but I also fear waste due to lack of communication with the PMs - we already encountered problems scheduling tasks in the weekly planning, because we didn't really know about business priorities. (I have to admit, though, that we are absolute beginners with this approach - we actually didn't have a monthly planning meeting yet. If that sounds somewhat backwards to you - well, it is. But that's what you have to do here to get something started... )

So if anyone has any experience to share, tips to give or Organizational Patterns to suggest that I should take a look at , I would be deeply grateful!


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30919
    
158

Background:
Over the past 3 years, our team has grown from three (really one, but I wasn't on then) to eight developers. It's a green-field project, so three years ago was the beginning and we have been refining our process since. Our manager travels for business fairly often too.

Of your two project managers, is it safe to assume that you speak to them regularly? (It doesn't need to be a formal planning session.) One thing our manager tries to do once or twice a week is go around the table and ask what we are working on. This serves as a sanity check to make sure our individual planning is in line with business priorities. And serves as a forum for the PM to remember to tell us when priorities change. It takes about 5-15 minutes to have the meeting and is well worth it. We hold this after another meeting while everyone is in the room, but you could easily do it in a standing meeting or by conference call.

Another thing we do about once a month is go through the high level chart. It shows the deadlines for deliverables on all our related projects. This is similar to your planning meaning. We also have component ownership. We try to rotate components periodically to spread ideas. Although you probably don't need to worry about that since you pair.

We have application ownership in addition to component ownership. The applications are business apps while the components are technical apps. The application ownership provides the contact person to talk to about status. It also allows different team members to "manage" the tasks on a lower level.

I think it's important to have a team architect in addition to component owners though. You need to have someone looking over the whole system at a higher level. Sometimes people get so caught up in their components that they miss that. We don't have a person with the title of architect, but we do have one or two people who evolved to fill that role.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Neil B. Harrison
author
Greenhorn

Joined: May 03, 2005
Posts: 8
Wow, Ilja, where to start? We have an entire pattern language (one of four) on Piecemeal Growth of the Organization. I'll try to give a few helpful nuggets.

It's clear you are experiencing growing pains -- moving to a paradigm of serving more customers. This is changing the dynamics of the organization: the responsibilities of the roles are changing, and some new roles are likely being introduced. On the positive side, you have more Developer Controls Process. On the negative side, it sounds like overall communication is being reduced. This is a big warning bell.

Communication is a key: if you look at the case studies in the book, you will see organizations that are HIGHLY connected -- it seems like everyone is talking to everyone. I worry that you are seeing a break between the customers' needs (via the PMs) and the developers, as well as between the PMs themselves and the developers.

Here are some things that might help, before this becomes a problem:

Unity of Purpose: Make sure everyone is on the same page about what your product is all about, your target market, etc. It sounds like you have the potential to lose this over time, though you are probably all right at the moment (maybe?)

Architect Controls Product: This is the technical reflection of Unity of Purpose: you need someone to ensure the technical aspects of the product stay sane. One of the developers will (preferably naturally) assume this role. (Aside: You may know that XP eschews "architecture". But every product has an architecture, regardless of how it comes about. You want to make sure that the architecture doesn't degrade into chaos...)

Surrogate Customer: The PMs are assuming this role -- make sure they know it, and take responsibility for it. That means they need to be available to talk to you -- a lot. A monthly meeting is probably not sufficient. The Architect role can help a lot here.

Function and Component Owner: The PMs are pushing for it; it will probably help grease some of the communication. If you have collective ownership, it will probably work fine underneath it.

Interrupts Unjam Blocking: The developers will have to interrupt the PMs to get questions answered. I think you will need this, but at the same time, I suspect the PMs might resent it. So expect some friction until you figure out how to work together.

Well, that's a start. I don't want to be self-serving, but there's so much more in the book that I'd recommend you pick up a copy and share it with your PMs...

Neil


Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0131467409/ref=jranch-20" target="_blank" rel="nofollow">"Organizational Patterns of Agile Software Development"</a>
James Coplien
author
Greenhorn

Joined: Oct 26, 2004
Posts: 22
There are four or five points I can make here, not all of which are consistent with each other (an artifact of having imperfect information about the organization) but which might be food for thought.

Let me naively point out that your approach might be predicated on the fact that developers were doing makework or otherwise had "slop time" that implies they had cycles to spare on some PM tasks. They will now be spending these cycles on tasks related to the project management responsibilities they have taken on. One simple question to ask yourself is what work developers will stop doing to take on these new responsibilities. Think of it as a zero-sum game. There's no free lunch. You may conclude that you either need more project managers (though I doubt it) or a new person with a new role (quite likely) or some other conclusion that I can't see here from several thousand miles away.

The way you talk about the change smacks a bit of "empowerment." You can think of it as the project managers "empowering" the developers. I hate that term. Empowerment is abdication. Studies at Rutgers University showed that empowerment in an organization indeed led to more local decision making -- at the expense of effective communication across teams. There is a tradeoff between Developer Controls Process (which is a bit like what you're talking about here -- give the Developer control over most decisions whose granularity is smaller than one week, because they can optimize tasks for parallelism and effect the highest work throughput that way) and the need for the guiding hand of coordination. We talk about this problem at length in the Organizational Patterns book (6.1.4, and a couple of other places like Community of Trust).

If your Project Managers were one of the communication hubs of the team -- a primary mechanism for shufflling information between developers or a major locus of Big Picture items -- then this scheme of pushing the work off on developers not only will increase their load but may harm the communication structure. Communication with the PMs is only one (albeit important) issue: also at stake is the communication within the team (of what might be otherwise tacit knowledge, knowledge that a PM's involvement makes explicit) and flows to other key stakeholders (library vendors, customers, tool suppliers, funders and other patrons, etc.)

I suggest you do an analysis of your organization's communication with respect to your internal communication paths under the old regime, and see if the new organization cuts major arteries of communication that you formerly depended on. There may be new paradigms of organization that will help your new structure work swimmingly, and there are patterns that might come to play in making that happen. Some of the patterns that might come to play here are Architect Controls Product (the architect playing the role of pontificus maximus, "building bridges" of communication), Face to Face before working remotely and, well, a host of others. It's difficult to prognosticate without more first-hand insight.

One thing you didn't mention is the need that PMs have to be in touch with what developers are doing. Developers know what can and can't be done. If PMs, wearing a sales or marketing hat, start selling things to customers without having been in touch with development realities for a week, they can get out of touch with what is possible or reasonable in the current development trajectories. Don't forget that PMs are people, too :-) and that they need to be richly fed with information about what's going on in the trenches.

Another interesting question: You said that developers have increased responsibility. You can't have responsibility without control. What new control have you been given that you didn't have before? Does the shift in responsibility also mean a shift in accountability? Most important, does the responsibility shift to people who have the authority (in the sense of "know-how") to take on those reponsibilities? There is nothing worse than being given accountability (often confused with responsibility) for something over which you have inadequate control and/or for which you do not have the proper authority (background, grounding, training, resources). That's another audit you can do. It's an alternative audit we've applied to organizations in the past, and it can be scary.


James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Thank you all very much for the answers - they are thought provoking!

I'm actually a little bit more relaxed today. In the morning we had a short emergency planning meeting, where we showed our PMs the burn up charts we produced yesterday, quite impressively depicting the fact that we can't possibly do all the work that is scheduled until the end of the quarter. They were quite responsive.

Things are never as bad as they look. I'm still a little bit scared by that "empowerment" thought, but it's not really backed by facts, much more of a gut feel. I will have to wait how things will develop; this discussion will be of great help to me to still see the wood regardless of all the trees...

Now let me work through your posts top-down...

Originally posted by Jeanne Boyarsky:
Of your two project managers, is it safe to assume that you speak to them regularly?


When they are on site, yes. They attend the daily stand up meetings and also regularly come to check status as you described above.

In the past weeks, this didn't work as well, simply because they weren't on site very much. This week is much better. I'm not sure what the future will bring in this regard.

Another thing we do about once a month is go through the high level chart. It shows the deadlines for deliverables on all our related projects.


We have started such charts (the burn up charts I mentioned above) three weeks ago, and they start to show effect. We update them weekly, and can raise issues in the stand ups, so perhaps it will just work out well.


We also have component ownership. We try to rotate components periodically to spread ideas. Although you probably don't need to worry about that since you pair.


What is your experience with component ownership and rotating? Why did you introduce ownership? How often do you rotate?


We have application ownership in addition to component ownership. The applications are business apps while the components are technical apps. The application ownership provides the contact person to talk to about status. It also allows different team members to "manage" the tasks on a lower level.


This evolved in our team, without ever being formalized. Actually we are currently trying to reduce the "application ownershipness" in our team, to reduce the lottery number* for the business apps.


I think it's important to have a team architect in addition to component owners though. You need to have someone looking over the whole system at a higher level. Sometimes people get so caught up in their components that they miss that. We don't have a person with the title of architect, but we do have one or two people who evolved to fill that role.


In my opinion we are doing quite well in this regard, without having an official role for this, either. I'd say that two of the four core developers are recognized as the ones to be consulted for architectural matters (and who feel responsible for interfering even when not being asked ).

* politically correct term for "truck number"
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Neil B. Harrison:
Wow, Ilja, where to start? We have an entire pattern language (one of four) on Piecemeal Growth of the Organization.


Your book is on the top of my buying list already.

It's clear you are experiencing growing pains -- moving to a paradigm of serving more customers. This is changing the dynamics of the organization: the responsibilities of the roles are changing, and some new roles are likely being introduced. On the positive side, you have more Developer Controls Process. On the negative side, it sounds like overall communication is being reduced. This is a big warning bell.


That's *exactly* how I feel! One thing we are struggling with is the "new roles" thing - we really are in the dark in this regard.


Communication is a key: if you look at the case studies in the book, you will see organizations that are HIGHLY connected -- it seems like everyone is talking to everyone. I worry that you are seeing a break between the customers' needs (via the PMs) and the developers, as well as between the PMs themselves and the developers.


Yes, that's my fear also. Actually I am sure I can already sense a bit of a disconnect between the developers and the PMs - but more in the sense that the PMs stop to understand (or even a little bit to care about) the development team's situation.

The current strategy regarding customers' needs is to let the developers have more direct customer contact, e.g. by having them participate in, or even drive, requirements discussion meetings.

Unity of Purpose: Make sure everyone is on the same page about what your product is all about, your target market, etc. It sounds like you have the potential to lose this over time, though you are probably all right at the moment (maybe?)


Currently I'm not concerned about it - I actually feel that this improved in the recent past. But it's certainly important to keep an eye on!

Architect Controls Product: This is the technical reflection of Unity of Purpose: you need someone to ensure the technical aspects of the product stay sane. One of the developers will (preferably naturally) assume this role.


I think we are doing well here - see my response to Jeanne. (As an aside, this is more a matter of "become more sane", as this was very much neglected in the first years of development.)

(Aside: You may know that XP eschews "architecture". But every product has an architecture, regardless of how it comes about. You want to make sure that the architecture doesn't degrade into chaos...)


I'm not sure how an architecture could degrade into chaos and still conform to the four XP rules of Simple Design - but I'm also not aware of a single globally accepted definition of "architecture", so you might mean something different by the term than I do...


Surrogate Customer: The PMs are assuming this role -- make sure they know it, and take responsibility for it. That means they need to be available to talk to you -- a lot. A monthly meeting is probably not sufficient.


Yes, that's one of my main concerns. I actually think that the PMs feel they can't fill the role any longer at the same intensity as in the past. That's why they want us to have more direct contact to the customers. I'm not sure what to think about that.


The Architect role can help a lot here.


That's not obvious to me. Could you please elaborate? Thanks!


Function and Component Owner: The PMs are pushing for it; it will probably help grease some of the communication. If you have collective ownership, it will probably work fine underneath it.


Yes, the more I think about it, the more I think we should at least give it a try.


Interrupts Unjam Blocking: The developers will have to interrupt the PMs to get questions answered. I think you will need this, but at the same time, I suspect the PMs might resent it. So expect some friction until you figure out how to work together.


I'd actually say that they take interruptions well when they are available. Problem is when they aren't.


Well, that's a start. I don't want to be self-serving, but there's so much more in the book that I'd recommend you pick up a copy and share it with your PMs...


Mhh, I guess I will have to request a copy for our company's library.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by James Coplien:
Let me naively point out that your approach might be predicated on the fact that developers were doing makework or otherwise had "slop time" that implies they had cycles to spare on some PM tasks. They will now be spending these cycles on tasks related to the project management responsibilities they have taken on. One simple question to ask yourself is what work developers will stop doing to take on these new responsibilities. Think of it as a zero-sum game. There's no free lunch. You may conclude that you either need more project managers (though I doubt it) or a new person with a new role (quite likely) or some other conclusion that I can't see here from several thousand miles away.


As far as I can tell, the current thought of our PMs is to try with more developers, and see wether new roles emerge.

The way you talk about the change smacks a bit of "empowerment." You can think of it as the project managers "empowering" the developers. I hate that term. Empowerment is abdication. Studies at Rutgers University showed that empowerment in an organization indeed led to more local decision making -- at the expense of effective communication across teams.


That's *so* on the point of my feelings! Where can I find more about those studies?

If your Project Managers were one of the communication hubs of the team -- a primary mechanism for shufflling information between developers or a major locus of Big Picture items -- then this scheme of pushing the work off on developers not only will increase their load but may harm the communication structure. Communication with the PMs is only one (albeit important) issue: also at stake is the communication within the team (of what might be otherwise tacit knowledge, knowledge that a PM's involvement makes explicit) and flows to other key stakeholders (library vendors, customers, tool suppliers, funders and other patrons, etc.)


Communication within our development team is quite good. Most of the time we all sit in one room - one of us has his desk in the neighbor room, but we pair a lot and have actually removed the door from the connecting doorway.

Information flow between the development team and the outside, that's what I will have to keep an eye on...


I suggest you do an analysis of your organization's communication with respect to your internal communication paths under the old regime, and see if the new organization cuts major arteries of communication that you formerly depended on.


Yes. That's not easy, though, because many of those communication paths were quite informal, tacit or even unconscious in the past. I will have to muse about it...


One thing you didn't mention is the need that PMs have to be in touch with what developers are doing. Developers know what can and can't be done. If PMs, wearing a sales or marketing hat, start selling things to customers without having been in touch with development realities for a week, they can get out of touch with what is possible or reasonable in the current development trajectories. Don't forget that PMs are people, too :-) and that they need to be richly fed with information about what's going on in the trenches.


Fortunately our PMs are quite concious about their limited knowledge - that's another reason for them wanting us to be more closely involved in customer negotiations.


Another interesting question: You said that developers have increased responsibility. You can't have responsibility without control. What new control have you been given that you didn't have before? Does the shift in responsibility also mean a shift in accountability? Most important, does the responsibility shift to people who have the authority (in the sense of "know-how") to take on those reponsibilities? There is nothing worse than being given accountability (often confused with responsibility) for something over which you have inadequate control and/or for which you do not have the proper authority (background, grounding, training, resources). That's another audit you can do. It's an alternative audit we've applied to organizations in the past, and it can be scary.


The only fear I have in this regard is that we don't have enough know-how of business priorities to effectively decide about which tasks to schedule for which (one week) iteration. But perhaps I'm overreacting here, and we just need to learn how to deal with it (by somehow getting the knowledge in time).

Besides that, our PMs are fortunately sane - they don't expect us to work miracles, but just to inform them in time should we discover a quarter's work package to be unrealistic.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30919
    
158

Ilja,
Even when they are off site, you can still speak to them. Our manager calls in (to at least one team member) when he is at the users'. Obviously, this wouldn't happen when the manager is on vacation. But going three weeks without any communication is a bit much.

We've always had code ownership because I can't get my team to buy into collective code ownership. Note that this is different from the component ownership I am describing (which is a good thing.) The component owner is the one who can make decisions about the component. For example, if someone wants to add a method to the Balance component, he/she checks with me before doing it. That provides an interim level of consistency. It's lower than the application, since components are shared and prevents the chaos of everyone just making changes.

We formalized component ownership when we started sharing a lot of components so there would always be a person to go to when discussing or having a question about a component. Before that, there were informal component owners. We don't have a schedule, but tend to rotate every 3-4 months for active components. We rarely rotate for stable components as there isn't enough change to be worth it.

Good to hear you have unofficial architects. Why do I suspect you are one of them It really does help though. Especially when the team is growing.
[ May 10, 2005: Message edited by: Jeanne Boyarsky ]
James Coplien
author
Greenhorn

Joined: Oct 26, 2004
Posts: 22
Originally posted by Ilja Preuss:

quote:
The way you talk about the change smacks a bit of "empowerment." You can think of it as the project managers "empowering" the developers. I hate that term. Empowerment is abdication. Studies at Rutgers University showed that empowerment in an organization indeed led to more local decision making -- at the expense of effective communication across teams.

That's *so* on the point of my feelings! Where can I find more about those studies?

It was a report published by Rutgers. I don't have the cite rite here, but I do have a populist citation that refers to it:
<dl><dt>Yates, Ronald E.</dt><dd>"Employee Empowerment Efforts Found to be Weak." Chicago Tribune, December 26, 1995.</dd></dl>
I know they have it in their on-line archives, and I almost certainly have a copy sitting around somewhere. Hmmm; write to me (you can send me mail through this interface, right?) and I'll send you a copy. (I'm happy to send you my Email, but I'm guessing that this web site is a great place for spammers to pick up addresses, so I didn't want to post it here...)
[ May 10, 2005: Message edited by: James Coplien ]
Neil B. Harrison
author
Greenhorn

Joined: May 03, 2005
Posts: 8

--------------------------------------------------------------------------------

The Architect role can help a lot here.

-------------------------------------------------------------------------------

That's not obvious to me. Could you please elaborate? Thanks!


In some situations, the Architect role can become the focus for making sense of all the feature requests coming in (in your case, from the PMs,) as well as managerial requests. In healthy organizations, we often see the Architect strongly connected to the Developer, the Project Manager, and to the Requirements gatherer roles. The Developer role is also tied closely to the others. (When we do organizational studies, we produce cool graphical renderings of this we call sociograms.)

Given your size, and the way you are currently communicating, this may be less important for you -- at the moment.
 
Don't get me started about those stupid light bulbs.
 
subject: Organizational changes for a growing team