Self-confidence is essential to tackling difficult problems. Where we need to be careful is not being falsely overconfident. What’s behind that overconfidence can either help or hinder your solving issues and achieving a good result. Here's how to make sure that confidence is backed up by competence in your team.
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
Is your process for pull requests compromising your team's agility? You can structure your changes in a way that facilitates more rapid feedback, but even then it is still possible to have a slow integration time if people don’t review pull requests promptly. Mechanics are part of it, but culture also matters.
Pull requests may not seem to fit into agile development, but they can work well if done right. If you can maintain feedback on your working software from frequent integration, using PRs can help people understand your code. The speed at which PRs can be reviewed depends on three things: context, size, and atomicity.
The Scrum Guide talks about an ordered backlog, not a prioritized one. While order and priority are related, they are not the same, and understanding the difference and why people focus on one over the other can help your team be more effective at delivering business value.
When a manager sees a problem on their team, they often want to act quickly to correct it. But if you take a “fix it” mentality too far, while you might get past the initial impediment, you have done little to help the team work better in the future. Let's look at another approach, based on one of Aesop's Fables.
When a process isn't working, you'll have to make a choice that will help move things along. However, some choices are less about inspecting and adapting than about getting things done quickly, and that incurs risk. To manage this risk you need to be aware of the differences between "practical" and "expedient."
Technical leads can be useful, both within the dev team and as a go-between. But is that a good idea on a Scrum team, which should be self-organizing? There is nothing wrong with having a technical lead on your team, as long as the role doesn’t impede the team. Here's where a tech lead can help or hurt a Scrum team.