Mythical Beasts or playing with team set-up in Scrum

As it happens, organising a group of people in product development so that they can actually get something done is rarely a simple task. At my last gig we had quite an interesting version of the dilemma and found solutions that might be of interest to some others as well. As this reorganisation was a major part of an agile transformation, the story is really a bit longer one, but I promise to try and make it worth your while.

When I started to think about how to describe the shaping of teams that we did, I first found inspiration in heraldry and particularly in the arms that one of Finland's eminent cybersecurity talents Lea of LAV Security uses, when playing in a bit different context. They show a tri-corporate ladybug i.e. a ladybug with three bodies sharing one head.?

The other arms above are those of Shoreditch, a borough of London. They were picked for the main charge, the crowned bi-corporate Lion, a curious and unusual beast. I found them apt to write these lines about Scrum and agile under as they have that delightful English tone (Shore's ditch as the name), a somewhat grand, (Shakespeare's Romeo and Juliet was performed here first before his troupe moved on to Southwark) turned shady history that later developed into a hipster phenomenon, and finally a motto nicking of - "More light, more power" - would be well justified by any agile transformation.?

Why these arms actually are here is because they lend themselves very nicely to highlight a pattern of team forming that I wished to showcase along some other key experiences from a recent story.

Story so far, what had happened...

The context here is a product development organisation about 20 strong. This organisation is responsible for the maintenance and development of their company’s single product which is of SaaS kind. At the time of this story the company had arrived at the conclusion that the product is in need of serious refactoring, maybe even what we in the industry lovingly call “refactoring with extreme prejudice”. As the product is in existence and serving the customers, the constraint and caveat of such action is of course the operations side, which cannot be neglected.

I was hired to this company and product development outfit as an agile coach / scrum master. I joined them at a time when they had decided to adopt Scrum and the related ways of working and were at the third or fourth sprint with most of the assorted roles still quite foggy. What I found was a set-up where there were nominally two “scrum” teams, one working on the backend of the system and another working on the frontend and design problems, two people developing the mobile app client, and some people doing tasks various and sundry. The product development organisation had three people in product management and then some additional personnel? who worked even less with the teams.

Lauri, the head of product management was painfully aware that things needed to change around there and he had already engaged with the work, but the process was surely not going to be easy. I got a hint of that on my starting morning when we first went over the situation together.

Some things to know and note before diving deeper

When playing with Scrum there are a couple of things that one should note from the old playbook. First is of course the fact that when we do Scrum, we play as a team. The rugby term was not chosen by accident and it reflects closely how the team should play together. The very definition of the word team is probably the thing that I always and again end up repeating to people. You likely know the one I’m referring to, the one that reads:

Team is a group of people that work together towards a shared and common goal.

I could add that “team” is also one of the most misunderstood and misused terms that I've met in my work. Most people seem to use it to refer to people who work around similar subjects and report to the same authority. Or maybe just report to the same authority. The problem from the agile coach's point of view is mostly getting the people in question to stop just working besides each other and getting them to share the work and responsibility with one another and fuse into working as an actual team. There are tricks to help with this, but most of them rely heavily on encouragement from the product management side.

Second thing is to concentrate on the produced value. When playing Scrum the first principle of agile manifesto must apply (What is our first priority...) and the team needs to organise around a product and the value it produces.

The latter is often difficult as in our complex world it is all too tempting to break the products down to their components and then give those components over to different teams to treat as their products. This is a problem because as we know, when products are created as social endeavours, the information flows of the system producing them are closely reflected by the information and value flows of the actual product. This phenomenon known as Conway's law enters the play rather easily and this in turn means that dividing the components amongst teams would generally be a premature architecture decision for a product developer.

Third is that there is a sweet spot when it comes to head count in teamwork. Scrum Guide is really diplomatic about this, telling that team size needs to fall between three and ten and like in sprint length, it is a bloody good idea to prefer the smaller size. Lauri, who had also seen quite a few agile implementations before the one we were in, was able to be less shy about this, and placed and pronounced the sweet spot at around five or six.

