Onboarding a new scrum member to support a massive, old, legacy data warehouse
I was recently hired into a new company as a Data Analyst for a BI group. The data warehouse that I was assigned to was created years ago and is a big kluge - a mishmash of tranforms, filters, and rules - mostly or all undocumented. In fact, it was so badly architected that the company eventually abandoned it and created a new dw, but they keep the old one running, and occasionally updated, for various reasons.
Most of the other people on the team I am on have supported the legacy warehouse for several years so they are used to working around its bad design and are intimately familiar with its million tiny secrets. I, however, am finding it very hard to come up to speed. The database is built on so much tribal knowledge, it's not very intuitive or self-teachable. While my teammates will answer my direct, specific questions, they are not inclined to proactively explain how things work, nor is there any time or tasks specifically for training or knowledge transfer. And it's a busy team, no one has a spare second between the ~25 hours of meetings a week and trying to get their own tasks done.
So I am trying to figure out what is "normal" for a well-established scrum team to do when a brand-new member is introduced. I should mention the department is recently converted to agile/scrum, about a year. I don't have a lot experience with scrum teams either (less than a year at another company, and the almost same exact situation occurred there as well). Surely I can't be expected to train myself on this Frankenstein's monster of a system, without training material, documentation or team support? Just curious how other individuals - and scrum teams - have dealt with a similar situation?
It's all about teamwork and self-organization in the face of change. If you are left out on a limb, it sounds as though the team (for whatever reason) does not self-organize appropriately.
Is there really a Scrum Development Team in this case, which is to say one without sub-roles? Or have you been hired by management to fill a "Data Analyst" skills-silo? When people occupy such silos, collaboration and a sense of team identity and joint purpose tend to suffer.
Julie,
It is unfortunate that your experiences so far with Scrum has been less than ideal. Often, organizations (and teams) will slap the Agile/Scrum label on without really changing anything, or truly following/embracing the Agile mindset / Scrum values.
Huge red flags to me are your comments about "tribal" knowledge, and the reluctance by others to share information that can benefit other team members. Agile promotes the practice of knowledge transfer and cross-training to the health-benefit of the organization.
And yet, that doesn't help you in your current situation, does it? What can you observe as Scrum practices and maturity within your team and the company? How is work discussed, created, and delivered? How do the team members work (collaborative, isolated)? What can you identify as changed or changing within the company (roles, practices)?
And why are team members attending up to 25 hours/week in meetings (giving only 15 hours/week for sprint work)? What meetings outside of the Scrum ceremonies are team members attending? Why are those meetings needed, and is there another way to "value" team member time by achieving the meeting goals another way?
Good luck.
Ian, thanks for the response. Everyone on the team has a specific title (scrum master, analyst, designer, developer, tester) and there is a department RACI (roles and responsibilities matrix) divided by job titles that is pretty dogmatically referenced by management as part of the overall structure. So yes, I guess you could say it's silo'd.
Another analyst hired about a year ago has had the same experience - she gets assigned and reassigned to existing teams and projects without any onboarding or orientation and is expected to contribute full tilt from day 1 like I have been. But in contrast, two new analysts started concurrently with the start of new projects and all-new teams, and their experience has been 180 degrees different.
I should mention that I've asked management for help. The first time, they apparently assigned an ETL developer to me to "teach me something". I say apparently and "teach me something" because they never told me what the plan was, or even that there *was* a plan, and then he quit a month later anyway. Then they assigned me to a senior analyst on a different team/different project who had worked on the legacy system before, and she wanted to help, but she was so busy I maybe got an hour of her time in a month.
Giving the department the benefit of the doubt, I'm not sure the team or management has enough experience in agile/scrum to know how to behave as a team when one person is way behind the learning curve from the others. Do you have any suggestions that I can pass on to the team? To management? Thanks in advance!
Timothy, thanks for the response. I feel like my team likes the scrum environment better than waterfall, but that there are so many people who are so new to it, they are doing a lot of things "wrong". When I first started, everyone was sent off to their little corners all day to do their tasks in isolation after morning stand-up, and I found it impossible to learn anything being so isolated. I voiced my difficulties with that approach, so they decided to do "design" sessions, which consists of hours and hours and hours of discussing possible design approaches, issues with data,etc.. But I always got a very strong sense that when I asked more general questions about the data or the data structure, that were having to "slow down" to answer my question, and then they moved rapidly back to what they were doing, at their level of understanding.
Several times recently, the rest of the team makes major redesign decisions while I'm not there, and it didn't even occur to them to tell me until I'm in another meeting and they are discussing the new design. Or they take my analysis, throw it in the trash, and do their own without telling me until they find a problem that I didn't find, and then point it out to me. Or they will do a design, that I wasn't a part of developing and haven't been trained on (e.g., Cognos and SAS environments which I haven't supported on the db side before), and expect me to transcribe it and convert it to Visio like a secretary.
The problem is, I have never worked in a healthy scrum environment, so I don't know how it should work better. Clearly, this is isn't working for me - I feel isolated and not at all valued.
The Scrum Master is the custodian of the Scrum Process, and is a coach to the team and the wider organization. In principle at least, that is the person you ought to approach. Also, are the teams holding effective Sprint Retrospectives which really dig into the matters you describe?