5

We are running Scrum on waterfall-style projects. This means that we use Scrum as a planning unit, conduct the ceremonies, have the PO/Scrummaster roles, but we do not have a customer-facing release at the end of each sprint (though we might have demoable features).

This is mostly driven by the nature of our business, and mostly works well. The one catch is that waterfall-style projects have distinct phases: development, regression testing, bug fixing, hardening etc. The latter three (regression testing, bug fixing, hardening) are quite different to the normal development cycle, and are more Kanban-like in nature. Essentially, team's velocity for planning purposes becomes less predictable.

What is the best approach of planning those phases? We are mostly dealing with it by applying factors such as 0.5 to teams' established velocity during planning, but it is imprecise.

Improve this question
6
  • 1
    To clarify... you don't do testing, bug fixing, or hardening during your normal sprinting process?
    – Sarov
    Nov 10, 2016 at 1:39
  • We do - as it relates to the tasks in the given sprint. But, there is special kind of testing towards the end of the release: manual regression, performance testing etc. Same about bug fixes and hardening.
    – RomanK
    Nov 10, 2016 at 2:31
  • Why use velocity for a process which you define as inestimable? That's a misuse of the metric.
    – Todd A. Jacobs ♦
    Nov 10, 2016 at 16:02
  • This is not a metric, but a planning indication which helps to understand what the team can and cannot achieve. The problem is that this indication is unstable throughout the waterfall development cycle.
    – RomanK
    Nov 10, 2016 at 18:24
  • As CodeGnome mentioned, velocity as it it traditionally expressed is likely the wrong tool for the job. If you're in a bug-fix cycle, it may be more valuable to look at throughput of fixed bugs to take a guess on capacity. Even this is very fragile though. Is there a reason that you're trying to work these into a waterfall process?
    – Daniel
    Nov 10, 2016 at 21:17

2 Answers 2

Reset to default
3

Don't distract the whole team with bugs coming from the latter three phases. Pull one (or how many you need) developers from the team and dedicate solemnly on resolving bugs from The phases. Rotate them every week or sprint while The phases keep going.

If there is not so many load from the phases - let them work on 'standard' regression bugs or whatever you have apart from the development of new features. If one man can't cope with the load - usually there is a good room for improvement in The phases process.

The approach is to divide and conquer. Dedicate people on non-sprint activity and don't disturb rest of the team who is still doing sprint activities. Pulled out part of the team can concentrate on the phases and rest of team can keep their tempo (with dropped velocity).

Improve this answer
7
  • One developer is not nearly enough - most of the team participates in those phases. There is always room for improvement, but currently this is the reality.
    – RomanK
    Nov 10, 2016 at 13:26
  • I see. @RomanK I made the answer broader to fit your situation. The approach itself is still applicable.
    – Vlad
    Nov 10, 2016 at 13:54
  • It is applicable, and thanks for the time taken to consider and respond. It works in some cases, though in most real-life scenarios you would have subject matter experts in particular components that can't be segregated entirely off non-project work. In any case, we're arriving to the same thing: load factor - whether it is at the individual or team levels.
    – RomanK
    Nov 10, 2016 at 18:29
  • Thank you. As a matter of fact my answer is the real life practice. I understand your point about experts, my sentence about rotation intentionally targets this problem. Of course it can't be resolved immediately and is a common issue. Regarding "whether it is at the individual or team levels" let me emphasise again - to dedicate 50% of the people is way better than dedicate 50% of the team time.
    – Vlad
    Nov 10, 2016 at 19:01
  • 1
    1. You don't pay overhead for switching between tasks. 2. It is impossible to measure what percentage was actually spend by each person.
    – Vlad
    Nov 10, 2016 at 20:49
3

My suggestion is to look at a development life-cycle that I've seen used in some "Waterfall Release" companies using agile.

The key to this is the word "Potentially" as in "potentially releasable Increment of “Done” product at the end of each Sprint.". Scrum doesn't actually say to ship every sprint. It just says it should be releasable. This has been widely interpreted as being "Ship every sprint" over the years. This in turn leads to many Enterprise companies only using Scrum/agile in the strict limits of the "coding" phase and then wrap waterfall around this.

Instead you need to separate the concept of Deployed and Released from one another. You need to step down the path of Continuous Integration.

  • Deployed: The feature is done, it is in the system. It is just under a flag so that only specific users can see this. Sometimes referred to as A/B testing. You start by deploying the feature internally and testing it yourself. Microsoft's TFS team does just this every three weeks with it's cloud service. Internally they see the feature a week before the public does.
  • Released The feature has been released to one or more users by changing the permission flags on the feature.

You build everything in your sprints to be deployed, even if that deployment is an internal production mirror. When you have enough features to warrant a release to the public, you just flip the switch and make them live. You separate the act of building from the act of giving it to the customer. Not unlike manufacturing where you could have a thousand Wigets in your factory before you ever sell one to a customer.

The other advantage of this method is it means if you have to, you can ship any time you need. For example, imagine a major security threat comes along. If you are able to ship every two weeks and just choose not to, then if there is a major security issue, you can choose to release.

This technique is being used successfully by most of the major "service" related internet companies now, Facebook, Google, Amazon, Apple OS, Microsoft Cloud anything, etc.

Move your development away from Waterfall, keep your product releases to the customer on their longer cadences.

Improve this answer
3
  • Interesting points - thanks for the answer. This requires having a strong automation framework, so that the intermediate, potentially releasable, builds do not have potential for regressions in preexisting features: both functional and non-functional. In my mind, this is the hard bit - once it's in place, getting the process is easier. This also goes back to my original question: if there was a strong CI pipeline and automation in place, there wouldn't have been such an overhead and velocity impact in that late Waterfall stages.
    – RomanK
    Nov 10, 2016 at 20:41
  • To do it right you do need test automation. You don't have to have it. You just have to have the discipline to build test into the development. As one of my VPs, who has done CI without automation, says "Test is Atomic with Coding." Try it in one area even. We did that at one company, UI and API were still monthly. The core server pieces were deployed as done with little to no automation.
    – Joel Bancroft-Connors
    Nov 10, 2016 at 21:11
  • Yes on the new features. My main comment was on changes that touch existing functionality: bug fixes, refactoring etc. These are harder to treat atomically.
    – RomanK
    Nov 10, 2016 at 21:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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