Is having a DataMart team and a Web front end team cross-functional?

There is worry that the web developers and the database developers will run into merging conflicts if they are working on separate teams.

Isn't this why you use source control systems? And this has been a problem of software development for decades.  In my opinion I don't see this as a valid excuse for making the teams less productive and taking longer to deliver value. 

You currently have a fantastic example of waterfall development. It even includes someone who is control of how teams operate and what they work on.  If you want to change this it will not be easy and is going to take some time.  Your organization will have to change to help cross functional teams successful.  Since you didn't mention anything about Scrum I am assuming that you are not attempting to use it. But Scrum is not a requirement to utilizing cross functional teams.  I have been in software development for over 30 years.  I have worked with a number of very successful cross functional teams in waterfall project management environments.  By using cross functional teams delivery is easier and more predictable.  In your scenario after the DB work is done and the UI teams starts there could be defects discovered that have to be repaired in order for the UI team to complete their work.  Or redesigns of either front end or DB could be discovered.  Both of those scenarios presents the need for teams to stop the work they are doing now, refocus on work that has been done in the past, fix the past, refocus on the previous work, etc....  Context switching is an expensive activity.  

You have tried to explain how it could work better to have cross functional teams.  Maybe you should try to show how cross functional teams can be less expensive. 

Yes, I work for a company with hundreds of thousands of employees who is about 18 months into an agile transformation and we are using SCRUM.  We were previously doing project management and waterfall methods.  There has been some talk of going to safe, but I don't think we're there yet and I'm unsure of the target.  I've also heard nexus come up.  I'm not sure if they know what scaled approach they wish to take at this point.  For now they just want to get all the teams on scrum agile to build a foundation.

There are all sorts of challenges in addition to the one I just described, but for this one in particular I'm hitting a wall.  Part of it is just because I don't know enough about devops and CI/CD to make a compelling argument that not only is this possible, but better.  I'm required to take 40 hours of training this year, so this is what I will be focusing on in the coming weeks.  I also bought a book on DevOps.

