Split skilled Scrum team

Question

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.

Did those who decided on using Scrum consider the cross-training technology issue? Do they even want it? — JeffO, Dec 09 '13 at 18:34
Those that decided are in an ivory tower, hence the team's feeling that this is being forced on them. In this particular case, I think I agree with them. I think I have a multi faceted problem on my hands, not just the implementation but Agile now has a bad rep for the team. I need to think of good starting points in order to get some movement. — BanksySan, Dec 09 '13 at 19:02
@BanksySan What makes you think that you are not just forcing a new buzz word on them? — TheCatWhisperer, Jul 28 '17 at 18:16
@TheCatWhisperer That may have been the case, and I suspect it was, but it wasn't my doing. — BanksySan, Jul 28 '17 at 18:21
Can you say enough about the project to tell us why there are COBOL and .Net devs on the same team? Seems like an awfully strange stack. Are they actually working on the same project? — RubberDuck, Jul 29 '17 at 10:46

score 13 · Answer 1 · answered Dec 09 '13 at 12:43

13

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.

answered Dec 09 '13 at 12:43

gbjbaanb

48,354
6
102
172

2

I have told them that their only obligation is to provide the business with a product and sundries (like updates, demos, etc. on the progress) and to make the best product they can. How they go about doing that is totally within their control and if the business is supporting Agile development, then they need to support that as well. What I need now are some non-theoretical tools they can use so that they don't feel like they are being shoe-horned into something they aren't comfortable with. – BanksySan Dec 09 '13 at 13:13
1

