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)
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.
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)
Software Estimation Without Guessing
Evolutionary Anatomy of Test Automation Code
Patterns of Agile Journeys