Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
In agile approach project, what is your view about IT team which request a stabilization print to ensure to consolidate the work done ?
Network:62



Some people say that is because definition of done is incomplete or not followed. Some people says that's a normal. What is your view ?
Sort By:
Page: 1 2 <prev
Network:2381



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.
Network:211



Jul 13, 2019 8:30 AM
Replying to Adrian Carlogea
...
"Each sprint should deliver working software, not software that is unstable." is easy to say especially when you have never written a line of code in your life. Developers however would often smile when they read or hear this kind of statements.

Developers do know that the software would always have defects in it no matter how hard they work on it an no matter for how long it is tested. Trying to release a bug-free software is impossible.

The above can be understood to some extent by non-developers but what it is harder to understand is that you can have working software with no major visible defects but with badly written code.

In order to keep the velocity up developers would often take shortcuts and write code without enough comments and worse than that, code that is hard to maintain or further develop. Non-developers would not be able to see this as they only care about results but this can hunt you down later in the project. This is know as technical debt.

At some point the technical debt must be paid and if you are using Scrum you would probably need some additional Sprints for that. If the technical debt is purely caused by code written quickly then refactoring it may invalidate most of the testing that has been done so far.
As it happens, I spent the first 15 years of my professional career as a software developer.

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.
...
1 reply by Adrian Carlogea
Jul 18, 2019 6:31 AM
Adrian Carlogea
...
Thank you for your message Eric.

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.
Network:92



Jul 18, 2019 12:25 AM
Replying to Eric Isom
...
As it happens, I spent the first 15 years of my professional career as a software developer.

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.
Thank you for your message Eric.

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.
Network:0



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.
Network:211



Jul 13, 2019 4:30 PM
Replying to Wade Harshman
...
Yes, you can have working software with badly written code, but that is not the goal. A software development team should focus on writing clean code that doesn't require comments or planned refactoring. (As we've said in other threads, Scrum doesn't fix problems, but it does reveal them.)

There are many good books and articles about this and I won't try to re-create them here. But if you find that your team has a habit of writing sloppy code with the intent to clean it up later, it could indicate a number of major issues, including:

- You are asking too much in each sprint. Stop focusing so much on "velocity" and focus more on producing quality ("done") increments. This problem might be with your development team making promises it can't keep, but it's at least as likely to be a management issue.

- Your team believes it can sacrifice quality for time. This is not the case. The quality you sacrifice for time now will demand interest when you pay it back later. Again, your team might not understand this, but it's as likely that management is the issue.

- Your Product Owner either doesn't understand technical debt or can't visualize it, and therefore is unaware of the growing problem.

- Your team needs to set some coding standards and enforce them through code review, pair programming, or some form of quality check.

- Your developers aren't all that good, or they don't have the right skill sets. I don't mean this to sound insulting, but it happens. I knew one developer that used to add comments to everything she did because none of the other developers could ever figure out what she was trying to do. They grew increasingly frustrated because they always had to clean up her code. Maybe she wasn't the right fit for that project based on her skill set, or maybe we didn't do a good job holding her to our own standards.


I completely understand why we're talking in terms of software development, but any other project team or scrum team could have similar issues.
Excellent answer! I'll add one more possibility.

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."
...
1 reply by Wade Harshman
Jul 23, 2019 7:59 AM
Wade Harshman
...
"The customer will get used to it."

That quote makes me laugh and cry at the same time.
Network:140



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.
Network:264



Jul 22, 2019 3:08 PM
Replying to Bob Thomas
...
Excellent answer! I'll add one more possibility.

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."
"The customer will get used to it."

That quote makes me laugh and cry at the same time.
Page: 1 2 <prev  

Please login or join to reply

Content ID:
ADVERTISEMENTS

Not that there's anything wrong with that.

- Jerry Seinfeld

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events