Final one is to understand the components of the framework used (Scrum or any other). Their roles and impacts in development and how altering them will affect the outcomes. This point is often neglected when people launch into the “that can never work here and we need to change it to make it our own” kind of thinking. True, the barely enough framework will always need additions and tweaks, but it can not be changed in just any manner.

Transformations or tell me what you want, what you really really want

In the design of any system there are design drivers, desires and constraints that should and do outline what is being done. In this case, we had a desire to change the development into agile mode and get the speed and quality outcomes it offers. At the time of my joining, there was also an articulated desire that what we do should be scrum. The clear constraints were that what we do should also be true to the culture that the surrounding company was building and that the legacy version of the system should not be neglected during the transition process. What we would guide the organisation towards should produce an energising and engaging working environment and minimise those effects that would encourage the development talents to seek careers outside the company. The less clear constraints were the adversities to change that some people harboured and the remnants of the previous command and control culture that were still bubbling under the later approaches.

In the field many people are familiar with the Scrum's product and team centric approaches. Figuring out how to scale them up is substantially rarer. These latter approaches produce easily siloed and sequential approaches that are far from desirable. With Lauri, we shared a clear idea that the cross functional feature team needed to be the basic unit. Fitting them together was the hard part. The organisation was on the small side for heavier scaling approaches as those would easily create an intolerable amount of overhead. This was a time to pour over the theory once more. SAFe offered a good amount of knowledge (being the great knowledgebase it is), but with our desire of being true to Scrum, LeSS had a lot more to give and the final key insight was readily available in the Scrum Guide's 2020 version. There at the third paragraph under the Scrum Team heading, one can find the following bit of wisdom:

If Scrum Teams become too large, they should consider reorganising into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

This bit provided the light bulb needed and became our load star in the reorganisation. It liberated us to consider the Product Organisation as a whole our primary scrum team and in order to make it a team of cohesive scrum teams, we "just" needed to reorganise inside it so that we had feature teams (teams doing fully working, customer value producing features).

I put those quotation marks around just in there as this reorganisation was anything but easy and we spent a lot of time in preparation. In the ideal scrum the developers are either truly full stack or have significant diversity along the crossbar of their t-shaped skill set. We didn't have that ideal situation. We had some backend developers who could handle that side of the tech stack and we had some front end developers capable of handling the other side of the stack. We had some quality assurance people oriented at the testing on the right, and after considerable head scratching we could identify two people that we felt? we could call full stack. We had exactly one developer who was responsible for the mobile client and then we had some people identifying as designers, but they came with various flavours (UX/ Product/ Service). We had OPS people, some of whom were great at handling the current infrastructure, and some of whom were wrestling with the new approach's infra as a code.

Additionally, the people here had two separate working contexts that were very disjointed. The existing version of the product and the upcoming next generation version of it. In practice this meant that some developers might drop from their team mid-sprint and just wander to the legacy code desert. The rumour was that they weren't too happy with their life there, but contact with them was sparse.

Map to the new world

20 people is a lot and at the same time with the specialisations we had, it wasn't quite enough for three cross-functional teams working in twoish (or two and a half) contexts of the customer facing product.?

While trying to figure out the division of the feature teams, I went for supporting structures. The major scaling frameworks have quite wholeheartedly embraced the communities of practice idea. Vodde and Larman had some further great guidance on how to use them, mostly that in communities like architecture community, the people from various teams can collaborate in drafting agreements that their teams can later choose to adopt regarding the matter. We decided to suggest and encourage such communities.

Another supporting structure was the idea of people shared by the teams. SAFe calls this shared services, LeSS being a bit more orthodox doesn't have it and might call it variously a concession to the old way or an outright cop out. Still, we had some people whose skills would be useful to the foreseeable feature teams and who would not be able to join them as 100% people. I myself was an example of such a person as the designated scrum master for the composite team and agile coach to the company as a whole. The infosec, quality assurance and service design leads were other prime candidates to work in such a context.

