3

I'm working on an Agile program and we are debating on how to deal with what we call "stabilization sprints". We have to build our team and decide on several key items but it seems there aren't really a well defined guideline to help us decide about them (or we can't find them) so I was hoping to pick your brain on this.

Our first release is due in June, we have three months of stabilization but in parallel we need to build a team and start working on next release due for October and then a 3rd release for next June.

Here are the items we want to decide on:

  • Do we build two separate teams to deal with next release and stabilization tasks? On one hand having a single team (several pods) to deal with both helps us to load balance our resources better and assign developers with deeper knowledge of the issues require fixing to them. On the other hand not having a dedicated team for next release makes it deficult to plan our next release.

  • Do we size issues identified (bugs to be fixed during stabilization, technical debts) or we deal with them by assigning a percentage of the pod's velocity to bug fixing as we used to do for our normal development sprints? Sizing them helps to plan better but creates a need for debates and meetings we want to avoid.

  • Do we combine our stabilization tasks with next release story cards or keep them separate? This is kind of continuation of the first question. If we decide to have a single team to deal with both stabilization and new release then do we really need two backlogs or just a single one?

I've been looking for a good book/article that describes the best practices to deal with an Agile project with multiple releases planned specifically to explain the team structure and estimation model but can't find anything good.

  • 1
    You need to define what you mean by "stabilization sprint". Sprints just for bug fixing / UI polishing without developing new features? Or something different? – Doc Brown Jan 1 '17 at 16:48
  • Sprints after all features are done and we focus on bug fixing, none functional requirements such as performance and security audits and so on. Basically time needed to make a release production worthy. – Amir Peivandi Jan 2 '17 at 12:57
16

You should not have stabilization sprints. Your software should be releasable every sprint. This means that if you need stabilization, that has to happen within each sprint and not just before a release. Once you achieve this, release planning becomes a product owner concern ("What features to I need in order to release?") and stabilisation a team concern (definition of done).

The same applies to bugs and technical debt: it's stuff that is always fixed, as needed and does not require stories -- in fact, it's normally part of each story: it can't be "done" unless it's stable and properly refactored.

I realize that this does not answer your question directly, but stabilization is not an agile concept at all, so it makes no sense to ask how to do it with Scrum.


Edited to address comment:

According to Scrum, bugs found pre-release are to be handled within the iteration. A story is not normally considered "done" if it has bugs. If you can't ship it, it does not have value. Also, according to basic Agile principles, teams should work at a sustainable pace. If you need to basically stop development in order to address debt or bugs, then you are not working at a sustainable pace. Decrease your velocity, ship less features, but without bugs.

Usually stabilization happens in teams that have a separate QA team checking features post hoc. This does not fit in the Agile or Scrum model. Teams should be cross-functional and able to ship a feature independently.

Overall the thing is, many companies say they do Scrum or Agile without understanding the deep changes it entails in the way software is built. If you are not prepared to build software according to these methodologies, don't use it as a "management add on" on different practices.

  • 1
    H@AmirPeivandi I am sorry, but I disagree. There are many teams, including my Stack Overflow team, that are perfectly fine releasing multiple times a day, and have no stabilization. I realize this might not be your real world case, but if so, you are not doing agile or scrum right. It might not be the right tool for you. You are asking what's the right way to do scrum, but wrong. – Sklivvz Jan 2 '17 at 15:18
  • 1
    @Skilvvz While reading and researching on the subject I found this and it made me realize reasoning behind your logic. Now that I see this I feel better knowing this is an ongoing debate so it's not just me agilerecord.com/hardening-sprints – Amir Peivandi Jan 3 '17 at 16:16
  • 2
    @AmirPeivandi from your source: "These sorts of sprints are considered a ScrumButt³ or Scrum anti-pattern by many of the leading Scrum authorities (CST’s and CSC’s)". I mean, sure you can do them. Agile is not a straitjacket and you can choose whether or not to apply it. However, there is no Agile or Scrum answer to your question. – Sklivvz Jan 4 '17 at 21:02
  • 1
    The same applies to bugs and technical debt: it's stuff that is always fixed -- What perfect world do you live in? :P – Robert Harvey Jan 9 '17 at 16:36
  • 1
    @RobertHarvey well... it should be, unless it's an insane amount of work I've always just done it as needed. Never got any complaints. – Sklivvz Jan 9 '17 at 16:38
1

Whether you give them the name 'stabilization' or just 'Sprint 12' doesn't matter, at some point your team will have stopped initial development of stories and will be doing sprints of technical debt or closing off stories that haven't been done because issues were found and you couldn't close them. These are just normal agile sprints, my guess is your team is like ours and knows we'll need that calendar time to deal with the "I didn't think of that" stuff.

In our shop, if we initially forecast a release backlog of 400 points, and initially think we can do 100 points velocity based on history, that should theoretically mean we can do that in 4 sprints. However, we also have enough experience on projects to know that our estimates of velocity and total backlog are not always correct. New functionality might be required for the MVP, an unforeseen delay might block us from completing something, so we plan a similar 'sprint' for dealing with that. So we might put 5 or 6 sprints into our calendar plan to account for the level of unknown.

Now, the amount of time you are forecasting for 'stabilization' indicates an organizational issue with delivery if you need almost as much time to stabilize as to initially build. As others have mentioned, you likely need to embed your testing earlier on in the phase so that you are getting your feedback earlier. By using Continuous Testing techniques you will have your team cleaning up the stories as you go. That way, when your team is actually 'done', the release is ready.

ASSUMING YOU MAKE THIS ADJUSTMENT: Now we get to the release management part of our question: how do you deal with trying to finish off the release while also starting a new release in parallel? Typically, the last sprint or two might not have enough work in it for your initial release to keep the whole team busy. This is when you can start bringing in your next release stories to keep the team at capacity. From a code management perspective, using your favourite branching strategy will help to keep the codebases isolated and your team can switch between branches based on the task they are working on. From a task management perspective, you need to be able to clearly delineate to the team which release a feature is for so they know where to put it.

Should you split the team? Personally, I have found this helpful to keep team members focused, but it really only works if your team can truly work on almost anything. If you have specialists at all, they will have abilities that everybody needs and they will need the flexibility to jump between releases. If you can define a core group to deal with both releases and then other team members which can float this can allow for a more balanced attack.

WHAT IF YOU ARE NOT CONTINUOUS TESTING? If you are building a bunch of code, throwing it over to another team, and then moving on to the new release and waiting for feedback, you'll need to manage your team differently. This is a more 'waterfall' manner of delivery and means the initial release team can't predict when feedback will come, or how much there will be. This makes sprint planning harder for the next release since you can't be sure how much work from the initial release will be there. In this scenario, you may need to plan your new release sprints to have a 'buffer' in the capacity to account for feedback from the test team. You'll likely use your whole team for the new release at first, and once you have some technical debt to resolve you can start forming a group to deal with that and clear it out.

0

I apologize because this may sound a bit militant and harsh, but if you want to play the top level agile game, you better be prepared to bring in the big guns, work like a madman, and never compromise.

I would considering shorting your sprints and making quality and testing a top priority. I've worked with agile teams releasing weekly and bi-weekly and find anything long than that can be problematic. A good solid test suite (100% coverage along with automated browser tests) and mandatory reviews of all code will do a lot to reduce bugs. The advantage of the weekly release cycle is that bugs are fixed almost immediately and stability sprints become a non issue. This sort of development requires a massive amount of discipline and must be driven militantly from the owner. If your company isn't willing to put forth that level of commitment you're just going to be another mediocre agile wannabe so don't waste your time.

To comment on your questions:

  1. You only need one team. People fix there own bugs since they have the most knowledge of them and with a weekly release schedule things should be fresh.

  2. Sizing and debates are pointless. Developers have tasks and they are responsible for estimations and scheduling. Management can overrule this obviously, but bugs should always be addressed first unless there is a critical business reasons not to. Treat technical debt like bugs. There shouldn't be any unless again a critical business reason creates it. Ideally technical debt should not make it past code review. If it does, like a bug fix it in the next release.

  3. Bug and new features are the same. There is no reason to differentiate as it's their priority that matters.

Finally, automate, automate, automate, and then find a way to automate some more. There is no way to accomplish this level of effort without automation.

  • Sorry if I sound a little bit provocative, but if you have always to work like a madman to get your projects done, you either are not well organized, or do not work with the right persons, or have to compensate your weaknesses with hard work... – Christophe Jan 1 '17 at 23:29
  • No offense taken. When I say work like a madman I mean working the full 40 hour weeks and cutting out the slack. There's time for your small breaks here and there and lunch, but not the typical hours of bs'ing I've seen at large companies. I also forgot to add, that moving to a weekly release cycle will take adjustment because the pressure will feel high until you settle into a rhythm, – backpackcoder Jan 2 '17 at 7:27
  • 4
    Technically a good answer, but then I read this: "must be driven militantly". With an attitude like that, there's no possible way that you value People over Processes & Tools. Here's a refresher. agilemanifesto.org – RubberDuck Jan 2 '17 at 12:52
  • Militant does not mean valuing process and tools over people. It means rules need to be strictly enforced and that must be driven from the top. – backpackcoder Jan 3 '17 at 8:22
  • 1
    @backpackcoder "rules need to be strictly enforced" is another way to say you value rules (which are process) over everything else. – immibis Apr 27 '17 at 4:06
0

Stabilization fit's into agile just fine. It's simply not a feature.

This is technical debt. Where this fits into agile is the amount of features you accept responsibility to deliver. Agile says you don't promise the product owner that this sprint will "stabilize" anything. That doesn't mean anything to them. You say, "We anticipate our velocity is going to drop because we've realized a need to clean up. We'll commit to only these 3 things." Make darn sure those 3 things are small enough that it will leave you time to clean up.

Sure, you should be stable and clean every sprint. But sometimes the code needs a big refactoring. Agile doesn't say you can't do that. It says you get no credit for it.

Just because you get paid to cut down tree's doesn't mean you shouldn't sharpen your axe. Just don't expect to get paid to sharpen your axe. Your axe is your responsibility.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.