September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
Such tasks should be taken up within the confines of a typical sprint, with each sprint delivering a product increment. Stories are created as necessary and prioritized in the backlog as needed, which can include some of these hardening tasks, though, the increment itself should still delivery valuable increment.
Even still, a core focus should be on delivering quality, not just delivering, which inherently would minimize the need for refactoring, etc.
Stable doesn't mean bug free. Applications like Microsoft Word have tens of thousands of known bugs, but they're minor or rare. The application is not unstable.
If you have developers that think that stable code is a joke, then you have the wrong developers on the team.
You should implement quality processes that prevent the team from calling something "Done" if the code is poorly written. Peer reviews. Coding standards. Automated tests.
You should also reserve a certain amount of time in each sprint to fixing technical debt. You shouldn't let it build up. You should put technical debt issues in the backlog, and pull some of them into each sprint.
It's also not a good idea to put a project manager in charge of a software development project who has no background in software development. It's best if they used to be a software developer before moving into project management. On the other hand, I recommend against technical project managers - software developers who have some PM skills. They tend to not have the depth in project management that is needed to effectively manage such projects.
What I wanted to say is that developers know that no matter how hard they work they can't guarantee the delivery of stable software in a 2 weeks sprint. They are doing their best but it is simply not possible no matter how good they are. In order to get the software stable you should stop developing new features and focus only on bug fixing for a period of time.
Regarding PMs that have no technical background they can't manage the technical aspects of the projects and they blindly accept all the technical decisions taken by the developers or the technical leads and technical managers.
Managing a software developing project is one thing managing developers is another thing. In order to manage developers you must be a developer, in order to manage software projects this is not a requirement but if the PM is not a developer his ability of managing the project is limited as he can't take technical decisions. Technical decisions are critical for the success of the project.
Regarding technical debt and the necessity of special sprints to address this only developers can know if they have debt and what needs to be done in order to pay it.
PMs, POs and Scrum Masters with no technical background are useless when it comes to technical debt. They can't see technical debt as you need to read the code for that.
Last time when I worked as a developer (contractor) on a Scrum Team there was a lead developer that had the power to override the POs decisions if this was needed by technical reasons. For example if he decided that technical debt needs to be addressed as the development is slowed down he could do that by postponing the business requirements and focusing slowly on technical debt issues.
Excellent conversation!! I've mostly worked with organizations that are still tinkering with the concept of Agile - and many that can't let go of their waterfall traditions. As such, I find that in practice, stabilizing or hardening sprints are often wise. As Adrian mentioned, code clean-up/notation, integration points with other systems (esp. those on the waterfall train!) and preparing for release are some of the activities needed.
I'd agree that in a truly agile world, we'd not need these sprints, but while on the journey to that end, we may need to compromise some.
I worked with a team that took no input from the product owner. The lead developer was also a manager and self-described expert in customer needs. Every two weeks the team released a "patch" that was used to "fix" his mistakes. Three of his famous statements were: "We know what the customer wants.", "We'll fix it in the next patch", and the best of all: "The customer will get used to it."
Hardening sprints can be necessary, but you should look at root cause as to why it's needed. As example, are you trying to get too much done within a sprint, is there not enough regression testing happening, is there not enough user acceptance testing. If you're having to do frequent hardening sprints then there might be underlying problems.
That quote makes me laugh and cry at the same time.
Please login or join to reply