tag:blogger.com,1999:blog-10280668.post114038997321002305..comments2023-09-22T06:05:17.495-05:00Comments on Brad Appleton's ACME Blog: Agile IT Organization Refactoring?Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-10280668.post-1142753238427032522006-03-19T01:27:00.000-06:002006-03-19T01:27:00.000-06:00Thanks Mishkin for your comments. You say: "If you...Thanks Mishkin for your comments. You say: "<I>If you move people around too much, you don't give teams a chance to go through the forming, storming, norming, performing progression.</I>"<BR/><BR/>Very true. If I treat the department as separate teams, this would certainly be the case. Yet some have said the same of pair-programming and frequently rotating pairs (e.g., several times a week, even daily).<BR/><BR/>I'm thinking that it essentially treats the department as a single team but takes pairing to the next level. If I have a single large-ish team, working together on a single large-ish system, short and small "teamings" form around features and components all the time.<BR/><BR/>I can either rotate that knowledge around or make people stick with the same feature/component long-term. If theyre all part of the larger team, and if the small subteamings are for pieces of the same larger system, I cant help but think that it wouldnt have to go thru the whole forming-storming-norming-performing for every "teaming".<BR/><BR/>I think it would be the same as with frequently rotating pairs, it's a bit unusual at first, but it becomes "normal."<BR/><BR/>As for the attempt to "manage a queue size of people" - I don't see how "people" are being queued here. The people are being allowed to self-organize to address the customer-pulled work-items of highest-priority.Brad Appletonhttps://www.blogger.com/profile/15136106921504315995noreply@blogger.comtag:blogger.com,1999:blog-10280668.post-1142632011042242512006-03-17T15:46:00.000-06:002006-03-17T15:46:00.000-06:00You said:Wouldnt that be essentially creating a "p...You said:<BR/><I>Wouldnt that be essentially creating a "pull" system for "allocating resources" to projects?</I><BR/><BR/>And of course, the answer is "yes"... but the problem is that you are creating a pull of resources instead of a pull of work items. Lean systems pull work items into a fixed set of work units and manage queue sizes, quality, etc. in order to get good cycle times.<BR/><BR/>If you move people around too much, you don't give teams a chance to go through the forming, storming, norming, performing progression.<BR/><BR/>As well, you can't manage a queue size of people in the same way that you manage a queue of work items (which is the whole point of pull systems).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10280668.post-1141122284969632482006-02-28T04:24:00.000-06:002006-02-28T04:24:00.000-06:00Nice blog with good information on articles.Thank ...Nice blog with good information on articles.<BR/><BR/>Thank you for providing relevant information. I’ll keep visiting it for updated information.<BR/><BR/>Keep it upAnonymousnoreply@blogger.com