How much capacity would you consider to refactor, fix important bugs, explore new technologies and ideas?
Welcome to part 7 of our scrum master interview questions where John McFadyen answers common questions asked of agile coaches and scrum masters during interviews.
In the traditional sense of stopping scrum to focus instead on these elements, I wouldn’t consider any time whatsoever.
The reason for this is that these elements have already been paid for by the product owner.
If we think of the product owner and the customer as the people who pay our bills, you realise that these elements constitute part and parcel of product development and the product owner has already paid our salary for the time invested in developing ideas, exploring new technologies, or ensuring that we don’t have any technical debt in the form of poor or broken code.
So, stopping work that the product owner and the customer desperately need, to do these other things, seems unfair.
It doesn’t mean that we don’t deal with these elements, it just means that we deal with them in a different way.
Dealing with bugs
I would recommend that you deal with bugs in the same way as you deal with any important work. You place it in the backlog. You estimate how much effort it will take, and you prioritise the work relative to other work in the backlog, and you simply bring it into the sprint backlog at the right time.
You may have a perfectionist programmer on the team who wants these bugs addressed right away, but when you compare the bug fix relative to other backlog items, you may find that it is something that you can address weeks later.
You may find that it is a priority, and that the product can’t move forward until it’s done, and so you prioritise it and get it done.
It’s simply a matter of common sense. If the house will be set on fire unless this is done, then get it done, if it is a nice to have then simply place it on the backlog and allow the team to decide the best time and place to resolve that issue.
A conversation with the product owner during backlog refinement will decide how much of a priority bugs are for them, and at which time it would make sense to add them to the sprint backlog. Doing this ensures that your product owner is aware and able to make an effective judgement call on that.
It isn’t the role or responsibility of a developer to decide whether fixing a bug is more valuable than a feature being shipped to a customer. Allow the product owner to make that call.
Refactoring
This is something I would handle differently.
Refactoring is an admission by the team that you didn’t get it quiet right and that the item needs to be revisited to achieve the purpose or standard that we have agreed upon.
It may not be a bug, it may actually work, but we agree that it could and should be better.
This is one of these items that require internal effort and commitment but isn’t apparent to the outside world – unless it results in a significant improvement to the product.
Simply address the item without adding it to the backlog and don’t claim points from the work you do either. It simply isn’t up to standard, the work has already been paid for, you are now correcting a mistake or ensuring that it is done to the correct standard.
It doesn’t need to be communicated to a product owner or the outside world, it just needs to get done. We are human, we do make mistakes, and this is one of those things that requires you to get it done before moving onto the next item.
If you’re finding that refactoring is coming into play more frequently, it should be a cue to work with the team to slow down.
Yes, velocity is often seen as a measure of contribution or productivity, but getting the job done right the first time, in the most valuable way, is far more important.
We are aiming to be effective rather than efficient, so let’s slow things down and allow ourselves the necessary time to do great work. A great rule for the development team is to commit to leaving code in a better condition than you found it.
When they open an item to code and notice that it might be in a bit of a shambles, simply take the time to correct it and code your element correctly before you close it, and through the process of working through backlog items, you will automatically be improving the environment.
We might have a track record of achieving 40 points in the sprint and decide to bring that down to 30 points per sprint to ensure that we are getting things right, improving the standard of the environment, and have time available to nip and tuck as we are completing our own items.
The last thing you want is for the team to run a refactoring sprint where they deliver nothing of value to the product owner or customer for a couple of weeks and instead focus exclusively on bugs, refactoring items, and cleaning up their mess.
Relationship Management
Why is this important?
Imagine you take your car in for a service and a couple of weeks later you go to fetch it, only to discover that nothing has been done and yet you are still responsible for the bill.
This is exactly what is happening to the product owner, customer, and stakeholders.
Sure, it’s your job to ensure that a standard is maintained, and you can include that in your sprints to ensure it gets done, but if you take a few weeks out just to clear up a mess that shouldn’t be there, you are damaging your relationship with the product owner, customer, and stakeholders.
They have already paid the team to deliver the work, and now they need to pay a second time for it to be done correctly, and on top of that they must wait for outcomes and features that are urgent.
Do this a few times and the team will have broken trust, wrecked a perfectly good working relationship with customers, and lose all the goodwill and good faith that has been generated.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster