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:58



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 next>
Network:98363



Bonjour Guillaume,

Is the IT team part of the project or the operations side? It is not unusual to have a sprint to tie up loose ends. It's not necessarily because of things not done, it could be a case of non-business stories being needed. For example, you could have a sprint to prepare for a release.

Of course, it could happen than things that are not completed in on sprint are no longer the highest priority in the next sprint. That would leave you with incomplete stories to be tackled in a later sprint.
Network:263



Agreed that a "0 sprint" or a stabilization sprint are common. It could be an opportunity for the team to improve, though. Can they split the work differently so they have a potentially deliverable increment every sprint? How often are these stabilization sprints happening?
Network:1481



Guillaume -

we should never plan for a hardening sprint as that implies we are tacking quality on vs. baking it in, but sometimes we are faced with the inability to do end-to-end lifecycle delivery within a sprint. The key is to produce as quality a product increment as we can given the constraints we face.

Kiron
Network:1837



This is new for me. I never hear before about "stabilization print". I do not know what it does mean so I hope to learn from comments.
Network:191



Such sprints are common, but they're wrong. If you're doing it right, you won't need them. As Kiron said, it indicates that you're not building quality in up front.

The Agile Manifesto includes 12 principles. Stabilization sprints violate several of them:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."

"Working software is the primary measure of progress."

Each sprint should deliver working software, not software that is unstable. If it's not stable, look to your quality processes and your definition of done, and tighten them up so that you stop delivering unstable software.
...
1 reply by Adrian Carlogea
Jul 13, 2019 8:30 AM
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.
Network:90



Jul 13, 2019 12:42 AM
Replying to Eric Isom
...
Such sprints are common, but they're wrong. If you're doing it right, you won't need them. As Kiron said, it indicates that you're not building quality in up front.

The Agile Manifesto includes 12 principles. Stabilization sprints violate several of them:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."

"Working software is the primary measure of progress."

Each sprint should deliver working software, not software that is unstable. If it's not stable, look to your quality processes and your definition of done, and tighten them up so that you stop delivering unstable software.
"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.
...
1 reply by Eric Isom
Jul 18, 2019 12:25 AM
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.
Network:263



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.
...
1 reply by Bob Thomas
Jul 22, 2019 3:08 PM
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."
Network:90



Thank you @Wade what you are saying is correct but things are not that simple.

If you use Scrum/Agile for product development and not project delivery then yes, depending on the situation you may have time to breathe and focus on avoiding technical debt. And yes technical debt is not only about software development.

However if you want to deliver a project to a customer using Agile/Scrum then the customer/sponsor would like to know from the beginning how long it would take to complete the project and how much would it cost. The information is needed in order for management to allocate the budget.

By the time you are asked to provide this information you may not have all the User Stories written and estimated and even if you have management would use the story points for budget estimation. I know this is not supposed to happened but I have seen it happen.

When you are in such a situation, and many times it is hard to avoid it, you would prefer to deliver as soon as possible much of the functionality to give confidence to the customer/sponsor. If you focus too much on quality and don't deliver much the customer may loose confidence and stop the project.

The only way to deliver faster is to take shortcuts and pay the debt later. In Scrum terms you may have some Sprints to resolve your technical debt later.
Network:58



Thank you for your contributions. Based on it, I can tell that there is a high level of competencies on this forum. Thanks !
Network:263



Adrian, you are correct, real life is never as simple as theory. That's why hardening sprints are so common. But I still see them as a concession. If a team is granted the authority to improve, it should ask itself how to deliver without stabilizing sprints.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"No Sane man will dance."

- Cicero

ADVERTISEMENT

Sponsors