Defining an organization structure - Azure Tutorial

- [Instructor] Defining an organization structure. There's two types of structures we're going to talk about, horizontal and vertical. The horizontal structure is the traditional structure you find in most teams. Horizontal teams are not optimized for delivering value, but rather, on just delivering something, and that something might not actually be what the users need. So it's of no value to the users. It's common in over half the features that teams build are rarely if ever used, and that makes for some terrible ROI. Horizontal teams that focus on specific areas of the application like UI or SOA, tend to work independent of other teams. For example, the UI and SOA teams are not working together to delivery some value, but rather, they each work on something that meets the demand being asked of the team: output over value. Teams that are working in silos on a specific layer of functionality, eventually must integrate with other teams. So that output delivered by the UI team, now that must be integrated with the SOA team and hope that it all works as expected. Does this sound familiar? If so it's happening like this in many organizations today. Wasted time waiting on others. How many times have you completed some functionality only to be told you must wait for the other team to finish their functionality before you can continue. So what teams tend to do is to start on the next thing and start to move away from what they just completed. Then they must go back and integrate, which is much more difficult to do. There's a false sense of project status. The teams independently feel that if they are on schedule, the project must be going well. So each team builds their functionality and feels they're doing well, and the project's on track, everyone's happy, right? Well, now they must integrate, and integration is difficult. And that's when the real status comes to light. The project is way off track, and now in danger of missing deadlines. This has a ripple effect across the whole organization. Vertical structure. The vertical structure spans the architecture. It's a cross cut, and the focus of the organization is not just outputs, but achieving outcomes. To deliver as much value as possible, we want to organize teams by outcomes so that they can focus on continuous delivery of value. Strive for cross functional feature teams to form teams vertically that cut through all the layers of the project so they can deliver value in every sprint. Break down work differently. Rather than all larger all encompassing user stories, build a book buying database for example, we should be creating smaller well-defined user stories. Stories such as building the add to car functionality, build the remove from car functionality, and then focus on the checkout process in the following sprint. User story teams work on should be independent and testable on their own. They should deliver value to the end user and be able to be tested by the end user. For example, the database may not be independent, but rather depended on the other pieces of the application under the SOA tier, or even the UI team. Vertical teams are cross functional teams and self contained. And everyone that's needed for the team is on that team. So if there are any dependencies between UI or SOA and database, the team would have team members with those skills. Ideally the team would work out of the same room, same team room, so that they are accessible and available to other team members. Coordination is the name of the game. It needs to be done every day. This may be a standup every day, or it may just be throughout the day we talk as needed. The important thing is, is that the team members should be communicating and in sync with each other all the time.