Author: Maik Seyfert

When coaching scrum teams it is alway a good idea to combine theoretical teachings with some exercises that simulate what you’re teaching in a short time. When thinking of which exercises I could use to simulated the methodology, “The Ball Point Game” I’ve done in a training class by Boris Gloger many years ago came to my mind. The game had a prompt impact on me in regards of Scrum. The game simulates all the sprint ceremonies, such as planning, sprint, review and retrospective.

What is the first thing to do when working as a Scrum Master with a new team? Whether the team is experienced in agile software development or not, it is important to create a basis that all future collaboration is build upon. This is the key to avoid misunderstandings based on assumptions or a lack of clarification which will affect all future collaboration and in worst case might damage trust. Therefore I believe a simple session or exercise should be the first step whenever start working with a team: Set expectation and boundaries! This post focuses on expectations as the basis for collaboration as Scrum Master with your team. Make use of your Scrum Master toolbox in order to keep …

The First Thing To Do As Scrum Master With Your Team Read more »

When implementing agile software development in teams, context seems one of the least noticed factors. That’s remarkable as it is one of the most important aspects to consider when adopting agile methods. With a series of posts I want to shed some light on that topic, looking at context in agile software developments from different angles. Contexts that are relevant and worth to consider when starting agile software development are organizational culture, team setup (distributed or collocated, skill levels, language and cultural differences) and experience in agile methods and principles (maturity).

Everyone who designs and manages products is familiar with the situation in which different ideas, requirements, market demands and legal regulations just pile up. You end up with a big stack of wishes and requirement and need to refine and prioritize them for implementation. Therefore a well maintained product backlog is highly beneficial and supports you in creating a good product. Here are practices that have proven useful to me over the years.

User stories in Scrum are work items that the team implements and turns into working software. The product owner is mainly responsible for developing user stories. However the team will have to work with the product owner to refine the user stories to ready user stories. This means the stories must be clear, concise, and immediately actionable. I’ve personally seen many teams struggling through the sprint, holding endless debates and get nothing done by the end of the sprint. The reason was simple that the user stories were not actionable and the result was frustration amongst team member as well as product owners.