You mentioned that all of your team are remote workers, right? Distributed Agile is painful. Latitude hurts and longitude kills. This is really good advice: http://agileinaflash.blogspot.com/2011/04/rules-for-distributed-teams.html
Agile is hard enough to introduce when everyone is in the same room. It's going to be nearly impossible without a very experienced Agile coach for your situation. My advice is get a good Agile consultant to help you work out all of these issues (this person can start as the SCRUM master). -- WSS4CF - WS-Security framework for CF http://wss4cf.riaforge.org/ On 3 September 2011 08:12, Nathan Strutz <[email protected]> wrote: > > Tariq, > Very thoughtful response. I appreciate it! > > We haven't fully embraced Agile in our group. Mostly for the fact that it's > a pain nobody wants to suffer, so we find ways to get around it. I guess > that's where the scrum master role comes in. I don't know that we have > anyone that forceful on the team. We probably have some who are forceful > against it though. I like the idea of syncing up sprints between projects, > so we all have the same release schedule - that would make it feel more > like > we are working at the same pace, same schedule and together. > > What did you have to do to make your team take the agile pill? Did you (or > do you still) have any holdouts? > > > nathan strutz > [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] > > > On Fri, Sep 2, 2011 at 3: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:347212 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