In our drafts try as we might we couldn't make the teams truly devops, so we settled for introducing the approach in the drafts and trying to provide as much of the ops through the shared service structure.

In the above image 1 we can see a depiction of one of our early drafts that shows the primary scrum context as a green circle and feature teams as blue circles. As we wished to be true to the Scrum’s ideas of work being done within the teams, the CoPs and Shared Services were intentionally placed on the sidelines. The OPS people were shown as a sidelined team of their own, reflecting the situation at the time.

The traveller approach discussed below can be seen in this version of one of our early drafts on the top right corner of the green holistic scrum team circle.

Walking the walk

While drafting the team structure, the hairiest problem we were wrestling with was the existing product context which presented a set of legacy code problems to those who were working with it. Over the full span of reorganisation a number of approaches were drafted. The best known approach to such a problem is to share the pain and rotate the duty of dealing with the legacy system. This had the problem that due to a recent turnover in the organisation there were only a few people who were familiar with the code base, and the others who would come to work with it would have to learn it.?

To tackle the problem we considered the Traveller guidance of the LeSS. In the traveller approach, a developer knowledgeable in a subject travels from one team to another and teaches the subject by working aside the team. This is a powerful model, but it can be quite a burden on the travelling developer who won't be able to enjoy the joys and comforts of a familiar and stable team around them.

The other approach we came up with was a bit more ruthless and we called it the "classic pen". In this model, we would bear a tax from the feature teams so that for each sprint they would need to send some of their developers as tribute to the legacy system. How these tributes would be chosen was left for the teams to decide and it would keep us from overburdening any developer with the legacy work.

In the above image 2 we can see a representation of our drafts showing the classic pen and the movement of developers from feature teams to pen and then back

With these ideas we were able to put together a few alternatives for reorganisation, but the decision between them felt anything but easy. Here again we got help from the Scrum, but that would have been impossible if we hadn't been in an organisation whose culture was also geared towards decentralised decision making. Even so the route was still so novel that it took an ally to give us the clue-by-four.

Scrum Guide's second paragraph says:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

