November 11, 2011

Webinar Recording - Agile XXL: Scaling Agile for Project Teams

Events
Agile
Thanks to everyone who joined us for our Scaling Agile for Project Teams webinar. The recording is now available on YouTube if you missed the webinar or want to watch it again. Q&A from the session follows. http://youtu.be/4vin2K_3qvs

Q&A

Where do you recommend locating product owners for the work done in India? And, are time lags a problem? It’s going to depend on your situation. My first recommendation is to have the product owner with the team. There is no reason that should not be possible, unless your customers are in another location. The product owner is a representative of the customer. Having that product owner sitting with the team in India and working with customers and stakeholders that may be in another country would be the optimal way to work. Regarding time lags, they are always a problem especially when you have distributed teams. That’s just something the organization is going to have to navigate. My experience has just been negotiation with different teams rotating schedules. Why don’t we ever see India working night shifts to match U.S. time zones? I don’t know if we could say never because I have worked on teams where Indian team members were working night shifts. In Agile Retrospectives: Making Good Teams Great, written by Diana Larson and Esther Derby, they talk about working agreements. What I would recommend for this and the previous question is that teams need to come up with a working agreement to determine the best way to work on the project. The sub teams will need to have working agreements. I worked on a team where we had our own working agreements with product owners and with anyone who was working offshore. I do recommend reading the Agile Retrospectives book to learn more about working agreements for teams. How scalable are Agile methods? This depends on many factors including the organization’s industry and the organization’s ability to embrace the Agile mindset. There are going to be plenty of people who will tell you that you are not Agile. If you look at where your organization is with Agile methods, and account for industry context and project size, you may find that you’re more Agile than you think you are. Agility is relative and can also go to the Agile mindset, like I said, of continuous improvement, empowering teams, getting close with the customer—not many organizations are set up to embrace those values. Your organization must embrace those values to help determine how scalable Agile is going to be for your organization. Do you know of any specific “experience reports” from early adopters in scaling Agile projects? Jeff Sutherland has written a couple papers on scaling Scrum teams. Dean Leffingwell has written a book and several papers. Dean’s approach is more methodology neutral, which is what I encourage, especially here in the U.S. When I talk to teams and people at conferences the common definition for Agile is Scrum but there is more out there than Scrum. I like to take more of a general approach and that’s the one thing I like about Dean’s work. If you have any questions about that you can email me (bustamantea@seapine.com) and I’ll send you some links. What early experiments can we conduct to test scaling an Agile team? My general recommendation is to scale up before you scale out. If you can grow the team locally before distributing, that will help you test many of the practices with other teams. If you scale up before you scale out, you’ll be able to test some of those communication advantages, feedback loops, and the testing process locally before trying to apply it to a distributed team. When you start getting distributed, you’ll find you have more communication issues. So, I highly recommend growing the team locally. It's easy to lose the big picture when teams are doing Agile. What's your recommendation on maintaining the big picture view and who should compile and communicate that overall picture? I definitely agree. The more communication channels there are, the easier it is to lose sight of the big picture. Usually, there is a delivery manager (or someone in a similar role, could be a senior project manager) who is responsible for maintaining the big picture view. As I mentioned in the webinar, the team will lay out many details in their working agreements and this will be one of them. For projects with many team members, especially distributed team members, it will be critical to understand how information (status, big picture, etc.) will be communicated up to senior management. More than likely, that communication will need to come from one person because senior managers will not want to reconcile multiple updates. This person will need to have a deep understanding of how Agile teams operate. Can I apply for a PDU for my PMP certification requirements for participating in this presentation? Yes, you can claim one (1) PDU for this webinar. Use Category B: Continuing Education. I am a PMP, so I understand the importance of this. Thanks for asking! How can we scale Agile to regulated products (product that should follow 21 CFR for example?) This is a great question. In fact, it’s such a great question that there is no simple way to answer it in the space I have here due to the intricacies of regulated software development. We are currently writing an eBook about Agile and regulated environments, which should be released early next year. Check our web site or grab our blog RSS feed (http://feeds2.feedburner.com/theseapineview ) to stay informed.