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.
If you deal with legacy code you’ve likely found yourself struggling to debug and fix a mysterious, intermittent problem. Along the way you may have discovered some code that didn’t quite make sense.
There are work items that will give the team an operational boost and perhaps avoid a crisis, but that never make it to the top of the priority list—like build and deployment improvements, or paying down technical debt. For enabling work that is valuable but too invisible to be a priority, consider breaking it down.
Agile teams know that cross-functional collaboration is central to the methodology, but there are often barriers to fully embracing this idea. If teams are used to handoffs, it may seem like it makes sense to maintain the status quo. Try collaborating on something small to realize the true value of cross-functional teams.
Many decisions about code branching models are made in the name of managing risk, and teams sometimes pick models that make integration harder in the name of safety. Moving slowly and placing barriers to change can seem safer, but agile teams work best when they acknowledge that there is also risk in deferring change.
Flaky tests could be the result of issues in the code, but more often they are due to assumptions in the test code that lead to non-relatable results. There are many reasons that tests can fail intermittently, and some can be easily avoided by applying good defensive design strategies. It's all about making your code agile.
Continuous integration is essential to provide the feedback needed to keep a team’s code agile. One crucial aspect to a successful CI process is a repeatable build. There are two parts to maintaining a repeatable build: the idioms and practices to define it, and the feedback cycle to maintain it. Here's what you need.
While using index cards and a wall can function just fine as a kanban or Scrum board, issue-tracking tools such as Jira can make it easier to manage a backlog, especially with a distributed team. But these tools are more complex to use and can add their own overhead to the process. You need to keep things simple.
