Articles and videos on creating and managing cross-functional Scrum teams: scrum master, product owner and development team.
The average Scrum team delivered a 35% improvement in velocity at Yahoo [1] where teams properly coached delivered 300-400% improvements. The best Scrum Master at MySpace peaked at 267% of initial velocity after 12 weeks and averaged 168% increase in velocity over 12 Sprints. Most teams were less successful.
Project charter discussions and documentation focuses traditionally on project scope and the goals and objectives for the project. To address specificity of Agile project, the author of this article has recently created and successfully utilized an Agile Development Team Charter. It differs from usual project charter as it focuses more on the ‘how’ of the project.
We would like solutions delivered fast without compromising quality, user experience, implicit requirements and non-functional aspects such as scalability and performance. This would have been easier, if we had all the time in the universe. Doing this in a sustainable manner becomes a huge challenge for teams as there are multiple competing forces at play and because software development is very complex.
This article discusses the challenges that Agile brings to the appraisal process. Agile methodology focuses on team performance more than on the individual. The objectives of the team aren’t easily broken down by individual; one cannot appraise the individual on the basis of team performance. This article presents a workable solution for appraising Scrum team members. This will address problems raised while remaining within the Agile framework and philosophy. If a team is self-organizing, per the Agile framework, we can empower that team to raise itself to a “self-appraising team.”
As Scrum teams should be self-managed and self-organized, they need empowerment, because without it, it is difficult for self-management and self-organization to happen. In this article, Jerry Rajamoney shares that the high-priority impediment item he has repeatedly faced as a ScrumMaster and struggled to solve is empowering the team. He gives four situations that could be considered as signals of lack of empowerment. He also notices that some issue come from the fact that managers are often asked to play the role of product owner or ScrumMaster, which creates confusion between the organizational role and their Scrum team role. A solution to these issues is proposed.
Even if the Scrum daily stand-up meeting isn’t a status report, it is often easy for team members to slip into a pattern of providing status-related information. In this article, Eric King proposes different techniques that you can integrate in your daily stand-up meting to get more value out of it, setting a positive tone for the daily activities as people grow both as individuals and as a team. These techniques are Speed Scrum, Pass-the-Conch Scrum, Time-Box Scrum, Challenge Scrum, Impediments-Only Scrum, Award Scrum, Business Value-Focused Scrum, No-Board Scrum, Whiteboard Scrum and Buddy Scrum. Being able to overcome and adapt lies at the core of Scrum team. The stand-up is an essential part of our Agile/Scrum process, but team members should constantly seekg new ways to challenge each other. Even if you still use the proven stand-up approach, you can have great success in periodically spicing it up with the methods above. You will get the job done, but you will also find that a little laughter at the beginning of the day can set a great tone.
Scrum likes to rely the technical practices recommended by eEXtreme Programming to improve the software quality. Pair programming is one of these practices, even if surveys tell us that it is not used as much as other practices like test-driven development (TDD). In this article, Zee Spencer shares four common pitfalls of pair programming and tell us how to avoid them.
Scrum Expert Copyright © 2009-2025 Martinig & Associates