I advise that you start your journey with the Scrum Guide (https://scrumguides.org/scrum-guide.html).  It is free and is the true source for learning about Scrum.  Nexus is an extension of Scrum as it is described in the Scrum Guide.  SAFe uses some Scrum terminology but it is not Scrum as described in the guide. 

Read the Scrum Guide and learn the reasons for what is described.  Also remember that Scrum is not a methodology or process.  It is a framework within which many processes and practices can be used. Take some of the free assessments from the site to validate that you are learning as intended.  

Thanks, yes I am PSM1 certified since 2019.  I probably do need a refresher on the scrum guide, since it's been updated more recently, but I am familiar with it.

I can talk about how teams need to be cross-functional until I'm blue in the face, but it doesn't seem to be convincing the tech lead, or our manager.

For now they just want to get all the teams on scrum agile to build a foundation.

Who are "they"?

I can talk about how teams need to be cross-functional until I'm blue in the face, but it doesn't seem to be convincing the tech lead, or our manager.

What are "they" doing to create a sense of urgency for agile transformation, so you are not blue in the face, and organizational gravity is overcome? Have you a sponsor for agile change?

Hi Ian,

Thanks for your response.

"They" being the enterprise agile transformation group.  They brought in an executive leader and stood up an enterprise agile transformation team.  They publish our scrum agile guide and set all the agile standards, provide training, coaching, etc.

There is no shortage of info or training about what it means to be cross-functional, or concepts like INVEST, vertical slicing, etc. Everyone has had it at this point.  It just seems like they are resistant to this particular recommendation.

I also just want to point out that when comparing to the rest of the enterprise, we are ahead of the average in terms of maturity.  Overall the teams are doing quite well.  But this area in particular I've had some difficulty convincing of the value of making the teams more cross-functional to reduce the dependencies.

Brian - Do you have any evidence (i.e. metrics) to share with the leader? Team Happiness might be a good one. Number of dependencies? Cycle Time? Quality? Release frequency? Dan also suggested trying to quantify the cost of these impediments.

Why not suggest a trial to have teams run in vertical structures for a few Sprints and inspect and adapt? Give these teams the trust to self-organize into teams with all the right skills to minimize dependencies and have integrated Increment every Sprint. Use those metrics to decide if trends are better or not.

Regarding Scaling: The first rule of scaling is don't do it of you don't have to. Scaling adds overhead and extra meetings, yet are sometimes a necessary evil. If there are dependency issues between teams, and I'm assuming there are challenges and overhead integrating work between the front-end and database components so you have a Done Increment, then you're most likely correct that vertically sliced teams are the way to go. Integrated work at the end of the Sprint will be more transparent. Vertically sliced Scrum teams will also gain collective code ownership and more T shaped skills. The only benefit of your current structure (component teams) is a deep bench.

All the best!

Unfortunately, the Tech lead (And subsequently our manager)

"They" being the enterprise agile transformation group. 

Is your Tech Lead/manager part of the enterprise agile transformation group?  If not, you might find allies and support from that group for your efforts to try something new.  

They publish our scrum agile guide and set all the agile standards, provide training, coaching, etc.

This immediately indicates to me that your organization isn't using the Scrum framework.  I am not opposed to companies creating their own style of agile practices but it means that all of the learning and understanding you have of the Scrum Guide and framework might be unimportant to them.  Especially if they are already talking about introducing a scaling mechanism after 18 months unless there is specific data to support that it is needed.  

You might be fighting a battle that you have no way of winning or even making progress.  If I were in your situation, I'd be doing my best to get involved with the enterprise agile transformation group as a stakeholder and see if I could at least influence some of the decisions that are being made.  

Good luck and I'd be interested in hearing more of your trials and tribulations. If you are willing, look me up on LinkedIn.  I can live vicariously through you to gain more insights into how companies decide to work towards being agile. 

Chris,

These are all great suggestions.  Yes I have most of those metrics and sent an email showing some of them.  One thing I don't have is an easy way to track dependencies.  I'll have to think of a way on how I can better document them.  I just think that people are just creatures of habit and having siloed groups is all the organization knows.  It will probably take years to transform.  

I also agree that scaling doesn't make sense just for 2 teams, but there definitely needs to be periodic collaborations between them since they are working on the same app.  I just think that by reorganizing them to be more cross-functional would be very helpful in reducing the dependencies.

Daniel,

So the transformation group has designated a hierarchy of experts and agile champions to help drive the transformation across the organization.  My manager is actually the one designated to do this for our line of business.  I think overall he has been a very positive force for change, but not as much when it comes to this particular recommendation of making these teams more cross-functional.  I think he's just placing the trust in what the tech lead wants to do, which is keep the two teams separate.  So on one hand, he's trying not to interfere with the "how" of the team.  On the other, the tech lead is single-handedly dictating it.

As for the scrum framework, the guidelines they have put out actually align with the scrum guide quite well.  In fact, I was just in a call yesterday where an enterprise coach cited the changes in the 2020 guide and said we should be moving away from the 3 question format to a more open ended planning discussion that is still time boxed to 15 minutes.  So I don't believe it's really an issue with the transformation group so much as an an issue of my team wanting to cherry pick which parts of it they wish to use within my group.

I realize how safe sort of turns things on it's head when dealing with scrum, but it's also not really at the forefront of what the group is trying to accomplish at this point.  It's just talk so far. 

One thing I don't have is an easy way to track dependencies.  I'll have to think of a way on how I can better document them.  

Information radiators might help. One example is to highlight blocked Product Backlog items on a Kanban board, and note how many days the item has been blocked. This is where metrics such as cycle time, flow efficiency, and work item aging trends might help. Removing a blocker is one way to lower cycle time and increase flow.

You could also look into Value Stream Mapping and highlight some of the wait times caused by dependencies.

All the best,

Chris

Concerning:

In fact, I was just in a call yesterday where an enterprise coach cited the changes in the 2020 guide and said we should be moving away from the 3 question format to a more open ended planning discussion that is still time boxed to 15 minutes.

Brian, just keep in mind that the 2020 guide doesn't say that the 3 questions cannot be asked, neither for that matter did it say in the 2017 guide that it had to. The scrum team is free do establish whatever best works for them. So if the 3 questions was working for the team(s), there is no problem keeping it regardless of the 2020 guide dropping them as examples. If switching out of it is better especially as discovered through the retrospective, that is fine as well and empirically contributing to the self-managing and inspection and adaptation aspect of the team's maturity. So again, whatever works best for the team so long that focus is maintained on progress towards the sprint goal and planning for the next day within the 15 min cap.