The Time to Fix Your Code Will Never Come

It’s a strong statement, but I have not yet seen that developers are “given” the time to fix the cause of problems. These problems can be post-release surprises, hard-coded values that multiply change efforts (and risk), manual configuration, testing and deployment,  duplicate logic and logic spread across many areas of the system, multiple languages (due to developer preference, not because of the product built), performance and scalability problems (and let’s not even talk about security).

The one thing I HAVE seen consistently – developers WANT to fix these problems. And management doesn’t want these problems (and doesn’t particularly like surprises). So, seems like a fit then, right? Developers tell management they know how to fix some of these problems, and management gives them the time to do so.

Not.

Or I should say, “Not now. After this next big release! But we’ll be sure to give the team the time to fix the root causes and refactoring in the next phase.”

Right…the “next phase.” Let’s just call that “Phase Never.”

So, what can we do about this? I have two ideas. I’m sure there’s 42 more out there, but these are ones I like because they are simple and you can start now.

First, ask management how much time they think is fair to allocate per sprint.

Development Budget for Features Maintenance Refactoring
Allocating Feature, Maintenance and Technical Product Backlog Items

I like to use a pie chart, like the example here. Now, we add to our Working Agreement to reflect that allocation with something as simple as “One backlog item for every every X business-requested items,” or “X% of points per sprint are team-selected Investment Stories (which could even be cross-training via pair programming or mob programming).” We have clear goals and measurement as to whether we do what we say as a business.

Another is to update your Definition of Done with your goals regarding technical practices. For example, “All new features must have unit tests”, “At least one item per sprint must have the automated tests”, or “If you see some bad code smells while working on an item, create a Technical Story in the backlog with Date/Who Found/Recommended Fix/Estimated Effort.” As far as spreading out knowledge, update your Working Agreement with a similar “At least one item per sprint must be paired on,” or “Someone must learn something new per sprint.”

Stop waiting for that perfect time, or that new re-write, or that break in the workload, because these things may never come.

Start today. Start small. Change how your team codes right now. Feel better about your work this week than last week.

One way to jump start this would be to immerse your team in the XP practices taught hands-on in the Certified Scrum Developer workshop.

Talk to one of our technical coaches about:

  • how to ease into making changes to the code base,
  • team practices such as continuous integration and automation,
  • design and architecture practices,
  • moving to Git or the cloud,
  • addressing knowledge silos and experts, and much, much more.

Having a technical coach sit with your team, working on the code together while delivering for the sprint is one of the most effective ways to learn and make real change! If you have questions about how technical coaching might help your team and organization, just fill out the form below. We’d be glad to talk.

     

    3 Critical Decisions for

    Agile Transformation Success

    Potentially save your company and career by discovering…