1. Software Development Team Organization Structures A Framework for project based companies seeking self organizing teams USC SOFTWARE ENGINEERING 577B Presenter: Stewart Allen

2. Abstract What is the research about? Organizational methods to help a small (25 person) Agile team keep up with the demands of increasing project needs Overlapping theme with Application Lifecycle Management (ALM)

3. Purpose Why was the research done? Conway’s Law (1968) – “organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.” “The structure of a software system reflects the structure of the organization that built it”. – Ray Valdes interpreting Conway’s Law

4. Purpose Why was the research done? Our team is growing and needs to adjust accordingly If we grow, we need to understand, why do large organizations struggle/fail in our industry? Siemens just left this sector a few months ago Honeywell and IBM both failed 10-15 years ago No Large corporation exists anymore in our business Large organizations cannot react to changing client needs fast enough. The customization and client care required in our industry is too much for them. Why is it important? As we grow our setup is not sustainable. However, we also need to understand that to stay competitive and deliver quality software, we cannot organize ourselves out of our niche in the industry and end up like the Honeywell, IBM, Siemens.

5. Research Methodology What did I do and How? Researched what others are doing in the industry Researched tools that may help us Interviewed members of large teams at Kimley-Horn

6. Information Sources Karhatsu, Henri; Ikonen, Marko; Kettunen, Petri; Fagerholm, Fabian; Abrahamsson, Pekka. “Building Blocks for Self-Organizing Software Development Teams: A Framework Model and Empirical Pilot Study”, University of Helsinki, Finland, Department of Computer Science http://blogs.gartner.com/ray_valdes/2008/09/19/organizational- structure-vs-product-architecture-which-one-wins/ Thomas, Joseph C.; “Organizational Structure for Innovative Software Development”, Regent University Center for Leadership Studies, September 20, 2002. http://www.martinfowler.com/articles/newMethodology.html Matthew Mayer, Kimley-Horn and Associates, Inc., Interview, 2013 Alexandar Mitrovic, Kimley-Horn and Associates, Inc., Interview, 2013 Seth Searle, Kimley-Horn and Associates, Inc., Interview, 2013

7. Decision Matrix What combination should I select? Your Weighted Decision Options ABCD Decision making factors Weighting Score Cost 2 Fits with the culture 4 Staff growth opportunities 5 Makes us better 5 *Options are combinations of (Tool, Organization Chart)

8. Current Organization Chart Consulting Firm Structure Strengths Very much a consulting growth chart Weaknesses Difficult to get each “team” to follow CSCI 577 best practices

9. Organization Option 1 Large Software Company Organization Chart Strengths Great for ALM, and process assurance Great for LARGE organizations managing many clients Weaknesses Not the best structure for staff growth in consulting Perhaps overkill for small to mid size organizations Bad for project based teams (slow moving giant)

10. Organization Option 2 Hybrid Approach Supports growth opportunities for staff into consulting Great for project teams

11. Tool Option 1 Current Tool Configuration Enterprise Architect for UML OnTime for Requirements Microsoft Excel and Word for Test Procedures Microsoft Team Foundation Server as source repository Strengths It’s familiar Each tool independently does a great job at a task Weakness Non Integrated Approach makes enforcement of process more challenging Must go to many places to do a job

12. Tool Option 2 Proposed Tool Setup Microsoft Team Foundation Server (TFS) UML Requirements Management Bug Tracking Test Case Tracking Automated Test integration Source Repository SharePoint Integration Microsoft Project and Excel Integration Strengths Familiar: We currently use TFS as our source repository (Best in my opinion) We use Microsoft Visual Studio IDE, so fully integrated approach Integrated approach makes management and enforcement easier Work flow enforcement policies for commits, etc. Easier to teach others the steps Export to Microsoft Project will help team planning and organization Weakness Cost: Upgrade required to get these extras All in one typically means some features are not the best in industry For Example: Enterprise Architect is better than Microsoft for UML

13. Research Results Option A – (Hybrid Org, Non Integrated ALM) Option B – (Hybrid Org, Integrated ALM) Option C – (Large Org, Non Integrated ALM) Option D – (Large Org, Integrated ALM) What combination should I select? Your Weighted Decision 1181149081 Options ABCD Decision making factors Weighting Score Cost 2 103 3 Fits with the culture 4 7755 Staff growth opportunities 5 8844 Makes us better 5 6867

14. Recommendations Option A was the winner. However, within the last week we received funding to move forward and purchase the upgrade to Microsoft Team Foundation and Visual Studio. So Option B wins as the cost driver was removed Now we need to discuss organizing teams that resemble CSCI 577, and not a consulting firm

15. CSCI 577 Take Away/Benefit In Industry, the culture often dictates the level of compliance, and the variations on the 577 teachings Which process to apply How much process to apply Organizing your teams and artifact generation so that you can succeed is important (my focus here today) If you want to get the attention of upper management use 577 logic to make your arguments in favor of change Risk is introduced without these steps. Risk is universally understood.

16. Questions