As I said in the introduction, software assembly lines are very different from production assembly lines and the main differents is their orientation. Ultimatily, software development is an extreme act of collaboration, a project will succeed only because of the people working on the project and nothing else. That’s why our assembly line is completely build to support our people and not the other way around.
We do have high expectations of our people however, we expect them to be a self organizing team of craftsman in which every individual is equally empowered. We expect them to continuously improve, with collective ownership, both the deliverables of the project as the assembly line itself.
Does that mean that everyone has to be a superstar, master every aspect of the development life cycle, and there is no room for juniors or lesser gods? Well no obviously, but we do try to create a mix on the team of senior people with a T shape profile, in which people are specialised in one aspect but have adequate knowledge of the rest, an more junior people that are still specialising in a specific aspect.
The more senior people are also expected to take up a Manager-Teacher role in which they both drive the project in the good direction as actively teach all others on the team how the job is done properly. There are 4 of these roles in our teams:
Scrum master: The facilitator of the team, who makes sure all impediments are being taken care of, but also acts as a process coach for the rest of the team. (Not just the Scrum process, but also f.e. the customer’s governance model)
Product owner: The person who’s not only owner of the backlog, but whom also acts as a business expert and body of knowledge.
Coach: A technical expert with in-depth knowledge of the development platform, design and architecture. Who spents a significant amount of time coaching and teaching the other team members.
Guide: A functional testing expert who both provides continuous functional feedback on the work delivered as well as spreads the test-first mantra through the team and assists them in writing proper tests.
Ideally anyone on the team could pick up any of these roles, and could do any kind of work (analysis, design, coding, testing, politics…) but in the real world it doesn’t work like that. Therefore wel like to configure our team in such a way that for every role there are at least 2 candidates that could pick up the job in case the other falls ill (or similar).
But what is very important is that everyone on the team realises that there is always a better way, and that all members of the team are responsible to ensure that both the project as the assembly line are continuously being improved.
