Re: How do you compose your dev teams?
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 str...@gmail.com 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 ta...@dopejam.com 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:
How do you compose your dev teams?
Hi everybody. I have a little management-type dilemma that I can't solve. I'm no manager, so I'm trying to collect info about how other people do it. I work in a small group of CF developers (7 of us) inside a big company (100k+ of us). The way we work is that pretty much everybody owns one or more applications in our group's portfolio of programs (probably 10 apps, 3 or 4 are big important). My manager has noticed that we don't communicate enough and has started threatening drastic measures, moving people around and putting us where we don't want to be. I am not sure of his motivation, but it may be partially the hit-by-a-bus protection, wondering if his apps will be supported if one of us eats a piece of public transportation. 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. I'll start us off. I asked my friend Mario, who says they have a team of core developers that do RD at a higher level, overseeing the technical direction of their applications. Those RD projects are flowed out into application development teams, and then they have a lot of other developers who do front-ends and integration work. Regular flow-down meetings help people share ideas and copy adapt similar projects. Mario's team compositon sounds awesome, but he has a lot more people than I do. What do you do? nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] ~| 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:347188 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
Two words. Walkie talkies. On Fri, Sep 2, 2011 at 1:12 PM, Nathan Strutz str...@gmail.com wrote: Hi everybody. I have a little management-type dilemma that I can't solve. I'm no manager, so I'm trying to collect info about how other people do it. I work in a small group of CF developers (7 of us) inside a big company (100k+ of us). The way we work is that pretty much everybody owns one or more applications in our group's portfolio of programs (probably 10 apps, 3 or 4 are big important). My manager has noticed that we don't communicate enough and has started threatening drastic measures, moving people around and putting us where we don't want to be. I am not sure of his motivation, but it may be partially the hit-by-a-bus protection, wondering if his apps will be supported if one of us eats a piece of public transportation. 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. I'll start us off. I asked my friend Mario, who says they have a team of core developers that do RD at a higher level, overseeing the technical direction of their applications. Those RD projects are flowed out into application development teams, and then they have a lot of other developers who do front-ends and integration work. Regular flow-down meetings help people share ideas and copy adapt similar projects. Mario's team compositon sounds awesome, but he has a lot more people than I do. What do you do? nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] ~| 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:347191 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
I have a little management-type dilemma that I can't solve. I'm no manager, so I'm trying to collect info about how other people do it. Actually, no, you're a manager (whether you like it or not!) Sorry about that. I work in a small group of CF developers (7 of us) inside a big company (100k+ of us). The way we work is that pretty much everybody owns one or more applications in our group's portfolio of programs (probably 10 apps, 3 or 4 are big important). My manager has noticed that we don't communicate enough and has started threatening drastic measures, moving people around and putting us where we don't want to be. I am not sure of his motivation, but it may be partially the hit-by-a-bus protection, wondering if his apps will be supported if one of us eats a piece of public transportation. 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. I'll start us off. I asked my friend Mario, who says they have a team of core developers that do RD at a higher level, overseeing the technical direction of their applications. Those RD projects are flowed out into application development teams, and then they have a lot of other developers who do front-ends and integration work. Regular flow-down meetings help people share ideas and copy adapt similar projects. Mario's team compositon sounds awesome, but he has a lot more people than I do. What do you do? Mario's approach seems a bit ... ambitious ... for your current environment. You might try something simpler: having a second participant on each project who participates in periodic code reviews, for example. This is something that could be scheduled to occur once a week, and the owner could brief the second participant on the changes made that week, and that participant could review them and ask questions. Of course, this will only work to the extent that they take it seriously - there's no enforcement mechanism here to ensure that real knowledge transfer is happening. On the other hand, you could probably do this without much disruption of your current efforts. You could even go a step farther and make the second participant responsible for documentation (which would be reviewed by the owner for accuracy and completeness). Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| 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:347193 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
Nathan, I guess I have questions. Usually there is a reason (real or perceived) when a manager starts making such 'threats'. The only stated reason so far is 'communication'. What does he mean by communication? Whom is he expecting the communication to be with? Is there something other motivation? If it's general knowledge sharing, then start by pointing to the documentation for each project. You have that right? if not, then he's right to be concerned. Each project should be documented enough for a person with no clue about the project can come in and get started. This is never fun to do. It's something we are trying to do here at CF Webtools. We have an internal Wiki that we upgraded and are making an effort to document each clients site. With our developers spread around the country it's becoming important that we do this. If it's communicating the projects, status, progress etc, then maybe short meetings or status updates once a week are needed. IMHO some managers just need to quantify things. Provide the material he needs so he can do that and quantify you're jobs. If true cross training on these projects are needed, there are valuable tools to use. Besides documentation, tried pair programming. Take someone that has never worked on a project, put them at the keyboard and have the other person sit next to them and guide them along. Once each person has enough of the basics for each project, then maybe a project updates to the team to keep everyone informed will help. Or hey, try project swapping. Swap projects for a week or two. -- Just my random vague thoughts Wil Genovese Sr. Web Application Developer/ Systems Administrator CF Webtools www.cfwebtools.com wilg...@trunkful.com www.trunkful.com On Sep 2, 2011, at 2:12 PM, Nathan Strutz wrote: Hi everybody. I have a little management-type dilemma that I can't solve. I'm no manager, so I'm trying to collect info about how other people do it. I work in a small group of CF developers (7 of us) inside a big company (100k+ of us). The way we work is that pretty much everybody owns one or more applications in our group's portfolio of programs (probably 10 apps, 3 or 4 are big important). My manager has noticed that we don't communicate enough and has started threatening drastic measures, moving people around and putting us where we don't want to be. I am not sure of his motivation, but it may be partially the hit-by-a-bus protection, wondering if his apps will be supported if one of us eats a piece of public transportation. 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. I'll start us off. I asked my friend Mario, who says they have a team of core developers that do RD at a higher level, overseeing the technical direction of their applications. Those RD projects are flowed out into application development teams, and then they have a lot of other developers who do front-ends and integration work. Regular flow-down meetings help people share ideas and copy adapt similar projects. Mario's team compositon sounds awesome, but he has a lot more people than I do. What do you do? nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] ~| 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:347194 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
On 9/2/2011 3:12 PM, Nathan Strutz 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. Sounds like you guys could use some sort of internal social media thing to stay in tune with each other. You didn't say what the actual locations were so it is hard to say. If they are completely separate locations, it would be different than all in one building. I curious as to how the cross project fertilization works small groups. In general, you have to own your project (or at least your part of it) to do your best work. Having someone back you up is an expense that most companies won't want to sustain. It is only a backup plan which is rarely needed. I would say that more important is to get the bigger picture stuff sorted out like general guidelines, source control, testing, documentation, etc. sorted out across the team. If someone leaves, those remaining would know where to look for things. You also might want to build a library of primitive functions for the group. That way, people are using the same building blocks if that is possible. There are other ways to keep in touch, but most developers that I have met were very busy so the communication is tough. The hit by the bus thing was mentioned to me at an annual review. I just asked if they could afford another developer. It was never mentioned again. -- LinkedIn: http://www.linkedin.com/pub/8/a4/60 Twitter: http://twitter.com/RogerTheGeek Google+: https://plus.google.com/117357905892731200369 ~| 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:347196 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
Our tools. Paymo.biz or time tracking and task management. Google Apps for internal communication and tracking project related emails (using ActiveInbox) and document sharing. There is a paymo plugin for Gmail that allows you to turn emails into tasks. projectlocker.com for source control Kayako SupportSuite for communicating with clients. We use the ticketID as reference in the Paymo tasks so far has worked well working with teams and external suppliers, contractors. Russ On Fri, Sep 2, 2011 at 8:50 PM, Roger Austin raust...@nc.rr.com wrote: On 9/2/2011 3:12 PM, Nathan Strutz 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. Sounds like you guys could use some sort of internal social media thing to stay in tune with each other. You didn't say what the actual locations were so it is hard to say. If they are completely separate locations, it would be different than all in one building. I curious as to how the cross project fertilization works small groups. In general, you have to own your project (or at least your part of it) to do your best work. Having someone back you up is an expense that most companies won't want to sustain. It is only a backup plan which is rarely needed. I would say that more important is to get the bigger picture stuff sorted out like general guidelines, source control, testing, documentation, etc. sorted out across the team. If someone leaves, those remaining would know where to look for things. You also might want to build a library of primitive functions for the group. That way, people are using the same building blocks if that is possible. There are other ways to keep in touch, but most developers that I have met were very busy so the communication is tough. The hit by the bus thing was mentioned to me at an annual review. I just asked if they could afford another developer. It was never mentioned again. -- LinkedIn: http://www.linkedin.com/pub/8/a4/60 Twitter: http://twitter.com/RogerTheGeek Google+: https://plus.google.com/117357905892731200369 ~| 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:347197 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
Great feedback so far, everyone. Thanks, keep it up. Will. The communication point is the only one I perceive. It has to do with lack of active developer knowledge on various systems, so dev-to-dev communication - I have my system and no one else really knows it, certainly not like I do. It's expected to a degree, but for the hit-by-a-bus scenario. The communication point comes from the complexity of our software and our loss of ability to add features fast enough. This is a technical debt situation, especially for some of these projects. Customers are getting agitated, developers are getting frustrated. My manager thinks we need to reorganize our group, so I'm looking for pointers to see how others do it. Projects are generally over-documented, CMMI style, so a lot of fluff and specifics, but not always something that says here's the system, here's how it works, you are up to speed in 15 minutes. It's like we have application silos, but we should be one single silo. I like the wiki idea. We had weekly status meetings, but it end up that no one cared what the status of the other projects was. I don't care if a project I don't touch is working on a feature I've never heard of (and i'm willing to take blame if I should). Thanks for your thoughts. nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Fri, Sep 2, 2011 at 12:40 PM, Wil Genovese jugg...@trunkful.com wrote: Nathan, I guess I have questions. Usually there is a reason (real or perceived) when a manager starts making such 'threats'. The only stated reason so far is 'communication'. What does he mean by communication? Whom is he expecting the communication to be with? Is there something other motivation? If it's general knowledge sharing, then start by pointing to the documentation for each project. You have that right? if not, then he's right to be concerned. Each project should be documented enough for a person with no clue about the project can come in and get started. This is never fun to do. It's something we are trying to do here at CF Webtools. We have an internal Wiki that we upgraded and are making an effort to document each clients site. With our developers spread around the country it's becoming important that we do this. If it's communicating the projects, status, progress etc, then maybe short meetings or status updates once a week are needed. IMHO some managers just need to quantify things. Provide the material he needs so he can do that and quantify you're jobs. If true cross training on these projects are needed, there are valuable tools to use. Besides documentation, tried pair programming. Take someone that has never worked on a project, put them at the keyboard and have the other person sit next to them and guide them along. Once each person has enough of the basics for each project, then maybe a project updates to the team to keep everyone informed will help. Or hey, try project swapping. Swap projects for a week or two. -- Just my random vague thoughts Wil Genovese Sr. Web Application Developer/ Systems Administrator CF Webtools www.cfwebtools.com wilg...@trunkful.com www.trunkful.com On Sep 2, 2011, at 2:12 PM, Nathan Strutz wrote: Hi everybody. I have a little management-type dilemma that I can't solve. I'm no manager, so I'm trying to collect info about how other people do it. I work in a small group of CF developers (7 of us) inside a big company (100k+ of us). The way we work is that pretty much everybody owns one or more applications in our group's portfolio of programs (probably 10 apps, 3 or 4 are big important). My manager has noticed that we don't communicate enough and has started threatening drastic measures, moving people around and putting us where we don't want to be. I am not sure of his motivation, but it may be partially the hit-by-a-bus protection, wondering if his apps will be supported if one of us eats a piece of public transportation. 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. I'll start us off. I asked my friend Mario, who says they have a team of core developers that do RD at a higher level, overseeing the technical direction of their applications. Those RD projects are flowed out into application development teams, and then they have a lot of other developers who do front-ends and integration work. Regular flow-down meetings help people share ideas and copy adapt similar projects. Mario's team compositon sounds awesome, but he has a lot more people than I do. What do you do? nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] ~| Order the Adobe Coldfusion Anthology now!
Re: How do you compose your dev teams?
Roger, Spot on - all of us are completely remote. Some from our various sites around the country, some from our homes centered around the Phoenix area. We've been making an effort to get closer with monthly meetings, code reviews and tech insertion presentations, but a lot of that ends up being just enough to stave off management intervention. Good thoughts. Thanks. nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Fri, Sep 2, 2011 at 12:50 PM, Roger Austin raust...@nc.rr.com wrote: On 9/2/2011 3:12 PM, Nathan Strutz 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. Sounds like you guys could use some sort of internal social media thing to stay in tune with each other. You didn't say what the actual locations were so it is hard to say. If they are completely separate locations, it would be different than all in one building. I curious as to how the cross project fertilization works small groups. In general, you have to own your project (or at least your part of it) to do your best work. Having someone back you up is an expense that most companies won't want to sustain. It is only a backup plan which is rarely needed. I would say that more important is to get the bigger picture stuff sorted out like general guidelines, source control, testing, documentation, etc. sorted out across the team. If someone leaves, those remaining would know where to look for things. You also might want to build a library of primitive functions for the group. That way, people are using the same building blocks if that is possible. There are other ways to keep in touch, but most developers that I have met were very busy so the communication is tough. The hit by the bus thing was mentioned to me at an annual review. I just asked if they could afford another developer. It was never mentioned again. -- LinkedIn: http://www.linkedin.com/pub/8/a4/60 Twitter: http://twitter.com/RogerTheGeek Google+: https://plus.google.com/117357905892731200369 ~| 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:347199 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
On 9/2/2011 4:01 PM, Nathan Strutz wrote: Projects are generally over-documented, CMMI style, so a lot of fluff and specifics, but not always something that says here's the system, here's how it works, you are up to speed in 15 minutes. It's like we have application silos, but we should be one single silo. I like the wiki idea. Wow, what level CMMI did you achieve? Maybe you are over documenting and just creating make-work for developers. It might be worth stepping back so you have time to communicate. How many support staff are supporting your CMMI initiative? Maybe management needs to get y'all some help so you have more time. Looks like management wants a business continuity plan in case of a disaster (proverbial bus.) I suggest looking at it from that direction without starting some communications plan that will just piss off the help. -- LinkedIn: http://www.linkedin.com/pub/8/a4/60 Twitter: http://twitter.com/RogerTheGeek Google+: https://plus.google.com/117357905892731200369 ~| 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:347200 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
On 9/2/2011 4:10 PM, Nathan Strutz wrote: Roger, Spot on - all of us are completely remote. Some from our various sites around the country, some from our homes centered around the Phoenix area. We've been making an effort to get closer with monthly meetings, code reviews and tech insertion presentations, but a lot of that ends up being just enough to stave off management intervention. One thing you could do right away is set up Google+ hangouts and discuss with everyone ideas for doing this. Sort of like a stand up meeting thing on Monday mornings. You could do some brainstorming to come up with ideas. -- LinkedIn: http://www.linkedin.com/pub/8/a4/60 Twitter: http://twitter.com/RogerTheGeek Google+: https://plus.google.com/117357905892731200369 ~| 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:347201 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
Nathan, I've only seen the hit-by-a-bus scenario happen once, but thankfully it was a slow moving bus and she was only bruised and only out a couple of days. Yes, it really happened. However, the 'terminated' or 'just up and quit' scenario is more likely and I have been the person that has to handle the fallout. Simultaneously taking on the former employees project fully and training someone else to do the project that I had been doing full-time. Based on that experience I can tell you that cross training in each others projects would have helped. Status update meetings had almost no help other than I knew the other guys project existed. A setup docs explaining 'How to get setup and going' in the dev environment would have been useful. The details on the production environment would have been nice. Maybe we each should have cared a bit more about each others work during those status updates. Peer reviews would have been useful. We all like to think our code don't stink. And it might not, but I can tell you that I don't always know the best way to get something done. Peer reviews help with many aspects, such as helping each other learn more techniques. Preventing the reinvention of wheels, because the guy next to you knows how to do something you've never had to do. - Having just saw another post to this thread by you stating that the team is all remote, then I have to say Skype and screen sharing are great tools. Acrobat Connect is also great, you can screen share a three way conference call for free. Wil Genovese Sr. Web Application Developer/ Systems Administrator CF Webtools www.cfwebtools.com wilg...@trunkful.com www.trunkful.com On Sep 2, 2011, at 3:01 PM, Nathan Strutz wrote: Great feedback so far, everyone. Thanks, keep it up. Will. The communication point is the only one I perceive. It has to do with lack of active developer knowledge on various systems, so dev-to-dev communication - I have my system and no one else really knows it, certainly not like I do. It's expected to a degree, but for the hit-by-a-bus scenario. The communication point comes from the complexity of our software and our loss of ability to add features fast enough. This is a technical debt situation, especially for some of these projects. Customers are getting agitated, developers are getting frustrated. My manager thinks we need to reorganize our group, so I'm looking for pointers to see how others do it. Projects are generally over-documented, CMMI style, so a lot of fluff and specifics, but not always something that says here's the system, here's how it works, you are up to speed in 15 minutes. It's like we have application silos, but we should be one single silo. I like the wiki idea. We had weekly status meetings, but it end up that no one cared what the status of the other projects was. I don't care if a project I don't touch is working on a feature I've never heard of (and i'm willing to take blame if I should). Thanks for your thoughts. nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Fri, Sep 2, 2011 at 12:40 PM, Wil Genovese jugg...@trunkful.com wrote: Nathan, I guess I have questions. Usually there is a reason (real or perceived) when a manager starts making such 'threats'. The only stated reason so far is 'communication'. What does he mean by communication? Whom is he expecting the communication to be with? Is there something other motivation? If it's general knowledge sharing, then start by pointing to the documentation for each project. You have that right? if not, then he's right to be concerned. Each project should be documented enough for a person with no clue about the project can come in and get started. This is never fun to do. It's something we are trying to do here at CF Webtools. We have an internal Wiki that we upgraded and are making an effort to document each clients site. With our developers spread around the country it's becoming important that we do this. If it's communicating the projects, status, progress etc, then maybe short meetings or status updates once a week are needed. IMHO some managers just need to quantify things. Provide the material he needs so he can do that and quantify you're jobs. If true cross training on these projects are needed, there are valuable tools to use. Besides documentation, tried pair programming. Take someone that has never worked on a project, put them at the keyboard and have the other person sit next to them and guide them along. Once each person has enough of the basics for each project, then maybe a project updates to the team to keep everyone informed will help. Or hey, try project swapping. Swap projects for a week or two. -- Just my random vague thoughts Wil Genovese Sr. Web Application Developer/ Systems Administrator CF Webtools www.cfwebtools.com wilg...@trunkful.com
Re: How do you compose your dev teams?
On 9/2/2011 4:10 PM, Nathan Strutz wrote: Roger, Spot on - all of us are completely remote. Some from our various sites around the country, some from our homes centered around the Phoenix area. We've been making an effort to get closer with monthly meetings, code reviews and tech insertion presentations, but a lot of that ends up being just enough to stave off management intervention. One other thing that I think is critical is to get an inventory of all the applications and who is working on them. That should be used to set up a risk assessment as to what is the most critical to have backup. You might even get management's thoughts on what they think are critical or most important. Then, you have an idea of what steps to take. You might get away with only having backup to a few systems rather than every single one. Not everything people work on will destroy the company. Loss of one developer could wipe out a quarter of earnings when another developer leaving might just annoy people temporarily. -- LinkedIn: http://www.linkedin.com/pub/8/a4/60 Twitter: http://twitter.com/RogerTheGeek Google+: https://plus.google.com/117357905892731200369 ~| 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:347203 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: How do you compose your dev teams?
Create a maintenance role that is dedicated to fielding bug reports and prioritizing them for resolution. Prioritization may come from higher up, but the role could at least asses the reports to explain what the problem is and describe steps to resolve (not actually resolve). The role would be across all of the apps. Once the role is defined, rotate the team members responsible for it every week or two. It is going to open up communication between the person handling the maintenance role and the person who knows the most about the particular app in question. At the same time, it is going to allow the people in the maintenance role to gain more knowledge about the other apps. We do something similar and I think it would work well in your situation. .:.:.:.:.:.:.:.:.:.:.:.:. Bobby Hartsfield http://acoderslife.com http://cf4em.com -Original Message- From: Nathan Strutz [mailto:str...@gmail.com] Sent: Friday, September 02, 2011 3:12 PM To: cf-talk Subject: How do you compose your dev teams? Hi everybody. I have a little management-type dilemma that I can't solve. I'm no manager, so I'm trying to collect info about how other people do it. I work in a small group of CF developers (7 of us) inside a big company (100k+ of us). The way we work is that pretty much everybody owns one or more applications in our group's portfolio of programs (probably 10 apps, 3 or 4 are big important). My manager has noticed that we don't communicate enough and has started threatening drastic measures, moving people around and putting us where we don't want to be. I am not sure of his motivation, but it may be partially the hit-by-a-bus protection, wondering if his apps will be supported if one of us eats a piece of public transportation. 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. I'll start us off. I asked my friend Mario, who says they have a team of core developers that do RD at a higher level, overseeing the technical direction of their applications. Those RD projects are flowed out into application development teams, and then they have a lot of other developers who do front-ends and integration work. Regular flow-down meetings help people share ideas and copy adapt similar projects. Mario's team compositon sounds awesome, but he has a lot more people than I do. What do you do? nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] ~| 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:347204 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
On Fri, Sep 2, 2011 at 12:12 PM, Nathan Strutz str...@gmail.com 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. One thing you might suggest is one day a week, have developers pair on an app they don't own (pairing with that app's owner). That will help knowledge transfer as well as providing a second set of eyes to help with design, review bug fixes, and to create test cases. That won't be too disruptive but will really help get everyone up to speed on everyone else's app, as well as help those developers who normally work solo on an app. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) ~| 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:347205 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
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
Re: How do you compose your dev teams?
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 ta...@dopejam.com 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:347207 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
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 ta...@dopejam.com 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
Re: How do you compose your dev teams?
Thanks, Sean. It's stuff like this I know, but I need to force-feed it to the rest of the group. nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Fri, Sep 2, 2011 at 3:11 PM, Sean Corfield seancorfi...@gmail.comwrote: On Fri, Sep 2, 2011 at 12:12 PM, Nathan Strutz str...@gmail.com 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. One thing you might suggest is one day a week, have developers pair on an app they don't own (pairing with that app's owner). That will help knowledge transfer as well as providing a second set of eyes to help with design, review bug fixes, and to create test cases. That won't be too disruptive but will really help get everyone up to speed on everyone else's app, as well as help those developers who normally work solo on an app. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) ~| 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:347209 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: How do you compose your dev teams?
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 ta...@dopejam.com 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:347210 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
