Comments on: Musings About Agile Program Management http://www.jrothman.com/blog/mpd/2010/07/musings-about-agile-program-management.html Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk. Fri, 18 May 2012 15:02:36 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Musings About Agile Program Management - PM Hut http://www.jrothman.com/blog/mpd/2010/07/musings-about-agile-program-management.html/comment-page-1#comment-96824 Musings About Agile Program Management - PM Hut Sat, 01 Jan 2011 15:59:54 +0000 http://jrothman.com/blog/mpd/?p=9126#comment-96824 [...] The original article can be found at: http://www.jrothman.com/blog/mpd/2010/07/musings-about-agile-program-management.html [...] [...] The original article can be found at: http://www.jrothman.com/blog/mpd/2010/07/musings-about-agile-program-management.html [...]

]]> By: jfbauer http://www.jrothman.com/blog/mpd/2010/07/musings-about-agile-program-management.html/comment-page-1#comment-79762 jfbauer Tue, 03 Aug 2010 16:04:17 +0000 http://jrothman.com/blog/mpd/?p=9126#comment-79762 Very much interested in the knowledge/experienced shared in the large agile team arena. If the 300 person team is focused on building a brand new product without any legacy dependencies, then I assume the exercise is more straight forward. If thee 300 person team is an amalgamation of various IT resources, more a virtual team extending existing systems, then I believe the challenge is increased exponentially as those virtual resources are pulled in multiple directions, technology road maps cross or don't cross when needed, etc. Very much interested in the knowledge/experienced shared in the large agile team arena.

If the 300 person team is focused on building a brand new product without any legacy dependencies, then I assume the exercise is more straight forward.

If thee 300 person team is an amalgamation of various IT resources, more a virtual team extending existing systems, then I believe the challenge is increased exponentially as those virtual resources are pulled in multiple directions, technology road maps cross or don’t cross when needed, etc.

]]> By: André Faria Gomes http://www.jrothman.com/blog/mpd/2010/07/musings-about-agile-program-management.html/comment-page-1#comment-77161 André Faria Gomes Wed, 07 Jul 2010 16:58:13 +0000 http://jrothman.com/blog/mpd/?p=9126#comment-77161 Hi Johanna. Even when building huge products, don't you think that could be useful, having smaller teams, working in difference parts of the product? I think that the sense of being part of a team that is working to achieve a common goal is a really important in an agile approach, and the bigger the team the smaller this sense, due to communication, and the problems others you already know. I've experienced some cases where two teams were working in the same product but in different projects running in parallel. It worked very well. Good luck in this challenge. I'll be following your next posts. Thanks for sharing your experiences. Best Regards, André Faria Hi Johanna.

Even when building huge products, don’t you think that could be useful, having smaller teams, working in difference parts of the product? I think that the sense of being part of a team that is working to achieve a common goal is a really important in an agile approach, and the bigger the team the smaller this sense, due to communication, and the problems others you already know.

I’ve experienced some cases where two teams were working in the same product but in different projects running in parallel. It worked very well.

Good luck in this challenge. I’ll be following your next posts.

Thanks for sharing your experiences.

Best Regards,
André Faria

]]> By: Veretax http://www.jrothman.com/blog/mpd/2010/07/musings-about-agile-program-management.html/comment-page-1#comment-77138 Veretax Wed, 07 Jul 2010 12:46:36 +0000 http://jrothman.com/blog/mpd/?p=9126#comment-77138 Wouldn't it be possible to take a team of 300 developers and find a way to break up a large product into various components and sections to develop simultaneously so that you could have say 30 teams of ten working on these components? Or would that violate your ideas of agile? Wouldn’t it be possible to take a team of 300 developers and find a way to break up a large product into various components and sections to develop simultaneously so that you could have say 30 teams of ten working on these components? Or would that violate your ideas of agile?

]]> By: Stephan http://www.jrothman.com/blog/mpd/2010/07/musings-about-agile-program-management.html/comment-page-1#comment-77054 Stephan Tue, 06 Jul 2010 17:50:55 +0000 http://jrothman.com/blog/mpd/?p=9126#comment-77054 Dear Johanna, How does 'agile' reduce Technical and schedule risk? Where does this differ from 'plain' program management? regarding 2, I can just as easily claim that if you don't have a clear architecture vision up front, "you will be wrong". You'Lessons Learned just as likely find out half-way through that your first assumptions were wrong, because you didn't see the whole picture. What kind of products are being created through an 'agile' program? Best Regards, Stephan Dear Johanna,
How does ‘agile’ reduce Technical and schedule risk?
Where does this differ from ‘plain’ program management?
regarding 2, I can just as easily claim that if you don’t have a clear architecture vision up front, “you will be wrong”. You’Lessons Learned just as likely find out half-way through that your first assumptions were wrong, because you didn’t see the whole picture.
What kind of products are being created through an ‘agile’ program?

Best Regards,

Stephan

]]>