How much does the organizational structure affect the successful delivery of software?
By org structure, I mean:
- Who makes scope decisions?
- Are QA and UX separate departments, or integrated in the development team? And so on.
My personal opinion, after years of consulting: it can make a huge difference.
What are your thoughts?
Latest comments (4)
I've worked in many organizations which run the gamut of little-to-no organization and very small teams to very large organizations with strictly defined roles and structure.
I'm a personal believer in agile, cross-functional teams comprised of a business owner (e.g. product owner) that manages the work content, a process manager (e.g. scrum manager) that manages the process, a QA lead and a development lead. These would be supplemented as needed and could also interface with other dedicated teams (e.g. systems admin, database, documentation, etc).
Each team should be limited to a reasonable number of people and have a limited scope based on a related feature set.
The teams should be short-lived and members would flow between the teams and their 'parent' functional area when each team is formed and disbanded. This keeps them grounded in their functional areas when off the team and fosters communication between development and the various business areas when the team is working.
Note that here I am using the term 'development' very loosely. This structure could be applied to many business processes.
In my experience, there are frequently tensions between a number of things:
The result of these tensions is usually a series of delivery pain points, caused by people focusing on the wrong thing (typically the thing they are measured on!) at the expense of others: even with cross-functional teams that can 'do everything', there can still be issues when money is required, business risk needs to be mitigated (arguable example: hello PCI-DSS, bye bye DevOps) or the paying customers need something across multiple teams (like single sign-on).
The effect of org structure on development even has a name, it's called Conway's Law. And I absolutely agree that this effect exists, here is an example...
Several years ago I was working in a team that did everything related to application integration. We supported the planning process of project leaders, we designed the architecture, we've built interfaces, we deployed them, and we also run the servers. So all the tools we've developed for ourselves could've been used from anyone on the team.
Unfortunately when DevOps became a thing some managers decided to do the opposite to my team and split developers and operators into separate teams, even separate departments. This resulted in chaos. Not only was it difficult for us to decide which of the existing tools and processes belonged to which department, but also everybody else in the company (our "customers") didn't know when to go to which department.
In the following years we could solve some of our internal problems by splitting tools & processes and specify exactly what dev has to deliver to ops. But we never could make it clear to our customers when to address which group, but that's another topic. Concerning your question: yes, after splitting the team, our tools started (and had to) represent this split.
I think understanding the differences between teams and workgroups is very important for success of a project or even feature. Different groups like coders, QA, and UX are all examples of workgroups. People that all do the same thing together. Mixing each of them together to form a team is the key to success, in my opinion. The team completes a task, and then returns the new knowledge to the various workgroups. Where I work, a team usually consists of UX, a coder or two, and a systems guy. Together they can accomplish a great deal in a short time, and each is responsible for their portion of QA.