We call that "the 15 minute rule" Russ.....if you have stared at the screen for more than 15 minutes...ask for help.
Asking for help is a sign of wisdom and not weakness is what we tell everyone ;-) Works great and usually results in some light-hearted ribbing because dufus (even though double checking the spelling 27,000 times) has spelled a variable name wrong ;-) Everyone has little chuckle and back to work. On Sat, 2011-09-03 at 00:04 +0100, Russ Michaels wrote: > The SCRUMM approach is good in theory, but a lot of people find it annoying > and embarrassing and try to get it over and done with as soon as posisble. I > find it works better to just get developers to socialise in a non formal way > and talk about their projects. The biggest problem is getting a lot of > developers to ask for help when they get stuck, many folks will spend a week > battling with a problem when it could have been solve din 10 minutes by > asking someone else. > Getting developers to interact is an informal way more often prompts them to > actually talk about what their working on and bring up challenges they are > facing. > > On Fri, Sep 2, 2011 at 11:24 PM, Tariq Ahmed <[email protected]> wrote: > > > > > >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:347208 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
