Running a software development project is complex and scaling it is even more difficult. Typically, scaling means multiple teams, roles and processes. In the worst scenario, ‘metawork’ such as meetings, coordination, handovers and over planning kills the development efficiency totally.
A common root cause is the wrong organisational structure. Often, organisations are based on specialised teams which are focused to deliver only one thing. A specialised team is also called a component team and is accountable, for example, for requirement analysis; front-end development; user experience; architecture design or deployment. This structure might feel rational, but the reality is different.
Problem makers
In the component-based organisation, the development process is slow, complicated and contains a lot of handovers. Typically, a new feature is created and planned by the requirement team. When the feature is written, the first development team (i.e. backend team) will implement the feature and assign it to the next development team (i.e. frontend team). When implementation is ready, the testing team will test the feature. Finally, after the feature is tested, the system team will deploy the feature to the production.
Features are rarely the same size and they often overlap. For this reason, some teams create queues and other teams become bottlenecks. This is the textbook example of the sub-optimisation that creates a lot of waste (i.e. partially ready features) and causes priority and resource fights. Multitasking is also very frequent in the component-based organisation.
A feature typically consists of multiple components which generate dependencies between component teams and make integration painful. The feature’s programming code is separated into different components and continuous integration turns into “delayed integration”. A typical pattern is to introduce a coordinator role, such as an integration manager, whose responsibility is to integrate parts together.
The feature ownership is also vague in the component-based organisation. Should the frontend team, database team or user experience team take on the responsibility of the feature? The solution is a new coordination role such as feature manager or product manager. The larger the project, the more coordinator roles are needed.
In the component-based organisation, every team knows only one part of the system. This reduces learning and makes the product vision unclear to team members. Component team’s “customers” are other component teams, not real end-users.
The end result is a waterfall development model where completing one feature can take from months to years. Agile practises on the team level won’t help because impediments are at the organisational level. Luckily, there is a solution available and it’s called the ‘feature-based organisation’.
Cross-functional and cross-component
In the feature-based organisation, teams are cross-functional and cross-component. Cross-functional means that the team completes end-to-end features independently. Typically, the team consists of developers, testers, system specialists and designers. Having said that, the individual team member does not need to know the whole system or have all the skills.
Teams are also not organised around specific components but can work on all modules. Components still exist, but they are not used as an organisational structure.
Dozens of benefits
The feature-based organisational benefits are clear. According to ‘Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum’, advantages include:
- increased value throughput–focus on delivering what the customer or market values most
- increased learning–individual and team learning increases because of broader responsibility and because of co-location with colleagues who are specialists in a variety of areas
- reduces the waste of underutilized people
- simplified planning–by giving a whole feature to the team, organising and planning becomes easier
- reduced waste of handoff–since the entire co-located feature team does all the work (analysis, design, code, test), handoff is reduced
- less waiting; faster cycle time–waiting is reduced because handoff is eliminated and because completing a customer feature does not have to wait for multiple parties each doing part of the work serially
- self-managing; improved cost and efficiency— The team has responsibility for end-to-end completion and for coordinating their work with others. Feature teams are less expensive–there isn’t the need for extra overhead such as extra managers and coordinators
- better code/design quality–multiple feature teams working on shared components create pressure to keep the code clean, formatted to standards, constantly refactored, and surrounded by unit tests.
- better motivation–research shows that if a team feels they have complete end-to-end responsibility, and the goal is customer-directed, then there is higher motivation and job satisfaction
- simple interface and module coordination— the feature team works across all components; no need for inter-team coordination.
- change is easier–changes in requirements or design are absorbed by one team; multi-team re-coordination and re-planning are not necessary.
Minor caution
There are a few boundaries in the feature-based organisation which must be tackled. The organisation could have special contracts with vendors, for example, infrastructure and development contracts are separated. Nevertheless, a feature-based organisation is possible, teams would just be a mixture of different vendors.
Team sizes might also be bigger in the feature-based organisation. Scrum guide recommends a team size of less than nine. Although, working with larger teams has much fewer side effects than working with component teams.
Keeping the quality consistent and how to share best practices are challenges in large projects. These risks can be reduced by creating communities or guilds with responsibilities for example, for architecture, user experience or testing. Communities or guilds are run by the team members and their communication and coordination is informal.
Sometimes the feature team lacks skills. A shared team member is a quick fix, but not the optimal solution. In the long term, the organisation must support the team e.g. with training, finding the best team-sets or hiring new people.
Culture follows the structure
The component-based organisation is based on the assumption that one person can only do one specific job. In contrast, an Agile mindset is based on learning, cooperation and the team’s self-managing abilities. Agile and the component-based organisation is a contradiction that cannot be resolved. The organisation must choose which road to take.
Graphic Design Ville Takala
References
Feature teams:
https://less.works/less/structure/feature-teams.html
http://www.craiglarman.com/content/feature-teams/feature-teams.htm
A Decade of Descaling with LeSS:
https://www.youtube.com/watch?v=kwpdeER1Jm8
The Scrum Guide:
https://www.scrumguides.org/scrum-guide.html
Further reading from the Gofore blog
Agile Transformation in Action – Part 1
Agile Transformation in Action – Part 2
What’s the point scaling Agile
We are always on the lookout for skilled developers to join our award-winning team. We have exciting projects running throughout 2018 in Helsinki and Tampere – get in touch to find out more
