>So my question to the list is this: How do you organize your teams of >developers successfully? Please let me know what you do, or what you have >seen that actually works.
Hi Nathan. I manage a team of 11 technical folks, and when I was promoted to management we had a similar challenge. Internal teams that build apps that support the business tend to get into this silo'd structure because what they're building has a specialized purpose, and as the business demands more of these specialized applications, it usually starts off with just one guy building it... and then they become the lone expert. With a heavy demand for change, the low hanging fruit it to use the guy who knows the app vs. risking someone unfamiliar with it who'll have to go through the learning curve. Management wise, it is a motivator to give people ownership. But, it is also a huge risk to have SPOKs (Single Points of Knowledge). Sure you can have knowledge bases, Yammer.com, IMs, Wikis, etc... and it's good to do that, but that's just information. It's only until you have a deep understanding of the domain/context are you able to leverage that information as knowledge. One technique I used was to maintain is a Knowledge Matrix of all our applications/features, I map out who knows what and what their strength is, and how critical/complex that feature is in order to calculate risk. I can then prioritize by risk, and make sure that other developers are getting exposure to these areas. Another highly successful thing we did was switching to Agile/Scrum development practices. Although you guys on a Visio chart are one team, you're functioning as independent one man teams. A Scrum practice you can start tomorrow are daily standups - from 10am to 10:15am everyone stands up together and discusses what they did yesterday, what they're doing today, and if they're stuck on anything (in order to invite others to help). It's time limited, no additional conversation allowed - that can be done outside of that meeting, no sitting down and getting comfortable... the team needs to feel confident that it never ever goes beyond 15mins. It'll help promote some awareness of what everyone is doing and encourage some communication. But it won't be enough to solve the problem as no one will really know deeply what you're talking about unless they're very familiar with the application. So the next step would be to truly get the team functioning together cohesively by going full Agile. Everyone is working together on the same cycle, and although different applications, you're working together as if it were one project. Very short iterations of 2 to 4 weeks, requirements are broken down into small little pieces - the team picks who is working on what, but no one is limited to working on just "their app". You can try to learn it yourself - but getting in an agile training organization like cPrime.com to give your company a 3 day onsite bootcamp on how the process works is the fastest way to make it happen. Hope that helps. Tariq Ahmed http://www.aftershox.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:347206 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
