Software Development Team Organization StructuresA Framework for project based companies seeking self organizing teams

U S C S O F T WA R E E N G I N E E R I N G 5 7 7 B

Presenter: Stewart Allen

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)

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

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.

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

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

Decision MatrixWhat combination should I select?

Your Weighted Decision

Options A B C D

Decision making factors Weighting Score Score Score Score

Cost 2

Fits with the culture 4

Staff growth opportunities 5

Makes us better 5

*Options are combinations of (Tool, Organization Chart)

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

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)

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

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

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

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

118 114 90 81

Options A B C D

Decision making factors Weighting Score Score Score Score

Cost 2 10 3 10 3

Fits with the culture 4 7 7 5 5

Staff growth opportunities 5 8 8 4 4

Makes us better 5 6 8 6 7

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

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.

Questions