Cross-functionality: where it all began
It was 2011 when the multinational company Ericsson decided to introduce Scrum Teams in the R&D organization, and R&D Germany became part of this pilot. It was quite a ‘bold’ step, as so far many companies had introduced Scrum up to a certain extent, but not many multinationals were so far looking into Scrum and Scrum at scale. As a member of the development department, and in my role as Senior SW Developer, I joined one of the first Scrum teams at Ericsson R&D Aachen.
Until this point in time, we had a department writing the software, architects writing the specifications, a huge tester department running the tests, quality coordinators responsible for the quality of the products, and technical writers taking care of the documentation. All of a sudden, all these responsibilities and many more lay on the SCRUM Teams! We were supposed to commit to common goals in a self-organized modus…with a cross-functional way of working. To make matters worse, the code ownership was distributed: there were no more software blocks owners, but any Scrum team could access any of the 2000 software blocks of our products. We were absolutely convinced this could never, ever work!
But it did. For the first, everybody in the Scrum team stuck to their turf: software engineers were developing following the specifications written by the architects while testers were testing the code…all within the Scrum team. The daily Scrum was a wild mixture of information on the different responsibilities, until little by little the synergies began to arise.
First steps towards cross-functionality
First of all, there were tasks which had been done so far by specialists outside the team, like quality and documentation: these activities were lying around on the Team board waiting for a ‘volunteer’, and we, the Scrum team, accepted our responsibility. Some of the Scrum team members began taking care of those ‘tasks’ none of us had any expertise in. By pairing with the specialists we managed to get the knowledge needed in order to complete the required work, growing some skills we did not have before. To be very honest, for most of the cases, the Scrum team members did not enjoy doing ‘other things’ outside their own turf, but we had understood the responsibility we had as a Scrum team to complete our work, with ‘everything’ and ‘everybody’ involved. The basis for cross-functionality in the Scrum team was in place.
Next big step ahead was to spread the cross-functionality within the Scrum team to the different areas of knowledge of each Scrum team member: the most obvious need was quickly identified! We observed quite a few bottlenecks for verification and testing, which made us realize that if we wanted to increase the speed of delivery and the effectiveness of our team, we needed to move on! Could really software engineers take care of testing, and even testers write the software?
Cross-functionality: we made it happen
We, the software developers in the Scrum team, began looking into the testing environment, learning the functionality of the testing tools, cloning the testing repository, and pairing with senior testers to understand the verification processes. After several sprints, we as a Scrum team were able to ‘break through’ the bottleneck, and our workflow became smooth: by software engineers taking care of some of the tests our reliability and speed as a Scrum team increased. And yes, we were even enjoying working in different areas and trying out other responsibilities. I later learned that this was called ‘t-shape.’
Challenges: What are problems of cross-functional working?
As a business agility consultant is part of my job, and the one I really enjoy, to bring these experiences to our clients: it is always a beautiful challenge to create out of a bunch of specialists who are working shoulder to shoulder, a cross-functional Scrum team.
I hear quite a few reasons why cross-functionality should not be applicable:
- sometimes it is a skills issue (“we don’t know how to do it”)
- sometimes it is a process issue (“we don’t have access rights”)
- sometimes it is a management issue (“resources should be allocated and distributed efficiently for their main skills”)
- and sometimes it is even a contract issue (“what do we do if the testers and developers have different salaries?”).
At the very end, with very few exceptions, it is all about mindset.
For sure, there might be cases where some activities require very special skills which only concrete members of the Scrum teams have: these can be the case where sensitive data is involved, legal regulations apply, or very specific knowledge. We did have a customer where the development of algorithms could only be done by mathematicians, or some documents could only be signed by the colleagues with a lawyer degree. But experience shows that those cases are not necessarily the wide majority.
Replies to This Discussion