Building Frameworks For Internal Use

Suppose you have a number of products, or a number of applications, that share some common functional needs. It seems obviously reasonable to create a separate team to build those functions in common. Often these grow to become known as a framework, and the product or application teams are expected to use it.

It’s a seductive concept, but don’t do it. Why not? I can think of several reasons. (Continued)

Enterprise Agile

Smaller organizations have an easier time adopting Agile development practices than do larger ones.  Once you get beyond a handful of teams, things start to get much more complicated.  Not only that, but no “cookie-cutter” approach seems to work very well.  Context always matters, and even more so in the large.

Bob Payne and I recently had a conversation with Sanjiv Augustine about the issues, and some ways of dealing with them.

Combined backlog for multiple projects

Our teams sometimes have multiple projects. I am wondering what is the best way and what is the SCRUM way of handling this. My feeling is that the best way is to have a single backlog per team (even if this means that in a sprint the team is working on backlog items belonging to multiple projects). I think the purists will recommend splitting the team and having multiple backlogs.

That’s what Gilad Gruber asked on the Scrumdevelopment list. This question reminded me of a client I once had. (Continued)