Scrum is a fairly minimal agile process framework that you can adapt to work best for your team. But adaptation works best once the team has internalized the principles and values of the Scrum process, and that takes practice. In other words: Before you start to adapt Scrum, first try fully adopting the framework.
Steve Berczuk is a Principal Software Engineer with experience as a manager, Scrum Master and technical lead in Boston, MA. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a Certified ScrumMaster. Contact Steve at [email protected] or visit berczuk.com and follow his blog at blog.berczuk.com.
All Stories by Steve Berczuk
Sprint retrospectives are often skipped, compressed, or organized in a way that doesn't provide good feedback. This is unfortunate, as a well-planned retrospective is a great way to improve how you work. Good retrospectives enable engagement and safety, distill and prioritize ideas, and create concrete action items.
On any team, there are bound to be some differences. But even though work styles may differ from what you expect, they may not be problematic simply because they are different. Before making assumptions about what a teammate is doing or why, just ask to find out. Their differences may bring a helpful new perspective.
A common complaint in organizations adopting Scrum is that Scrum has too many meetings. However, people may not be considering all the time they spent meeting before Scrum—and how effective that time really was. As long as you keep meetings focused, people should waste less time in meetings than they did before Scrum.
The degree of confidence in your knowledge may vary, often due to the process you went through to learn the concept. An understanding of how different learning techniques affect the depth of your knowledge can help you with how you process information you already have and how to approach learning new things.
A common problem for Scrum teams is having a good understanding of what work is complete by the end of the sprint. Teams often end with a few items coded but not fully tested, but since the goal of a sprint is to have a deliverable increment of work, skipping tests isn’t a good idea. Here's how you can fit them in.
In project management, it's easy to focus on details to the extent that you lose track of the larger goal. Scrum can help you identify flaws and gaps, and skipping or trivializing Scrum events will just hide the fact that there are things you need to improve. Finding problems is something to be celebrated, not hidden.