Agile – Split skilled Scrum team

agiledevelopment-methodologiesproduct-ownerscrumscrum-master

A Scrum team has been forced together and is feeling very uncomfortable. They are constantly saying that it is not working for them and that they are fed up with hearing the words Agile and Scrum. They are feeling that the business if simply forcing a new buzz word on them.

They don't have any Agile experiance before this, including the Scrum master. Also, the team consists of a very disconnected skill set.

  • 1 manual tester
  • 1 .NET developer
  • 2 Cobol developers
  • A BA turned PO
  • The scrum master

The .NET dev doesn't want to learn Cobol and the Cobol devs don't want to learn .NET.

I've been asked to help out with making them more Agile, however, one of the main tennets of Agile is that the power for change must lie with those with the domain knowledge.

Kanban could help, but it wouldn't tackle the broken skill set.

Any advise on where to start?

Currently my plan is to start with the PO and see how stories are being written, but I am not sure where to go from there.

Best Answer

Embrace this... you see, Agile does NOT mean the proscribed ways of working are what you have to do. It means you get to decide what works for you and do exactly that.

Now I'm sure, given that advice, your team will become effective immediately with the Cobol guys doing their thing and communicating with the .NET guy who'll do his thing. Hopefully they'll be interested enough to pick up a few pointers to be able to find their way around the different technology, but it does not mean they all have to suddenly become multi-skilled and swap roles daily. It doesn't look to me that the skill stack is broken at all.

Make sure the team sits in a "black box" environment where external managers don't get to see what or how they do what they do. Just ensure the team is fed requirements and produces software regularly so said managers can see progress but otherwise leave them alone and let them get on with it however they choose. That is the core and true meaning of agile, regardless of whatever you've read in some Scrum bu****it manuals.

If you need some backup on this, get Alistair Cockburn's Crystal books - he part invented Agile, he know what its about. What I said above is advice taken from him.