Component Stewards
I’ve been an advocate of using feature teams instead of component teams for a long time. Back in the 1980s and 1990s, when I was working on embedded systems using 8-bit microprocessors, I often did both the hardware and software development. The easiest way I found to work was to develop both in parallel, adding complete functionality feature by feature. Working in this fashion also gave me great insight into choosing whether to implement a particular bit of logic in the hardware or software. Sometimes a software implementation could save a lot of expensive hardware, and other times a small bit of hardware could save a lot of software or provide better performance. Since I was working on both sides of the fence, I could easily move the logic from one to the other, sometimes changing my mind as I learned new information while implementing the functionality.
When working in larger teams, the work was usually split between hardware engineers and programmers. Occasionally I could influence a change in the hardware while working as a programmer, but not always. I really missed the ability to optimize across the hardware/software interface that I’d had when doing both sides.
When you scale up to large numbers of people working on a system, things can get out of hand, though. What happens when a lot of people make changes to the same components without talking with each other? Usually, the conceptual integrity goes out the window. So, what to do?
Bas Vodde and Craig Larman, in their book, Scaling Lean & Agile Development, advocate “a component guardian whose role is to teach others about the component ensur[ing] that the changes in it are skillful.” Where the issue is not just a fragile component but a heavily used one, I suggest you might want to go a half-step beyond a component guardian to a component steward.
Whereas a component guardian teaches people about the component and reviews changes, a component steward collaborates on changes. When a team needs to make changes to the component in question, the component steward would work with them on the change as though they were temporarily part of that team. This ensures both that the component design and the business needs are kept in mind for the change. Neither of these concerns should be sacrificed for the other.
A component steward could be a single person, but I would generally recommend a group of two or three. This raises your “truck number” and also provides multiple viewpoints to aid in keeping the component robust. There is generally more than one reasonable way of designing a component, and using multiple heads helps find more of those ways. Also, given that the issue being solved is that frequently multiple teams may need modifications to the component at the same time, having multiple people in the component steward role makes it easier to satisfy those needs. These people should, of course, talk with each other very frequently as they do this work. They may want to get together multiple times a day to coordinate their work.
Large scale software development is hard. It’s tempting to abandon the business focus for a technical focus that protects the code. This extracts a high price from the organization as a whole, though. With component stewards, you don’t have to make that sacrifice. There is, of course, additional overhead, but you should find that only a very few components really need such stewardship.
It’s also tempting to abandon the technical focus for the business focus. How many times have teams (or their management) knowingly taken on technical debt to “get something done”? How often has that debt been paid back?
Another way of managing this is to treat heavily used components as products in their own right. This means there’s a product owner who controls the direction. The control doesn’t need to be full blown, rigid change requests, approvals and so on. An open source style with teams making proposals, coding changes and issuing pull requests is lightweight and often works better.
This isn’t much different to your concept of component steward, except that I think it conveys the actual relationship more accurately. If the requester and owner don’t see eye to eye, the owner has the last word. The requester can always pursue the clone-and-own path, although this is almost always a smell (if not now then soon).
Hi George,
Originally we used the word “component steward”. However, the word steward isn’t well understood, especially for non-native English speakers, so then we chose to use guardian instead…
Thanks, Bas, I didn’t know that. I think there are a number of similar ways to handle the problems that exist when the organization gets larger.
George,
Thanks for posting your thoughts about component “stewards”. I tuned into this article from two points you made — embedded systems and stewardship.
Embedded systems was a big part of my background. I’ve seen functional groups being formed around equipment, platform and network processor code. With the agile transformation, specialists were spread across the teams but worked independently. “Stewardship” within the teams did not work that well. Mostly because the specialist was not skilled in teaching or letting other designers learn for themselves. The other reason was the large knowledge transfer that had to occur before someone could begin to understand the code. One solution that presented itself was to form a Community of Practice. In one particular case there was a lot of technical debt for the network processor code. The P.O. allowed developers from each team to voluntarily form this group to learn about this code area. The CoP first restored the automated test suite that was broken and also automated it to run as part of the CI system. With each bug found they shared their knowledge and worked together to fix them. This was without the help from the specialists who did not participate for various reasons. Eventually, some of these developers were able to deliver new features.
The second item in your article that caught my eye was stewardship. I learned this from the late Stephen Covey “7 Habits” book. As a coach, I find this a difficult skill to teach, especially to specialists. They usually don’t see the point of passing along their knowledge for a number of reasons. Loosing their specialty, someone else changing the code for the worse, architecture, etc.. The CoP worked well to circumvent this issue and the code actually improved beyond what the specialists were able to do historically.
Thanks for the comments, Bill. The stories you tell reinforce my recommendation for the steward to be more than one person. I’d love it if you could write more about your experiences with a Community of Practice approach. It would be valuable for others attempting something similar.
The Community of Practice around a particular subsystem was formed to create knowledge and expertise. All of the code for this module was developed off-shore and dropped into the local product repository. Requirements and design documents were available as well (very dry and inaccurate) The original off-shore developers were disbanded and went on to other product areas. So the local team was on their own to figure it out.
Two specialists in network processor code were the go-to designers for all feature and bug fixing in this module. It was a very large module and required a deep understanding of ethernet packet processing, IP, QoS and VLAN tagging. As indicated above the two specialists soon became overwhelmed with changes and could no longer keep up with the demands of maintaining this code.
Four scrum teams decided that they all needed to have the capacity to work within this module. Hence a proposal was sent to the PO to allow a selected group of volunteers to spend 4 hours per week on ramping up on the knowledge and meeting with each other. The approval was given.
I helped facilitate the first few meetings to get the vision and charter in place. We held a workshop and got a good response with a clear mandate for the CoP. They also set forward some of the first steps such as restoring the automation suite and fixing some glaring bugs. Initially things seemed to get off to a good start with their workshops in a common area so they could multi-pair program and demonstrate what they learned.
After a month or so, I dropped into one of these workshops and found that the junior volunteers had dropped out because of the technical complexity of it all. Also the two specialists dropped out because they felt they were not getting anything out of these workshop meetings. Likewise they had lost interest in being stewards. It all seemed to be going in the wrong direction than they had intended.
The CoP invited me to a special meeting to discuss how to get things up and running again. I brought in a a copy of their vision and goals from the first meeting. We reviewed it and the CoP decided it was still valid. Hence they created some new ways to work together and learn.
After three months of working on module bugs, the CoP got involved with their first feature. It was picked up by one team but shared within the CoP. The feature was almost completed within a few sprints but there were over 15 failing UTDD tests that needed to be fixed. The whole CoP banded together to fix the code and got the UTDD to pass within a short period of time.
The stewardship that occurred was not exclusive to one person but to the whole group working together to learn and share their knowledge. One thing that I observed is that developers learn in different ways. Some go to their desks and pour over everything and get right into the code (most of these kinds of learners gave up on the documentation because it was too much). Others need someone to guide them. And some worked together with others to learn. Each of these learning paths took place during the subsequent months.
Unfortunately the product line was cancelled and the teams/CoP’s were disbanded. But the experience was a good one to figure out how to ramp up a new knowledge area. In effect the CoP became their own stewards. There also needs to be a shift in the mentality of learning versus delivering something. Difficult mindset change for some because learning does not translate into producing something in their minds. I tried to coach this and help the team use short term goals to see their progress. This was also difficult to coach towards the PO who did not understand the nature of the learning required. Given all of the challenges the CoP still prevailed.