What should be the lenght of a Scrum sprint? There is no unique answer to this question. In this blog post, Mitch Lacey provides some key factor to consider when you try to choose the right sprint length for your Scrum project. These should be considered looking at the expected duration of the project, the customers/stakeholders and the Scrum team. His conclusion is that the right sprint length balances a craving for customer feedback and input with the team ability to deliver and the customer’s ability to respond.
One of the first steps in an Agile adoption is the formation and organization of agile teams. Leadership often struggles to figure out how many people should be on each team, what skill sets should included, and whether the team should be focused on solution components, feature delivery, or a mix.
How do you manage activities that don’t seem directly related to features in your Scrum sprints? This blog post discusses why it is a problem when Scrum teams start to wonder about having time to manage infrastructure, technical debt or test framework. For Johanna Rothman this is the sign that the culture is not Agile enough and that the product owner doesn’t want to take iteration time to schedule anything other than features in an iteration. She offers seven hints on how to improve this situation, saying that product owners that don’t want to fund technical debt will instead create more of it.
What do you do when models collide? Every team has their own mental model of how things are supposed to work. We often call these “processes” or “methodologies”, but they are really just a shared understanding of how things get done by a team. Sometimes, however, problems can’t be tackled by just one team because of size, company structure, diversity of required skill sets, or any number of other reasons.
There is a tendency to use agile software development approaches and all their practices simply because it is in the book. Why don’t we select the tools based on the context of the task we are trying to complete?