I asked if he was looking for things like the following:
- Configuring the Agile Organization
- How to Build an Agile IT Department
- Design Principles for Highly Adaptive Business Systems (and a companion article)
- Social Network Analysis
- Organizing the Agile Company
- Agile Methods for Large Organizations - Building Communities of Practice
- Show Them How (article from CIO Magazine)
- Dion Hinchcliffe's article.entry on Post-Modern Enterprise Architecture: Service-Oriented, Agile, Decentralized
Mishkin Berteig wrote that he thinks that "this is one of those places where Lean and Agile really start to blur into one-another via queuing theory." I mentioned that I think Theory of Constraints (TOC) also blurs-in with Agile and Lean via queuing theory as well, as evidenced by the work of David J. Anderson.
Mishkin also wrote:
"The answer is that in a lean portfolio management situation this is a mandated constraint for projects. Projects simply are not approved unless they are able to fit inside that timebox. If you have a larger project, you must break it into two.... and you must not make it fit by making a larger team.... which leads to the other side: all teams should be roughly the same size, team composition should change very slowly, and people should be dedicated to a single team at a time."I replied that, rather than the above, the practice of "pairing" and "refactoring" might actually scale up by refactoring people across projects and teams every 3-6 months. I'm thinking about the case of an IT department that supports several so called "products", and in any 3-6 month period, they of course get requests against those projects, as well as requests for new projects.
Now, not every request and/or project has the exact same priority. So having each project or product prioritize it's backlog and then work on whatever "fits" into the next iteration sort of assumes that each project has the same priority (if all the teams are more-or-less the same size and experience mix).
If, instead of each project/product separately prioritizing it's backlog, they might instead do something like:
- Form a combined backlog list across the entire department
- Have representatives [governance] from each customer organization in the enterprise meet, and prioritize the department-wide backlog list
- And whatever shows up as the topmost requests that can be handled in the next financial quarter with the available staffing is what gets worked.
Wouldnt that be essentially creating a "pull" system for "allocating resources" to projects?
If pairing were used, it would help the "refactored" folks come up-to-speed more quickly on the new product or project. And after awhile, I'd think most folks in the department would have a reasonably high knowledge level and awareness (and appreciation) about all the "important" projects going on in the department, and understand the overall "business" big-picture a little better (at least for that department).
That would still seem agile to me. It looks similar to some matrixed approaches, but I think its a bit different because it is more fine-grained and incremental. I'm thinking it would help "scale" a single agile project and team into an overall "agile" department servicing an entire portfolio of projects, and making sure that those projects that are most valued for the given quarter get the appropriate amount of resources relative to how the "Customer" prioritized the backlog across the entire portfolio.
Wouldn't it? Or would team-dynamics and other people-issues make it too darn hard to incrementally rotate/refactor people in that manner?
Isn't this also an example of using the Five Focusing Steps of TOC? (Would this be an example of a team/project constraint elevated to the level of the department and using dynamic allocation of the entire department's staff to subordinate to the constraint and place the most staff on the projects with the most valued requests?)
3 comments:
Nice blog with good information on articles.
Thank you for providing relevant information. I’ll keep visiting it for updated information.
Keep it up
You said:
Wouldnt that be essentially creating a "pull" system for "allocating resources" to projects?
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.
If you move people around too much, you don't give teams a chance to go through the forming, storming, norming, performing progression.
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).
Thanks Mishkin for your comments. You say: "If you move people around too much, you don't give teams a chance to go through the forming, storming, norming, performing progression."
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).
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.
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".
I think it would be the same as with frequently rotating pairs, it's a bit unusual at first, but it becomes "normal."
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.
Post a Comment