Considering when to make certain decisions is just as important as how. “Inspect and adapt” is a valuable approach in agile, not only for product and process, but also for figuring out when to implement choices about your projects. Evaluating the reversibility, migration, and sustainability of decisions can help.
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
One way to address poorly defined product backlog items is to spend time refining the items as you go. Refining the backlog continuously helps the team deliver consistently and can lead to shorter planning meetings at the start of the sprint. It can even help improve reliability, velocity, and the quality of work.
While teams are composed of individuals, all of whom solve problems and make decisions, people on consistently successful teams understand that they can be more effective when the focus is on the team, not the individual. Making the best decisions collectively delivers the most value to customers in the long run.
Many explanations of relative sizing in agile estimation fail to capture the mix of knowledge, skill, and effort involved in completing a task. Learning to play a song seems to capture the core ideas of estimation. With a metaphor, it is easier to come up with baselines to estimate against for your own agile sizing.
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools,” and for many teams, being located in the same place facilitates these interactions. However, being part of an effective, collaborative team is less about location than it is about motivation and good practices.
Some people believe branching and pull requests are inherently bad. True, branching done poorly can slow down a team, but advocating for avoiding branching altogether can lead you to ignore the more important goal of an agile process: rapid integration of changes. First, make sure you're considering the right metrics.
When organizations are distributed across multiple locations, it brings questions about how much each location should have a unique identity relative to the larger company. While a theme of “we are one” is common, it’s better to embrace the differences and work toward being a cohesive group that celebrates diversity.