In a session he had with us, Lare drew our attention to the latter part. Self-managing team should manage its own organisation. We decided to go that route (or really, Lauri as CTO decided. I just pitched the idea to him and gathered my jaw from the floor when he without moment's hesitation said yes) and presented our reorganisation drafts to the rest of the people as just that, drafts to serve as a starting point in the reorganisation effort.

Final stretch always feels like forever

The finalised drafts were introduced to the larger group with a set of accompanying information, and first discussion to be had about them was scheduled a few days after this. The ideas were introduced and I found myself time and again stressing that what we were looking at were merely drafts. Just how difficult it was for most people to believe this spoke volumes of the old organisational culture being replaced. They found it near impossible to believe that they were asked to actually participate in the decision making and that this wasn't merely a show and tell to take some nominal feedback before the decision would be hammered down from above. It took some repetition of the message on different occasions before the new reality started to really sink in, but once it happened we started to see very interesting developments.?

First was that some ideas like legacy responsibility with a traveller-developer was shot down with the developers telling us in no uncertain terms that this would screw the team cohesion badly and that they wouldn't have it. Another thing that was now possible was that the person who had fallen to the legacy developer position found a voice to say that he wanted to be part of the new product's effort as well. Both of these were extremely valid and welcome points and addressing them of course helped the people involved in believing that they indeed had power in the process.

Next we started seeing counter proposals. Could we organise ourselves into three teams instead? Where should the designers really be: In the teams, by product management or as a separate design team? There was also some push back: Why couldn't we keep the backend and frontend division in the teams as the backend was moving so much faster and better?

Many of the counter proposals had problems that had caused them to be put aside in the original sketches and with decisions that now needed to be reiterated. Many of us were very keen on particular ideas and had trouble putting them aside even when they didn't meet that much support. The doubts that the legacy system could not be looked after with the rotating people were difficult to address at this time. Some of the worries related to control being lost (or given to people other than those who used to have it) and some of the worries related to others gaining control over one's own work.

As the process of deciding on reorganisation dragged on, it took a toll on people. This was only natural as uncertainty about fundamentals of one's working life is understandably hard to bear and the new ideas such as the whole product development organisation being one team were not only new, but often quite alien to many.

We struggled hard to keep the process going, neither abandoning nor wrapping it up early.

There was a seemingly small victory that could be gained during the transition period and that was reorganising the sprint review. In the beginning each team had had its own sprint review with few outsiders attending. The demos would be repeated at later times for various audiences, but the real review was the team curling up on itself. This needed to change, so that’s what we did. We timed it as a common event, assumed (to a large part) the agenda proposed by Scrum Guide and went ahead, and that alone turned the needle up a lot. We were now looking at how our product sprinted, instead of how our teams sprinted. There were people from outside our immediate teams who were interested in what was going on, and we were addressing the work getting done at the right time. In retrospect, I think that this mattered hugely in the reorganisation as it illuminated the common context and started binding the developers better together.

When we were finally able to finish the decision making process regarding reorganisation, everyone was somewhat exhausted by it. Lauri and I wondered if it could have been achieved in a shorter time and with less damage. Should we have followed the company’s traditional model with the powers that be deciding and thus absorbing much of the pains of such a decision. I don't think so. I do believe that sharing the decision was exactly the right thing to do and painful as that process might have been, it created a much stronger foundation for the new cohesive team of teams to get on their way and some of the counter proposals provided ideas that ought to be re-evaluated as the organisation grows.

The Good, the Bad and the Ugly, or did it work?

What we ended up with in the end was a scrum team, within that we had two feature teams, a developer/designer pair working on the mobile app and the pen to contain the work with the existing legacy system where developers rotated into, and the separate ops team.

The image 3 shows the form of the team after the reorganisation.

My evaluation of how well this worked in practice is somewhat limited as my involvement with the organisation was cut short. The two and a half sprints that I did see, however, strongly suggest that the primary principles that we drove the reorganisation with were correct and fully functional, and there were a number of things where the outcomes exceeded our expectations even if we still had a couple of low points that seemed quite challenging.

The key success indicators here were:

• The feature teams pulling well together: In this time, their output seeming to my eye as improved and both teams developed identity having named themselves.
• The common planning activities were observed to discuss more of customer/user value than before. When a developer commented that we are now doing the right thing as we're finally discussing the customer value, I felt a great deal of relief and satisfaction.
• Teams making headway in tasking down the features and user stories they were doing.
• Relative ease of finding volunteers for our legacy pen and the people freshly dropped there being able to gain traction in the legacy work in record times. (There was a legend that it takes six months for a developer to do any good there, but the new volunteers got to the level of doing valuable contribution in less than two weeks.)
• The product development organisation was able to move into a shared planning that we adopted from the LeSS framework and increase the time allotted for how to implement part of sprint planning available for developers. The shared part allowed for customer and value centric understanding and the feature team's time for ascertaining sprint success.
• The growing intensity with which the developers were able to take part in the planning activities. In this they were supported by a move to describe the product backlog items increasingly as user stories with the acceptance criteria in the style of behaviour driven development. Both approaches were rather well received amongst the developers even if the testing tools in use were not the optimal ones for BDD.
• The communities of practice that we had decided to endorse were well embraced. The programming communities were providing cross team boundary cooperation from day one, the somewhat hidden design system community was blooming out for the rest of the people to see, and at the third sprint quality assurance community emerged into being as a natural development brought on by the practitioners.
• DevOps happened after all and it happened by a very developer centric move. One day the ops people had just decided that they wanted to take part in the feature teams' work and so both teams now had a regular ops person being a partial member. This can be explained in our context from many angles (e.g. shared developer, belonging to two teams), but what matters the most is that they wanted to do this, suggested it, and were welcomed by the rest of the feature teams’ people.

The stress factors or counter indicators:

• The throttle of development speed had to remain a bit lower than what many of us would have liked as the lacks in product backlog work were admittedly still not on par with the rest of the effort.
• The desire for a design team seemed like a very strong one, and I was wondering if the designers were going to fall back to that way or to grow into design leads of the scrum and feature teams. Challenges in making design work relevant and part of the development on the singular sprint’s level were evident, but in my view not fatal.

• The distributed product ownership between three people was a thing that continued to produce problems for the outfit. This presented itself as problems in communicating and formulating product vision and product goals and in great difficulties in doing shared design and planning in the team. From my perspective this was such an issue that I consider writing a follow-up to this article to study and discuss the problems of the three headed eagle.
• The amount of change was challenging for some people in the organisation. This was especially evident in cases where control and power needed to be yielded to the developers.

Looking at the events and developments it seemed to me like this organisation was now dedicated to going along in the agile way and would not easily revert back to the old waterfall follies even if they still have some struggles to overcome. What they had become was very much the kind of a team of teams that the Scrum 2020 and the scaling systems seek. The product, its users and their desires had become to be at the front and centre of the focus and effort and with all this I have to take the transformation and our reorganisation efforts that enabled it as success.

What comes next?

The bicorporate lion that I used as a metaphor for the new team structure is indeed not the only many bodied entity that the organisation can emulate and growing the number of constituent teams in the composite scrum team should be relatively easy. The many bodiedness of the team still needs to be carefully considered. Like with the lion and the ladybug, the bodies need to be joined at the head, not at the hip, and if our experiences with handling product management (as a latest example) indicated, manyheadedness is likely detrimental to the team's performance.

Increasing the body count, i.e. further division of constituent teams, would in this case likely allow a different and a bit more traditional way of handling the legacy work circulating it in the teams without breaking developers apart to a separate pen. This would likely increase team cohesion and further strengthen the capability that the people in the organisation have regarding working with the legacy system

Addition of teams will of course put more strain on those people on whom more than one team depend on. On ScrumMaster duties the obvious answer is to foster those capabilities within feature teams delegating them inwards and that is the likely course to be adopted here. On the product management side, the customer understanding would need to be strengthened within the teams, but with designers present this should not be too difficult.

So in summary, as the organisation grows, should it be happy with the path taken here it will likely continue by adding feature teams to its cohesive scrum team. From the efforts so far, it should have? learned the value of guidance that can be gained from Scrum Guide itself and the body of assorted scaling efforts like LeSS and SAFe, understanding that the things suggested in such bodies are tried measures that are likely to produce success. This being said, the pen approach should also have taught the organisation not to shy away from novel ideas developed in-house. With all this in mind I’d dare to say that this effort was a successful one and indeed produced lessons that could be useful to others outside the original context.

----------------------------------------------------------------------------------

An acknowledgement

Writing of this piece proved a bit larger undertaking and effort than I expected and I ended up getting a considerable gift of editing and proof reading help from Susanna Turkki, an English translator, computer scientist and dear friend. Her help and collaboration reminded me of how great it is to have such an opportunity when working on written material.

In case there is someone else in need of such services, please accept my recommendations and if wondering their worth, do note that this article is written by a somewhat dyslexic non-native language user.

----------------------------------------------------------------------------------

About the images used in the article:

• Desert tumbleweed picture is from a popular meme generation site (https://imgflip.com/memetemplate/106406967/desert-tumbleweed).
• The three headed eagle is from Wikimedia and can be found at https://upload.wikimedia.org/wikipedia/commons/f/fe/Triple_eagle_Alexey_Mikhailovich.png
• The Rider-Waite's Knight of Wands from Wikimedia: https://en.wikipedia.org/wiki/Knight_of_Wands#/media/File:Wands12.jpg