Scrum on a Data Science project
Dear all,
I'm working as a Scrum Master in a Data Science project. The project consists of several specialized skill sets and people working on those like Data Modelers, Data Engineers, Big Data Architect, ETL Testers, Qlik Report Developers & Mashup Developers (we almost have a full team if we just have one each from the skillset!).
The challenge (as you can already sense from the above statement) that we have varied skills and specialized people to work on those areas, creating a lot of sylos. I have tried hard to facilitate in enabling them to be as cross-functional and self-managing as possible but considering the different technology backgrounds that each member/s represent, its hard to motivate them to take on each-others areas and help the cause of the team in any way forward possible.
Some of the team members were even willing to learn the other technologies and contribute cross-functionally but licensing restrictions on the different technology platforms came as a barrier. When we took this up with our Client, they came back saying that they have limited licenses (dedicated) across each technology platforms and they cannot be shared or extended to additional team members. Not sure what can be done further to that to help the cause of the team. Currently, it seems the team is following Scrum just to continue with the motions of the different events and not actually be a Scrum team.
Any suggestions to improve this state of affairs please? Thanks in advance!
It sounds like there is an enabling constraint. If team members are keen to collaborate and learn, why don't they pair together and swarm precisely because there are limits around the number of available licences?
I'm also wondering what project management platform that you're using? If it's JIRA - instead displaying the cards by epic - considering displaying the cards by assignee so it becomes apparent where resources is lacking. If A has 2 tickets and B has 6, A should volunteer to help, code review, or co-work in pairs any issue.
It sounds like there is an enabling constraint. If team members are keen to collaborate and learn, why don't they pair together and swarm precisely because there are limits around the number of available licences?
Thanks for your response Ian! The team members do swarm on several topics or challenges that they face from time to time. However, pair-programming has been a challenge with this team because the team started during the pandemic and almost all team members are geographically distributed. So the pair-programming happens with one person actually doing the work while sharing his/ her screen and others look the screen. Soon, they lost their interest as they just get to see the screen and provide inputs/ comments and not get to 'do' any hands-on.
As if the varied technologies with licensing restrictions was not enough of a problem, distributed team members add to the woes. I'm not sure how do I keep the team motivated in swarming up for work items in general and not just at times of a crisis.
I'm also wondering what project management platform that you're using? If it's JIRA - instead displaying the cards by epic - considering displaying the cards by assignee so it becomes apparent where resources is lacking. If A has 2 tickets and B has 6, A should volunteer to help, code review, or co-work in pairs any issue.
Thanks for your response Cythia! We currently have a pull-system in our Jira board where the team first, plan for Stories as per their capacity and second, pull Stories as and when they complete their current Story (it remains in unassigned category till then). Having said that, I agree with your point that having a visual radiator like a Kanban board do help in visualizing the bottlenecks that we have if someone working on a specific technology platform has a lot of work and would need some help.
Apologies to Cynthia for the mistake in typing the name in my earlier comment, couldn't edit the previous one.
I'm not sure how do I keep the team motivated
If licenses are not an enabling constraint, challenge them:
- those who issue them may know the price of everything and the value of nothing
- there appears to be a clear impact of this restriction on team performance and productivity
Remember that a Scrum Master has a low tolerance for organizational impediments.
So the pair-programming happens with one person actually doing the work while sharing his/ her screen and others look the screen.
This does not sound like the way I know pair programming. This is the opening statements from the Wikipedia article on pair programming.
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator,[1] reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
Even if both individuals do not know the languages/tools being used, I have used this method very successfully to help pass on knowledge. The Observer would be the one with little/no knowledge. They would read the problem statement and provide plain language directions. The Driver would then translate that into the code, explaining to the Observer how the code works. This allows the Observer to be involved in the solution and learn the language at the same time. At intervals, the two might swap positions with the original Driver still acting as a tutor in the language.
However, pair-programming has been a challenge with this team because the team started during the pandemic and almost all team members are geographically distributed.
That sounds like an excuse. Many companies have faced that challenge and succeeded. Even before the pandemic, when offshoring was starting up, I worked in these situations with success using remote conferencing tools. With the tools available today, it is even easier. As the Scrum Master, you can help the team to resolve this impediment.
My opinion is that your client has made it clear that they really don't care if you are trying to be more efficient by stating their position on the licenses. If they are going to knowingly restrict you, then you work within the confines you have. Not all impediments can be removed, so you end up working within the constraints to the best of your ability. You can still be a Scrum Team using the Scrum Events, artifacts, and values. Knowledge can be shared in other ways. But you may not realize all of the benefits and neither will your stakeholders.
Thanks a lot @Daniel Wilhite! This is really helpful and provided me with some guidance on how to move forward with my case!