Would Scrum work for us, even without fully automated CI?

Question

I am technical lead/architect of an internal product in my company. The team used to be 2 members initially including me, the other guy doing both software and hardware design. The customer (another internal team) of our product hired a candidate to work on our product which looked very unusual to me. It should be us who should be hiring to support them...

Recently, customers have heard of Scrum and are very eager to implement this starting in a week. Since their team member is working on our product, he nominated himself to be Scrum Master as he took a course recently. The hardware guy in our team nominated himself to be Product Owner.

To make it clear, there was no evaluation done to see if Scrum fits or not... All their argument was Scrum supports transparency. I am not against it, but I would like to see if it really fits or not. At the moment, we do daily catch-ups to see who is doing what and hold customer meetings every week. We have a release cycle of 2 weeks, but we don't have a fully automated continuous integration system (CI) yet. I take care of making builds and releases manually. It takes half a day for me at the moment including verification of releases. Although we do bits and pieces of Scrum, I am not convinced that we have to do Scrum...

As I understand, for Scrum to be effective, having CI is very much essential including running some integration testing... Is my understand correct?

How do the roles work in this case? Is the Scrum Master part of the customer team itself?

And what is my role in the case of a technical architect?

Answer 1

I see several points of concern, but, ironically, the one you seem most concerned with, I am not.

As I understand, for Scrum to be effective, having CI is very much essential including running some integration testing... Is my understand correct?

It's certainly helpful, but there's nothing in the Scrum Guide that says having continuous integration is necessary. If that were your only concern, I'd say 'Go for it.'

However.

The customer (another internal team) of our product hired a candidate to work on our product [...] he nominated himself to be Scrum Master.

(Opinions may differ, but), there's nothing inherently wrong with the Scrum Master(SM) being a developer. What is strange is for that developer to not be a part of a single Development Team. Having two Development Teams, one with 2 developers and one with one developer/SM, is not going to work. You'd need to consolidate into one Team, ideally with co-location. It's not 100% necessary to be co-located or for all members to work for the same company (or, 'internal team', in your case), but these assist in the Team viewing itself as a cohesive whole, which is necessary.

The hardware guy in our team nominated himself to be Product Owner

No. Unlike the Scrum Master, the Product Owner (PO) should not be a developer. The job of the PO is to represent the needs of the customer. The customer team should probably be providing a PO.

That being said, assuming you can work out those two issues (the 'customer developer' needs to be consolidated into your team, and you need a PO who is authorized by the customer team), I see no reason why you cannot at least attempt Scrum.

Don't forget to Scrum the Scrum - during the Retrospective, inspect the Scrum process and try to find ways to improve it - and, if there are none, then consider aborting.

After every sprint (sprint review), scrum says that demo the work and receive feedback. We mostly work on bugs and very rarely develop features [...] What feedback are we expecting from the customer?

Have a look at the "Dealing with 'undemonstratable' stuff" section of Scrum And XP from the Trenches. The gist is that if you can't demo something, then you can't even know if it's done (because how can you check if it's done?). Contraversely, if you have somehow verified that something is done, then you can demo it in the same way.

If we do Scrum, all the requirements should come from PO and no personal talk?

Scrum doesn't really say one way or the other. What worked well for me was talking to the PO 85% of the time, talking to both the PO and the customer 10% of the time, and talking to just the customer directly 5% of the time (and radiating the results to the PO). We had an exceptional PO who almost always fully understood the customers and was almost always available, though.

Answer 2

I think your understanding about CI is broadly correct. You can certainly do software Scrum without automation but you will not accelerate and you will not enjoy the benefits of Scrum (a hyper-performing team). Dedicate a percentage of effort towards creating the infrastructure you need while delivering product increments that deliver business value every Sprint. Map out the architecture you need then iterate towards it.

It's a similar situation with the Scrum roles. The people in your org who have self-selected the roles are OK but the Team will soon stagnate. The PO should be a business person. The SM should ideally be an experienced Scrum coach. The people in these roles will need to develop these skills or accept they are 'holding the place' for the eventual candidates.

I find these 'The Evolution of...' articles at Scrum.org extremely useful:

Evolution of the Product Owner

Evolution of the Scrum Master