Moving towards continuous delivery

Sometimes we work on huge features that takes around 2 months to implement (MVP version), how to deal with them?

How do you intend to validate any assumptions over that 2 month period? Is the risk and complexity of the feature so low that a two-month leap of faith is acceptable to stakeholders?

Sounds like you are trying to mix to many techniques and buzz words in your agile practice. 

"agile train" approach” this is jargon that does not match your scenario

Jenkins and what else i: e” bit bucket\git? Why are you doing Manual regression? Automate all your testing if you really are trying to do CI\CD.

Bunch of red flags here for me. If I were going in as a consultant we’d change some things just from this one paragraph.

Sounds like you are trying to mix to many techniques and buzz words in your agile practice. 

 +1

Using complicated solutions to handle complex problems will exacerbate the complexity of the problems.

We'd like to move to 1-motnth release to markets cycle...

Sometimes we work on huge features that takes around 2 months to implement (MVP version)

So, do you want to change to a monthly release cycle of the product?

Have you ever thought, Fixed-date and fixed-scope which is more suitable for you? 

How do you intend to validate any assumptions over that 2 month period? Is the risk and complexity of the feature so low that a two-month leap of faith is acceptable to stakeholders?

Usually we validate ideas with dynamic prototypes before commencing the development on a feature (we share it with ~10 users and capture feedback). 2-months long features are rare guests. I used them as an example of what I trying to achieve - while team is working let's say on this big feature, they will also complete few small features, and fix some bugs. The idea is to have intermediate release, that will include these small fixes, and a part of this big feature that will not affect end users yet. Looks like developing this big feature in separate branch will not work, since it will be merged at the end of the development and likely cause many bugs. I heard that many teams use a special design that allows to "switch off" a not ready feature and include a part of it's code to the released build. More details on this would be appreciated.

"agile train" approach” this is jargon that does not match your scenario

By agile train here I meant basically a fixed schedule of the releases.

Jenkins and what else i: e” bit bucket\git? Why are you doing Manual regression? Automate all your testing if you really are trying to do CI\CD.

Yes, we are using git. Why Manual testing - since we just started doing automation and it is not covering the whole apps yet. More info on this will also be very useful. I.e. during the release cycle we do many manual smoke tests, + regression test before the release. Are both usually automated? I believe the optimal scheme would be to use a mixture of automated and manual testing. Also I read that many apps like facebook do numerous releases per day, and just curious how long their automated smoke test last. Tests that we already wrote took around 2 hours to pass, that I believe is already too much time for smoke. 

Bunch of red flags here for me. If I were going in as a consultant we’d change some things just from this one paragraph.

Would be great if you could share your thoughts on this!

So, do you want to change to a monthly release cycle of the product?

Have you ever thought, Fixed-date and fixed-scope which is more suitable for you? 

Yes, I'd like to introduce monthly releases. Even if there are few minor fixed will do the release. We used Fixed-date-scope before but they did not work out well.

"Bunch of red flags here for me. If I were going in as a consultant we’d change some things just from this one paragraph. Would be great if you could share your thoughts on this!"

Well I am working right now with a customer here in Austin that had some "Agile Techniques" similar and dissimilar to what you are doing. Also, an IOS\Android Web Agency.

They were sort of half cocked like this struggling but getting there slowly. I had to go in and say “NO!” They were very open to changing what was broken.

I don’t know where they learned Agile, but it was bad. We are getting turned around will take time. The very 1st thing I focused on was team structure, sprint cadence, and then their release cycle.  Not a start from scratch but enough to improve upon. I could go on for days and if I were near you I would offer to come in and do an assessment for a free. Hard to tell what you really have going on here. To much guessing based on what you have written to give you a good answer.

Hi John,

Sorry, my English is not good. I made a very funny mistake.

I mean, have you ever considered fixed-date OR fixed-scope which release cycle is better for your team?

If the PRODUCT OWNER decides to continue releasing every month, he/she must spend more time dealing with the Product Backlog and proposing a clear Sprint Goal.

If there is a feature must use two months to complete, that is, 4 Sprint. It may not be a problem for fixed-scope. For the fixed-date release cycle, it does not make sense.

If this feature is not available to customers in a phased manner, it must be hidden at the time of release. But this loses the opportunity to get customer feedback as quickly as possible.

The PRODUCT OWNER needs to make a decision.

Hi , Sorry that I just catch the first story post. 

This situation, I see that PO need set Release Target for each 3 months. And if we break down the backlog items good enough and have cut line, we can see and deal with PO on these features can map with timeline or not. 

I heard that many teams use a special design that allows to "switch off" a not ready feature and include a part of it's code to the released build. More details on this would be appreciated.

I think you mean feature toggling/flipping. The idea is not so much to switch off work, but rather to limit its use to a targeted environment (e.g. restricted cohorts of users) so it can be validated under circumstances of controlled risk.

Thanks everyone for the replies. 

If we get a little more technical - how do you approach automation and manual testing? 

For instance if you have weekly releases - do you solely rely on automation or have your QA team run some tests on beta builds manually?

You use the automated test software to automate your test. If you are using Jenkins correctly every time you check in code a series of test are ran that either pass or fail. Manual tests are still used but to what extent depends on the organization. Who is running the show and how Agile are you. 

I really don't like the beta build mindset either who came up with that as a step? 

"Manual regression testing takes around 2 full days. Sometimes we work on huge features that takes around 2 months to implement (MVP version), how to deal with them? What would be our steps towards this goal?" This is sooooooo long. I guess if works for you great but there is great change needed here for you to be truly Agile.