I like the "black box" analology. – JeffO Dec 09 '13 at 18:15
Oh dear, [Alistair Cockburn's Crystal Methodologies](http://alistair.cockburn.us/) is busted! – BanksySan Dec 09 '13 at 19:05
Let's hope he's agile in fixing it... – Marjan Venema Dec 09 '13 at 19:08
no, [its back](http://alistair.cockburn.us/Shu+Ha+Ri) – gbjbaanb Dec 10 '13 at 11:23

score 4 · Answer 2 · answered Dec 09 '13 at 12:40

To understand how to approach the problem you need to first understand from your superiors what the ultimate business goal is for having a cross functional Agile/Scrum team. Once you know that and understand the business perspective as well as understand the culture of the company and the goals of the individual members of the team can you begin to address the concern.

Cross functional skill sets among a team is a desired goal however hiring a new team isn't a good option. Even if you could find a number of .NET/Cobol developers who are experts in both technologies then they would be expensive and rare.

The best option is to invest in training your team. Depending on the culture of the business and your region this may also be an unattractive option to the business if typically in your area developers have a short tenure and are constantly hopping jobs. With the stated goal however of a cross functional team with such wildly disparate technology stacks needed for the following project, it is unfortunately the only way given the absolute that the team must be fully Cross Functional Agile.

When estimating user stories, let it be known that any given user story may be assigned to any given technical resource and that if a Cobol developer is given a primarily .NET user story that a .NET developer is obliged to provide guidance and direction to the Cobol developer. It might be a 1 point story for the .NET dev but a 3 point story for the Cobol dev. It is important to keep in mind that there are more Cobol devs than .NET devs so the .NET developer will have less available time for guidance and training making .NET tasks much more expensive. Pair programming is a useful tool while doing this so encourage this.

The advantages are that this investment in your team will result in them being more cross functional to where this is no longer an issue. The big caveat however is that user story estimation possibly being dependent on one or more people it will make various project management metrics meaningless for a while. It will be harder to evaluate an individuals contribution to a project if it seems like they aren't producing much but perhaps they are learning a great deal along the way.

On a side note, you mentioned the team has a Scrum Master but that you are called in to do this? In a typical Scrum team this kind of task is exactly the role of the Scrum Master.

Thanks for the advice, I've been asked to provide some training as I have a fair bit of experience of Agile, unfortunately this company is just starting it. The main problem is that the .NET and Cobal devs don't want to work on each other's technologies. They have their specialisations and they want to keep that up. I'll be telling then that if Scrum is forced on them, then it's not Scrum, but I really need some real solutions to the problem rather then saying "Tough, you are now all Cobol, .NET and Testers". — BanksySan, Dec 09 '13 at 13:10
@BanksySan This is one of those problems that have only a few possible answers, and each of those answers have a significant drawback to one or more parties. The business that wants Cross Functional Agile /Scrum, and the team that does not want to be cross functional. Because they want to be Agile then you have the opportunity to present them different options and find out a compromise that works for both business and the team. We can't give you a solution because we don't know what compromise is tenable in your situation. The only thing we can do is show you a number of different options. — maple_shaft, Dec 09 '13 at 13:49
Why would a .Net dev want to learn COBOL? It is not exactly a highly demanded skillset. It is not reasonable to ask a .Net dev to learn COBOL unless you are paying well above the market rate. — TheCatWhisperer, Jul 28 '17 at 18:23

score 3 · Answer 3 · edited Jun 16 '20 at 10:01

I just want to say that people generally feel "forced" into Scrum when Scrum isn't being done properly. Common mistakes are:

A "Scrum Master" that's really a PM. The Scrum Master is a passive role. His or her job is to remove impediments from the team's path and make sure the team adheres to the ceremony of Scrum (Sprint Planning, Dailies, Sprint Review and Retrospective). That's it. The development teams decides what they're going to work on and how they're going to get it done. If the Scrum Master is assigning tasks or dictating work to be done, you're doing it wrong, and your development team is going to think this whole Scrum thing sucks.
The dailies should be engaging and short. Nothing will kill development team morale quicker than the oft-recommended Three Questions: What did you do today?, What are you doing tomorrow? Do you have any impediments. To which you'll almost invariably get the following responses: incoherent babble, what they think you want to hear, and "No".

Instead, pull up your sprint board and go through the PBIs one by one. Ask things like "Did anyone do any work on this PBI?" If so, then "What did you do?" and "How far along is that task? Can it be moved to done or how much effort do you think is left?". Finally, "Is there anything hindering us from getting this done?". This is sort of a variation on the Three Questions, but it's better in two ways: it's non-confrontational and it engages the whole team, not just a single individual. It's about what has the team done, not what have you done. The dailies are just to get an idea of how the sprint is progressing and to catch problems early if there are any. That's it. You want to get in and get out.
Sprints aren't based on velocity, or velocity is played with in order to fit the work the PO wants done. This one is always shocking to me and it's far more common than one would imagine. Velocity is a measure of what the team can accomplish in any given sprint. As such, the only time it should ever change is if there's reduced hours due to holidays or time off or if you hire or lose a team member. In other words, it should only change when the actual capacity of your team changes. After three to four good sprints, you should have honed in on your velocity and it should be pretty well consistent sprint to sprint. If your velocity is all over the place, you're either estimating wrong, trying to do more work than the team can handle, or both. The result either way will be diminished team morale, as they'll either feel like they failed or they'll be overworked and potentially burned out. Sprints should be easy and natural. Once a team gets in the flow, can estimate accurately, and knows their velocity, it should feel like you have just the right amount of time to do the work in the sprint. No one is bored and no one feels overworked or stressed about getting stuff done.
Making commitments instead of forecasts. Originally Scrum talked about the work being done as part of a sprint as "commitments", but later, revised the language to "forecasts". That was done for very good reason as the connotation of each word is vastly different. If you miss a commitment you failed. If you miss a forecast, you just try to do better next time. When the team embarks on a sprint, there's every intention to get everything done by the end of the sprint, but then life rears its ugly head. Things happen, and both the Scrum team and stakeholders need to understand that. If the team doesn't get all the PBIs done in a sprint, you should discuss that in the retrospective, but it's not a big deal. Missing your target actually helps you better gauge your capabilities and set a more accurate target the next time. Punishing your development team is only going to kill whatever morale you might have left.

Split skilled Scrum team

3 Answers3