3

Background: We have long running product development project, which consists of different features. The development team consists of 15 developers and 5 QA engineers. We setup releases each 5-7 month. Each release we either add new features or enhance/existing features. Each release consists of 6-8 development sprints (3 weeks each) and 2-3 pure stabilization/bug fix sprints.

Issue: Some of features take several months and more to complete development to be at minimum level of deliverable or production ready stage. We do split them into small tasks and progress developing them in each sprint, but it ready for first demo only after 2-4 sprints and ready for QA/production after 5-8 sprints. Those features are complex and generally consist of developing new or enhance infrastructure, core/services, business logic, UI, Web and then integration in monitoring, reporting, printing, marketing and etc. Before these all done the feature cannot be considered as done (production ready). On the other hand in same release we have small features or enhancement which are much smaller and can be production ready in single sprint or two... Those long running features prevent from us to release product in smaller chunks since they takes much more sprints to be production ready rather the others.

Question: Any idea/advice what could be better approach if we would like to make our releases shorter?

Thanks, Pavel

Improve this question

6 Answers 6

Reset to default
5

What I think is happening, you are calling sprints to the development effort then you have "sprints" for QA.

I think you are using a cascade model instead a incremental model. I would try to dissect the tasks in backlog to the minimum size and in each sprint integrate QA, so you don´t wait until the sprint 5 to 8 to testing and go back with the 2-3 weeks or sprints for stabilization.

At the end of each sprint, you should have working histories developed and tested, then with a Configuration Management Strategy you can deploy those new or reworked functionality to the stating environment and after UAT, you can deploy to the live system, so the system have new functionality every sprint, and to at the end of the development and testing "sprints"

I think you are misunderstanding the "sprint" and SCRUM life-cycle with the traditional life-cycle.

Improve this answer
3
  • 1
    +1 for the note about "cascade model". Indeed the process explained looks like micro-waterfall, instead of incremental and iterative.
    – yegor256
    Commented Feb 24, 2011 at 18:25
  • +1 definitely sounds more "cascade" or rolling wave than Agile -which is fine given the constraints and how he's defining release.
    – Mark Phillips
    Commented Feb 24, 2011 at 22:36
  • I agree that we are not working agile methodology, but we try to use it guidance and we trying to move there smoothly. The question was raised exactly due the fact we cannot create small production ready chunks of work since it require much more time than it can fit in the single iteration. We do not want to develop it separately and then integrate in main branch, since we do want to use new infra which added in each sprint and we what see/demo the progress as whole and not in separate branches which each of them will require testing.
    – PavelRe
    Commented Feb 26, 2011 at 11:17
2

I think the answer here may be a good tool. I don't know what kind of solution you use for version control but I think moving to Distributed Version Control System might help. The main change of the mindset with using DVCS is you don't merge everything into one trunk, which you have to stabilize before pushing into production, but you can add different features into one release basing on distributed code base.

Many Kanban teams face the same issue, although in a smaller scale and DVCS proved to be pretty good solution.

UPDATE (based on comment): With DVCS you change the mindset regarding working with trunks/branches. Read Joel Spolsky's introduction to DVCS. Also you may check Joel's Mercurial tutorial to get familiar with DVCS.

Improve this answer
2
  • We use SVN. I am not familiar with any DVCS. Anyway the reason we do not want to break it in different trunks and then merge because of 2 reasons: 1 - In the main branch we develop an infra which might to be used the long running feature. 2 - We do want to see/follow/demo some kind of progress to make sure we are on right path - even it is not production ready. Doing these, in two or even more separate trunks, make it quite expensive. Furthermore when the feature(s) will be ready to be integrated to main branch it still require whole sprint or more to test them, because of complex merge.
    – PavelRe
    Commented Feb 26, 2011 at 11:33
  • 1
    With DVCS you change standard trunk/branch mindset. What you do is you basically build your versions from chosen parts of distributed code repository. Whenever you need to demo some feature you can build version which includes it. Hard to describe in a few words: you an read Joel Spolsky article as introduction: joelonsoftware.com/items/2010/03/17.html Also if you need a kick start you can check Joel's Mercurial tutorial hginit.com (Mercurial is one of top DVCS these days)
    – Pawel Brodzinski
    Commented Feb 26, 2011 at 13:04
1

I think that you the problem is that the scope is not elaborated properly. There are 15 developers, 5 testers and no analysts? Who is working with the scope documentation/analysis?

You need someone at this "system analysis" role. You need this person to break down the scope to much smaller chunks than now.

Improve this answer
1
  • We do have analyst, sorry I did not mentioned it. But it still does not help to define "production ready" scope which will fit single sprint. We do break it to smaller chuck, unfortunately it not enough to encourage customers to deploy because they want everything will be ready fully worked before they go live/upgrade.
    – PavelRe
    Commented Feb 26, 2011 at 11:23
1

I'd start by taking a look at the critical path of your delivery cycle.

Map it out with the different durations of each phase then see where you can condense or better sequence your activities.

Improve this answer
1

I have to agree with a lot of the comments here. You seem to be iterating a waterfall structure and confusing it with Agile. There is no problem with an iterating waterfall process, and I think you can find solutions in the way you initiate each cycle. If you think of each cycle as a new project, you may notice you've missed a bit of the methodology. If you don't have Analysts, you need to get some as yegor256 said. Also this is a great environment for you to conduct lessons learned sessions and implement change suggestions.

Improve this answer
1

I think pawelbrodzinski provided the best answer...but it seems you/your-team is code branch averse.....another approach would be to release the changes - working or not - with each sprint, making them only reachable by certain user roles or links (so the current user base can not access it prior to completion)...this might mean duplicate tables (some with a new structure to support the new functionality) and duplicate links (one to the old functionality and one to the new functionality)...not a good solution or one I would follow myself, but another approach

Improve this answer

Your Answer

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

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