Software Development Team Organization Structures

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

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 *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)

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