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?)